Puncte:0

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

drapel mm

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.

Semicolon avatar
drapel jo
Sintaxa care funcționează pentru mine a fost tradusă în rețeaua dvs. (utilizați sAMAccountName al obiectului computer, la FQDN-ul domeniului: " kinit -k [email protected]
drapel mm
@Punt și virgulă Am încercat următoarele (presupun că poziția semnului dolar a fost intenționat imediat după numele computerului?): `kinit -kt /etc/krb5.keytab [email protected]` `kinit -kt /etc/ krb5.keytab [email protected]` și `kinit -kt /etc/krb5.keytab [email protected]` Toate încercările se termină cu următorul rezultat: `kinit: Keytab nu conține chei potrivite pentru COMP01@COMPANY. LAN în timp ce obțineți acreditările inițiale` Doar numele principale sunt diferite: [email protected], [email protected] și [email protected]
Calchas avatar
drapel br
Cum ai obținut acest keytab? Rețineți că dolarul este un caracter special în shell-urile POSIX, așa că va trebui să scăpați de el. O modalitate mai bună de a verifica dacă un principal există în baza de date este cu instrumentul `kvno`.
drapel mm
@Punt și virgulă Ai avut dreptate, dar am fost prea orb pentru a vedea soluția. Capcană: trebuia să plasez semne de bifare în jurul identificatorului; în caz contrar, $ este înlocuit cu „COMPANY.LAN”, ceea ce duce la acreditările ciudate din comentariul meu anterior. Am realizat problema doar după răspunsul de la @user1686. Prin urmare, comanda reușită pentru obținerea biletului este `kinit -kt /etc/krb5.keytab '[email protected]'` Vă mulțumim foarte mult pentru ajutor!
Puncte:1
drapel fr

Cu Kerberos cu aromă de Active Directory, există o distincție între numele principal de „utilizator” (client) și „serviciu” (țintă). Specific, numai sAMAccountName al contului poate acționa ca principal client, SPN-urile acestuia nu.

Numele de cont al obiectelor computer este întotdeauna numele de gazdă în majuscule și sufixat cu a $, de exemplu. pentru un computer numit „COMP01” numele contului ar fi COMP01$.

Între timp gazdă/comp01 și gazdă/comp01.company.lan există doar ca serviciu directori – un AD KDC va emite bilete pentru clienții care solicită „host/comp01” ca server țintă, dar nu le permite să acționeze ca clienți în timpul autentificării inițiale. Acestea există în tasta dvs. de chei numai pentru a fi utilizate pe partea „acceptor”.

drapel mm
Într-adevăr, asta mi-a rezolvat problema! În combinație cu comentariul de la @Semicolon, am reușit să obțin un bilet folosind `kinit -kt /etc/krb5.keytab '[email protected]'` (Sufixul dolarului și semnele de bifare sunt foarte importante!) Vă mulțumesc foarte mult pentru ajutorul tau!

Postează un răspuns

Majoritatea oamenilor nu înțeleg că a pune multe întrebări deblochează învățarea și îmbunătățește legătura interpersonală. În studiile lui Alison, de exemplu, deși oamenii își puteau aminti cu exactitate câte întrebări au fost puse în conversațiile lor, ei nu au intuit legătura dintre întrebări și apreciere. În patru studii, în care participanții au fost implicați în conversații ei înșiși sau au citit transcrieri ale conversațiilor altora, oamenii au avut tendința să nu realizeze că întrebarea ar influența – sau ar fi influențat – nivelul de prietenie dintre conversatori.