Active Directory and ASP.NET 2.0 Beta 2

Are you evaluating Visual Studio 2005 Beta 2 and ASP.NET 2.0? Did you know that we shipped an Active Directory Membership Provider in Beta 2? Until recently, I didn't either. Apparently we didn't make too much noise about it because while the team had the time to get the provider in, they didn't have time to get the documentation for it.

The good news is that (with a little coaching from some of the very helpful folks on the ASP.NET team) I was able to get this provider working successfully on a Virtual PC image of Visual Studio Team System Beta 2. Given that I'm hardly what one would call an active directory expert, if I can get it working that's a pretty good sign.

So here's what I did:

1. Created a new web site.
2. Added a web.config file.
3. Set the authentication type to "Forms"
4. Added a connection string pointing to my Active Directory store. This was one of the parts I had trouble with, since I wasn't very familiar with LDAP syntax. The fully-qualified domain name for my domain controller was win2k3.vstsb2.local (I know, not very creative), while the domain was vstsb2.local. So the successful connection string section in web.config looks like this:
   <connectionStrings>
    <add connectionString="LDAP://win2k3.vstsb2.local/CN=Users,DC=vstsb2,DC=local"
         name="ADConnString"/>
   </connectionStrings>
   
5. Then I added the following Membership section (note that this is a very simple implementation, and omits many of the optional attributes):
   <membership defaultProvider="AspNetActiveDirectoryMembershipProvider">
      <providers>
         <add name="AspNetActiveDirectoryMembershipProvider"
            type="System.Web.Security.ActiveDirectoryMembershipProvider,
            System.Web, Version=2.0.3600.0, Culture=neutral,
            PublicKeyToken=b03f5f7f11d50a3a"
            connectionStringName="ADConnString"
            connectionUsername="vstsb2.local\Administrator"
            connectionPassword="password"/>
      </providers>
   </membership>
    
6. Next, I added a new folder to the site, named it "protected" (the name is arbitrary), and added a web.config to this folder with an authorization section denying access to anonymous users.
7. Finally, I added a page to the new folder that writes out the name of the current user, and added a login page at the root level with a Login control to perform the authentication.

In addition to my musings above, there's some good coverage of this provider in the security article I pointed to earlier this week (see the authentication section).

A couple of other notes:

• With the syntax above for the membership provider configuration, you'll need to log in using the User Principal Name (UPN) rather than the typical DOMAIN\user syntax used for Windows authentication. The UPN syntax is basically user@domain (note that there may be more to it than that...UPN is something I only read up on today, so I'm hoping my explanation is adequate <g>). So for my example above, the user Andrew would log in using andrew@vstsb2.local as the username, and then the password as normal.
• If you'd prefer to use the SAM account name instead of the UPN, you'll need to add the following attribute to the <membership> element:
     attributeMapUsername="SAMAccountName"
• Once having added the above attribute, you should be able to log in using the username alone.

I hope if other folks are experimenting with this provider, it'll help you avoid some of the pitfalls that I ran into. I'm guessing that folks with a little more AD and/or LDAP experience will find it easier than I did, but it's very cool to be able to take advantage of AD with a pretty straightforward configuration change, and still have all the login controls "just work".

UPDATE:

One other point I want to be sure to make is that it is even more critical, when using Forms Authentication to authenticate against an Active Directory credential store, that you use SSL to protect the login page. By default Forms Authentication (much like Basic Authentication in IIS) sends credentials across the wire unencrypted. So make sure SSL is a part of your development, testing, and deployment plan.