Kerberos/NTLM Single Sign On (SSO)

This happens when the NTLM protocol is used for Authentication instead of Kerberos.
This may occur due to multiple reasons:

• Check if you are using a domain joined machine to access the website.
• Make sure the time is synchronized between the LDAP server and webserver.
• Confirm if your browser settings and Internet options are configured for Kerberos SSO.
• If you are still facing this issue, feel free to contact us.

Yes, you can use an existing LDAP user as a Kerberos service principal. However, this user must have a password set to never expire. Kindly make sure this account is not used by any user as the application uses this account as the Kerberos service principal and the corresponding keytab to obtain a kerberos ticket.

All authentication in Kerberos occurs between clients and servers. Therefore, any entity that receives a service ticket for a Kerberos service is referred to as a "Kerberos client" in Kerberos terminology. Users are often considered clients, but any principal might be one.
The Key Distribution Center, or KDC for short, is typically referred to as a "Kerberos server". Both the Authentication Service (AS) and the Ticket Granting Service (TGS) are implemented by the KDC. Every password connected to every principal is stored in the KDC. Because of this, it is essential that the KDC be as safe as feasible.
The phrase "application server" often refers to Kerberized software that clients use to interact while authenticating using Kerberos tickets. An example of an application server is the Kerberos telnet daemon.

In theory, the realm name is arbitrary. You can name your realms whatever you want.
In practice a Kerberos realm is named by uppercasing the DNS domain name associated with the hosts in the to-be named realm. For example if your hosts are all in the "example.com" domain, you might call your Kerberos realm as "EXAMPLE.COM".
If you wish to have two Kerberos realms in the DNS domain "miniorange.com" for Human Resource and Sales, you might create the Kerberos realms as "HR.MINIORANGE.COM" and "SALES.MINIORANGE.COM"
The convention to use uppercase for realms names is to easily distinguish between DNS domain names (which are actually case-insensitive) and kerberos realms.
The recent revisions to the Kerberos standard have specified that uppercase realm names are preferred and lowercase realm names have been deprecated.

On each application server, you'll need to put:

• A Kerberos configuration file (/etc/krb5.conf).
• The Kerberos application server daemons (telnetd, rlogind, ftpd, etc).
• At least one encryption key (usually stored in /etc/krb5.keytab).

The portion that is most important is the encryption key; it must be sent to the application server host in a safe manner. Usually, the host principal (host/example.com@REALM) uses this key. It should be noted that the MIT admin client kadmin encrypts every transfer between it and the admin server, making it safe to use ktadd from within kadmin as long as you're not transmitting your admin password over the network in clear text.
If you intend to have interactive user logins on your application servers, you'll probably also want to install the Kerberos client binaries on each one.

GSSAPI is an acronym; it stands for Generic Security Services Application Programming Interface.
Client-server authentication is handled using the GSSAPI, a general-purpose API. The reasoning for it is because each security system has its own API, and because security APIs differ so much, it takes a lot of work to add various security systems to apps. The generic API could be written to by application providers, and it would be compatible with a wide range of security systems if there were a common API.

Any Kerberos principal can establish an authentication connection with another principal inside the same Kerberos realm. However, a Kerberos realm can also be set up to allow principals from different realms to authenticate with one another. This is called cross-realm authentication.
This is accomplished by having the KDCs in the two realms share a unique cross-realm secret, which is used to validate the identification of principals when they cross the realm border.

In Kerberos 5 you can not change the master key.
You have the option to modify the master key using the kadmin. The master key, however, is used to encrypt every database entry and is most likely also kept in a stash file (depending on your site). The stash file or all of the database records won't be updated if the master key is changed using kadmin.
To change the master key, Kerberos 4 offered a command, and it carried out the necessary actions. For Kerberos 5, no one has (yet) implemented this capability.