How many different sets of credentials do you need to manage to access every system, application, and resource in your environment? Of course, some simply tie in via Active Directory (Exchange, SharePoint, SQL Server, etc.) making the answer there one, but in many cases, there are application or system-centric directories utilized – both on-prem and in the cloud – that require authentication to give you access. And no one wants to have multiple accounts – too many and you either start using the same password (yes, even you!) or you begin to use some kind of password repository (read: anything from an Excel spreadsheet to a fully-encrypted vault-type application). Even if you stay on the multiple passwords stored in a vault side of things (which is far more secure than the alternative options posed here), it’s still an additional step – one that is no longer needed in today’s IT environments.
We recently wrote about using multi-factor authentication (MFA) as a means to identify trusted users that will assist with some of your group management, but when it comes to managing both AD and other resources in other environments, the real answer lies in taking things farther than just MFA, and instead look at federating identity within your organization.
If you’re not familiar with federated identity, it’s a simple approach whereby one organization providing data or a service trusts the authentication measures in place at a partner organization. By doing this, you don’t need to share personal details about the user wanting access, but are willing to grant access based on the partner organization’s assertion that the person has been authenticated.
A great example is Google. They use Security Assertion Markup Language-based federated single sign-on to act as the “trusted partner” by a myriad of applications and systems, where Google says “It’s Jim. I validated it’s him.” And Jim is given access. One authentication with many, many different applications and systems.
So, what does all this have to do with IT tasks?
Simple, with all the applications and systems that need to be managed, it makes far less sense for organizations to work to maintain multiple directories (when the one you primarily use – Active Directory – isn’t even being managed properly in the first place, so the same is probably true or worse for any others you may be hosting today), and much more sense to federate.
Federating for IT tasks has a number of benefits:
- Truly single-sign on – whether AD-based or cloud-based, users responsible for IT tasks across multiple systems only need to know one set of credentials.
- Validation of identity – Because you’ll be allowing a single logon to have access to, potentially, many systems without needing to re-provide credentials, federation can employ multi-factor authentication to ensure it’s not just the person’s correct credentials, but actually the person.
- Extend IT tasks beyond IT staff – with an ability to empower users with a single sign-on, and an ability to make certain it’s really them, you’re in a much better position of trust to delegate responsibility to users to manage certain IT tasks. For example, giving a Sales department manager the ability to modify the Sales-Users group in AD (who better to know which users should be in that group than someone close to daily sales execution?).
OK, that last one was both a benefit and, really, the point of this post. IT cannot do everything themselves (in fact, in some areas, you’re not keeping up as it is). So, having an ability to delegate out IT tasks that users can do makes sense, but in a scenario where you can validate it’s truly the designated user.
If you’re still relying on a single AD instance, federating your directories is the next step in extending your organizations ability to take advantage of external applications, systems, and resources, all while empowering its users to take on tasks historically reserved only for IT.