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 what functional changes we want to make toward this end, (2) interview a broad range of customer to identify the most requested functional changes, and (3) still have this be the "hot potato" issue next week. To help me get beyond the broad topic of "active directory integration," what does it mean in your .NET app, both ASP.NET and WinForms?

Here are some sample changes I have to consider:

1. When creating and managing users in your app, are administrators presented with a list of all AD users or just a group of AD users?
2. When creating new security groups within your app (we call them Departments, like "Human Resources"), should this create new AD groups?
3. Do administrators assign users to security groups within your app or outside via AD? Does it matter?
4. Is the user signed on to your app by virtue of being signed on to Windows? If not, do you track users with your own user table and some kind of foreign key into AD? What foreign key do you use to link app users to AD users? Do you have to prove your login process protects user passwords?
5. What foreign key do you use to link app security groups to AD security groups?
6. If you have a WinForms component to your app (we have both ASP.NET and WinForms), do you use the Membership Provider in your WinForms app? Currently, our Membership and Role management predates the framework's version, so we do not use the Membership Provider.

Am I missing any other areas of functional changes?

Followup question

Do apps that support "active directory integration" have the ability to authenticate users against more than one domain? Not that one user would authenticate to more than one domain but that different users of the same system would authenticate against different domains.

Answer 1

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 2

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 3

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

Answer 4

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 5

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.