- The first step is to install and configure ADAM. You can download it free from here.
- Run the installation. At the end of the install, you’ll have an application group on your Start Menu called "ADAM." Choose the "Create an ADAM Instance" option. (Note that ADAM allows you to run multiple instances on the same server, provided they’re listening on different ports.)
- On the first step of the ADAM wizard, choose to create a unique instance. (Screenshot)
- Next, give your ADAM instance a name. Tapping my creative juices, I used "ADAMTest." (Screenshot)
- Set up the ports that the ADAM instance will use. Note that these must be ports that are not currently in use on your computer. The standard LDAP port is 389, and the SSL-enabled one is 636. I ran my install on a machine that was also a domain controller, so the LDAP ports were already in use. In that case, the wizard defaults them to 50000 and 50001. (Screenshot)
- The next step is setting up an application directory partition. You can do this after the wizard runs, but it’s easier to do it here. Give your partition a name in LDAP form. (Screenshot)
- In the next step, choose where you you’d like the data files for the directory to reside. Personally, the default location is nearly always my favorite. 🙂 (Screenshot)
- Choose the account in whose context you’d like the ADAM service to run. In this example, I used a domain account, though the Network Service account is fine, too. If you choose to connect to ADAM via SSL (something I’ll deal with in a later post), the SSL certificate you use needs to be made a part of the personal certificate store of the account under whose identity the ADAM service is running. (Screenshot)
- Select the account or group that will have administrative privileges within ADAM. In my case, you can see I’ve made this available to my computer’s administrators. (Screenshot)
- On the next screen, you’ll have the opportunity to import LDIF files. These files contain the schema information for specific entities within the directory. For the purposes of user authentication within MOSS, I’ve only needed the "MS-User.LDF" file. (Screenshot)
- That’s it for the install. The wizard will run, and assuming all goes well, it will complete and start up the new ADAM instance. The next step is to connect to the instance and do a little initial configuration.
To connect to the instance, start the "ADAM ADSI Edit" utility from the ADAM folder on your Start Menu. Right-click on the top node of the tree view in the MMC console and select "Connect to."
Enter the connection information in the "Connection Settings" dialog. Choose to connect to a Distinguished name (DN), and enter the same value that you used for your application partition in step 6. (Screenshot)
Your ADSI ADAM console should now look something like this.
- The next step I took is optional. You can put your user entries directly into the application partition itself. However, since there are other containers already there (e.g. Roles), I like to create a new container to hold the user information. To do this, right-click on the partition folder in the tree view, select "New" and "object" from the context menu.
In the "Create Object" wizard, select "container" from the list of classes. (Screenshot)
The next step will prompt you for the container name. I chose "Users." (Screenshot)
That’s it! Just 12 short steps (grin) and your ADAM directory is ready to provide authentication services for WSS.
Configuring Multiple Authentication Providers in SharePoint 2007
This post assumes that you have an existing intranet site within WSS and that it is authenticating against Active Directory.
The first step in allowing WSS to connect to the ADAM instance is to make the provider available for use.
Edit the web.config for your SharePoint Central Administration site. Add the following block inside the <system.web> tags.
Note that you will need to modify the sections highlighted in red to fit your installation.
<membership defaultProvider="ADAMMembership">
<providers>
<add name="ADAMMembership"
type="Microsoft.Office.Server.Security.LDAPMembershipProvider, Microsoft.Office.Server, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71E9BCE111E9429C"
server="myserver"
port="50000"
useSSL="false"
userDNAttribute="distinguishedName"
userNameAttribute="cn"
userContainer="CN=Users,OU=ADAMTest,O=ADAM,C=US"
userObjectClass="user"
userFilter="(ObjectClass=user)"
scope="Subtree"
otherRequiredUserAttributes="sn,givenname,cn" />
</providers>
</membership>
Note that the "userContainer" attribute is the distinguished name of the container I created in step 12 above.
Next, you’re ready to configure WSS to use the ADAM directory. Within the SharePoint admin site under "Application Management," choose to "Create or extend web application" and click the "Extend an existing Web Application" link. (Screenshot)
When specifying the settings for the new IIS web site, you can specify a host header if this is how you want to segregate traffic from the extranet. Most, importantly, set the zone at the bottom of the page to "Extranet." This differentiates this web site from the default site in the application, and will allow us to choose a different authentication provider. (Screenshot)
The next step is to specify that we want to use ADAM to authenticate the users coming from the Extranet zone. This is done using the "Authentication providers" link within Application Management. When you click the link, you should see two zones, Default and Extranet, configured to use Windows authentication. (Screenshot)
Click on the "Extranet" zone to modify the authentication provider for this zone. To use the provider we’ve configured, change the "Authentication Type" to be "Forms," and set the "Membership provider name" to be the same as we specified in the web.config above. In this case, I called it "ADAMMembership." (Screenshot)
Save that information. Your Authentication Providers list should now look like this.
Still with me? Just a few more steps!
So far, we’ve told the SharePoint administration site about the ADAM membership provider and told it to use that for authentication on a new IIS site that extends an existing application. Now we have to configure the web application to make sure that it’s aware of the ADAM provider.
To do this, open the web.config for the new IIS web site that you just created. Mine was found in "C:InetpubwwwrootwssVirtualDirectoriesextranet.myserver.local3072"; yours will be different, depending on how you set up your site.
Paste EXACTLY the same XML as above into the site’s web.config within the <system.web> section and save the file. Once you’ve completed that, try hitting the site you’ve set up; you should see the forms authentication screen.
Paste the same XML into the web.config for the intranet site. This is needed so that the PeoplePicker running on the intranet can search the ADAM directory.
As usual, save yourself any lurking questions and do a preventative iisreset. 🙂
One final step: the account under which WSS is running needs to have "Read" permissions within the ADAM directory. To do this, go back to your "ADAM ADSI Edit" utility. Navigate to the "Roles" container within your application partition. The default install will place a group here called "Readers." Right-click and select "Properties." Scroll down to the "members" property and click the "Edit" button. On the member screen, click "Add Windows Account" and add the account under which your WSS instance is running. (Screenshot)
Next Steps
That’s all there is from a configuration standpoint. Your next steps will be to add users to the ADAM directory and configure permissions within WSS.
To add a user within ADAM, right-click on the "Users" container within "ADAM ADSI Edit" and select "New–>Object." Choose "user" as the class, and enter the desired username as the "cn" of the new user.
Once you’ve created the new user, you can set the password by right-clicking the user in the right panel and selecting "Reset Password" from the context menu.
It’s also worth noting that when ADAM is installed, any existing password policy on a Windows Server 2003 instance is enforced (see this link for details). In my case, this causes any accounts that I create to be disabled until after I set a complex password. To enable the account, you need to set the "msDS-UserAccountDisabled" property of the user to false.
Now that you’ve created ADAM users, you must add them as users to SharePoint before they’ll be able to access the WSS site. You can do this using the standard user administration functions within SharePoint. You’ll notice from the intranet site that the PeoplePicker now validates and searches against both the Active Directory and against the ADAM directory.
