Meeting the InCommon Assurance profile criteria using Active Directory

[Jeff Whitworth <>]

I would agree and think it wise to focus on ADDS.

Jeff Whitworth

Manager, Enterprise Systems Architecture

University of North Carolina at Greensboro

336.334.9854

 

MCITP: Enterprise Administrator

GIAC Certified Windows Security Administrator

On Fri, Mar 1, 2013 at 1:58 PM, Brian Arkills <> wrote:

Here's some product background to get us moving in a direction around scoping & mapping to functional models as it relates to the IAP.

 

AD-DS

                Domain Services. This is what most people are referring to when they say "Active Directory", and was the only "Active Directory" until the Microsoft branding machine got carried away (as it always does). 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--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.

 

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.

 

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.

 

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. The most commonly known example is not being able to forward Steve Balmer's company-wide email outside of Microsoft. No password storage or authentication here.

 

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. My 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.

 

I'd personally consider AD-LDS and AD-RMS as out of scope of this effort, because they aren't very relevant to the IAP, and because I'd be surprised to hear that there is more than 5% of universities using either of these products. I think AD-FS is relevant to the IAP, but I'd want a separate effort to look at that if there are any real issues at all (which I'd guess there aren't). I'd leave AAD out of scope, because I think AAD is a gorilla that could consume a ton of time, isn't yet in as wide-spread deployment as AD-DS, and you have the option of not storing passwords there. It may make sense to include some kind of note about AAD (or other components) in whatever artifact we produce.

 

-B