This blog entry is meant to describe how you can get Active Directory Application Mode (ADAM for short) up and running in combination with ASP.NET 2.0 Membership and Role Management. If you are not familiar with ADAM, I suggest you read this introduction to ADAM: “Madam, I’m Adam“
Installing a ADAM partition
First of all, download and install ADAM SP1 and install it on Windows Server 2003 or Windows XP. This should be pretty straightforward. Once ADAM is installed you can create a particular instance of ADAM by selecting ‘Create an ADAM instance’ from the Start > Programs > ADAM menu. It will prompt you for details.
- Create a unique instance
- Give an instance name: e.g. ‘SomeApplicationDirectory’. This will also create a Windows Service called ‘ADAM_SomeApplicationDirectory’.
- Choose a port other than the default of Active Directory 389, such as 50000 (for normal connections) and 50001 (for SSL connections). This way there is no risk of interfering with an existing Active Directory.
- Specify that you need to create an application specific instance. Name it with a distinguished name, e.g. CN=SomeApplicationPartition,O=MyCompany
- Skip through the following steps until you reach ‘Importing LDIF Files’. Select the schema definitions MS-AzMan.LDF, MS-User.LDF and MS-UserProxy.LDF.
- Click Next and let it rip.
This should give you a running instance of ADAM with a partition that you can use for your (ASP.NET 2.0) application. Side note: this instance will show up in Add/Remove Programs under Control Panel, where you can uninstall/remove the instance.
ASP.NET 2.0 Membership provider for ADAM
The ActiveDirectoryMembershipProvider is used to perform Forms Authentication against Active Directory or ADAM. Its configuration is somewhat different from the usual SQL Server based providers.
ActiveDirectoryMembershipProvider can connect to ADAM to access the information inside. This requires an ADAM administrator account. The admin account is created from either the ‘ADAM ADSI Edit’ MMC snap-in or the Ldp.exe tool. Ldp.exe is part of the Support Tools for Windows Server 2003 and is somewhat difficult to use. Let’s focus on the MMC snap-in.
Start ‘ADAM ADSI Edit’ from the ADAM programs start menu and select ‘Connect to…’ from the Action menu. Fill in the details for the connection, which could be these if you followed along.
Once logged in, create a new container called Users under the root of the partition. In it, add a user object called ADAMAdmin or something similar. Set the msDS-UserAccountDisabled attribute to FALSE. Next, go to the CN=Roles container and change the member attribute of the CN=Administrators object. Add a new ADAM account called ‘CN=ADAMAdmin,OU=Users,CN=SomeApplicationPartition,O=MyCompany’ to this multi-valued attribute. Once created, right-click the new ADAM object and choose Reset Password. Set the password and keep it handy for the web.config connection information.
Now that the provider has an login-account it can perform its work, such as validating logins and creating additional user accounts.
The important parts here are the connection related attributes of the membership provider. The connectionStringName specifies the name of a configured connection in the <connectionStrings> section. The connection string is of the form ldap://servername:port/usercontainer,partitionname, which in our case comes down to ldap://localhost:50000/CN=Users,CN=SomeApplicationPartition,O=MyCompany. The username and password details are visible, so you will need to protect this configuration section in a production environment. And, notice that the connectionProtection is set to None instead of the default Secure, which uses unsecured connections. This is not allowed by default and rightly so. Don’t use unsecured connections in a production environment, but only for development. Secured SSL connections require certificates to be set up, which can be a hassle.
We will need to
- let ADAM support unsecured bind operations
- allow sending of passwords over an unsecured connection
Testing the ADAM provider
Now that you have got everything setup correctly, it is possible to test the provider from the ASP.NET Administration Tool website. Here, you can see the existing users and create new ones. Everything should be functioning at this point.
You can add arbitrary levels of containers or organizationUnits for a hierarchy of users. The provider does a recursive search throughout the levels. You can even set up userProxy objects to refer to actual AD users in ADAM. Finally, there is the option to use the AD to ADAM synchronizer to push users from AD into ADAM. There are Microsoft products such as Microsoft Identity Integration Server (MIIS) and the Identity Integration Feature Pack for Active Directory that do a two way synchronization, but you will have to pull out your wallet for those.
Important note: When you create new users by hand or programmatically, make sure you set the userPrincipalName attribute to the user name. If you don’t these users will not be available for the ASP.NET Membership service. This is also why the ADAMAdmin will not show up. Pretty useful, so it cannot be accidentally deleted by an overenthusiastic application administrator (or yourself).
Some additional information can be found here: Making ADAM work with ASP.NET 2.0 on Windows XP.
Drop a comment if you have questions or are interested in using Authorization Manager for authorization.