The Kerberos authentication protocol is one of the most widely used protocol in today’s enterprise networks. Yet there is still a lot of confusion about it. The main goal of Kerberos is to enable application authentication without the need to transmit user passwords. Kerberos is another name for the three headed hound that guarded Hades in Greek mythology. Most of us in the US know the mythical beast by the name Cerebos. The mythological Kerberos was the offspring of Echidna and Typhon and was captured by Heracles as one of his twelve labors. The protocol Kerberos was the offspring of MIT’s project Athena and was captured by Microsoft in Windows 2000. Microsoft operating systems have supported Kerberos ever since, but the relationship has often be a rocky one (but that’s a story for another time). What does all this have to do with identity, federation, and directories?
The Difference Between Kerberos and LDAP
Let’s start with LDAP. LDAP has long supported Kerberos LDAP authentication as a standard authentication mechanism, and AD supports this as well. When a user authenticates to his desktop, the Windows OS sends his credential to a Domain Controller which is also a Kerberos Distribution Center (KDC). The user gets a ticket which can be used to authenticate to other network services. When accessing an LDAP server using Kerberos authentication, the user binds to LDAP using a Kerberos ticket rather than sending a password. The LDAP server then validates the ticket and verifies that it belongs to the user trying to bind. VIS supports Kerberos LDAP binds like most LDAP servers. But there is one additional wrinkle that comes up when doing LDAP authentication in a Virtual Directory. VIS can present a virtualized view of multiple directories, including multiple AD forests. When VIS does Kerberos authentication it can only authenticate tickets granted by the domain that VIS is joined to, or one in which there is cross-forest trust established. Or, to put it another way, if VIS is joined to one domain but connects to multiple additional AD forests without cross-forest trust, VIS will only be able to do Kerberos authentication for users joined to the same forest VIS is joined to. This also means that while VIS does support Kerberos, it really requires the user to be an AD for Kerberos authentication.
Kerberos and Federation
Now, if we go up the identity stack and talk about federation, how does Kerberos play a part? A lot of our customers ask for “Kerberos authentication” in our Optimal Federation & Identity Services (OFIS). We certainly do support that but it’s not exactly what people think it is. First of all, it is technically not Kerberos, although Kerberos plays a part. Technically, it is Windows Integrated Authentication. What happens is that at authentication the user’s browser is redirected to a page that has been configured for Windows Integrated Authentication. When that happens the IIS server tells the browser that it needs to provide an authentication token. If the browser is Kerberos enabled it will send the user’s Kerberos ticket in response so IIS can authenticate the user. OFIS then detects that user authentication and the federation continues from there. This is a very powerful feature. The user can be authenticated without ever even seeing a login page. There are however some limitations. For the Kerberos token be validated both the users client machine and the IIS server must be joined to the same forest, or to a forest for which there is cross forest trust. If the user is on a BYOD that is not domain joined (such as an iPad or Android device) then the Windows Integrated Authentication will not be possible. Still, where it’s possible it’s powerful feature.
Can’t wait? Get Optimal IdM IAM Services Now
Contact Us Start Your Free Trial
