Home / Why Ansible Engine / Tower job fail with ‘Server not found in Kerberos database’ Error ?

Why Ansible Engine / Tower job fail with ‘Server not found in Kerberos database’ Error ?

My playbook job fails with the error “Server not found in Kerberos database” when executed against a Windows server with Kerberos authentication.

TASK [Ping host] ******************************************************************************************************************************************************************************************
fatal: [host01.mydomain.com]: UNREACHABLE! => {"changed": false, "msg": "kerberos: authGSSClientStep() failed: (('Unspecified GSS failure. Minor code may provide more information', 851968), ('Server not found in Kerberos database', -1765328377))", "unreachable": true}

For Kerberos to function, the environment must be set up correctly. Error message “Server not found in Kerberos database” denotes a problem with Kerberos settings. Check the following methods to troubleshoot Kerberos issues:

Verify that the remote managed node joins the domain you’ve set up in /etc/krb5.conf.

Verify the correct configuration of the /etc/krb5.conf Kerberos configuration file.

The documentation link below includes an example of a Kerberos configuration file:

Here is an excellent example of a krb5.conf configuration.

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
default_realm = AD.ISHWAR.IO
dns_lookup_realm = false
dns_lookup_kdc = false
ticket_lifetime = 24h
rdns = false
renew_lifetime = 7d
forwardable = true

[realms]
AD.ISHWAR.IO = {
kdc = ad.ishwar.io
admin_server = ad.ishwar.io
}

[domain_realm]
.ad.ishwar.io = AD.ISHWAR.IO
ad.ishwar.io = AD.ISHWAR.IO

An FQDN, not an IP address, is used as the hostname for the Windows host. An example is given below.

PS C:Userssetupadmin> net config workstation | findstr /C:"Full Computer name"
Full Computer name win1.ad.ishwar.io

In the domain, both forward and reverse DNS lookups function as intended. Ping the Windows host by name and then use the IP address obtained from a nslookup to test this. The same name should be returned when using nslookup on the IP address. Alternatively, you can use nslookup on the DNS name and check if the returned IP has the same name. You won’t need reverse DNS to function if rdns = false was specified in the [libdefaults] section of the krb5.conf file. However, set the reverse DNS PTR record for testing on the problematic remote node.

The clock of the domain controller and the Ansible host are in sync. A small amount of clock drift can result in the ticket generation process failing because Kerberos is time-sensitive.

Make that the krb5.conf file has the domain’s fully qualified domain name specified. Check to verify this as below.

kinit -C username@MY.DOMAIN.COM
klist

As an example.

[root@centos ~]# kinit -C setupadmin@AD.ISHWAR.IO
Password for setupadmin@AD.ISHWAR.IO:

[root@centos ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: setupadmin@AD.ISHWAR.IO

Valid starting Expires Service principal
03/18/2020 09:41:36 03/18/2020 19:41:36 krbtgt/AD.ISHWAR.IO@AD.ISHWAR.IO
renew until 03/25/2020 09:41:31

An alias is utilized if the domain name supplied by klist differs from the requested one. It is necessary to edit the krb5.conf file so that the fully qualified domain name rather than an alias is utilized.

Verify the remote host’s service principal settings. The setspn -l HOSTNAME command is accessible from a Powershell window.
for instance:

PS C:Userssetupadmin> hostname
win1

PS C:Userssetupadmin> setspn -l win1 Registered ServicePrincipalNames for CN=WIN1,OU=Computers,OU=Cloud,DC=ad,DC=ishwar,DC=io: Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/win1.ad.ishwar.io TERMSRV/WIN1 TERMSRV/win1.ad.ishwar.io WSMAN/win1 WSMAN/win1.ad.ishwar.io RestrictedKrbHost/WIN1 HOST/WIN1 RestrictedKrbHost/win1.ad.ishwar.io HOST/win1.ad.ishwar.io PS C:Userssetupadmin>

Check whether you can access a remote host’s service principle ticket. You can employ the command kinit -S SERVICE PRINCIPAL OF THE HOST. For instance:

[root@centos ~]# kdestroy

[root@centos ~]# kinit setupadmin@AD.ISHWAR.IO
Password for setupadmin@AD.ISHWAR.IO:

[root@centos ~]# kinit -S HOST/win1.ad.ishwar.io
Password for setupadmin@AD.ISHWAR.IO:

[root@centos ~]# klist
Ticket cache: FILE:/tmp/krb5cc_0
Default principal: setupadmin@AD.ISHWAR.IO

Valid starting Expires Service principal
03/18/2020 09:31:17 03/18/2020 19:31:17 HOST/win1.ad.ishwar.io@AD.ISHWAR.IO
renew until 03/25/2020 09:31:10

You can set export KRB5_TRACE=/dev/stdout to get kinit commands to print more verbosely.

The Python Kerberos library installation or upgrade may encounter problems if the default Kerberos toolset has been changed or replaced (specific IdM solutions may do this). Check that the system requirements for Kerberos have been satisfied (see: Installing the Kerberos Library), delete any customized Kerberos tools paths from the PATH environment variable, and then try installing the Python Kerberos library package again to remedy installation problems.

This library, known as pykerberos as of the time of writing, is known to function with both the Heimdal and MIT Kerberos libraries.

Leave a Reply