I'm developing using the GSSAPI, and I have code which works with a vanilla MIT Kerberos 5 server to do some client/server work. I'm now verifying it's functionality against Active Directory and I've hit an issue.

I have my server authenticated and listening. I can get the client to login. For the record, this is code based off of . However, I cannot get the client to get the ticket back from AD to get the session between it and the server. I get KrbException: Server not found in Kerberos database (7), and I cannot figure out where the proper place is to add it. I've tried putting the server name with ip in the hosts file, updating dns, putting in server records, etc, with no luck.

If anyone knows where the proper place is to update AD to set a server in the Kerberos Database, that would be great!

10 Answers

This exception comes from the client, right? Please perform a forward and reverse DNS lookup of the server hostname. Your server has incorrect DNS entries. They are absolutely crucial for Kerberos. The proper place is your DNS server, in your case: domain controller. Figure out the IP address of your DNS server and contact your admin. The other option is a missing SPN, please check that too.

21

I hope this helps .. I got this same error message (Server not found in Kerberos database (7)) but this occurs after the successful use of the keytab to login.

The error message occurs when we attempt to use the credentials to do LDAP searches against AD.

This has only started happening since java 1.6.0_34 - it worked with 1.6.0_31 which I think was previous release. The error occurs because the java doesn't trust that the KDC it is communicating with for LDAP is actually part of the Kerberos realm. In our case, I think it is because the LDAP connection is made with the server name found via the round-robin'd resolved query. That is, java resolves realm.example.com, but gets any one of kdc1.example.com or kdc2.example .com ..etc). They must have tightened the checking betweeen these releases.

In our case the problem was worked around by setting the ldap server name directly rather than relying on DNS.

But investigations continue.

2

In my case, it's caused by wrong configuration of the requested server's address.

The server address should be an FQDN (fully qualified domain name).

FQDN is always required by Kerberos.

1

This looks like a missing SPN issue. The website you had pointed to has 

principal="webserver/"

This is the principal for which the ticket would be obtained. Did you change this to a value relative to your AD domain?

You could use the command line kerberos tools to test if you have the SPN defined:

[root@gen-cs218 bin]# kinit Administrator 's Password: [root@gen-cs218 bin]# kgetcred host/ [root@gen-cs218 bin]# klist Credentials cache: FILE:/tmp/krb5cc_0 Principal: Issued Expires Principal <br> Dec 15 11:42:34 2012 Dec 15 21:42:34 2012 krbtgt/ Dec 15 11:42:48 2012 Dec 15 21:42:34 2012 host/

Hostname based SPNs are pre-defined. If you want to use a SPN that is not pre-defined you will have to explicitly define it in AD using the setspn.exe tool and associate it with either a computer or an user account, for example:

c:\> setspn.exe -A "webserver/bully@MYDOMAIN" myuser

You can check which account a SPN is associated with by using the command below. This will not show pre-defined SPNs.

c:\> setspn.exe -L "webserver/bully@MYDOMAIN"

"Server not found in Kerberos database" error can happen if you have registered the SPN to multiple users/computers.

You can check that with:

$ SetSPN -Q ServicePrincipalName ( SetSPN -Q HTTP/my.server.local@MYDOMAIN )

sqlcmd works, System.Data.SqlClient not working - Server not found in Kerberos database. You should add RestrictedKrbHost SPN

5.1.2 SPNs with Serviceclass Equal to "RestrictedKrbHost"

Supporting the "RestrictedKrbHost" service class allows client applications to use Kerberos authentication when they do not have the identity of the service but have the server name. This does not provide client-to-service mutual authentication, but rather client-to-server computer authentication. Services of different privilege levels have the same session key and could decrypt each other's data if the underlying service does not ensure that data cannot be accessed by higher services.

Just if someone has a similar setup...

  1. I was setting up an windows active directory (AD) server under Windows Server 19 similar to this tutorial
  2. And wanted to authenticate a Debian client against it (with sssd), using this tutorial.

I got the error message ...

msktutil: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Server not found in Kerberos database)

... when I tried to add my client machine as a COMPUTER to the AD:

msktutil -N -c -b 'CN=COMPUTERS' -s DEBIAN/debian.ad.local -k my-keytab.keytab --computer-name DEBIAN --upn DEBIAN$ --server winserv19.ad.local --user-creds-only

Could fix the error by:

  1. Adding of course the DNS server IP to the /etc/resolv.conf
  2. Adding a reverse lookup zone on to the DNS Server (running also on the Win Serv 19, next to AD DS) Windows Server 19 DNS Reverse Lookup Zone
  3. Activating the Update associated pointer (PTR) record option in the forward lookup entries on the win DNS server Windows Server 19 DNS A Record PTR Option

In my case, My principal was kafka/ I got below lines in the terminal:

>>> KrbKdcReq send: #bytes read=190 >>> KdcAccessibility: remove kerberos.niroshan.com >>> KDCRep: init() encoding tag is 126 req type is 13 >>>KRBError: cTime is Thu Oct 05 03:42:15 UTC 1995 812864535000 sTime is Fri May 31 06:43:38 UTC 2019 1559285018000 suSec is 111309 error code is 7 error Message is Server not found in Kerberos database cname is kafka/ sname is kafka/ msgType is 30

After hours of checking, I just found the below line has a wrong value in kafka_2.12-2.2.0/server.properties

listeners=SASL_PLAINTEXT://kafka.com:9092

Also I got two entries of kafka.niroshan.com and kafka.com for same IP address.

I changed it to as listeners=SASL_PLAINTEXT://kafka.niroshan.com:9092 Then it worked!

According to the below link, the principal should contain the Fully Qualified Domain Name (FQDN) of each host and it should be matched with the principal.

You would be surprised if I told you that I received this error when the UPN search was not returning any entry, meaning the user is not found, instead of getting a clear indication that the query returned no items.

So I recommend revising your query part or using AdExplorer to make sure that the users/groups you are looking for are reachable by the query you are using (depending on what you are using as an attribute for search sAMAccount, userPrincipalName, CN, DN).

Please note this can also happen when the AD you are connecting to is trying to find that user in another AD instance that your machine could not reach as part of your connections settings to that initial AD instance.

params.put(Context.REFERRAL, "follow");

Consider adding

[appdefaults] validate=false

to your /etc/krb5.conf. This can work around mismatching DNS.

0