Are there any objective reasons to use dedicated user/password instead of identity providers within a large organization?
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:
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.
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.
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.
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.
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 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.