Active Directory has dominated identity and access management (IAM) in organizations for years, due to the dominance of on-site Windows servers in enterprises.
When a person joined an organization, a server administrator would add new user and/or device accounts. These accounts let the person sign in and connect to organizational resources, such as files, folders, apps (e.g., email), printers, and more. Active Directory typically acted as one of the primary gateways to the organization’s data. When a person left the organization, one of the first steps to secure data would be to disable access to their Active Directory account.
Then the internet and web-based SaaS (software as a service) apps emerged – all of which meant that people created new, external accounts, with each new web-based service needing yet another account. However, few of these SaaS offerings connected in any way to Active Directory or legacy IAM systems. IT leaders often resisted cloud app adoption because it meant a proliferation of accounts without appropriate administrative controls.
Sign-in services sought to centralize management controls over SaaS access. Companies such as Ping Identity, Okta, OneLogin, and JumpCloud, built solutions intended to give administrators consistent control over web app access.
Larger IT companies entered the IAM market, too. Google provides IAM systems (Cloud Identity and Access Management). So does Cisco, IBM, Oracle, and RSA. And Microsoft eventually entered the cloud IAM competition, with their Azure Identity and Access Management Solutions.
If you’re looking for a way to better manage devices, app access, and accounts, the following sequence may help you identify viable options.
1. Identify Apps People Use
As experienced IT folks know, the list of “officially supported” apps is only a subset of all the apps that people in an organization use. To gather a much more complete list of actual apps in use, try the following tactics.
- Send a survey. Create a form, and ask people to list all the apps they use. Remind them that this list should include both any apps installed on their computer, as well as sites they sign-in to online.
- Look at logs. A review of network monitoring tools, such as a firewall, can indicate apps in use. For example, visits to drive.google.com or admin.salesforce.com are indicators that people are using Google Workspace or Salesforce.
- Try Torii. Torii can monitor your admin and financial systems to detect payments and usage of SaaS providers.
2. Compare Your Apps-in-use With Vendor Lists
Some IAM systems integrate better with certain apps than others. For example, some systems allow a third-party app to create a new account, while others only allow a third-party IAM system to access an existing account. So compare your list of apps-in-use with the app integrations offered by potential IAM providers.
Often vendors support the ability to create custom authentication connections (e.g., with systems such as SAML, security assertion markup language). However, customizing and configuring these connections can take some time, especially if you have tens or hundreds of apps to connect. In most cases, you will save a lot of time and hassle by instead selecting a vendor with pre-built connections to apps people in your organization use.
3. Prioritize Protection
Prioritize the accounts and data that represent the most significant sources of potential concerns to your organization. Often, this will be based on the type of data handled in an app (e.g., sensitive information, such as medical or banking information) as well as the number of people in your organization who need access (e.g., every employee). Seek to centrally manage and secure every app that contains customer data.
4. Select Your System(s)
Unless people in your organization use an unusually small number of apps, it’s unlikely you’ll be able to handle all account access with a single system. Often, organizations end up with two systems: one to manage internal access and one to manage web app access. For example, Microsoft’s own Azure Active Directory might be thought of as a complementary addition to an existing on-site Active Directory setup, not a complete and comprehensive replacement of it.
However, many organizations end up with three pools of accounts: accounts in Active Directory, accounts in a web-based sign-on system, and accounts elsewhere. That last category often consists of accounts where only one or two people need access. For example, how many people need access to sign in and pay for utilities (e.g., internet service providers, gas, water, or electrical) or taxes (e.g., to various governments)? Typically very few. Often these accounts remain outside the purview of a centrally managed IAM system, even though they may be essential and important.
What IAM System Do You Use?
Do you solely rely on Active Directory in your organization? What additional systems do you use to manage access to web-based accounts? What accounts do you worry about that remain outside of IT control? In the comments or on Twitter (@awolber), let me know if and/or how your organization has chosen to move beyond Active Directory.