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

Question

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?

Answer 1

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.

Answer 2

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...

Answer 3

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.

Answer 4

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.

Answer 5

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).

Answer 6

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.