Ramblings by David Crawford [MSFT]
Here is a quick set of steps to get working fast with ASP.NET 2.0 ADAM Authentication from
Windows 2003 SP 1:
- Install and Configure ADAM
- Set security to allow access by your applications process owner or an ADAM user in appropriate ADAM role e.g. Administrators, Readers
- Drop in web.config in your newly created web project and fire up Web Admin Tool in VS2005 or create a basic ASP.NET page and drop the create user wizard control on it.
- Use the control on the new page or WAT to create a user (Each approach creates the necessary attributes and sets permissions in ADAM)
- Configure the forms authentication in the web.config (to only allow authenticated users from here out)
- Add a logon user page and drop the default control (login.aspx is default and overridden by loginUrl in the config)
- Test Authentication with the newly created user
If you do not have the necessary fields set in ADAM on a “user” object the provider will not authenticate even if the connection to the store succeeds with the same user / administrator ADAM account. The “user” object is the only type supported for Authentication out of the box. E.g. no userProxy or other without custom extension. An example of a custom provider is
If using VS2005, IIS is not required to test this scenario – the VS2005 web server will do. (just remember that if you are impersonating a user in the web.config that when you run your project that you have given access to the project directory. Not every user has access to the my docs\vs projects directory )
Note: A key in ADAM is that the user account is created, enabled, has an email address, and a userPrincipalName. It is required that all these users are in the ADAM Readers Role. This isn’t done by default when creating an ADAM user with ADSI Edit however if you fire up the Web Administration Tool in VS2005 with a valid connection string these accounts are created properly – ignore a current bug with updates – the update occurs regardless of the error msg in the web tool. The ASPX controls do not have this error/message and work just fine as well (to create a user – just add the create user wizard on a page from the toolbox with a working connection string and away you go )
The SSL setup configurations are on ADAM FAQ http://www.microsoft.com/windowsserver2003/adam/ADAMfaq.mspx
I tested this approach with both ADAM and Windows credentials. I did it using SSL and without. If you are using the ADAM Provider without SSL then you need to set the connection protection in the adapter configuration to None and the ldap port to non-SSL e.g. 389. Connecting to ADAM with Windows Credentials will not support connectionProtection="None" however using ADAM credentials to connect to ADAM for authenticating ADAM principals will support it.
The following is used to drop the requirement for setting passwords over a clear connection:
Open ASDI edit and disable SSL bind requirement for connections (see http://support.microsoft.com/default.aspx?scid=kb;en-us;817583 for details):
· Go to the Configuration context and choose the properties for CN=Directory Services, CN=Windows NT, CN=Services.
· Double click the attributes "msDS-Other-Settings" and click edit and remove the entry "RequireSecureProxyBind=1" and replace it with "RequireSecureProxyBind=0", then choose "OK".
· Open a command prompt to disable the SSL bind requirement for setting passwords.
· Go to C:\WINDOWS\ADAM. Run dsmgmt.
· At the dsmgmt: prompt, type: ds behavior
· At the ds behavior: prompt, type: connections
· At the server connections: prompt, type: connect to server localhost:389
· At the server connections: prompt, type: quit
· At the ds behavior: prompt, type the following: allow passwd op on unsecured connection
· Type quit repeatedly until you’re back at a directory prompt.
There are a number of topologies that you may want to run using ADAM Authentication and when you are crossing between Workgroup and Domain machines, there are some configuration changes that you must be aware of. For instance, if running your own Certificate Authority or using a custom certificate, you have to remember to add the appropriate certificates to the correct store on each machine and then set permissions to the appropriate directory on the ADAM server. The scenario that I am discussing utilizes ADAM with SSL primarily. The machine in the domain runs ADAM and is accessed from a workgroup machine. There is a local shadow account – adamadmin which was tested demonstrating access to the remote file system via a UNC to ensure there was no prompting for credentials. With that test successful, I create an ADAM user (apparently it doesn’t matter if it has a userPrincipalName for the connection only – interesting tidbit that I picked up is that an account without a userPrincipalName doesn’t show up in Web Administration Tool or via the provider controls. Create a new user running WAT and then test authentication with the default control on a page. My site has two pages, default.aspx and login.aspx (note – there is a default login page set in machine.config) Another important note is that the login.aspx page should always be modified with a NAMESPACE otherwise if you pre-compile and publish – you get namespace error conflicts with the system.web control. Adding your own namespace prevents this failure on a pre-compiled site.
The web.config below has application impersonation setup, but you also have explicitly specified domain creds in the provider for the connection username. With this combination the provider will use the explicitly configured credentials - not the credentials in the <identity /> attribute.
If the intent is to run the ASP.NET site as "adamamin" (and hence the provider as well), then remove the connectionUsername and connectionPassword attributes from the provider config.
Note: As an alternative to hand editing this file you can use the
web admin tool to configure settings for your application. Use
the Website->Asp.Net Configuration option in Visual Studio.
A full list of settings and comments can be found in
machine.config.comments usually located in
Secure - LDAP with SSL default port is 636
<add name="ADConnectionString" connectionString="LDAP://ADOM.DOM.ORG:636/CN=TheUsers,CN=Program Data,DC=Portal,
<identity impersonate="true" userName="adamadmin" password="xxxxxxxxxxxx"/>
<compilation debug="false" strict="false" explicit="true"/>
The name spaces directly above are not necessary for ADAM AuthN however the <authentication> section enables configuration of the security authentication mode used by
ASP.NET to identify an incoming user.
<deny users="?" />
<allow users="*" />
<!-- connectionProtection="None" -->
<!-- connectionProtection="Secure" -->
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
<!—ADAM Identity to logon with (Interesting note – removing the userPrincipal Name makes this ADAM account invisible to the Membership provider but works for connectivity and management – set the credentials below in place of what is in the add node above
You can alter the logon page using this node - <forms loginUrl="logon.aspx" requireSSL="false"/>
and use the default logon control on the page logon page.
The configuration above has the application impersonation setup, but also explicitly sets domain credentials in the provider for the connection username. This combination results in the provider using the explicitly configured credentials and not the credentials specified in the <identity /> attribute. When the intent is to run the ASP.NET site as "adamamin" (and hence the provider as well), then remove the connectionUsername and connectionPassword attributes from the provider configuration.
Note: The above configuration is meant to get started with the provider and ADAM however when ready for production check out the following :
I hope you found this useful… Please let me know…
Also, a big thanks to a couple of my colleagues for helping me along…