This comeback is all about new year’s new energies and commitment to this blog, ;D. So I’ll tell you some hurdles I encountered when following the HOW TO present in MSDN at this address http://msdn.microsoft.com/en-us/library/ms998360.aspx
I'll try to cast light in some dark spots in this HOW TO which I'm sure the authors didn’t mention because they considered were out of the scope of the ASP.NET developer. In fact it’s 50% true. There are some caveats in the ASP.NET side but actually some others in the Active Directory administration side.
One should read the HOW TO before reading the rest of this article, because (for the sake of brevity) I will not duplicate here any of the steps given in it.
This was perfectly explained by Scott Guthrie in his post http://weblogs.asp.net/scottgu/archive/2006/04/22/443634.aspx , but I’ll recall here the most important points of his discussion for the sake of comprehension.
Every web application should explicitly set the value for this parameter to avoid possible conflicts between the web application metadata settings and the actual location of the web application. This value should be set to the virtual directory under which it is published in IIS.
The application should run in full trust in order to be able to connect to an Active Directory. I don’t know why this is not mentioned in the HOW TO, but it’s clearly mentioned in the MSDN documentation: http://msdn.microsoft.com/en-us/library/system.web.security.activedirectorymembershipprovider.aspx. So, for full trust to be enabled in the web application, one should add to the web.config file the following lines:
<trustLevel name="Full" policyFile="internal"/>
<trustLevel name="High" policyFile="web_hightrust.config"/>
<trustLevel name="Medium" policyFile="web_mediumtrust.config"/>
<trustLevel name="Low" policyFile="web_lowtrust.config"/>
<trustLevel name="Minimal" policyFile="web_minimaltrust.config"/>
<trust level="Full" originUrl=""/>
When promoting a Windows Server 2003 machine to domain controller, all the existing users will be entered in the Active Directory hierarchy, but they won’t have an user logon name. All the logon requests using these users will fail.
One should enter an user logon name as displayed below:
If you leave the config like this, you have a “sAMAccountName-style” user logon. You can also set the account logon name to “UserPrincipalName-style”, like this (specifying domain).
These two styles of configured user logon name will work depending of the value of the following web.config property.
The previous factors (two different styles of user logon name) and the presence of the configuration parameter above, produce the following behaviour matrix:
Forms auth logon name
AD user logon name: Empty
AD user logon name: user
AD user logon name: firstname.lastname@example.org
And having avoided these obstacles, we can now use the provider to work with Active Directory.
NOTE 1: When using the “Create new user” functionality present in the article, every new user created with it will automatically have an appropriate user logon name filled in.
NOTE 2: domain\user format will always fail in the forms login page, because it will assume it is the whole username, not separating domain from user. But, in the connection string configured in the web.config
email@example.com are valid.
See you… soon?