Recently I needed to provide authentication from the Active Directory for a custom ASP.Net form. I was pleasantly surprised to find that there is a ready-made authentication provider available for active directory, similar to the database one.
Despite the provider the second problem was that I had to put the authentication inside a custom form where I could not use the Login controls that are integrated with the membership providers for ASP.Net. Then with little investigation I found out that it was very simple to do that as well and all the functionality of the provider could be accessed from outside the controls. I became a fan of ASP.Net once again.
The steps to use it in the custom form are very simple. Since this is forms authentication, you put in the relevant entry in web.config.
<authentication mode="Forms">
<forms
name=".ADAuthCookie"
timeout="10" />
</authentication>
This put ASP.Net in forms authentication mode, hence next step is to define the details of which forms will be used for this purpose.
<forms name=".ASPXAUTH" loginUrl="login.aspx"
defaultUrl="default.aspx" protection="All" timeout="30" path="/"
requireSSL="false" slidingExpiration="true"
cookieless="UseDeviceProfile" domain=""
enableCrossAppRedirects="false">
<credentials passwordFormat="SHA1" />
</forms>
The above tag specifies the default.aspx page as the url it gets redirected to once the user is authenticated. The authentication is actually done on the login.aspx page. The rest of the parameters define what will be the behavior of the authentication mode, for example, that there will be a 30min timeout with sliding window, it will not use SSL and cookie creation will depend on the client device.
The next step is to secure all the files so that only a select few are available without authentication and the rest can be accessed only after the user has successfully logged in. The few available anonymously contains the login page.
<authorization>
<deny users="?" />
<allow users="*" />
</authorization>
The above tags say that all anonymous accesses should be denied and all authenticated access allowed. The reason for saying both of them is that you can choose what to deny and what to allow. For example you can deny all then allow a selected number of files and directories. This kind of rule logic is common in firewall configurations.
Since we are authenticating through AD, we need to define it as a data source. This data source will first of all have a connection string.
<connectionStrings>
<add name="ADConnectionString" connectionString="LDAP://testdomain.test.com/DC=testdomain,DC=test,DC=com" />
</connectionStrings>
The only thing that needs explanation here is the connectionstring parameter. It is defining that AD will be accessed through LDAP protocol and what follows the // is the server name holding AD, you don't necessarily need to specify the actual server name if the domain name resolves to it. The DC part specifies the domain name. So if its contoso.com then it will be DC=contoso, DC=com. The reason I understand for this is that AD is a hierarchical database and hence we are defining this part of the connection string in a tree fashion. After the connection string we need to define the actual membership provider that will service all authentication queries.
<membership defaultProvider="MyADMembershipProvider">
<providers>
<add
name="MyADMembershipProvider"
type="System.Web.Security.ActiveDirectoryMembershipProvider, System.Web, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="ADConnectionString"
connectionUsername="testdomain\administrator"
connectionPassword="password" attributeMapUsername="sAMAccountName" />
</providers>
</membership>
It references the assembly required and provide a username/password that will be used to query the active directory server. This user should have enough rights to read the active directory. The last attribute attributeMapUsername is set to "sAMAccountName" which means the user will provide username in the format domain\username. While if this was not set then the default format is username@domain. This is all there is to it for the setup. Now lets use it in the code.
The first thing I intend to do is to validate a user from active directory using the submitted username and password. Once the user is authenticated we would typically like to redirect user to the first page, which in our case is defined as the default page in forms configuration.
if (Membership.ValidateUser(username, password))
{
//valid user do your thing here
FormsAuthentication.RedirectFromLoginPage(username, false);
}
else
{
//failed, give some message
}After authentication from the membership provider we can use the FormsAuthentication class to send the user to the default page. The second parameter which is 'false' in our case relates to the 'Remember Me' in the login box, which allows you to put a persistent cookie.
The followingMSDN article gives you some recommendations on making your website more secure:
Security Considerations
Failing to protect authentication tickets is a common vulnerability that can lead to unauthorized spoofing and impersonation, session hijacking, and elevation of privilege. When you use forms authentication, consider the following recommendations to help ensure a secure authentication approach:
- Restrict the authentication cookie to HTTPS connections. To prevent forms authentication cookies from being captured and tampered with while crossing the network, ensure that you use Secure Sockets Layer (SSL) with all pages that require authenticated access and restrict forms authentication tickets to SSL channels.
- Partition the site for SSL. This allows you to avoid using SSL for the entire site.
- Do not persist forms authentication cookies. Do not persist authentication cookies because they are stored in the user's profile on the client computer and can be stolen if an attacker gets physical access to the user's computer.
- Consider reducing ticket lifetime. Consider reducing the cookie lifetime to reduce the time window in which an attacker can use a captured cookie to gain access to your application with a spoofed identity.
- Consider using a fixed expiration. In scenarios where you cannot use SSL, consider setting slidingExpiration="false".
- Enforce strong user management policies. Use and enforce strong passwords for all user accounts to ensure that people cannot guess one another's passwords and to mitigate the risk posed by dictionary attacks.
- Enforce password complexity rules. Validate passwords entered through the CreateUserWizard control, by setting its PasswordRegularExpression property to an appropriate regular expression. Also configure the membership provider on the server to use the same regular expression.
- Perform effective data validation on all requests. Perform strict data validation to minimize the possibilities of SQL injection and cross-site scripting.
- Use distinct cookie names and paths. By ensuring unique cookie names and paths, you prevent possible problems that can occur when hosting multiple applications on the same server.
- Keep authentication and personalization cookies separate. Keep personalization cookies that contain user-specific preferences and non-sensitive data separate from authentication cookies.
- Use absolute URLs for navigation. This is to avoid potential issues caused by redirecting from HTTP to HTTPS pages.
Once you are done with the authentication there are a number of features that you might want to explore. For example, one thing I needed was the ability to query the AD for verifying usernames when they are put in one of the admin screens. For that you need to put the line enableSearchMethods ="true" in your membership provider and you will have access to search functions.
MembershipUserCollection users = Membership.FindUsersByName(username);
string email = users[username].Email;
The search function returns you a collection of users matching the criteria and once you get this collection you can get individual users properties set in the AD. For example in this case I needed the email of the user to send an information email regarding the executed process.
I am pasting links to two MSDN articles which will allow you to explore this further. At the end of the first article you will find a table of all the properties you can set in you membership provider which will allow you to use almost all services provided by the AD.
How To: Use Forms Authentication with Active Directory in ASP.NET 2.0
The second article discusses specifically the security considerations of using this membership provider and this might of use when you are looking to tune the security of your site for a specific environment.
How To: Protect Forms Authentication in ASP.NET 2.0
Subscribe