Linux Client mit Kerberos im Active Directory einbinden

[Heiko Barg]

Hallo miteinander,
ich versuche nun schon eine ganze Weile eine Linux Büchse
in eine AD (2008 R2 basiert) zu integrieren.
Und irgendwie scheitere ich an der Kerberos Keytab :-/
Tante Google hat mir bisher nicht den entscheidenden Hinweis geliefert.
Eigentlich dürfte mein Problem mehr auf der Linux Seite liegen, aber ich denke, dass ich hier eher
jemanden finde der meine Problemstellung schonmal erfolgreich gemeistert hat?!

Die Integration/Authentifizierung soll ohne Samba auf die Weise wie es in der Zeitschrift iX 10, 11
& 12/2008 beschrieben wurde rein per Kerberos erfolgen.

Mal der Reihe nach was ich bisher gemacht habe:

* Maschinen Konto im AD angelegt
* service principal name mit setspn -a host/<HostName>.domain <HostName> angelegt
Im Adsi-Editor kann man sehen das der service principal name existiert.
* Passwort für das Maschinen Konto zurück gesetzt
Auf der Linux (in meinem Fall Ubuntu 9.10 Kiste):
* Mit kpasswd das Maschinenkonto Passwort auf etwas "sicheres" gesetzt.
* Mit kinit <HostName> bekommt man nach Eingabe des neuen "sicheren" Passwortes auch ein Ticket
(kann man mit klist sehen)
* mit kvno die kvno Nummer herrausfinden

Soweit so gut und wie in den diversen Anleitungen die ich bisher bemüht hab auch noch unproblematisch:

Und nun der Teil der Probleme macht:
Die Maschine soll sich mittels keytabs selbständig Tickets holen können:

Also mit ktutil Keytab erstellt:
addent -password -p <HostName> -k 4 -e aes256-cts-hmac-sha1-96
addent -password -p host/<HostName>.mpi-dortmund.mpg.de -k 4 -e aes256-cts-hmac-sha1-96

Vier ist die kvno Nummer laut "kvno Tool".
Danach Keytab geschrieben und mit kinit -k (-t keytab-Datei) <hostname> ausprobiert:
Und da bekomme ich immer ein "kinit: Preauthentication failed while getting initial credentials"
was laut Netz auf falsches Passwort oder falsche Verschlüsselung hindeutet.
Falsche Verschlüsselung schließe ich aus, da "aes256-cts-hmac-sha1-96" mir per "klist -e" bei einem
Ticket angegeben wird welches ich "manuell" per kinit <hostname> "-> Passwort eingeben" geholt habe.
Also das manuelle holen eine Tickets funktioniert, nur wenn es automatisiert per KEytab erfolgen
soll scheitert es. Nichts desto trotz habe ich auch andere Verschlüsselungsmethoden (die so im NEtz
angegeben werden) probiert mit mehr oder minder dem selben Ergebnis.
Entweder ich bekomme obige Fehler Meldung oder ein "kinit: Key table entry not found while getting
initial credentials". Wobei meiner Ansicht ein klist auf die Keytable sagt das es den Eintrag gibt
;-) :-/

Auch ein erstellen der Keytable auf dem Windows Domänen Controller per ktpass.exe (dann nat. nach
Linux rüberkopieren) liefert letztlich das gleiche Ergebnis.

Nun hoffe ich das hier mir jemand den entscheidenden Wink geben kann was ich falsch mache. (Ich
hoffe ich habe alle nötigen Informationen gegeben, ansonsten reiche ich sie gerne nach.)

Vielen Dank schon mal.

Schönen Gruß,
Heiko

["Frank Röder [MVP]"]

Hallo Heiko,

> "kinit: Preauthentication failed while getting initial credentials"

es ist momentan nur ein Schuss ins Blaue: Ist die Zeit auf dem Client
und auf dem Server gleich?

--
Viele Grüße

Frank Röder
MVP Directory Services
Blog: http://blog.iteach-online.de

[Heiko Barg]

Frank Röder [MVP] schrieb:

> Hallo Heiko,
>
>> "kinit: Preauthentication failed while getting initial credentials"
>
> es ist momentan nur ein Schuss ins Blaue: Ist die Zeit auf dem Client
> und auf dem Server gleich?
>

Ich vergaß, ja das ist auch überprüft.
Beide Maschinen haben die gleiche Zeitquelle und die Uhrzeit ist auch identisch ...so einfach ist es
leider nicht ;-)

Andere Ideen?

Schönen Gruß,
Heiko

[Heiko Barg]

Hallo miteinander,
ich antworte mir hier mal selber, da ich das Problem zwischenzeitlich lösen konnte.
(Vielen Dank an dieser Stelle an Herrn Pröhl (Autor des unten zitierten iX-Artikels)
für den entscheidenden Hinweis)

Heiko Barg schrieb:

> ich versuche nun schon eine ganze Weile eine Linux Büchse
> in eine AD (2008 R2 basiert) zu integrieren.
> Und irgendwie scheitere ich an der Kerberos Keytab :-/

> Die Integration/Authentifizierung soll ohne Samba auf die Weise wie es

> in der Zeitschrift iX 10, 11 & 12/2008 beschrieben wurde rein per
> Kerberos erfolgen.
>
> Mal der Reihe nach was ich bisher gemacht habe:
>
> * Maschinen Konto im AD angelegt

> * service principal name mit setspn -a host/<HostName>.<domain> <HostName>

> angelegt
> Im Adsi-Editor kann man sehen das der service principal name existiert.
> * Passwort für das Maschinen Konto zurück gesetzt
> Auf der Linux (in meinem Fall Ubuntu 9.10 Kiste):
> * Mit kpasswd das Maschinenkonto Passwort auf etwas "sicheres" gesetzt.
> * Mit kinit <HostName> bekommt man nach Eingabe des neuen "sicheren"
> Passwortes auch ein Ticket (kann man mit klist sehen)

-> Wichtig: Dies zeigt das kein Grundsätzliches Problem vorliegt und
grenzt den Fehler eigentlich schon auf die keytab ein!

> * mit kvno die kvno Nummer herrausfinden
>
> Soweit so gut und wie in den diversen Anleitungen die ich bisher bemüht
> hab auch noch unproblematisch:
>
> Und nun der Teil der Probleme macht:
> Die Maschine soll sich mittels keytabs selbständig Tickets holen können:
>
> Also mit ktutil Keytab erstellt:
> addent -password -p <HostName> -k 4 -e aes256-cts-hmac-sha1-96

> addent -password -p host/<HostName>.<domain> -k 4 -e
> aes256-cts-hmac-sha1-96
Und hier liegt jetzt der Fehler!
Ein kurzer Exkurs:
Windows verwendet seit "Windows Server 2008" die AES Verschlüsselung und verwendet hierfür noch
einen "Salt" der in das Passwort "einzustreuen" ist. Afaik erklärt Windows Server 2008 R2 (und das
entsprechende Active Directory) aes256-cts-hmac-sha1-96 zur Standard Verschlüsselung. Die alte RC4
Verschlüsselung hat noch keinen Salt verwendet und würde dabei keine Probleme machen.
Bis Windows 2008 ("R1") musste man wohl AES256 über die Eigenschaft ms-DS-Supported-Encryption-Types
des Computerkontos im AD-LDAP explizit aktivieren. Seit Windows 2008 R2 scheint es so zu sein, daß
AES256 default mäßig an ist (Dies jetzt hier alles afaik und aus meinen Beobachtungen heraus).

So, zurück zum Problem:
Windows und das ktutil haben unterschiedliche Vorstellungen wie der Salt auszusehen hat.
Das ktutil verwendet immer (ich habe keine Möglichkeit gefunden etwas anderes vorzugeben) den mit
"-p" angegebenen Principalname als Salt bei der Key-Generierung.
Windows möchte aber den Salt in der Form "host<hostname>.<domain>" (alles klein,ohne Leerzeichen,
Schrägstriche oder sonstiges).
Um zu überprüfen ob man den richtigen Salt hat, sollte man sich Wireshark installieren und den
Verkehr (Display-Filter "kerberos" in Wireshark), den ein erfolgreiches kinit erzeugt, anschauen.
Der Salt wird dabei vom KDC (Also dem Domain Controller) im Klartext dem Client mitgeteilt.

Nun zum Trick um mit dem ktutil unter Linux einen Key mit dem richtigen Salt anzulegen:
Als erstes erzeugt man mit
addent -password -p <Salt> -k <KVNO-Nr.> -e aes256-cts-hmac-sha1-96
einen Eintrag bei dem man statt des Principalname den oben herausgefundenen Salt angibt.
Dadurch erhält man einen gültigen Key.
Mit "list -k" läßt man sich den Key anzeigen (steht in Klammern als Langer Hex-String in der Form
0x.....)
Nun legt man mit
addent -key -p <Hostname/Principalname/....> -k <KVNO-Nr.> -e aes256-cts-hmac-sha1-96
die "eigentlichen" Einträge an. Statt nach dem Passwort wird nach dem Key als Hex-String gefragt.
Hier kopiert man einfach den oben per list herausgefundenen Key rein (ohne führendes 0x).
Dies macht man für alle Einträge die man für das Maschinenkonto benötigt.
Danach kann man den ersten Eintrag löschen (wenn man mag ;-) ), da er ja keinen gültigen
Principalname hat.
Noch per wkt speichern und nun sollte ein kinit -k -t <keytab> <Hostname bzw. Principalname>
erfolgreich sein.

> Auch ein erstellen der Keytable auf dem Windows Domänen Controller per
> ktpass.exe (dann nat. nach Linux rüberkopieren) liefert letztlich das
> gleiche Ergebnis.

Dies wiederum verstehe ich nicht, da Windows ja wissen sollte welchen Salt es verwendet.
...ist mir allerdings jetzt auch nicht so wichtig, da ich die Keytab auf den Clients generieren
möchte um nicht den Umstand zu haben vom DC aus auch noch die Datei zum Client zu transferieren.

Ich hoffe damit dem ein oder anderen ein wenig Lebenszeit erspart zu haben ;-) Ich für meinen Teil
habe nämlich im Netz für diese Schritte keinen Hinweis gefunden.

Gruß,
Heiko

[Rainer Fruehwacht]

Hi Heiko,

ich m?chte das genauso umsetzen, habe hier einen Windows Server 2008 R2 und m?chte meine Linux Kisten in das AD integrieren und das ganze ohne Samba. Die Heise Artikel habe ich auch alle 3 noch in meiner Sammlung.
Kann man zusammenfassend sagen, dass das Heise HowTo f?r
Windows Server 2003 und Server 2008 funktioniert, ohne
Anpassungen vornehmen zu m?ssen? Nur wenn man Windows
Server 2008 R2 nutzt, muss man den Trick anwenden, den Du beschrieben hast?

Auf jedenfalls schonmal Danke f?r Deinen L?sungsweg!

Gru?
Rainer

> On Thursday, April 08, 2010 8:41 AM Heiko Barg wrote:

> Hallo miteinander,
> ich versuche nun schon eine ganze Weile eine Linux B?chse

> in eine AD (2008 R2 basiert) zu integrieren.
> Und irgendwie scheitere ich an der Kerberos Keytab :-/

> Tante Google hat mir bisher nicht den entscheidenden Hinweis geliefert.

> Eigentlich d?rfte mein Problem mehr auf der Linux Seite liegen, aber ich denke, dass ich hier eher

> jemanden finde der meine Problemstellung schonmal erfolgreich gemeistert hat?!
>

> Die Integration/Authentifizierung soll ohne Samba auf die Weise wie es in der Zeitschrift iX 10, 11
> & 12/2008 beschrieben wurde rein per Kerberos erfolgen.
>
> Mal der Reihe nach was ich bisher gemacht habe:
>
> * Maschinen Konto im AD angelegt

> * service principal name mit setspn -a host/<HostName>.domain <HostName> angelegt

> Im Adsi-Editor kann man sehen das der service principal name existiert.

> * Passwort f?r das Maschinen Konto zur?ck gesetzt

> Auf der Linux (in meinem Fall Ubuntu 9.10 Kiste):
> * Mit kpasswd das Maschinenkonto Passwort auf etwas "sicheres" gesetzt.
> * Mit kinit <HostName> bekommt man nach Eingabe des neuen "sicheren" Passwortes auch ein Ticket
> (kann man mit klist sehen)

> * mit kvno die kvno Nummer herrausfinden
>

> Soweit so gut und wie in den diversen Anleitungen die ich bisher bem?ht hab auch noch unproblematisch:

>
> Und nun der Teil der Probleme macht:

> Die Maschine soll sich mittels keytabs selbst?ndig Tickets holen k?nnen:

>
> Also mit ktutil Keytab erstellt:
> addent -password -p <HostName> -k 4 -e aes256-cts-hmac-sha1-96

> addent -password -p host/<HostName>.mpi-dortmund.mpg.de -k 4 -e aes256-cts-hmac-sha1-96
>
> Vier ist die kvno Nummer laut "kvno Tool".
> Danach Keytab geschrieben und mit kinit -k (-t keytab-Datei) <hostname> ausprobiert:
> Und da bekomme ich immer ein "kinit: Preauthentication failed while getting initial credentials"

> was laut Netz auf falsches Passwort oder falsche Verschl?sselung hindeutet.
> Falsche Verschl?sselung schlie?e ich aus, da "aes256-cts-hmac-sha1-96" mir per "klist -e" bei einem

> Ticket angegeben wird welches ich "manuell" per kinit <hostname> "-> Passwort eingeben" geholt habe.
> Also das manuelle holen eine Tickets funktioniert, nur wenn es automatisiert per KEytab erfolgen

> soll scheitert es. Nichts desto trotz habe ich auch andere Verschl?sselungsmethoden (die so im NEtz

> angegeben werden) probiert mit mehr oder minder dem selben Ergebnis.
> Entweder ich bekomme obige Fehler Meldung oder ein "kinit: Key table entry not found while getting
> initial credentials". Wobei meiner Ansicht ein klist auf die Keytable sagt das es den Eintrag gibt
> ;-) :-/
>

> Auch ein erstellen der Keytable auf dem Windows Dom?nen Controller per ktpass.exe (dann nat. nach
> Linux r?berkopieren) liefert letztlich das gleiche Ergebnis.

>
> Nun hoffe ich das hier mir jemand den entscheidenden Wink geben kann was ich falsch mache. (Ich

> hoffe ich habe alle n?tigen Informationen gegeben, ansonsten reiche ich sie gerne nach.)
>
> Vielen Dank schon mal.
>
> Sch?nen Gru?,
> Heiko

>> On Thursday, April 08, 2010 1:45 PM Frank_R?der_[MVP] wrote:

>> Hallo Heiko,

>>
>>
>> es ist momentan nur ein Schuss ins Blaue: Ist die Zeit auf dem Client
>> und auf dem Server gleich?
>>

>> --
>> Viele Gr??e
>>
>> Frank R?der

>> MVP Directory Services
>> Blog: http://blog.iteach-online.de

>>> On Friday, April 09, 2010 5:56 AM Heiko Barg wrote:

>>> Frank R?der [MVP] schrieb:
>>> Ich verga?, ja das ist auch ?berpr?ft.

>>> Beide Maschinen haben die gleiche Zeitquelle und die Uhrzeit ist auch identisch ...so einfach ist es
>>> leider nicht ;-)
>>>
>>> Andere Ideen?
>>>

>>> Sch?nen Gru?,
>>> Heiko

>>>> On Wednesday, April 14, 2010 4:46 AM Heiko Barg wrote:

>>>> Hallo miteinander,
>>>> ich antworte mir hier mal selber, da ich das Problem zwischenzeitlich l?sen konnte.
>>>> (Vielen Dank an dieser Stelle an Herrn Pr?hl (Autor des unten zitierten iX-Artikels)
>>>> f?r den entscheidenden Hinweis)
>>>>
>>>> Heiko Barg schrieb:
>>>>
>>>> -> Wichtig: Dies zeigt das kein Grunds?tzliches Problem vorliegt und

>>>> grenzt den Fehler eigentlich schon auf die keytab ein!
>>>>

>>>> Und hier liegt jetzt der Fehler!
>>>> Ein kurzer Exkurs:

>>>> Windows verwendet seit "Windows Server 2008" die AES Verschl?sselung und verwendet hierf?r noch
>>>> einen "Salt" der in das Passwort "einzustreuen" ist. Afaik erkl?rt Windows Server 2008 R2 (und das
>>>> entsprechende Active Directory) aes256-cts-hmac-sha1-96 zur Standard Verschl?sselung. Die alte RC4
>>>> Verschl?sselung hat noch keinen Salt verwendet und w?rde dabei keine Probleme machen.
>>>> Bis Windows 2008 ("R1") musste man wohl AES256 ?ber die Eigenschaft ms-DS-Supported-Encryption-Types
>>>> des Computerkontos im AD-LDAP explizit aktivieren. Seit Windows 2008 R2 scheint es so zu sein, da?
>>>> AES256 default m??ig an ist (Dies jetzt hier alles afaik und aus meinen Beobachtungen heraus).
>>>>
>>>> So, zur?ck zum Problem:

>>>> Windows und das ktutil haben unterschiedliche Vorstellungen wie der Salt auszusehen hat.

>>>> Das ktutil verwendet immer (ich habe keine M?glichkeit gefunden etwas anderes vorzugeben) den mit

>>>> "-p" angegebenen Principalname als Salt bei der Key-Generierung.

>>>> Windows m?chte aber den Salt in der Form "host<hostname>.<domain>" (alles klein,ohne Leerzeichen,
>>>> Schr?gstriche oder sonstiges).
>>>> Um zu ?berpr?fen ob man den richtigen Salt hat, sollte man sich Wireshark installieren und den

>>>> Verkehr (Display-Filter "kerberos" in Wireshark), den ein erfolgreiches kinit erzeugt, anschauen.
>>>> Der Salt wird dabei vom KDC (Also dem Domain Controller) im Klartext dem Client mitgeteilt.
>>>>
>>>> Nun zum Trick um mit dem ktutil unter Linux einen Key mit dem richtigen Salt anzulegen:
>>>> Als erstes erzeugt man mit
>>>> addent -password -p <Salt> -k <KVNO-Nr.> -e aes256-cts-hmac-sha1-96
>>>> einen Eintrag bei dem man statt des Principalname den oben herausgefundenen Salt angibt.

>>>> Dadurch erh?lt man einen g?ltigen Key.
>>>> Mit "list -k" l??t man sich den Key anzeigen (steht in Klammern als Langer Hex-String in der Form

>>>> 0x.....)
>>>> Nun legt man mit
>>>> addent -key -p <Hostname/Principalname/....> -k <KVNO-Nr.> -e aes256-cts-hmac-sha1-96

>>>> die "eigentlichen" Eintr?ge an. Statt nach dem Passwort wird nach dem Key als Hex-String gefragt.
>>>> Hier kopiert man einfach den oben per list herausgefundenen Key rein (ohne f?hrendes 0x).
>>>> Dies macht man f?r alle Eintr?ge die man f?r das Maschinenkonto ben?tigt.
>>>> Danach kann man den ersten Eintrag l?schen (wenn man mag ;-) ), da er ja keinen g?ltigen

>>>> Principalname hat.
>>>> Noch per wkt speichern und nun sollte ein kinit -k -t <keytab> <Hostname bzw. Principalname>
>>>> erfolgreich sein.
>>>>

>>>> Dies wiederum verstehe ich nicht, da Windows ja wissen sollte welchen Salt es verwendet.
>>>> ...ist mir allerdings jetzt auch nicht so wichtig, da ich die Keytab auf den Clients generieren

>>>> m?chte um nicht den Umstand zu haben vom DC aus auch noch die Datei zum Client zu transferieren.
>>>>
>>>> Ich hoffe damit dem ein oder anderen ein wenig Lebenszeit erspart zu haben ;-) Ich f?r meinen Teil
>>>> habe n?mlich im Netz f?r diese Schritte keinen Hinweis gefunden.
>>>>
>>>> Gru?,
>>>> Heiko

>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>> Composite UI Pattern and RAD Development for Data Entry Applications, Part 1
>>>> http://www.eggheadcafe.com/tutorials/aspnet/a119aebe-7478-4aaa-b415-12786ec5cf90/composite-ui-pattern-and-rad-development-for-data-entry-applications-part-1.aspx