Using ActiveDirectoryMembershipProvider with ADAM Principals

Chris Jackson — Tue, 13 Dec 2005 01:26:00 GMT

One of the interesting scenarios where you can use ADAM (Active Directory in Application Mode) is for extranet authentication. For external users, you create accounts in the ADAM store. For internal users, you can create a userProxy object for each of your internal users, and keep these proxy objects up to date using either MIIS or the Identity Integration Feature Pack for Microsoft Windows Server Active Directory. Using this approach, you can authenticate internal users while allowing them to use the same user name and password they use while inside the firewall, without having to poke a hole in your firewall to allow access to the corporate directory.

There is also a new framework for user management in ASP.NET 2.0 - the concept of membership, which uses a provider model. You can use the ActiveDirectoryMembershipProvider to point to an Active Directory internally. And, because ADAM is a subset of AD, you can also point this provider at ADAM, and it just works.

Except...

When you point the provider to an instance of ADAM and attempt to authenticate one of your proxy users, it fails.

Internally, the ActiveDirectoryMembershipProvider uses a DirectorySearcher to search, using the criteria ...(objectClass=user).... A proxy object is a different object class - userProxy.

So, if you want to use the membership framework for user proxy objects, you can either roll your own provider, or you can inherit from the ActiveDirectoryMembershipProvider to enable the use of object with an objectClass of userProxy.

Configuring ADAM for SSL on Windows XP without a certificate server using makecert.exe

Chris Jackson — Wed, 16 Nov 2005 01:11:00 GMT

I frequently run into situations where I need to configure my laptop to support some technology, without having a lot of server resources to depend on. Most recently, I configured a local instance of ADAM to support SSL. While the information on how to configure this is available, it is scattered across multiple sources. I figured it might be helpful to somebody to bring all of the information together in one place.

First you will want to download the Platform SDK. This will include the tools that you need.

With the Platform SDK installed, go to start -> all programs -> Microsoft Platform SDK for Windows Server 2003 SP-1 -> Open Build Environment Window -> Windows XP 32-bit Build Environment -> Set Windows XP 32-bit Build Environment (Retail). This will open up a command prompt with all of the necessary path variables set.

Now, you want to create a new root certificate using the makecert.exe utility. At the command line, enter the following:

makecert -pe -n "CN=Test and Dev Root Authority" -ss my -sr LocalMachine -a sha1 -sky signature -r "Test and Dev Root Authority.cer"

This will create a root authority certificate, which you can use to sign new certificates. In fact, that's exactly what we are going to do. Generate a new certificate, signed by this root certificate, that is configured to support server authentication. At the command line, enter the following:

makecert -pe -n "CN=insert.fully.qualified.domain.name.here.com" -ss my -sr LocalMachine -a sha1 -sky exchange -eku 1.3.6.1.5.5.7.3.1 -in "Test and Dev Root Authority" -is MY -ir LocalMachine -sp "Microsoft RSA SChannel Cryptographic Provider" -sy 12 "Test and Dev SLL.cer"

Now, both of these certificates have been created and installed to the local machine store. We need to make our root certificate a trusted root certificate, so we will open the certificates MMC console. From the command line you have open, you can type mmc. Go to File -> Add/Remove Snap In -> Add -> Certificates. Press the Add button. Select Computer Account and click Next. Leave the default of Local computer and click finish. Click close and then click OK. If you drill down to Certificates (Local Computer) -> Personal -> Certificates, you should see both certificates. Move the root certificate to Trusted Root Certificate Authorities. Move the root authority to Trusted Root Certification Authorities. Now, you have a certificate that can be used for SSL with a trusted root authority.

Finally, you need to make sure the service account has read access to the certificate, which is stored in c:\documents and settings\all users\application data\microsoft\crypto\rsa\machinekeys. You can use Windows Explorer, but if you don't want to leave your trusty command line, you can also use:

cacls "c:\documents and settings\all users\application data\microsoft\crypto\rsa\machinekeys" /e /t /c /g "NT AUTHORITY\NETWORK SERVICE":R

Note that this assumes that you accepted the default of Network Service when you installed ADAM. If not, then add read permissions to whichever account you did use.

Finally, you can restart the ADAM service from the services administrative tool.

Now, if you start up LDP, connect over port 636 with SSL selected (making sure you use the fully qualified domain name of your computer, which is required by the SSL standard), you should be connecting over a secured transport!

Chris Jackson's Semantic Consonance : ADAM

Using ActiveDirectoryMembershipProvider with ADAM Principals

Configuring ADAM for SSL on Windows XP without a certificate server using makecert.exe