Authentication configuration issues, especially those tying into Kerberos, are a big call driver for the Active Roles by One Identity Support team.
When Kerberos requirements are met, Integrated Windows Authentication typically attempts Kerberos before falling back to NTLM.
Due to expected IIS functionality, we will see multiple HTTP requests which trigger authentication repeatedly. When these requests persistently attempt Kerberos, then fail over to NTLM, the Active Roles Web Interface can feel sluggish.
In more secure environments, where NTLM is blocked, authentication can fail completely if Kerberos is not properly configured.
Over the years, I have assisted with implementing and troubleshooting issues in Kerberos configurations in dozens of different environments. Because of this, I have a solid understanding of the moving pieces: what is needed, where, why and how to get it configured.
The goal of this post is to talk about some of these challenges and hopefully help you to get Kerberos authentication correctly implemented in your environment.
To start the conversation, we need to understand one thing: Kerberos relies on explicit trust relationships, service principal name (SPN) registration and delegation permissions that determine where credentials can be used and forwarded.
To get Kerberos working, you will likely need to add the necessary configuration to authorize impersonation across servers.
There are three very important considerations that need to be addressed when working with Kerberos:
-
The SPNs
-
The security context
-
The delegations
Let's talk about SPNs first.
SPNs live in the servicePrincipalName attribute of an Active Directory (AD) object. Think of them as describing the endpoint of a delegation hop.
There are three specific SPNs that are relevant from an Active Roles by One Identity authentication perspective:
The Active Roles Administration Service SPN: ARAdminSVC
The Microsoft IIS SPN: HTTP
The Microsoft SQL Server SPN: MSSQLSvc
SPNs can be viewed in any tool that uses LDAP to read AD attributes, including the Active Roles Console, the Active Roles Management Shell, Active Directory Users and Computers, and native Active Directory PowerShell, to name a few.
The servicePrincipalName attribute is formatted as a multivalued DirectoryString, and a single SPN contains both a service class reference as well as a connection string.
For an example, let’s look at an Active Roles Administration Service SPN:
ARAdminSVC/ActiveRolesServiceHost.domain.local
-
ARAdminSVC is the name of the Active Roles Administration Service itself. You can see this if you check the General tab of the Active Roles Administration Service in the services.msc snapin. It also happens to be the service class reference name.
-
ActiveRolesServiceHost.domain.local is the valid connection string that is described by this SPN. In this case, it is the FQDN of the Active Roles Administration Service host.
Note: If a non-default port is used, there may also be a port reference in an SPN.
Whatever connection string the client uses (in this example, it would be an Active Roles Administration Service client) needs to be specified. If we want to allow the client to use a Domain Name System (DNS) alias, or a load-balanced URI, then we need to have those connection strings configured as separate SPNs. The exact connection string must match, or Kerberos will not function.
The question of "Where do these SPNs need to be specified?" is answered by looking at the security context of the authentication.
As previously mentioned, SPNs live in the servicePrincipalName attribute of an AD account. But which account? You may note that the servicePrincipalName attribute doesn't exist only on User class objects. In the default AD schema, this attribute lives on User, Computer and gMSA/sMSA objects.
If the service passing the authentication is running under an AD User account or a gMSA/sMSA, then the SPN needs to be configured on that service account.
If the service passing the authentication is running under a local computer account, like an IIS Application Pool running as LocalSystem or ApplicationPoolIdentity, then the SPN must be configured on that computer object in AD.
Recognizing the security context is very important because of a constraint with Kerberos: Every SPN must be unique and can live on only one AD account.
This is why, although you can see them using any tool that uses LDAP to read AD attributes, you should only ever set them using the setspn tool that is provided by Microsoft. It has the handy -S parameter, which ensures that the SPN is unique. If you don't use setspn with the -S parameter and accidentally add an SPN that is not unique, Kerberos authentication will fail for that SPN.
Recognizing this constraint is important, because it shapes your deployment of Active Roles by One Identity, especially the Active Roles Web Interface.
If you have one Active Roles Web Interface, then you can run the ARWebAppPool application pool either under the security context of the computer account (LocalSystem/NetworkService) or as a custom service account, and you can place the necessary HTTP SPN appropriately.
However, if you are using more than one Active Roles Web Interface host for redundancy behind a DNS alias or a load-balancer, then you must use the same service account to run the ARWebAppPool on each of these Active Roles Web Interface hosts. Doing so will allow you to have a unique SPN (existing only on the AD service account) while using that SPN on multiple hosts.
Finally, after the SPNs exist, you can configure delegations.
If an SPN is the endpoint of a hop, then a delegation is the path between these endpoints.
There are, generally, two options: unconstrained delegation or constrained delegation.
Unconstrained delegation allows authentication to be passed to any endpoint that has a valid SPN, as needed, without restrictions.
Constrained delegation is a list of specific allowed SPNs.
Delegations are generally configured in AD Users and Computers on the Delegation tab.
Note: You won't even see the Delegation tab unless you are looking at an account that has at least one SPN.
If you choose the option to Trust this user/computer for delegation to any service (Kerberos only), then you've configured unconstrained delegation.
If you choose the option to Trust this user/computer for delegation to specified services only, search for a service account or host, and select an SPN, then you've configured constrained delegation.
As a security best practice, you should configure constrained delegation wherever possible. Not only is it an inherently more secure configuration, but the Credential Guard feature, which might be enabled on Windows clients, explicitly blocks the use of unconstrained delegation.
https://learn.microsoft.com/en-us/windows/security/identity-protection/credential-guard/
Enabling constrained delegation will ensure that you have a configuration which will work for all your users.
Having a client pass authentication to a server which passes that authentication to another service on behalf of the users is something that Microsoft calls a "Kerberos double hop."
https://techcommunity.microsoft.com/blog/askds/understanding-kerberos-double-hop/395463
In most configurations where the Active Roles Administration Service uses Windows Authentication to communicate with the backend Microsoft SQL Server, then the full impersonation path will be Client -> IIS -> Active Roles Administration Service -> Microsoft SQL Server.
The ARWebAppPool security context will need permission to delegate credentials to the Active Roles Administration Service SPN, and the Active Roles Administration Service security context will need permission to delegate credentials to the Microsoft SQL Server SPN.
Troubleshooting SPNs and missing delegations can be difficult. It is extremely useful to enable Kerberos logging on the client and all servers so that errors will be logged.
The klist command is also very useful when troubleshooting. Running klist will allow you to view the cached Kerberos tickets on a host. Klist purge will allow you to clear that cache.
Some relevant Active Roles by One Identity resources are below:
Solution title: HOW TO: Enabling Kerberos Constrained Delegation for a stand-alone Web Interface instance
Solution URL: https://support.oneidentity.com/kb/4336757
Solution title: HOW TO: Configuring Kerberos Constrained Delegation on a standalone Active Roles Web Interface when using a gMSA
Solution URL: https://support.oneidentity.com/kb/4339070
With that, we've covered most of the pertinent details for configuring Kerberos in an environment where Active Roles is present. There are many related topics that we haven't touched, like encryption suites, time skews, DNS and protocol mismatches, but those topics are better served by referring to Microsoft resources.
