Kerberos Authentication

Kerberos is a network authentication protocol that verifies the identity of a user or a host. A user obtains a ticket-granting ticket (TGT) from the Key Distribution Center (KDC), which runs on the domain controller. The user then uses the TGT to request a service ticket and presents that ticket to the service they want to access.

The Kerberos protocol lets Active Directory users sign in to the Axidian Privilege console with a domain account: the user doesn't need to enter a password, because authentication relies on the issued ticket.

Limitations

• Kerberos authentication supports a single Active Directory domain. If other directories are connected, disable them in the Web Wizard.
• When Kerberos authentication is configured, only internal users can sign in to PAM with a username and password.
• The time on the Management Server, the domain controller, and the user's computer must be synchronized. If the time skew exceeds the maximum tolerance configured in the domain (5 minutes by default), the KDC rejects the tickets. For more information, see the Microsoft documentation.

Preparing the infrastructure

Select the scenario that matches your PAM deployment.

Management Server on Windows

If the Management Server runs on Windows, complete the following steps:

1. Verify the SPN for each address that users use to open the PAM console.
2. Configure authentication in the Web Wizard.
3. Configure the browser for Kerberos sign-in.

A Windows-based Management Server is joined to the domain, so no keytab file is required.

---

Verifying the SPN

A service principal name (SPN) is the unique identifier of a service instance. Kerberos authentication uses SPNs to associate a service instance with a service logon account.

Basic deployment

info

Perform these steps on a domain controller or on a domain-joined computer that has the Remote Server Administration Tools (RSAT) or the Active Directory module for PowerShell installed.

For the DNS name of the SPN management server, an SPN is automatically registered for the computer account if the following conditions are met:

• The Management Server is joined to the domain.
• In the Windows Authentication settings, the useAppPoolCredentials parameter is set to False, so the service ticket is decrypted with the key of the computer account.

If users open the PAM console through a load balancer address or through a DNS alias that doesn't match the DNS name of the Management Server, register the SPN manually.

Verify that the SPN for each PAM FQDN is registered to exactly one account:

1. Run PowerShell as an administrator.

2. Run the following command:

   setspn -Q */<PAM FQDN>

   The output must list a single account. In a basic deployment, this is the computer account of the Management Server, in the format <domain>\<DNS name of the Management Server>$.

   If the SPN isn't found, or if it's registered to more than one account, contact your domain administrator.

Load-balanced deployment

If users open the PAM console through the shared virtual address of a load balancer, you must manually register the SPN for the virtual name, because the virtual name doesn't match the DNS name of the Management Server.

To register the SPN:

1. Assign a service account as the identity of the Axidian.Privilege.Idp application pool.

   How to assign the account

   Note

   Perform these steps on every Management Server.

   1. Open IIS Manager.
   2. In the Connections pane, select Application Pools.
   3. Right-click the Axidian.Privilege.Idp pool, and then select Advanced Settings.
   4. In the Process Model section, next to Identity, click .
   5. Select Custom account, and then specify the service account. Enter the username in the format DOMAIN\Account name.
   6. Click OK.

2. Configure IIS to use the application pool identity (Axidian.Privilege.Idp) for decrypting Kerberos service tickets.

   How to configure Axidian.Privilege.Idp to validate tickets

   info

   Perform these steps on every Management Server.

   1. In the Connections pane, select Sites → Default Web Site → idp.

   2. In the Management section, double-click Configuration Editor.

   3. In the Section list, select system.webServer → security → authentication → windowsAuthentication.

   4. Set the useAppPoolCredentials parameter to True.

   5. In the Actions pane, click Apply.

   6. In the IIS section, double-click Authentication.

   7. Select Windows Authentication, and then in the Actions pane, click Providers.

   8. Make sure that the authentication providers are listed in the following order:

      Negotiate
      NTLM

      If a provider isn't listed, select it in the Available Providers list, and then click Add.

      To change the order of the providers, use Move Up and Move Down.

   9. Go to Application Pools, select Axidian.Privilege.Idp, and then in the Actions pane, click Recycle.

3. Register the SPN for the service account that the Axidian.Privilege.Idp application pool runs under.

   How to register the SPN manually

   info

   Perform these steps on a domain controller or on a domain-joined computer that has the Remote Server Administration Tools (RSAT) or the Active Directory module for PowerShell installed.

   To register the SPN:

   1. Run PowerShell as an administrator.

   2. Run the following command:

      setspn -S HTTP/<PAM FQDN> <domain>\<AD account>
      Example

      setspn -S HTTP/pam.company.local PAM\pam-ad-user

      The -S switch checks the forest for duplicate SPNs before it adds the SPN.

      info

      An SPN must be unique within the forest. Don't register the same SPN for another account.

      What to do if the SPN is already registered

      If setspn returns Duplicate SPN found, aborting operation!, the SPN is already registered to another account.

      To resolve the conflict:

      1. Run the following command:

         setspn -Q HTTP/<PAM FQDN>

         The output shows the account that the SPN is currently registered to.

      2. Delete the SPN from that account:

         caution

         Coordinate the deletion with your domain administrator. The existing SPN might be in use by another service.

         setspn -D HTTP/<PAM FQDN> <domain>\<current AD account>

      3. Register the SPN for the new account:

         setspn -S HTTP/<PAM FQDN> <domain>\<new AD account>

      4. Verify that the conflict is resolved and that the SPN is registered to the intended account:

         setspn -Q HTTP/<PAM FQDN>

         The output shows the account that the SPN is now registered to.

   3. List the SPNs registered to the account:

      setspn -L <domain>\<AD account>

Management Server on Linux

If the Management Server runs on Linux, complete the following steps:

1. Prepare the service account that is used to validate tickets.

2. Register the SPN for each address that users use to open the PAM console.

3. Prepare the keytab file that is used to validate tickets.

   Warning

   The keytab file contains the keys of the service account. Treat this file as a secret: never share it or store it in shared file repositories, such as network shares or version control. If the file is compromised, reset the service account password and generate a new keytab file.

4. Configure authentication in the Web Wizard.

5. Configure the browser for Kerberos sign-in.

---

Preparing the Active Directory service account

A Linux-based Management Server isn't joined to the domain, so PAM has no domain account of its own to validate user tickets during Kerberos authentication. A dedicated Active Directory service account fills this role: you generate a keytab file for this account, and PAM uses the file to validate the tickets that users present when they sign in to the console.

info

Perform these steps on a domain controller or on a domain-joined computer that has the Remote Server Administration Tools (RSAT) or the Active Directory module for PowerShell installed.

Active Directory

1. Open Active Directory Users and Computers.
2. Go to the appropriate organizational unit, and then create a dedicated service account for the Kerberos configuration.
3. Right-click the new account, and then select Properties.
4. On the Account tab, in Account options, do the following:
   • Select This account supports Kerberos AES 256 bit encryption.
   • Clear Use only Kerberos DES encryption types for this account.
5. Click OK.

PowerShell

1. Run PowerShell as an administrator.

2. Create a dedicated service account for the Kerberos configuration:

   New-ADUser -Name "<AD account>" -SamAccountName "<AD account>" `
     -UserPrincipalName "<AD account>@<domain>" `
     -AccountPassword (Read-Host -AsSecureString "Password") `
     -PasswordNeverExpires $true -Enabled $true
   Example command

   New-ADUser -Name "pam-ad-user" -SamAccountName "pam-ad-user" `
     -UserPrincipalName "pam-ad-user@company.local" `
     -AccountPassword (Read-Host -AsSecureString "Password") `
     -PasswordNeverExpires $true -Enabled $true

3. Set the Kerberos AES-256 encryption type for the service account:

   Set-ADUser <AD account> -KerberosEncryptionType AES256

Registering the SPN

A service principal name (SPN) is the unique identifier of a service instance. Kerberos authentication uses SPNs to associate a service instance with a service logon account.

Basic deployment

Determine the primary FQDN that users use to open the PAM console. Register an SPN for this address in the format HTTP/<PAM FQDN>, and map it to the dedicated Active Directory service account.

Load-balanced deployment

If users open the PAM console through the shared virtual address of a load balancer, register the SPN for that shared address, and map it to the dedicated Active Directory service account.

info

Perform these steps on a domain controller or on a domain-joined computer that has the Remote Server Administration Tools (RSAT) or the Active Directory module for PowerShell installed.

To register the SPN:

1. Run PowerShell as an administrator.

2. Run the following command:

   setspn -S HTTP/<PAM FQDN> <domain>\<AD account>
   Example

   setspn -S HTTP/pam.company.local PAM\pam-ad-user

   The -S switch checks the forest for duplicate SPNs before it adds the SPN.

   info

   An SPN must be unique within the forest. Don't register the same SPN for another account.

   What to do if the SPN is already registered

   If setspn returns Duplicate SPN found, aborting operation!, the SPN is already registered to another account.

   To resolve the conflict:

   1. Run the following command:

      setspn -Q HTTP/<PAM FQDN>

      The output shows the account that the SPN is currently registered to.

   2. Delete the SPN from that account:

      caution

      Coordinate the deletion with your domain administrator. The existing SPN might be in use by another service.

      setspn -D HTTP/<PAM FQDN> <domain>\<current AD account>

   3. Register the SPN for the new account:

      setspn -S HTTP/<PAM FQDN> <domain>\<new AD account>

   4. Verify that the conflict is resolved and that the SPN is registered to the intended account:

      setspn -Q HTTP/<PAM FQDN>

      The output shows the account that the SPN is now registered to.

3. List the SPNs registered to the account:

   setspn -L <domain>\<AD account>

Preparing the keytab file

Note

All Management Servers use the same keytab file. If you change the service account password or the PAM FQDN, generate a new keytab file.

The keytab file contains one or more Kerberos principal names and their corresponding secret keys, which are derived from the service account password. The Management Server uses these keys to decrypt and validate the service tickets that the browser presents.

Generating the keytab file

info

Perform these steps on a domain controller or on a domain-joined computer that has the Remote Server Administration Tools (RSAT) or the Active Directory module for PowerShell installed.

Basic deployment

To generate the keytab file, Run PowerShell as an administrator, and then run the following command:

ktpass -princ HTTP/<PAM FQDN>@<REALM> `
  -mapuser <domain\AD account> `
  -crypto AES256-SHA1 `
  -ptype KRB5_NT_PRINCIPAL `
  -pass * `
  -out <path to save keytab>

Load-balanced deployment

If users open the PAM console through the shared virtual address of a load balancer, generate the keytab file for that shared address.

To generate the keytab file, Run PowerShell as an administrator, and then run the following command:

ktpass -princ HTTP/<Load Balancer FQDN>@<REALM> `
  -mapuser <domain\AD account> `
  -crypto AES256-SHA1 `
  -ptype KRB5_NT_PRINCIPAL `
  -pass * `
  -out <path to save keytab>

Store the resulting keytab file on a trusted host with restricted access.

Command example and parameters

Example command

ktpass -princ HTTP/pam.company.local@COMPANY.LOCAL `
  -mapuser PAM\pam-ad-user `
  -crypto AES256-SHA1 `
  -ptype KRB5_NT_PRINCIPAL `
  -pass * `
  -out http.keytab

Parameter	Description
-princ	The Kerberos principal that the keys are generated for. Specify the value in the format HTTP/<PAM FQDN>@<REALM>, where REALM is the Kerberos realm name. In most cases, the realm name is your Active Directory DNS domain name, written in uppercase. For example, company.local becomes COMPANY.LOCAL.
-mapuser	The Active Directory account that the principal is mapped to. The keys in the keytab file are derived from the password of this account. For example: PAM\pam-ad-user.
-crypto	The encryption type of the keys. Specify AES256-SHA1.
-ptype	The Kerberos principal type. Specify KRB5_NT_PRINCIPAL—the general principal type used for user and service accounts.
-pass	The password of the Active Directory account. Specify an asterisk (*) to be prompted for the password. Avoid passing the password in plain text. ktpass resets the account password to the value that you specify.
-out	The path or the file name to save the keytab file to. You can specify: only a file name, for example, http.keytab. The file is created in the current folder. a full path, for example, C:\keytab\http.keytab.

Warning

Avoid running ktpass more than once: each run resets the service account password and increments the Key Version Number (KVNO), which invalidates any keytab file generated earlier. Use only the keytab file that the most recent run produced.

If you generate the file again, update the keytab file in PAM through the Web Wizard.

Validating the keytab file

Note

Validate the file on a trusted Linux host that has restricted access and Kerberos utilities installed.

To validate the keytab file:

1. Copy the keytab file to the trusted host.

2. In the directory that contains the copy of the keytab file, create a krb5.conf file with the following structure:

   [libdefaults]
     default_realm = <REALM>
     dns_lookup_realm = false
     dns_lookup_kdc = true
     rdns = false
   
   [domain_realm]
     .<DNS domain> = <REALM>
     <DNS domain> = <REALM>
   File example and parameters

   Example file

   [libdefaults]
     default_realm = COMPANY.LOCAL
     dns_lookup_realm = false
     dns_lookup_kdc = true
     rdns = false
   
   [domain_realm]
     .company.local = COMPANY.LOCAL
     company.local = COMPANY.LOCAL

   Parameter	Description
   default_realm	The default Kerberos realm—your Active Directory DNS domain name in uppercase letters. The value must match the realm of the principal that is stored in the keytab file.
   dns_lookup_realm	Specifies whether the Kerberos realm is resolved through DNS. Set this parameter to false.
   dns_lookup_kdc	Specifies whether DNS SRV records are used to locate the KDC. Set this parameter to true.
   rdns	Specifies whether reverse DNS lookups (PTR records) are used when host names are canonicalized. Set this parameter to false.
   [domain_realm]	The rules that map DNS names to the Kerberos realm: .<DNS domain> = <REALM> — maps the subdomains of the DNS domain to the realm. <DNS domain> = <REALM> — maps the DNS domain itself to the realm.

3. In the directory that contains the keytab and krb5.conf files, run the following command to obtain a ticket-granting ticket (TGT) for the service principal:

   KRB5_CONFIG=./krb5.conf \
   KRB5CCNAME=FILE:./<ticket file>.ccache \
   kinit -V -kt <keytab file> \
   HTTP/<PAM FQDN>@<REALM>

   For the KRB5CCNAME parameter, specify the credential cache file that the ticket is written to.

4. Verify that the ticket was obtained:

   KRB5CCNAME=FILE:./<ticket file>.ccache klist

   If the output lists a ticket, the keytab file contains valid keys: the keys match the current service account password and the Key Version Number (KVNO) in Active Directory.

   If the command returns an error

   Error	Possible cause and solution
   Preauthentication failed	The keys in the keytab file don't match the current password or the Key Version Number (KVNO) on the domain controller. Generate the keytab file again.
   Keytab contains no suitable keys	The keytab file doesn't contain a suitable key: either the file has no key for the specified principal, or it has no key of an encryption type that the domain controller supports. Check the contents of the file with klist -kte <keytab file>.
   Client not found in Kerberos database	The domain controller has no principal that matches the value of the -princ parameter. Make sure that the principal name is correct and that the SPN is registered.
   Server not found in Kerberos database	The domain controller has no krbtgt principal for the requested realm. Make sure that the REALM value is correct.
   Cannot find KDC for realm	The host that runs the validation can't locate a domain controller for the specified realm. Check the DNS settings and the availability of the domain controller.

5. After the validation, destroy the credential cache:

   KRB5CCNAME=FILE:./<ticket file>.ccache kdestroy

6. Delete the krb5.conf file and the copy of the keytab file from the trusted host.

Configuring authentication in the Web Wizard

You enable Kerberos authentication in the Web Wizard.

1. Launch the Web Wizard.

   How to launch the Web Wizard

   1. In the PAM distribution directory, run the following command to start the Web Wizard:

      sudo bash run-wizard.sh

   2. Open the URL that the script displays in the console.

   3. In the Access code field, enter the AuthenticationCode that the script displays in the console.

      For example: vVHyTVRyKX5pxUKM6e1ZgCWEnOdXFdOy.
      Time limit

      The access code is valid for two hours.

   4. Click Sign in.

2. Select a scenario, such as Changing PAM configuration, and follow the instructions in the Web Wizard.

3. On the Authentication step, select the Kerberos authentication mechanism.

   Upload the keytab file that you generated. The file must be generated with AES-256 encryption.

4. Continue to change the configuration by following the instructions in the Web Wizard.

When the Web Wizard finishes, Kerberos authentication is available on the sign-in page of the PAM console.

Configuring the browser

To sign in to the PAM console using the Kerberos protocol, the browser must send the user's domain credentials to the address where the PAM console is opened. To allow this, add the PAM address to the list of addresses allowed for Integrated Windows Authentication. The list is defined by the AuthServerAllowlist browser policy.

The AuthServerAllowlist policy is configured on a domain controller and distributed through Active Directory Group Policy to all domain-joined computers.

Note

Perform these steps on a domain-joined computer that has the Group Policy Management Tools installed or the GroupPolicy PowerShell module available.

1. Run PowerShell as an administrator.

2. Create a Group Policy Object (GPO):

   New-GPO -Name "<GPO name>"

3. Configure the AuthServerAllowlist policy for the target browser.

   Google Chrome

   Set-GPRegistryValue -Name "<GPO name>" `
     -Key "HKLM\Software\Policies\Google\Chrome" `
     -ValueName AuthServerAllowlist -Type String -Value "<PAM addresses>"

   Microsoft Edge

   Set-GPRegistryValue -Name "<GPO name>" `
     -Key "HKLM\Software\Policies\Microsoft\Edge" `
     -ValueName AuthServerAllowlist -Type String -Value "<PAM addresses>"

   For the -Value parameter, specify the addresses that users use to open the PAM console. You can define the list of allowed addresses in the following formats:

   • <PAM FQDN> — an individual PAM address, for example, pam.company.local
   • *.<DNS domain> — every PAM address in the domain, for example, *.company.local
   • *.<DNS domain>,<PAM FQDN> — a combined list, for example, *.company.local,pam.company.local

   Specify explicit PAM FQDNs whenever possible. Use the *.<DNS domain> wildcard only when necessary, because it applies the policy to every server in that DNS domain.

4. Link the GPO to the domain or to the organizational unit (OU) that contains the users' computers:

   New-GPLink -Name "<GPO name>" -Target "<DN of domain or OU>"

   For the -Target parameter, specify the distinguished name (DN) of the domain or OU, for example, DC=company,DC=local or OU=Workstations,DC=company,DC=local.

The policy takes effect at the next Group Policy refresh interval on the user's computer. To apply the policy immediately, close all browser processes on the target computer, and then run gpupdate /force.

How to verify that the policy has been applied

info

Verify the policy on the user's computer.

Google Chrome

1. Open Google Chrome, and then enter chrome://policy in the address bar. The browser policies page opens.
2. Verify that the AuthServerAllowlist policy is listed under Chrome policies.

Microsoft Edge

1. Open Microsoft Edge, and then enter edge://policy in the address bar. The browser policies page opens.
2. Verify that the AuthServerAllowlist policy is listed under Microsoft Edge policies.

3. (Optional) Run PowerShell as an administrator and purge the cached Kerberos tickets:

   klist purge

4. (Optional) Request a service ticket for the PAM FQDN:

   klist get HTTP/<PAM FQDN>
   klist

   The output lists the following Kerberos tickets:

   • A ticket-granting ticket (TGT), which is used to request service tickets.
   • A service ticket (also called a TGS ticket), which is used to authenticate to the PAM console.

Sign in to PAM

info

Users from the connected Active Directory domain can sign in only with Kerberos.

Signing in with a username and password is available only for internal PAM users.

1. Open the PAM user console or administrator console.
2. Click Sign in with domain account.
3. (Optional) Provide your second authentication factor.

If the sign-in attempt fails, contact the PAM administrator.