Active Directory Product Details

The Active Directory family offers a number of products that potentially fall within the scope of an individual institution's application for a specific assurance profile. The work of the group will consider several of the most common or potential usage cases for Active Directory products under the scope defined by the functional model on pg 4 of the InCommon Identity Assurance Assessment Framework. The functional model and more importantly, the definition of "IdMS Operations" defines the scope for which the controls of the assurance profile should be applied. Below is a brief outline of the Active Directory products and a suggested mapping to the functional model that may or may not apply in a given institution's situation.  

AD-DS                Domain Services. This is what most people are referring to when they say "Active Directory". AD-DS stores passwords, issues logon tokens, provides LDAP directory services, and via extension of its directory services can also provide other services such as DDNS, certificate authority, etc. Note that on a per security identity basis, AD-DS supports more than just password based authentication&nbsp including both external Kerberos realms and certificate based authentication. Also note that AD-DS can trust other identity providers this is usually other AD-DS instances. 

• (Attribute Service) - In Scope
• (Verifier) - In Scope
• (non-IdP Apps) - out of scope 

AD-LDS                Lightweight Directory Services. This is AD-DS without the network operating system specifics. In other words, a LDAP directory service that you can almost fully modify. AD-LDS can be used in conjunction with AD-DS, to extend AD-DS. Depending on how AD-LDS is used, it might store passwords or simply act as an authentication proxy to AD-DS. 

• (Attribute Service) - In Scope
• (Verifier) - In Scope 

AD-FS                Federation Services. This is Microsoft's federated authentication provider. It does not store passwords. It only supports two identity claims providers: AD-DS and SAML claims providers. ADFS is subtly different than Shibboleth, but can interoperate with Shibboleth. AD-FS facilitates authentication, issuing the equivalent of a logon token, but it doesn't actually do the authentication. 

• (IdP) - In Scope 

AD-RMS                Rights Management Services. This is Microsoft's DRM product. Application specific data is encrypted specific to a user or group of users, and can only be decrypted when the specific application specific restrictions on that data are satisfied. No password storage or authentication here. 

• (non-IdP Apps) - not in Scope 

AAD                Azure Active Directory. In general, you synchronize your on-premise AD-DS with Azure Active Directory, but there are a lot of details. There are multiple components under the cloudy hood. They are: MSODS, OrgID, and ACS. MSODS is a highly customized fork of AD-LDS about which little has been publicly disclosed. The understanding is that MSODS doesn't store passwords or issue logon tokens. OrgID is a parallel instance of the Microsoft LiveID system (LiveID was re-branded Microsoft Accounts), but is *not* a consumer focused system, but instead for enterprise customers. OrgID issues logon tokens, and depending on your AAD configuration may or may not store passwords. ACS is Microsoft's cloud version of AD-FS, except on steroids. ACS supports many more identity claims providers including almost every social identity provider, and can do much more than AD-FS. Like AD-FS, ACS issues the equivalent of a logon token, but doesn't do the authentication itself. Note that the AAD tenant owner has the option of either storing passwords in AAD or not. Note: I am aware of no public knowledge about how those passwords are stored. You must setup federated authentication with AAD to avoid storing passwords there. Finally, even if you elect to not store passwords in AAD, there are several *common* scenarios where a user's password will be sent to Microsoft Cloud systems. In specific, most of the "active profile" use cases (e.g. Outlook and Lync) with Exchange/Lync Online involve sending the password to the Exchange/Lync Online server so that it can get a federated logon token on your behalf. To be clear, those Microsoft Cloud systems aren't part of AAD, rather they are part of the set of services Office 365 provides. Every Office 365 deployment leverages AAD. 

• (Attribute Service???) - In Scope
• (Verifier???) - In Scope
• (Service Provider ???) - Out of Scope
• (non-IdP Apps ???) - out of scope