Overview



Kerberos Protocol:

Kerberos is a cryptography-based authentication protocol that guards access to applications. This protocol is designed to provide secure authentication over an insecure network. The key idea behind Kerberos is to authenticate users while preventing passwords from being sent over the internet.


Kerberos terms:

Kerberos: Kerberos is an authentication protocol that supports the concept of Single Sign-On (SSO). In the case of HTTP, support for Kerberos is usually provided using the term "SPNEGO" authentication mechanism.

Kerberos Realm: An administrative domain for authentication is denoted by the term realm. Its goal is to define the restrictions on when an authentication server can authenticate a user, host, or service. This does not imply that a user and a service must be members of the same realm in order for authentication to occur: if the two objects are connected through a trust connection despite belonging to different realms, authentication can still occur.

Principal: In a Kerberos system, a Kerberos Principal represents a distinct identity to whom Kerberos can issue tickets for access to Kerberos-aware services. The "/" separator is used to separate the various components that make up principal names. The "@" character can be used to identify a realm as the name's final element. If no realm is specified, it is presumed that the Principal belongs to the default realm set in the krb5.conf file.

Clients/Users: a process that accesses a service on the behalf of a user. There can be multiple clients or users within a realm.

Service: Something the user wants to gain access to.

SSO: Single Sign-On is a procedure that enables a user to log in just once and access numerous services after completing user authentication. After logging into a primary service, this entails authentication into every service the user has granted authorization to. SSO has a number of advantages, one of which is the avoidance of the tiresome process of repeatedly validating identity using passwords or other authentication systems.

GSSAPI: Programs can access security services through the Generic Security Service Application Program Interface(GSSAPI), which is an application programming interface (API). An IETF standard is GSSAPI. It doesn't offer any security on its own. Instead, GSSAPI implementations are offered by security-service providers. The exchange of opaque messages (tokens), which conceals the implementation detail from the higher-level application, is the distinguishing characteristic of GSSAPI applications.

SPNEGO: Client-server software uses the Simple and Protected GSSAPI Negotiation Mechanism, frequently called "spen-go," to negotiate the selection of security technology. When a client application has to log in to a remote server but neither end is certain which authentication protocols the other supports, SPNEGO is employed. The pseudo-mechanism uses a protocol to identify the available common GSSAPI mechanisms, chooses one, and then assigns all subsequent security actions to that chosen mechanism.

KDC: A Key Distribution Center is a network service that supplies tickets and temporary sessions keys; or an instance of that service or the host on which it runs. The KDC services both initial ticket and ticket-granting requests. The initial ticket portion is sometimes referred to as the Authentication Server (or service). The ticket-granting ticket portion is sometimes referred to as the ticket-granting server (or service).


NTLM Authentication Protocol

A client's access to a resource on an Active Directory domain can be authenticated using the challenge-response authentication protocol known as Windows NT LAN Manager (NTLM). When a client requests access to a domain-related service, the service sends a challenge to the client, instructing it to use its authentication token to perform a mathematical operation, and then provide the outcome to the service. The result may be verified by the service or verified by the Domain Controller (DC). The service grants access to the client if the DC or service verifies that the client's response is accurate.
Because it allows the user to enter the underlying authentication factor only once, during login, NTLM is a sort of single sign-on (SSO).


Kerberos SSO NTLM Authentication Protocol
  • The NEGOTIATE_MESSAGE defines an NTLM Negotiate message that is sent from the client to the server. This message allows the client to specify its supported NTLM options to the server.
  • The CHALLENGE_MESSAGE defines an NTLM challenge message that is sent from the server to the client and it is used by the server to challenge the client to prove its identity.
  • The AUTHENTICATE_MESSAGE defines an NTLM authentication message that is sent from the client to the server after the CHALLENGE_MESSAGE is processed by the client.

Windows authentication uses either Kerberos authentication protocol or NTLM authentication protocol, depending on the client and server configurations.

Kerberos Authentication Protocol


A computer network security system called Kerberos authenticates service requests between two or more trusted hosts over an untrusted network, such as the internet.
  • Message A: Client/TGS Session Key encrypted using the secret key of the client/user.
  • Message B: Ticket-Granting-Ticket encrypted using the secret key of the TGS.
  • Message C: Composed of the TGT from message B and the ID of the requested service.
  • Message D: Authenticator encrypted using the Client/TGS Session Key.
  • Message E: Client-to-server ticket encrypted using the service's secret key.
  • Message F: Client/Server Session Key encrypted with the Client/TGS Session Key.
  • Message G: A new Authenticator, which includes the client ID, timestamp and is encrypted using Client/Server Session Key.
  • Message H: The timestamp found in the client's Authenticator encrypted using the Client/Server Session Key.

Kerberos SSO On Ubuntu/Debian



Step 1: Create Keytab file on the AD Domain Controller.

  • On the AD Domain Controller, execute the following command to create the Keytab file.
  • ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
    -pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytab

    Note: Ensure EXAMPLE.COM should be in uppercase. The Kerberos principle is case-sensitive. Please check for differences in upper/lower-case writing before running the keytab command.

  • The following are the components of the command.
  • Server Host Name: It is the host name of the site hosted on the Server.
    EXAMPLE.COM: It is the Active Directory Domain Name.
    Username: It is a service account in Active Directory.
    Password: It is the password of the service account used above.
    Path: Path to a local location which will store the keytab file. (C:\Temp\kerberos.keytab)

    Note: The above command creates a keytab file. It needs to be placed on the client server where your WordPress site is hosted. The user running Apache should have full access to this file. The user should have permission to the keytab file.

  • The Service Account has a few prerequisites:
    • The account password should have a password set to Not Expired.
    • The account should be trusted for delegation.
  • Copy the Keytab file from AD Domain Controller to the web server hosted on Apache.
  • Provide permission to kerberos keytab file:
  • chmod 644 etc/apache2/krb5.keytab

Step 2: Install kerberos client libraries on the web server.

  • Use the following command on your terminal to install the Kerberos client libraries.
  • sudo apt-get install krb5-user

    Note: In the most recent releases of Ubuntu/Debian, the mod_auth_kerb has been deprecated and replaced with the mod_auth_gssapi.


Step 3: Install modules for Apache.

    1: Install the mod_auth_kerb module for Apache.
  • Use the following command to install the auth_kerb module for Apache on debian-based systems:
  • sudo apt-get install libapache2-mod-auth-kerb
  • Once the auth_kerb module is installed, it needs to be enabled through the following command.
  • a2enmod auth_kerb
  • After enabling, Restart Apache to take effect.

    2: Install the mod-auth-gssapi module for Apache.
  • Use the following command to install the libapache2-mod-auth-gssapi module for Apache on debian-based systems:
  • sudo apt-get -y install libapache2-mod-auth-gssapi

Step 4: Configure the Active Directory domain in the Kerberos Configuration file.

  • Open and edit the /etc/apache2/krb5.conf file.
  • Add the following configuration snippet to the krb5.conf file under [realms] section:
  • [libdefaults]
    default_realm = EXAMPLE.COM
    # ...
    # ...
    [realms]
    EXAMPLE.COM = {
    kdc = <DNS entries pointing to your primary domain controller>: Port
    admin_server = <DNS entries pointing to your primary domain controller>: Port
    }
    [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM

    Note: Replace the AD DOMAIN CONTROLLER IP/DNS with your IP/DNS address. Ensure EXAMPLE.COM should be in upper case.
    Replace the EXAMPLE.COM with the Active Directory domain name.
    And ensure that the port 88 on the AD Domain Controller is accessible from this server.

  • Save the file.

Step 5: Configure Kerberos SSO for the site directory

  • Edit the /etc/apache2/sites-enabled/000-default.conf file.
  • Add the following section in the directory of the site for mod_auth_kerb.
  • <Directory "/placeholder">
        AuthType Kerberos
        KrbAuthRealms EXAMPLE.COM
        KrbServiceName HTTP/<Server Host Name>
        Krb5Keytab <PATH TO KEYTAB>
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        require valid-user
    </Directory>

  • Add the following section in the directory of the site for mod_auth_gssapi.
  • <IfModule !mod_auth_gssapi.c>
        LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
    </IfModule>
    <Directory "/placeholder">
        AuthType GSSAPI
        AuthName "Kerberos auth"
        GssapiAllowedMech krb5
        GssapiBasicAuth On
        GssapiCredStore keytab:/etc/krb.keytab
        GssapiLocalName On
        BrowserMatch Windows gssapi-no-negotiate
        Require valid-user
    </Directory>

    Note: Ensure EXAMPLE.COM should be in upper case.
    The following are the components of the above configuration:

    EXAMPLE.COM: This is the Active Directory domain as configured in krb5.conf.
    PATH TO KEYTAB: Accessible path to the keytab on this server.
  • After this configuration, Apache needs to be restarted for the changes to take effect.

Once you have finished configuring settings, click here to configure browsers for Kerberos SSO.

To test your Kerberos/NTLM SSO configuration, click here.

To troubleshoot any error, please click here.

Kerberos SSO On CentOS


Step 1: Create Keytab file on the AD Domain Controller.

  • On the AD Domain Controller, execute the following command to create the Keytab file.
  • ktpass -princ HTTP/<Server Host Name>@EXAMPLE.COM -mapuser <username@EXAMPLE.COM>
    -pass password -ptype KRB5_NT_PRINCIPAL -out <PATH>\spn.keytab

    NOTE: Ensure EXAMPLE.COM should be in uppercase. The Kerberos principle is case-sensitive. Please check for differences in upper/lower-case writing before running the keytab command.

  • The following are the components of the command.
  • Server Host Name: It is the host name of the site hosted on the Server.
    EXAMPLE.COM: It is the Active Directory Domain Name.
    Username: It is a service account in Active Directory.
    Password: It is the password of the service account used above.
    Path: Path to a local location which will store the keytab file. (C:\Temp\kerberos.keytab)

    Note: The above command creates a keytab file. It needs to be placed on the client server where your WordPress site is hosted. The user running Apache should have full access to this file.The user should have permission to the keytab file.


  • The Service Account has a few prerequisites:
    • The account password should have a password set to Not Expired.
    • The account should be trusted for delegation.
  • Copy the Keytab file from AD Domain Controller to the web server hosted on Apache.
  • Provide permission to kerberos keytab file:
  • chmod 644 etc/apache2/krb5.keytab

Step 2: Install kerberos client libraries on the web server.

  • Use the following command on your terminal to install the Kerberos client libraries.
  • yum install -y krb5-workstation krb5-devel krb5-libs mod_auth_gssapi mod_session

    Note: In the most recent releases of CentOS, the mod_auth_kerb has been deprecated and replaced with the mod_auth_gssapi.


Step 3: Install modules for Apache.

    1: Install the mod_auth_kerb module for Apache.
  • Use the following command to install the auth_kerb module for Apache on Red Hat-based systems.
  • yum install mod_auth_kerb
  • Restart Apache to take effect.

    2: Install the mod-auth-gssapi module for Apache.
  • Use the following command to install the libapache2-mod-auth-gssapi module for Apache on debian-based systems:
  • sudo apt-get -y install libapache2-mod-auth-gssapi

Step 4: Configure the Active Directory domain in the Kerberos Configuration file .

  • Open and edit the /etc/apache2/krb5.conf file.
  • Add the following configuration snippet to the krb5.conf file under [realms] section:
  • [libdefaults]
    default_realm = EXAMPLE.COM
    # ...
    # ...
    [realms]
    EXAMPLE.COM = {
    kdc = <DNS entries pointing to your primary domain controller>: Port
    admin_server = <DNS entries pointing to your primary domain controller>: Port
    }
    [domain_realm]
    .example.com = EXAMPLE.COM
    example.com = EXAMPLE.COM

    Note: Replace the AD DOMAIN CONTROLLER IP/DNS with your IP/DNS address. Ensure EXAMPLE.COM should be in upper case.
    Replace the EXAMPLE.COM with the Active Directory domain name.
    And ensure that the port 88 on the AD Domain Controller is accessible from this server.

  • Save the file.

Step 5: Configure Kerberos SSO for the site directory

  • Edit the auth_kerb.conf configuration file in the /etc/httpd/conf/ directory.
  • Add the following section in the directory of the site for mod_auth_kerb.
  • <Directory "/placeholder">
        AuthType Kerberos
        KrbAuthRealms EXAMPLE.COM
        KrbServiceName HTTP/<Server Host Name>
        Krb5Keytab <PATH TO KEYTAB>
        KrbMethodNegotiate on
        KrbMethodK5Passwd on
        require valid-user
    </Directory>

  • Add the following section in the directory of the site for mod_auth_gssapi.
  • <IfModule !mod_auth_gssapi.c>
        LoadModule auth_gssapi_module /usr/lib64/httpd/modules/mod_auth_gssapi.so
    </IfModule>
    <Directory "/placeholder">
        AuthType GSSAPI
        AuthName "Kerberos auth"
        GssapiAllowedMech krb5
        GssapiBasicAuth On
        GssapiCredStore keytab:/etc/krb.keytab
        GssapiLocalName On
        BrowserMatch Windows gssapi-no-negotiate
        Require valid-user
    </Directory>

    Note: Ensure EXAMPLE.COM should be in upper case.
    The following are the components of the above configuration:


    EXAMPLE.COM: This is the Active Directory domain as configured in krb5.conf.
    PATH TO KEYTAB: Accessible path to the keytab on this server.
  • After this configuration, Apache needs to be restarted for the changes to take effect.

Once you have finished configuring settings, click here to configure browsers for Kerberos SSO.

To test your Kerberos/NTLM SSO configuration, click here.

To troubleshoot any error, please click here.

SSO with Windows Authentication On IIS Server



  • Create a new user account (service account) in Active Directory Users and Computers. Ensure that this object does not have any SPN entries (servicePrincipalName attribute should be empty) allocated.
  • Open Command prompt in Administrator mode.
  • Execute the following command to add Service Principal Name (SPN) for the service account.
  • Note: Suppose, that the website has to respond at http://machinename and http://machinename.domain.com. We have to specify these addresses in the SPN attribute of the service account.

    Setspn -S http/<computer-name>.<domain-name> <domain-user-account>

    Example: C:\Users\Administrator> setspn -S HTTP/machinename.domain.com service_account

    Note: "machinename.domain.com" here is computer-name. Make sure it's resolvable on the Windows server running AD service.


  • Verify whether this has been properly set by running the following command:
  • setspn -l domain or service_account

    Example: C:\Users\Administrator> setspn -l service_account or C:\Users\Administrator> setspn -l domain_name

    Kerberos for windows authentication on IIS server set service principal name (SPN)
  • The result should list http/machinename.domain.com

  • Open Active Directory Users and Computers and from the top menu select View >> Advanced features.
  • Open the service account and go to the attribute editor tab, browse to the servicePrincipalName to verify the SPN entry.
  • Navigate to the Delegation tab.
  • Select Trust this user for delegation to any service (Kerberos only).
  • Kerberos for windows authentication on IIS server
  • Click Apply.
  • Open the IIS Manager and click on the website for which you want to enable the windows authentication.
  • Double click on Authentication.
  • internet information service IIS manager to configure authentication settings for sites
  • In the Authentication section, you can see only Anonymous Authentication is enabled by default. IIS always tries to perform anonymous authentication, So Disable Anonymous Authentication and Enable Windows Authentication.
  • internet information service IIS manager anonymous authentication and windows authentication
  • Right click on the Windows Authentication and click on the Providers.
  • internet information service IIS manager windows authentication providers list
  • The following window will appear. Make sure "Negotiate" is at the top of the list in the providers list.
  • internet information service IIS manager windows authentication providers list to enable providers

    Note: By default there are two providers available, Negotiate and NTLM. Negotiate is a container that uses kerberos as the first authentication method, and if the authentication fails, NTLM is used. So it is required that Negotiate comes first in the list of providers.


  • Click on Ok to close the window.
  • To Configure the IIS Application Pool to launch it from the SPN account created, Click on the Application Pools to open the Application Pools window.
  • Right click on the domain and from the list click on the Advanced Settings.
  • internet information service IIS manager application pool site advanced settings
  • In the Advanced Settings window under Process Model click on the Identity.
  • internet information service IIS manager application pool advanced settings identity
  • In the Application Pool Identity, select Custom Account and click on the set button to set the Identity.
  • Change it from ApplicationPoolIdentity to <domain_name>\<username>.
  • Example:domain.com\service_account

    internet information service IIS manager application pool identity settings custom account
  • Go to the Configuration Editor.
  • internet information service IIS manager configuration editor
  • From the dropdown, select system.webServer > security > authentication > windowsAuthentication.
  • internet information service IIS manager site configuration settings useAppPoolCredentials
  • Change useAppPoolCredentials to True. and useKernelMode to False.
  • Note: Setting useAppPoolCredentials to True means that we allow IIS to use the domain account to Decrypt Kerberos ticket from the clients.

  • Click Apply.
  • Restart IIS server.

  • You can check that kerberos authentication is being used on the website by monitoring HTTP traffic using Fiddler.
  • Launch the fiddler and launch the browser to the desired website. Locate the line of website access in the window's left side. Select the Inspect tab from the window's right side. It is evident that Kerberos has been used to authenticate on the IIS website from the line "Authorization Header (Negotiate) appears to contain a Kerberos ticket."

    fiddler Authorization Header Negotiate appears Kerberos ticket

Once you have finished configuring settings, click here to configure browsers for Kerberos SSO.

To test your Kerberos/NTLM SSO configuration, click here.

To troubleshoot any error, please click here.

SSO with Apache on Windows Xampp Server



  • Create a new user account (service account) in Active Directory Users and Computers. Ensure that this object does not have any SPN entries (servicePrincipalName attribute should be empty) allocated.
  • Open Command prompt in Administrator mode.
  • Execute the following command to add Service Principal Name (SPN) for the service account.
  • Setspn -s http/<computer-name>.<domain-name> <domain-user-account>

    Example: C:\Users\Administrator> setspn -S HTTP/machinename.domain.com service_account

    Note: "machinename.domain.com" here is computer-name. Make sure it's resolvable on the Windows server running AD service.

  • Verify whether this has been properly set by running the following command:
  • setspn -l domain\service_account
  • The result should list http/machinename.domain.com
  • Open Active Directory Users and Computers and from the top menu select View >> Advanced features.
  • Open the service account and go to the attribute editor tab, browse to the servicePrincipalName to verify the SPN entry.
  • Navigate to the Delegation tab.
  • Select Trust this user for delegation to any service (Kerberos only).
  • Kerberos for windows authentication on IIS server
  • Click Apply.

  • Click Here to download the apache module.
  • Copy the mod_authnz_sspi.so from Apache24 > modules folder and place it in the modules (C:\xampp\apache\modules) directory.
  • Copy the sspipkgs.exe file from Apache24 -> bin folder and place it in the bin folder of your Xampp apache folder (.....\xampp\apache\bin) on your webserver.
  • Open httpd.conf (.....\xampp\apache\conf) and place the below line of code in the LoadModule section.
  • LoadModule authnz_sspi_module modules/mod_authnz_sspi.so
  • Make sure that the following modules are uncommented:
  • LoadModule authn_core_module modules/mod_authn_core.so
    LoadModule authz_core_module modules/mod_authz_core.so

  • Also, make sure to enable ldap extension.
  • Open the httpd.conf file from (.....\xampp\apache\conf\httpd.conf).
    Go to and paste the below lines after #Require all grants.
  • <Directory "...../xampp/htdocs">
    ......
    ......
    #Require all granted
    AllowOverride None Options None
    AuthType SSPI
    SSPIAuth On
    SSPIAuthoritative On
    Require valid-user
    </Directory>

  • Restart your Apache Server.

Once you have finished configuring settings, click here to configure browsers for Kerberos SSO.

To test your Kerberos/NTLM SSO configuration, click here.

To troubleshoot any error, please click here.

Configure browsers for Kerberos SSO



The client-side configuration enables the respective browser to use SPNEGO to negotiate Kerberos authentication for the browser. You must make sure that the browser on an end user's system is configured to support Kerberos authentication.


General Kerberos SSO Configuration for all Browsers


  • Go to Control Panel and click on Network and Internet >> Internet Options.
  • This will open a Internet Properties window. Click on Security >> Local Intranet >> Sites.
  • Configure internet explorer settings for Kerberos Authentication

  • After that, click on the Advanced button.
  • Configure internet explorer settings for Kerberos Authentication advanced settings

  • In the Add this website to the zone section add the website URL that you wish to login with SSO.
  • Configure internet explorer settings for Kerberos
  • Click Tools > Internet Options > Security > Local intranet > Custom Level.
  • Scroll down to the User Authentication options and select Automatic logon only in the Intranet zone.
  • automatic logon to the intranet zone
  • Click on Ok button and then restart your browser.


Once done with the above settings, you need not to configure the browser settings for internet explorer, Google Chrome and Apple Safari.


1. Internet Explorer
2. Google Chrome
3. Mozilla Firefox
4. Apple Safari


Internet Explorer

By default the general browser configuration settings will be applicable, no more additional settings are required for Internet Explorer.



Google Chrome

By default the general browser configuration settings will be applicable, no more additional settings are required for Google Chrome.



Mozilla Firefox

  • Open Mozilla Firefox browser and enter about:config in the address bar.
  • Search for network.negotiate-auth.trusted-uris Preference Name, and click on Edit. enter the hostname or the domain of the web server that is protected by Kerberos HTTP SPNEGO. Specify multiple domains and hostnames separated with a comma.
  • configure mozilla Firefox settings for kerberos authentication
  • Search for network.automatic-ntlm-auth.trusted-uris Preference Name, and click on Edit. enter the hostname or the domain of the web server that is protected by Kerberos HTTP SPNEGO. Specify multiple domains and hostnames separated with a comma.
  • configure mozilla Firefox settings for kerberos authentication
  • Click OK and then restart your browser.


Apple Safari

  • Safari on windows supports SPNEGO with no furthere configuration. It supports both kerberos and NTLM as sub mechanism of SPENGO.

Test your Kerberos/NTLM SSO Configuration



Time Synchronization

The Kerberos protocol requires the time of the client and server to match: if the system clock of the client does not match that of the server, authentication will fail. The simplest way to synchronize the system clocks is to use a Network Time Protocol (NTP) server.


Verify With Commands.

To verify your keytab and kerberos configuration, you can run the following commands:

  1. Klist
  2. The klist command displays the contents of a Kerberos credentials cache or key table. With this command you can check if you got a valid ticket or not.

  3. klist -t -k etc/apache2/krb5.keytab
  4. To list all of the entries in the etc/apache2/krb5.keytab key table with timestamps.

  5. klist -ek /etc/apache2/krb5.keytab
  6. Displays the encryption type for the session key and the ticket and lists the entries in a key table.

  7. kinit -V -kt /etc/apache2/krb5.keytab -p HTTPS/webserver.yourdomain.com@YOURDOMAIN.COM
  8. Verify Kerberos Authentication with keytab file.

  9. kdestroy -A
  10. You can use the this command on Linux to reset any Kerberos token on your local machine. The command destroy your previous Kerberos ticket.

  11. klist purge
  12. You can use the this command on Windows to reset any Kerberos token on your local machine. The command destroy your previous Kerberos ticket.


Test Configuration.

  • To test the SSO configuration create a test.php file in your WordPress root directory.
    Enter the below line:
  • <?php
    var_dump($_SERVER);
    ?>
  • Save the file and access it in the web browser. You will see the $_SERVER content.
  • Search for "REMOTE_USER" and it should contain the currently logged in username.
  • Note: Please remove the test.php file after verifying your configuration. As it contains some valuable information.


Kerberos Authentication Across Multiple Domains



  • Create separate Keytabs on each domain and merge them with the ktutil tool:
  • ktutil
    ktutil: read_kt <keytab_filename_1>
    ktutil: read_kt <keytab_filename_2>
    ktutil: read_kt <keytab_filename_3>
    ktutil: write_kt krb5.keytab
    ktutil: quit

  • Verify the merge with the below command:
  • klist -k krb5.keytab
  • Configure krb5.conf:
    The krb5.conf file contains Kerberos configuration information which includes KDC & admin servers for one or more Kerberos realms, default values for the current realm and mappings of hostnames onto Kerberos realms. In case of multiple domains the krb5.conf file should be updated with information about various domains/domain realms for authentication to work.

Troubleshooting



These are the most common error messages:

    Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
    or
    kinit: krb5_get_init_creds: Too large time skew
  • Kerberos is very time sensitive. Verify that the clocks on the hosts for Active Directory and the web server are identical. Set up one of your domain controllers to serve as the NTP server for your client computers.

  • gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
  • Wrong file system permissions for /etc/apache2/krb5.keytab, i.e. not readable for the webserver's Linux user.
  • To change file system permissions use chmod 644 /etc/apache2/krb5.keytab

  • gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Key table entry not found).
  • Missing service principal (possibly HTTP/webserver.yourdomain.com@YOURDOMAIN.COM) in /etc/apache2/krb5.keytab.

  • Warning: received token seems to be NTLM, which isn't supported by the Kerberos module. Check your IE configuration. gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error)
  • The website is not in the zone "Local Intranet" in IE or IE is configured incorrectly, see Authentication Uses NTLM instead of Kerberos.

  • gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ).
  • Wrong kvno or machine password in etc/apache2/krb5.keytab. Recreate the keytab using the correct information.
  • Problem with local Kerberos ticket cache on your workstation, use Kerbtray.exe to purge the ticket cache and open the website in IE again.

  • kinit: KDC has no support for encryption type while getting initial credentials
  • Change the default encryption type in the libdefaults section of the /etc/apache2/krb5.conf file. Add the default_tgs_enctypes and default_tkt_enctypes to your config.
  • [libdefaults]
    default_tgs_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5
    default_tkt_enctypes = arcfour-hmac-md5 des-cbc-crc des-cbc-md5

    kinit: krb5_get_init_creds: Error from KDC: CLIENT EXPIRED
    or
    kinit: Client's entry in database has expired while getting initial credentials
  • Your Kerberos account is no longer active. The account credentials need to be renewed.

  • kinit: krb5_cc_get_principal: No credentials cache file found
    or
    kinit: krb5_get_init_creds: Error from KDC: CLIENT_NOT_FOUND
  • The wrong domain was targeted when running the kinit command. Verify the domain name, it should be in capital letters EXAMPLE.COM

  • kinit : Cannot find KDC for requested realm while getting initial credentials
  • /etc/apache2/krb5.conf file does not contain the active directory domain name (.EXAMPLE.COM).

  • kinit: Preauthentication failed while getting initial credentials
  • Caused by mistakenly typing the kerberos password. Please try again. Or due to your system's clock. Make sure that the date command returns a time correct to within 5 minutes.

  • kinit: Client not found in Kerberos database while getting initial credentials
  • Your kerberos principal may differ from your username on your local system.

  • kinit: Client's entry in database has expired
  • You must change your kerberos password.

Hello there!

Need Help? We are right here!

support
Contact miniOrange Support
success

Thanks for your inquiry.

If you dont hear from us within 24 hours, please feel free to send a follow up email to info@xecurify.com