.png?width=667&height=667&ext=.png)
Kentico CMS Quick Tip - Mixed Mode Authentication
Introduction
Kentico has supported multiple authentication methods for a long time now. I know this capability was in the older versions like 4.0, and 5.0, heck it may have even been there since version 2.0 or 3.0. Chances are if you have been developing on Kentico for any length of time you may have been tasked with configuring Kentico to do more than just Forms based authentication. That could be in the form of some sort of custom authentication, Single Sign On (SSO) authentication, or the next most likely, Windows Active Directory for Mixed Mode based authentication.
My team and I have done this exact thing many times. Most frequently it involves enabling what is commonly referred to as mixed mode authentication. In Kentico, mixed mode authentication lets you use both Forms based authentication as well as Windows AD based authentication. Even though I have done this specific task many times there always seems to be some sort of trick required to getting it to work correctly. Today I am going to share a tip that hopefully helps out any developer who needs to configure Kentico to utilize Windows AD for Mixed Mode authentication.
The Scenario
First of all, the best place to start when you need to configure authentication methods in Kentico is the documentation on how to Configure Mixed Mode Authentication. Definitely follow the instructions there to a "T" to setup the correct configuration. It does boil down to setting up three or four different configurations in your web.config file. You need the correct settings there, plus access to IIS on your webserver where you need to enable Windows authentication.
But what happens if you follow the documentation, have your web.config file updated, and have IIS setup the correct way, and your login page still does not work. In my experience the problem always comes down to one or two things.
Quick Tip(s) for Troubleshooting Mixed Mode Auth in Kentico
The first thing that I recommend doing is using a tool called ADSI Edit. This is a windows program that comes standard on Windows Server 2008+. You can use the tool to validate your AD Connection string, and more importantly use it to prove that the domain account (username) and password in your connection string has correct access to enumerate the AD tree you are trying to connect to.
The main goal here is to prove that your LDAP connection string is setup the correct way. Things to check include the path to the users OU that you are trying to target, as well as the name of the domain controller or DNS name that is acting as your LDAP endpoint.
Which leads me to my second tip on this topic. Sometimes organizations will have multiple services or applications that use LDAP to authenticate. In this case they might also have a strong infrastructure or IT team that likes to abstract server names with DNS entries for their LDAP endpoints. So instead of having a simple LDAP connection string, an organization might have:
LDAP://auth.bizstream.com/OU=users
In most scenarios this does not cause an issue. However, I have found that once in awhile, when it comes to the ASP.NET way (which is what Kentico's auth code is based on), having a DNS name for the endpoint can cause a problem. So again, if you have everything setup the correct way according to the Kentico documentation, and your Windows AD based for Mixed Mode auth throws an error like "Cannot connect to domain" try using the main server name in the first part of your LDAP connection string, and not the DNS name.
LDAP://domain-controller-01.bizstream.local/OU=users
I have found that this approach has worked for a few scenarios after many minutes of banging my head on my keyboard wondering why in the world everything looks right but still does not work.
