0

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/comp01.company.lan@COMPANY.LAN
[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/comp01.company.lan@COMPANY.LAN' 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 COMP01$@COMPANY.LAN (arcfour-hmac)
   4 02/17/2022 07:34:59 COMP01$@COMPANY.LAN (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 COMP01$@COMPANY.LAN (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/COMP01@COMPANY.LAN (arcfour-hmac)
   4 02/17/2022 07:34:59 host/COMP01@COMPANY.LAN (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/COMP01@COMPANY.LAN (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:34:59 host/comp01.company.lan@COMPANY.LAN (arcfour-hmac)
   4 02/17/2022 07:34:59 host/comp01.company.lan@COMPANY.LAN (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 host/comp01.company.lan@COMPANY.LAN (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/COMP01@COMPANY.LAN (arcfour-hmac)
   4 02/17/2022 07:35:00 RestrictedKrbHost/COMP01@COMPANY.LAN (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/COMP01@COMPANY.LAN (aes256-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/comp01.company.lan@COMPANY.LAN (arcfour-hmac)
   4 02/17/2022 07:35:00 RestrictedKrbHost/comp01.company.lan@COMPANY.LAN (aes128-cts-hmac-sha1-96)
   4 02/17/2022 07:35:00 RestrictedKrbHost/comp01.company.lan@COMPANY.LAN (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.

Ronny
  • 3
  • 2
  • 1
    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 COMP01$@COMPANY.LAN – Semicolon Feb 22 '22 at 04:58
  • @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 COMP01$@COMPANY.LAN` `kinit -kt /etc/krb5.keytab COMP01@COMPANY.LAN` and `kinit -kt /etc/krb5.keytab COMP01.$@COMPANY.LAN` All attempts end up with the following result: `kinit: Keytab contains no suitable keys for COMP01@COMPANY.LAN while getting initial credentials` Only the principal names are different: COMP01@COMPANY.LAN, COMP01COMPANY@COMPANY.LAN and COMP01.COMPANY.LAN@COMPANY.LAN – Ronny Feb 22 '22 at 07:55
  • 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. – Calchas Mar 13 '22 at 21:54
  • 1
    @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 'COMP01$@COMPANY.LAN'` Thank you very much for your help! – Ronny Mar 16 '22 at 14:33

1 Answers1

1

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.

user1686
  • 8,717
  • 25
  • 38
  • 1
    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 'COMP01$@COMPANY.LAN'` (Dollar suffix and tick marks are very important!) Thank you very much for your help! – Ronny Mar 16 '22 at 14:34