Kerberos protocol with focus on SSO in AD DS

So far, we've covered the Kerberos authentication (SSO) process within a single domain (Realm). The advantage of Kerberos is that it can establish relationships between Realms and perform Cross-Realm authentication. In the case of Microsoft domains, this means that when we have established a trust relationship between some domains, authentication automatically works. The user account may be in one domain and the server (service) in another, the user still logs in using SSO.

In this article, we'll look at some troubleshooting options when we set up Single Sign-On (SSO) authentication using Kerberos and automatic login still doesn't work. We are considering an AD domain controller as the authentication server. Most of the options are generic, but in the practical examples we will consider a situation where authentication to a web application from a browser is involved.

Welcome to the first part of a series that focuses on Kerberos, with a focus on Single Sign-On (SSO) in Microsoft Active Directory. Today's episode doesn't focus on Kerberos directly, but we'll cover the basic Active Directory terms that we need to know and what Kerberos authentication is related to (when using it in a domain environment). We'll briefly mention the AD components because the structure is related to Kerberos Realm. Next, we'll describe how the client finds the domain controller (which is also the Kerberos authentication server).

The second part of the series on the Kerberos protocol, focusing on Single Sign-On (SSO) in the Microsoft Active Directory environment, will follow on from the first part and will not focus on Kerberos, but on things related to Active Directory Domain Services. We will look in quite some detail at user account login names, i.e. User Principal Name (UPN) and sAMAccountName. Finally, we will describe the names of service instances (Service Principal Name).

In previous articles, we have covered important Active Directory Domain Services terms. Today, we will attempt to describe the Single Sign-On technique, starting with an introductory description of Kerberos and its features.

In this part of our series, we will continue to describe the Kerberos V5 protocol. We will explain all important concepts and used principles that play a role in Kerberos authentication. In the next part, we will use the knowledge of these terms and describe the principle of authentication with Kerberos SSO.

After we have explained the necessary basics and terms belonging to Active Directory Domain Services, Single Sign-On and Kerberos protocol, today we will start the main part. Description of the principle of how Kerberos authentication works, which also means Single Sign-On. The principle is not completely simple, various encryption keys, time stamps, tickets, etc. are used. Someone just needs to know the logical principle of the function and does not need to know what packets are sent and what they contain. That is why the description is given three times, each going more in depth.

In previous articles, we covered a lot of things about Kerberos and how it works for SSO authentication. In today's, and the next few, we'll cover a bit of a special situation. In general, this will be the last part of authentication, authentication to the service. But we're going to be describing a special case where the service is a web server and we're logging into a web application using SSO. We'll describe what we need to set up on the web server to make SSO work. And we'll discuss how Kerberos works over HTTP (which of course includes HTTPS).

In this part, we will follow up on the previous one, where we described SSO for a web application. Since we are considering web servers other than Microsoft IIS, we will describe in detail the creation of the keytab file that is used in that case. The keytab file replaces the inclusion and communication of the server with the domain controller.

In previous articles, we have discussed the use of Kerberos SSO against a web application mainly from the server side. In this article, we'll look at what needs to be set up on the client side of the web browser for SSO to work. We'll look at Internet Explorer, Firefox, and Chrome.

We've already covered the Kerberos protocol and related Active Directory components, and we've covered how Kerberos works over the HTTP protocol, so you should have all the knowledge you need to deploy any application that supports Kerberos SSO against the domain. In today's final installment, we'll take a brief look at configuring an application server and outline the related PHP implementation of SSO.

Let's take a look at the Kerberos authentication protocol. The main focus is the blocking of the weak and dangerous RC4 cipher and the complete transition to AES encryption. We will cover this in the second part. In this article, we will go through the workings of the Kerberos protocol, which is quite important to know in order to make changes. We will focus on encryption algorithms and keys, more generally encryption types. The main thing is how the type of encryption used is chosen, i.e. whether RC4 or AES is used. Apart from theoretical information, we will show some commands for finding data and setting parameters for encryption. At the end, we will discuss a bit the Microsoft update 11/2022, which partly changes the behavior and brings new possibilities. It probably contained an error when it was published, which we hope not to encounter again.

In the first part, we focused on the theory of how the Kerberos protocol works and the choice of encryption type. Today we will follow up with practical examples. How to detect tickets with RC4. How to find accounts that don't have AES enabled or AES keys exposed. What information and errors can we find among the events in the log on the domain controller. Where can be problems if we use Keytab files. We will be using PowerShell for most things. Finally, we will show you how to force the use of AES and block RC4.