What does “active directory integration” mean in your .NET app?

Question

Our marketing department comes back with \"active directory integration\" being a key customer request, but our company does not seem to have the attention span to (1) decide on

Answer 1

As someone who is both the AD Administrator and is currently developing an internal app which needs to be AD-integrated, here are my thoughts:

• Active Directory users have a unique GUID; if your app needed to support both AD and AspNetSqlMembership authentication, you could have a GUID FK field in your User/Person table and a flag denoting which information store the user belonged to (forms or AD)
• As an admin, I should be able to limit access to my application to users beneath a given OU - I don't want my SQL Server or BackupExec worker accounts being able to log in!
• In your documentation, use an OU other than the standard "Users" OU - most real-world implementations move their users out of this container, and for novice admins it's re-assuring to have an LDAP query example that includes OUs (e.g. MyCompany/Users/Executive or somesuch)
• If you're using AD forms authentication, then it's possible you could trap and do something malicious with the password. This is best dealt with by your legal department in your service agreement/warranty.

Answer 2

from a administrators perspective i want a ad-integration to do the following things

1. never ever write back to the AD, i just don't trust 3rd party software in this point
2. being able to import users from AD

3. being able to set a security group eg "ApplicationXYZ Users" to be used for software distribution and rights (shared folders, ...) if necessary but this should obey number 1., so the admin creates the security group and tells the appserver which one it is.

4. single sign-on (makes it easier for the users cause they only need to know their windows login, and enforces the domain wide password policy)

5. a deactivated AD-User, or a AD-User that is no longer in "ApplicationXYZ Users" should not be able to login

6. link AD-Group to Application Group but that would be optional, i really can life without that

hth

Answer 3

One of the main advantages of using AD is that it enables a dedicated team to manage all the user/grants things. Typically, when a new user arrives, his manager asks to the dedicated team to give him access to application A B and C, and this team can do all this stuff directly from AD. In fact, they often duplicate another user (typically a co worker).

Answer 4

Is the user signed on to your app by virtue of being signed on to Windows?

To me this is first and foremost what AD integration means (apart from Windows lockin :-). So for example if the organisation has implemented public key login, you get it in your app for nothing.

Do you have to prove your login process protects user passwords?

You should typically never even see a password if you're using AD, unless you have some legacy NT4 around (certainly shouldn't have to store a password).

Do administrators assign users to security groups within your app or outside via AD? Does it matter?

Via AD. After single sign on, a major benefit would be to be able to use any AD tools you have to security admin the application, report on permissions, create ACLs, etc. You shouldn't have to reinvent this stuff for every application.

Answer 5

As key to map AD-users/groups to stuff in the application, I typically use the Security Identifier (SID) from the AD-user/group.