Kerberos is a computer network security protocol that authenticates service requests between two or more trusted hosts across an untrusted network, like the internet. It uses secret-key cryptography and a trusted third party for authenticating client-server applications and verifying users' identities.
Kerberos ensures that only authorized users can access the network resources. Additionally, it provides AAA security: Authentication, Authorization, and Accounting.
Kerberos provides a more secure and efficient authentication protocol than its legacy counterpart, NTLM, enabling stronger encryption, and reduced risk of password attacks.
In order to use Kerberos, it is required to use a Group Managed Service Account (gMSA). More information on gMSA can be found here.
-------------
Group Managed Service Account (gMSA)
Group Managed Service Account (gMSA) is in many ways similar to Managed Service Accounts. It has automatic password management, a long password that is automatically periodically updated. The differencebetween Managed Service Accounts and gMSA is that multiple machines can use the same account. So, if you are running a service in a server farm and you want to use Integrated Authentication, you should use gMSA. When the client is requesting a Kerberos ticket to access the service it doesn’t matter which instance on the server farm processes the request.
In order to get gMSA to work in the Active Directory, and a prerequisite for using gMSA during Gatekeeper installation, the domain administrator has to create the Key Distribution Service root key. That can be done by logging in to a domain controller (Windows Server 2012 or later) and running “Add-KdsRootKey -EffectiveImmediately” from PowerShell that has the Windows PowerShell Active Directory module installed.
NOTE
Even though the flag -EffectiveImmediately is used, it can take some time for the DC to create the KDS root key. Get-KdsRootKey can be used in order to verify that the KDS root key has been created.
More information on gMSA: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/group-managed-service-accounts-overview.
More information on creating KDS root key: https://learn.microsoft.com/en-us/windows-server/security/group-managed-service-accounts/create-the-key-distribution-services-kds-root-key.
Creating gMSA during Gatekeeper installation
Administrators can let the installation process create the gMSA or the administrator can pick an existing gMSA. The Gatekeeper Installation wizard will set up the necessary permissions for the machine where the Gatekeeper is installed to be allowed to use the gMSA account. If the gMSA account is created during the installation, the server that is installing the Gatekeeper has to be restarted in order to get the necessary tokens to access the gMSA account. The restart process should be smooth and re-open the installation wizard when signed in, which should pick up from before the restart.
Kerberos configuration
First of all, as mentioned in the section on enabling Integrated Authentication, the Integrated Authentication url needs to be added to the Trusted Sites in Internet Options for every client.
Configuring the Service Principal Name (SPN)
In order for the browser to know which account it should ask the Kerberos Key Distribution Center (KDC) for a Kerberos ticket, the Service Princiopal Name needs to be configured. This can be configured by the Gatekeeper Admin Tool, it will also be checked by the GK Admin Tool.
The steps in the process for checking the SPN is as follows:
- Numerate all Gatekeepers and its accounts
- Check if a SPN exist for HTTP/uniqueId.trust.specopsauthentication.com (for NA production)
- Check that the account is the same as the account that is running the Gatekeepers
If Gatekeepers are running under multiple accounts, administrators will be alerted that it is best to run as a gMSA. Integrated Authentication will also work if multiple Gatekeepers are running under different accounts if the SPN matches the account that the primary Gatekeeper is running as. However, if the primary Gatekeeper goes down, Kerberos authentication will stop working.
More information
SPN Generation: https://www.chromium.org/developers/design-documents/http-authentication/
Configuring Chrome to disable cname lookup: https://chromeenterprise.google/policies/?policy=DisableAuthNegotiateCnameLookup
Configuring Edge to disable cname lookup: https://admx.help/?Category=EdgeChromium&Policy=Microsoft.Policies.Edge::DisableAuthNegotiateCnameLookup
Parameters
Parameter
| Description
|
---|
Active Provider
| Indicates the protocol currently used for this Gatekeeper
|
Integrated Authentication url
| The authentication URL that should be added to trusted sites for all clients
|
SPN Configuration Status
| Indicates if SPN has been configured
|
SPN Account
| The SPN account name, if SPN has been configured
|
Multiple Gatekeepers
If multiple Gatekeepers are configured, all Gatekeepers have to be configured to use the Kerberos protocol for Integrated Authentication to work properly. All Gatekeepers will have to have access to the same Kerberos account (otherwise Integrated Authentication will not work if one of the Gatekeepers is down).
Since all Gatekeepers need to have access to teh same account, Specops Authentication provides support for Group Managed Service Accounts.