6

I work for a large organization (thousands of employees + maybe tens of thousands of external users that have partial access to a fraction of internal information) and many of these people authenticate using username/password (which expires regularly).

However, most of these people (for employees is certain regardless if they typically work on Windows, Linux or iOS) are provided with an Active Directory account (internal e-mail address) and AFAIK all of our systems allow signing in using ADFS / Active Directory/LDAP Identity Provider.

Even for those external users that have very limited access (e.g. for some reports) we can implement a solution using a major identity provider (e.g. Google Identity provider), if ADFS is not allowed.

Having usernames/password creates a burden for the users and many are using Excel files and e-mails to store them which poses a security risk. Also, I have heard of user sharing, so one cannot possibly know who actually used a certain user.

So, by exclusively using only Windows credentials and maybe some other identity provider, the user has to take care only of one pair of credentials when dealing with all company's systems. Also, credentials sharing will disappear.

Question: Are there any objective reasons to use dedicated user/password instead of identity providers within a large organization?

  • 1
    Why do you not count Active Directory as an idendity provider, which it is? – Marcel Jul 12 '18 at 6:11
  • @Marcel - not clear what you mean, but I have explicitly added LDAP. Anyway, the question deals with possible reasons why there are so many user/passwords lurking around. Where I work, there are systems (e.g. data warehouse) that have virtually tens of thousands of user/pass pairs and this seems like a terrible headache for the users (some power users have hundreds of credentials and all expire after a while). – Alexei Jul 12 '18 at 6:20
  • 1
    Most orgs have non-federated authentication because of cost and implementation challenges – schroeder Jul 12 '18 at 10:36
3
+100

For most organizations, a comprehensive unified identity system is a positive thing. You asked if there are any reasons not to do this. I'll list a few which may or may not be valid in different organizations:

  1. The system does not support the identity provider. You may have a legacy terminal-based mainframe system that it is not easy to link to AD. There are many commercial products to link legacy products to identity systems, although these can be costly. Alternatively, you may have cloud-based systems (like Salesforce) that you struggle to integrate with.

  2. The system is sensitive and you don't want to expose it in case of a breach of the identity system. This may be valid for a small number of highly sensitive systems, although this argument is over-used in enterprise environments. If your identity provider is AD, a breach of AD is likely to mean a breach of all the workstations that people would user to administer these systems, so separation is little more than security theatre.

  3. The identity provider is not accessible from the system. A common example is Internet-facing systems in a DMZ that are blocked by a firewall from accessing the internal AD. I've seen large organizations that create a separate AD for DMZ systems. A similar issue can occur with development vs production systems.

  4. Some users are not part of the identity provider. The classic example is where you have a few external users accessing an internal system. You can deal with this by having the system support multiple authentication methods, or allowing the external users to be in your identity provider, with appropriate restrictions.

Whether the difficulties of integrating a system with the identity provider are worth the benefits is a balancing act. Most IT admins accept that managing a horde of credentials is part of the job.

3

First of all, Active Directory is a proprietary protocol that may not be the simplest to use outside of Windows world. For that reason it is common to have at least 2 authentications, one for the Windows world one for other systems (commonly Unix/Linux). This can be made almost transparent for users provided one of the authentication provider is synchronized on the other one.

This can normally solve most of the authentication needs. What can still remain are:

  • proprietary software that insist in having their own private authentication system. It it still more common than we could wish...
  • low level system accounts (ex: root on an Unix system, or dba account on a database). While normal user accounts can be given privileges or the ability to gain them via sudo, it is common to allow low level local administrative access for when things go wrong. But it should not be a concern for standard users.
  • dev accounts. In the development phase, an application may not be plugged on the main authentication providers. So developpers and testers have to use dedicated accounts.

This is for acceptable use cases. But there is still another category: settling a SSO system has a cost in terms of time and money. Some organization may choose not to go there because they think it is not worth it or sometimes because they are not aware of the possible gain. Only in that latter use case, you could suggest your direct manager that it would be very interesting, but you will have to find real use case where it would save time or prevent errors. Everybody does it may not be enough to convince a big boss...

  • Active Directory is based on Kerberos authentication, which is a standard that Unix supports. Linux systems can either configure SSSD (easiest), install a client like Centrify (licensing fee), or configure keytab files manually as needed (tedious). Newer releases should include SSSD, e.g., RHEL7. – DoubleD Jul 12 '18 at 14:39
  • @DoubleD: I know it. But I once had to administer a IMAP/POP/SMTP mail server running FreeBSD and thunderbird/OutlookExpress/webmail clients, not speaking of dev/admin accounts directly using CLI mail or whatever from Linux or Unix systems, I had not even tried to make all that AD/Kerberos compatible... – Serge Ballesta Jul 12 '18 at 15:01
  • FreeBSD runs SSSD now, so that would be the best approach today. Depending on when you set it up originally... it was extremely painful in the past. – DoubleD Jul 12 '18 at 16:41
2

Active Directory is insecure (by default)

This is a knock against ADFS because it relies on AD, which requires some effort to secure properly.

If you are using Active Directory at all---and especially if it controls access to critical systems---you need to design your environment to address its severe security deficiencies.

At a minimum, you should be implementing Microsoft's red forest design in accordance with their tiered administration model to mitigate pass-the-hash (PtH), pass-the-ticket (PtT), and golden ticket attacks.

Federation is the Future

When dealing with external users, ADFS is far superior to creating accounts in your domain or establishing AD trusts. If you can use ADFS, absolutely do so.

Since you specifically mention Google Identity, they are based on OAUTH, and OAUTH should interoperate with ADFS.

Since ADFS is simply Microsoft's implementation of a SAML identity provider, it should become more useful over time. In enterprise terms, SAML is still fairly new, but it has been growing.

Multiple Accounts Still Required

Administrative users will still require multiple accounts. You cannot reasonably eliminate that need. Any account that can access the internet should not have privileged access to manage your infrastructure or make changes in dev/test environments.

You may still be able to consolidate, even if administrators must have 2-3 individual AD accounts. E.g., both Oracle and MS SQL support authentication with Windows credentials, so your DBAs and developers would no longer need unique user/pass accounts in each instance.

1

One issue I would bring up would be the lack of access to real time attacks of the identity management system. For example, if someone is attacking your identity management server and successfully gets in you can take action as soon as you're aware. In the case of someone compromising a 3rd party identity provider, you might not know for a couple months when/if they decide to disclose the breach.

  • If I understood correctly, your answers covers the possible drawbacks of using an external identity provider. What about an internal identity provider (e.g. Active Directory / LDAP) which should be accessible from the Internet? – Alexei Jul 12 '18 at 6:35
  • 2
    Hmm, not sure if I'm following. Wouldn't an internal LDAP server require a dedicated user/password? – MikeSchem Jul 12 '18 at 6:40
  • yes, but one user would have to know only one pair of user/passwords. Currently, some users have to take care of hundreds of credentials for various databases, cubes, other systems and I am trying to understand if there are objective (security-wise) reasons to keep on having this instead of pushing single sign-on for all systems. – Alexei Jul 12 '18 at 6:59
  • well, the only security related reason I can think of to not using LDAP or a identity provider would be that it would be a single point of failure. So if the single identity provider was compromised, all the systems relying on it would be compromised too. But as having worked in a similarly sized organization, I can tell you that's probably not the reason. It's most likely that it's not worth adding LDAP support to every service in the businesses eyes so they don't spend the time/money to do it. – MikeSchem Jul 12 '18 at 16:57
1

First of all, I may not even be desired for some systems to have such a "single sign-on" system. In a comment you mentioned databases and other systems. As a tech-guy, I'd prefer a separate SSH-key (password protected) to connect to servers, passwords to access databases, etc. So the solution of a centralized identity provider is not suitable for all needs. Especially considering, that this approach adds another system (your identity provider) which must be reachable in order to authenticate. This is most likely the case for the majority of time, but still, it's a requirement to keep in mind.

Furthermore, the systems must be capable of working with identity providers. I doubt that accessing a database can generally be authorized using such an identity provider instead of username/password. Migrating all systems to use an identity provider may (and certainly will) cause problems you weren't expecting. Maybe nobody wants to invest time and money to change it, as username/password is certainly easier to implement.

Assuming that users writing their credentials is the problem you are trying to solve, I'd heavily promote the usage of password managers (maybe ship the with the default OS image?) one password to rule them all and users can still maintain hard to crack passwords for every service. Some users will continue to write them on a piece of tape below their keyboard, but that's business as ususal (unfortunately).

To be clear, I like the idea of a centralized identity provider. Those are all points against it, I can think of right now. Any addition are welcome (it's an interesting question).

  • But what is the security reason that you prefer separate SSH keys? – schroeder Jul 12 '18 at 10:37
  • @schroeder: I agree with GxTruth here. ssh/putty all come with tools that allow to give a password once and that will automatically choose the appropriate key to pass to a sshd server. And for security reason I prefere to use asymetric keys to connect to a ssh daemon. I must admit that I have never tried to use the AD kerberos here... – Serge Ballesta Jul 12 '18 at 15:08
  • @sergeballesta I did not say that I did not agree, but the answer lacks a connection to the reason – schroeder Jul 12 '18 at 17:20
1

Many good answers/comments before so I try to keep it short:

For me the main reason to use different user accounts with different credentials is security of long-term credentials, no matter whether you're using passwords (e.g. LDAP), shared secrets (e.g. Kerberos, TOTP, etc.), asymmetric signature schemes (e.g. SSH keys).

A simple example for passwords:

You don't want to accept the same password a user has stored on his mobile phone for reading e-mail to grant administrative access to a locked-down backend database server with all your customer data.

Another example for separate SSH keys:

For a subset of SSH systems you might be forced to use SSH key agent forwarding, or even worse to copy your personal private key to a jump host. And therefore you don't want to use this same private key as authorized key on other systems with different security requirements.

Yes, maintaining separate accounts in Excel file or similar is a nightmare and it shows that most IAM systems and processes do not handle multiple accounts per person very well. This problem can be solved by choosing a decent IAM system.

(You could require different combinations of authentication schemes for different systems but that's also a nightmare on its own.)

Regarding all kinds of single sign-on mechs like CAS, SAML, OpenID (Connect) etc.:

I think it is an admirable goal to use those if possible because long-term credentials do not pass systems which are potentially more insecure than your central login service. Today it is fairly easy to integrate web applications. You have to check whether they can deal with multiple identity sessions or setup different SSO instances.

But e.g. for SSH logins or network access control with 802.1x I currently see no easily usable SSO or 2FA solutions. For these use-cases issuing short-term certificates (OpenSSH certs or X.509 certs) might be a viable solution.

TLDR: Do not fall into the one-or-the-other trap. Use a decent IAM system and provide the right authentication front-ends for whatever systems and applications you have to deal with.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.