A common approach by organizations on tight budgets has been to solve their Identity and Access needs with Active Directory (AD). While this approach has its advantages, it has many more disadvantages. AD has its place in almost any enterprise-computing environment, but as security and risk professionals, we must know where it belongs (and doesn’t belong) in an IAM strategy.
An AD-centric approach has several virtues. First, because it usually has an established footprint in organizations, there is knowledgeable staff to manage AD – therefore the costs of IAM are already baked into the IT budget. Second, AD provides a solid authentication mechanism that can be extended to on-premise applications via Kerberos or native Windows authentication. Thirdly, many enterprise applications natively support AD authentication or provide add-ons to accomplish AD integration.
The aforementioned virtues are outweighed by the inability of AD to support the future demands of cloud and mobile computing.
The proliferation of applications in the cloud demands solutions for managing identities and simplifying access. Using Kerberos or exposing LDAP (the protocol of AD) over the Internet raises security concerns. Out of the box, many SaaS providers allow for batch loads of user accounts. Some organizations are “rolling their own” batch programs to transfer text files over the Internet. While this is feasible when the number of applications is small, it is not something that scales well. Also, “roll your own” approaches have traditionally been discouraged for a reason – while it appears cheaper at first, “roll your own” doesn’t account for the hidden costs. While there are some tools available that extend AD authentication to SaaS applications, they do not tackle the more critical requirements around provisioning workflows, automated de-provisioning, and access recertification and governance.
AD is a network directory. Unless a user requires network access, they should not have an AD account. Microsoft recognized this by deploying Forefront Identity Manager (FIM) to manage identities in a separate datastore. AD should be treated as an endpoint to an identity management system, not as an identity repository.
How people access resources is also changing. The proliferation of mobile devices is a game-changer. Most mobile devices do not authenticate to the network (my iPhone doesn’t). Some mobile users will not use traditional desktops (think field service and salespeople). AD-centric organizations will need new strategies and tools to manage authentications and policy deployment.
What’s the Solution?
We encourage organizations to leverage their investment in AD. Especially now, using AD as an authentication for enterprise applications is an inexpensive way to externalize identity from the application. However, this is not a complete solution.
There are three investments that make the most sense for AD-centric IAM solutions that are necessary to support a future in the cloud and mobile IT environment of the future.
- Authentication – Authentication to cloud applications is best done through secure web services. SAML, a tool that enables federated authentication and single sign-on has become the de-facto standard. Authenticating mobile devices is less standardized but AD-centric organizations should look for mobile applications that can leverage AD’s authentication capabilities. Most Mobile Device Management (MDM) solutions can build a link between enterprise mobile applications and AD.
- Identity Administration and Governance – This covers a lot but at a high level, identity should be managed against an identity repository that is separate from AD. AD should be treated as a provisioning target. Good identity administration tools expose access requests and approvals to business users (folks outside of IT). Access Governance enables business users to periodically recertify access, which serves as a detective control. These capabilities are not built into AD.
- Provisioning – Organizations must deploy IAM infrastructure to handle provisioning to cloud applications. We should not assume that AD will have all of the data that cloud applications require and therefore having an identity repository that aggregates this data will be required. The IAM system should provision using native connectors or by leveraging standards while still enforcing minimal disclosure of the data model. The Graph API model makes sense here to make sure data is shared efficiently. This is opposed to replicating AD to the cloud which can result in pushing much more data than what the cloud app needs. In reverse, the cloud application may ask for schema changes and the addition of hundreds of groups to AD – this would be unacceptable in most AD environments, especially as the use of cloud applications proliferates.