înregistrare Logare
Puncte:0
avatar Server

KDC nu are suport pentru tipul de criptare în timpul autentificării la OpenLDAP

drapel fr
Lars Hanke

Rulez un server de autentificare Kerberos / LDAP de mulți ani. Datele Kerberos sunt stocate în LDAP. Acum, am un al doilea site și vreau să oglindesc serverul pe noul site. Practic funcționează, dar există un efect secundar ciudat. Fiecare server are un KDC și un LDAP care rulează. KDC vorbește cu LDAP folosind local ldapi:///.

Dacă folosesc KDC-ul original krb1.example.com Mă pot autentifica la master LDAP și replica. Dacă folosesc KDC-ul replicat krb2.example.com, încă mă pot autentifica la master LDAP, dar încercând replica pe care o obțin

Autentificarea SASL/GSSAPI a început
ldap_sasl_interactive_bind_s: Eroare locală (-2)
        informații suplimentare: SASL(-1): eroare generică: Eroare GSSAPI: Eroare GSS nespecificată. Codul minor poate oferi mai multe informații (KDC nu are suport pentru tipul de criptare)

Ceea ce este ciudat, din moment ce krb2 este literalmente o clonă pe containerul LXC krb1 adicăconfigurațiile sunt identice sigure pentru modificările necesare pentru replicare. Dar și mai multă încurcătură este o privire în memoria cache a biletelor după ce ați încercat să interogați oricare dintre serverele LDAP. Cu un TGT de la krb1

root@krb2:/# klist -e
Cache-ul biletelor: FILE:/tmp/krb5_cc_0.tkt
Principalul implicit: user@EXAMPLE.COM

Valabil începând cu expiră principalul serviciului
04.02.2022 01:05:29 04.02.2022 11:05:29 krbtgt/EXAMPLE.COM@EXAMPLE.COM
        reînnoiește până la 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 01:05:42 04.02.2022 11:05:29 ldap/krb1.example.com@EXAMPLE.COM
        reînnoiește până la 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 01:05:53 04.02.2022 11:05:29 ldap/krb2.example.com@EXAMPLE.COM
        reînnoiește până la 05.02.2022 01:05:26, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

iar din krb2:

root@krb2:/# klist -e
Cache-ul biletelor: FILE:/tmp/krb5_cc_0.tkt
Principalul implicit: user@EXAMPLE.COM

Valabil începând cu expiră principalul serviciului
04.02.2022 00:53:45 04.02.2022 10:53:45 krbtgt/EXAMPLE.COM@EXAMPLE.COM
        reînnoiește până la 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 
04.02.2022 00:53:47 04.02.2022 10:53:45 ldap/krb1.example.com@EXAMPLE.COM
        reînnoiește până la 05.02.2022 00:53:41, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96

care nu are intrare pt ldap/krb2.example.com din cauza erorii. Dar se pare că nu există nicio diferență între tipurile de criptare necesare. Deci, de ce se plânge?

În prezent, ambele servere LDAP se referă la krb1. Dar, datorită replicării LDAP, toate cheile ar trebui să fie identice, adică o cheie de la krb1 ar trebui să fie la fel ca de la krb2, nu ar trebui? Și dacă cheile de la krb1 funcționează pentru ambele servere LDAP, de ce cheia de la serverul replica funcționează doar pentru LDAP principal?

suported_enctypes pentru tărâmul în ambele /etc/krb5kdc/kdc.conf sunt supported_enctypes = aes256-cts:normal arcfour-hmac:normal des3-hmac-sha1:normal des-cbc-crc:normal des:normal des:v4 des:norealm des:onlyrealm des:afs3. Nu există directive enctype în niciunul /etc/krb5.conf. Nu sunt ssf configurație utilizată fie în LDAP. The krbPrincipalName intrări pentru krb2 există atât în ​​LDAP.

Chiar daca obtin TGT-ul de la krb2 și apoi comutați krb5.conf la krb1 pentru biletul de serviciu, mă pot autentifica la LDAP activat krb2.

OpenLDAP este în versiunea 2.4.47, Kerberos 1.17 pe ambele mașini (debian stabil în prezent).

Actualizați: S-a dovedit că replicarea este incompletă, adică krbPrincipalKey nu este (în mod fiabil) replicat. Am verificat slapd ieșire de depanare:

9 februarie 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND authcid="sync/krb2.example.com@EXAMPLE.COM" authzid="dn:uid=sync/krb2.example.com, cn=example.com,cn=gssapi,cn=auth@EXAMPLE.COM"
9 februarie 19:14:52 krb1 slapd[19560]: conn=1300 op=3 BIND dn="cn=admin,dc=example,dc=com" mech=GSSAPI sasl_ssf=256 ssf=256

Asa de, sinprov se leagă aparent ca cn=admin,dc=exemplu,dc=com, ceea ce este destinat.Totuși, dacă o fac

root@krb1:~# ldapsearch -b 'cn=KERBEROS,dc=example,dc=com' -D 'cn=admin,dc=example,dc=com' -Wx 'krbPrincipalName=ldap/krb2.example.com@ EXAMPLE.COM'

atunci văd krbPrincipalKey. Deci de ce nu este replicat?

repornesc slapd pe krb2 cu optiuni -c rid=1,csn=0, despre care am înțeles că ar trebui să sincronizeze întreaga bază de date. Dar din moment ce unele intrări au o cheie, iar altele nu, nu am încredere că acest lucru este adevărat.

100
0 + 0
user1686 avatar
drapel fr
user1686
Ce vrei să spui mai exact prin „În prezent, ambele servere LDAP se referă la krb1”? Vorbești despre KDC-uri în krb5.conf sau despre keytab-uri sau altceva?
0
Răspunde
user1686 avatar
drapel fr
user1686
Puteți arăta procesul real de autentificare care eșuează? Dacă containerele sunt clone exacte, serviciul LDAP de pe kdc2 _știe_ că acum se numește `ldap/kdc2` mai degrabă decât `ldap/kdc1`, adică are cel puțin o nouă tastatură de taste pentru noul său nume sau folosește încă tastatura originală?
0
Răspunde
drapel fr
Lars Hanke
Da, numele de gazdă, adresa IP, intrarea DNS, keytab, certificatele TLS au fost adaptate pentru a se potrivi cu noua instanță.
0
Răspunde
drapel fr
Lars Hanke
Deci ceea ce am făcut a fost: ldapsearch -b "cn=admin,dc=example,dc=com" -H ldap://kdc?.uac.microsult.de. Setând /etc/krb5.conf la kdc2, pot face kinit, pot interoga kdc1, dar kdc2 eșuează. Dacă apoi schimb kdc în krb1 în /etc/krb5.conf, interogarea către kdc2 reușește, de asemenea, folosind același bilet.
0
Răspunde
user1686 avatar
drapel fr
user1686
Puteți solicita manual un bilet de la KDC „kdc2” folosind „KRB5_TRACE=/dev/stderr kvno ldap/kdc2.uac.microsult.de” și, dacă nu reușește, ce raportează krb5kdc în fișierul său jurnal? Puteți verifica dacă ambele KDC-uri au aceleași informații în replicile lor LDAP (de exemplu, aruncându-le pe ambele prin slapcat sau prin ldapsearch cu autentificare rootdn/rootpw)? Puteți rula `kadmin.local` în ambele KDC-uri pentru a verifica ce știu despre principalul ldap/kdc2?
0
Răspunde
user1686 avatar
drapel fr
user1686
Ah, și chiar nu ar trebui să aveți acea setare „supported_enctypes”... probabil că nu _doare_ (încă), dar lista este deja destul de învechită, iar configurarea explicit a acesteia nu are niciun scop bun.
0
Răspunde
drapel fr
Lars Hanke
Sugestia ```kadmin.local``` a arătat că serverul de replică de fapt nu are chei pentru unii directori. Nu am văzut asta, deoarece directorul meu de administrator pentru LDAP nici nu vede cheile din cauza ACL, adică intrările arătau la fel pe ambele servere. Cu toate acestea, principalul de replicare ar trebui să vadă cheile. Deci se pare că trebuie să depanez ACL-ul ```slapd``` și Authzid. Nu am găsit încă nicio valoare de depanare potrivită pentru a vedea ce utilizatori folosesc ce authzid la ce DN. Dar aceasta este cel puțin o problemă pură de configurare LDAP.
0
Răspunde
user1686 avatar
drapel fr
user1686
Nivelul de jurnal `stats` ar fi un început bun.
0
Răspunde
Puncte:0
avatar Server
drapel fr
Lars Hanke

Problema a fost rezolvată de slapcat baza de date master și slapadd de la zero asupra consumatorului.

Mulțumesc lui user1686 pentru că a indicat lucrurile de verificat pentru a mă face să rup gândurile circulare.

Cauza problemei a fost că unii directori Kerberos din LDAP nu aveau krbPrincipalKey atribut. ldap/krb2.example.com fiind unul dintre aceia. Acest lucru a devenit evident folosind get_principal în kadmin.local pe fiecare server. Confuzia a apărut din cauza utilizării inadecvate a DN-ului de legare și a ACL asociate cu acestea. În plus, am avut încredere că am folosit opțiuni pentru slapd pentru a prelua din nou întreaga bază de date la pornire, ceea ce nu s-a întâmplat.

Câteva capcane care m-au ținut prins: deoarece cu TLS activat -Y EXTERN nu funcționează, folosesc principii Kerberos speciale pentru întreținerea bazei de date. Directorul meu pentru cn=config nu are acces la acreditările stocate în baza de date principală, despre care nu mai știam. Deci, compararea intrărilor celor două LDAP a dat rezultate identice. În timp ce principalul de replicare real are acces la acreditări, probabil am folosit inițial celălalt DN de legare, adică înainte de a avea Kerberos configurat pentru replicare. Prin urmare, intrările create în această perioadă de timp au fost replicate fără acreditări și syncprov nu rezolvă asta mai târziu.

0 + 0
drapel romania
SEF 777
întrebarea această in alte limbi:

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.