Join Log in
Score:0
avatar Server

Cannot obtain credentials for computer account - client not found in kerberos database

mm flag
Ronny

I have successfully joined an ubuntu machine (Ubuntu 20.04 LTS) to an Active Directory. Therefore, I can log in with AD-Accounts, obtain and renew the ticket grantin ticket for the user, and access network shares with Kerberos authentication.

However, I struggle to obtain the initial credentials for the computer account:

admin@comp01:~$ sudo KRB5_TRACE=/dev/stdout kinit -kt /etc/krb5.keytab
[sudo] password for admin:
[232252] 1645435537.855061: Getting initial credentials for host/[email protected]
[232252] 1645435537.855062: Looked up etypes in keytab: rc4-hmac, aes128-cts, aes256-cts
[232252] 1645435537.855064: Sending unauthenticated request
[232252] 1645435537.855065: Sending request (187 bytes) to COMPANY.LAN
[232252] 1645435537.855066: Sending initial UDP request to dgram 172.27.17.6:88
[232252] 1645435537.855067: Received answer (84 bytes) from dgram 172.27.17.6:88
[232252] 1645435537.855068: Response was from master KDC
[232252] 1645435537.855069: Received error from KDC: -1765328378/Client not found in Kerberos database
kinit: Client 'host/[email protected]' not found in Kerberos database while getting initial credentials

I have spent several hours on that issue without progress. Probably I am missing some essential steps. The requested principal is contained in the local keytab on the ubuntu machine:

root@comp01:~$ klist -kte
Keytab name: FILE:/etc/krb5.keytab
KVNO Timestamp           Principal
---- ------------------- ---------------------------------------------
   4 02/17/2022 07:34:59 [email protected] (arcfour-hmac)
   4 02/17/2022 07:34:59 [email protected] (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 [email protected] (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/[email protected] (arcfour-hmac)
   4 02/17/2022 07:34:59 host/[email protected] (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/[email protected] (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/[email protected] (arcfour-hmac)
   4 02/17/2022 07:34:59 host/[email protected] (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 host/[email protected] (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (arcfour-hmac)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (arcfour-hmac)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/[email protected] (aes256-cts-hmac-sha1-96)

And the principal is also registered on the AD-Domain controller:

> setspn -L comp01
Registrierte Dienstprinzipalnamen (SPN) für CN=COMP01,CN=Computers,DC=company,DC=lan:
            RestrictedKrbHost/comp01.company.lan
            host/comp01.company.lan
            RestrictedKrbHost/COMP01
            host/COMP01

The ubuntu machine has been joined to the AD-Domain using

> realm join company.lan

And the Kerberos configuration file is as follows:

[libdefaults]
        default_realm = COMPANY.LAN
        ccache_type = 4
        forwardable = true
        proxiable = true
        fcc-mit-ticketflags = true
[realms]
        COMPANY.LAN = {
                kdc = DC.company.lan
                admin_server = DC.company.lan
                default_domain = company.lan
        }
[domain_realm]
        .company.lan = COMPANY.LAN
        company.lan = COMPANY.LAN

Forward and reverse DNS are also looking good:

> nslookup comp01
Server:  DC.company.lan
Address:  172.27.17.41

Name:    comp01.company.lan
Address:  172.27.17.131

> nslookup 172.27.17.131
Server:  DC.company.lan
Address:  172.27.17.41

Name:    comp01.company.lan
Address:  172.27.17.131

I am really thankful for any hint that guides me in the right direction.

122
0 + 0
Semicolon avatar
jo flag
Semicolon
The syntax that works for me translated to your network (use the sAMAccountName of the computer object, at the FQDN of the domain: " kinit -k [email protected]
1
Reply
mm flag
Ronny
@Semicolon I have tried the following (I suppose the position of the dollar sign was intentionally right after the computer name?): `kinit -kt /etc/krb5.keytab [email protected]` `kinit -kt /etc/krb5.keytab [email protected]` and `kinit -kt /etc/krb5.keytab [email protected]` All attempts end up with the following result: `kinit: Keytab contains no suitable keys for [email protected] while getting initial credentials` Only the principal names are different: [email protected], [email protected] and [email protected]
0
Reply
Calchas avatar
br flag
Calchas
How did you obtain this keytab? Note that dollar is a special character in POSIX shells, so you'll have to escape it. A better way to check if a principal exists in the database is with the `kvno` tool.
0
Reply
mm flag
Ronny
@Semicolon You were totally right, but I was too blind to see the solution. Pitfall: I needed to place tick marks around the identifier; otherwise, the $ gets replaced with "COMPANY.LAN", leading to the odd credentials in my previous comment. I only realized the problem after the answer from @user1686 . Therefore, the successful command to obtain the ticket is `kinit -kt /etc/krb5.keytab '[email protected]'` Thank you very much for your help!
1
Reply
Score:1
user1686 avatar Server
fr flag
user1686

With Active Directory-flavoured Kerberos there is a distinction between "user" (client) and "service" (target) principal names. Specifically, only the account's sAMAccountName can act as the client principal, its SPNs cannot.

The account name of computer objects is always the hostname in upper case and suffixed with a $, e.g. for a computer named "COMP01" the account name would be COMP01$.

Meanwhile host/comp01 and host/comp01.company.lan only exist as service principals – an AD KDC will issue tickets for clients requesting "host/comp01" as the target server, but doesn't allow them to act as clients during initial authentication. They exist in your keytab only to be used on the "acceptor" side.

0 + 0
mm flag
Ronny
Indeed, that has solved my problem! In combination with the comment from @Semicolon I was able to obtain a ticket using `kinit -kt /etc/krb5.keytab '[email protected]'` (Dollar suffix and tick marks are very important!) Thank you very much for your help!
1
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.