Search Results :
×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: 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).
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).
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. If the user with SPN is already exist, use that user insted creating a new one. The Kerberos principle is case-sensitive. Please check for differences in upper/lower-case writing before running the keytab 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\spn.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.
chmod 644 etc/apache2/spn.keytab
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.
sudo apt-get install libapache2-mod-auth-kerb
a2enmod auth_kerb
sudo apt-get -y install libapache2-mod-auth-gssapi
[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.
Note: Add the following section in the directory according to the apache module used. Eg: "mod_auth_kerb" or "mod_auth_gssapi".
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
<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:<PATH TO 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. (etc/apache2/spn.keytab) |
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.
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.
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\spn.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.
chmod 644 etc/apache2/spn.keytab
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.
yum install mod_auth_kerb
sudo apt-get -y install libapache2-mod-auth-gssapi
[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.
<Directory "/placeholder">
AuthType Kerberos
KrbAuthRealms EXAMPLE.COM
KrbServiceName HTTP/<Server Host Name>
Krb5Keytab <PATH TO KEYTAB>
KrbMethodNegotiate on
KrbMethodK5Passwd on
require valid-user
</Directory>
<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:<PATH TO 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. (etc/apache2/spn.keytab) |
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.
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.
setspn -l domain or service_account
Example: C:\Users\Administrator> setspn -l service_account or C:\Users\Administrator> setspn -l domain_name
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.
Example:domain.com\service_account
Note: Setting useAppPoolCredentials to True means that we allow IIS to use the domain account to Decrypt Kerberos ticket from the clients.
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."
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.
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.
setspn -l domain\service_account
LoadModule authnz_sspi_module modules/mod_authnz_sspi.so
LoadModule authn_core_module modules/mod_authn_core.so
LoadModule authz_core_module modules/mod_authz_core.so
<Directory "...../xampp/htdocs">
......
......
#Require all granted
AllowOverride None Options None
AuthType SSPI
SSPIAuth On
SSPIAuthoritative On
Require valid-user
</Directory>
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.
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.
By default the general browser configuration settings will be applicable, no more additional settings are required for Internet Explorer.
By default the general browser configuration settings will be applicable, no more additional settings are required for Google Chrome.
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.
To verify your keytab and kerberos configuration, you can run the following commands:
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.
To list all of the entries in the etc/apache2/spn.keytab key table with timestamps.
Displays the encryption type for the session key and the ticket and lists the entries in a key table.
Verify Kerberos Authentication with keytab file.
You can use the this command on Linux to reset any Kerberos token on your local machine. The command destroy your previous Kerberos ticket.
You can use the this command on Windows to reset any Kerberos token on your local machine. The command destroy your previous Kerberos ticket.
<?php
var_dump($_SERVER);
?>
Note: Please remove the test.php file after verifying your configuration. As it contains some valuable information.
ktutil
ktutil: read_kt <keytab_filename_1>
ktutil: read_kt <keytab_filename_2>
ktutil: read_kt <keytab_filename_3>
ktutil: write_kt spn.keytab
ktutil: quit
klist -k spn.keytab
Unspecified GSS failure. Minor code may provide more information (Clock skew too great)
or
kinit: krb5_get_init_creds: Too large time skew
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Permission denied)
gss_acquire_cred() failed: Unspecified GSS failure. Minor code may provide more information (, Key table entry not found).
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)
gss_accept_sec_context() failed: Unspecified GSS failure. Minor code may provide more information (, ).
kinit: KDC has no support for encryption type while getting initial credentials
[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
kinit: krb5_cc_get_principal: No credentials cache file found
or
kinit: krb5_get_init_creds: Error from KDC: CLIENT_NOT_FOUND
kinit : Cannot find KDC for requested realm while getting initial credentials
kinit: Preauthentication failed while getting initial credentials
kinit: Client not found in Kerberos database while getting initial credentials
kinit: Client's entry in database has expired