Konfigurieren der Kerberos-Datei krb5.conf für die Verarbeitung der primären und einer sekundären geklonten Domäne

471
Rachel Ambler

(Obligatorisches Newbie-Präfix: habe noch nie viel mit Kerberos gespielt, also behandeln Sie mich hier sanft!)

Wir haben zwei Domänen foo.localund .test.

.testwurde geklont foo.localund wenn er sich bei einem Server in .testder Domäne angemeldet hat, wird er als foo.localDomäne betrachtet.

zB myserver.foo.localeine IP - Adresse von 10.250.20.10 und myserver.testhat eine IP - Adresse von 10. 253 .20.10, wenn innerhalb der foo.localDomäne, sondern versteht sich als 10.250.20.10 wenn innerhalb der .testDomäne.

Darüber hinaus myserver.foo.localkann man myserver.testaber auch das Gegenteil erreichen .

Auch myserver.foo.localwenn Annäherung an myothersever.foo.localanstößt tatsächlich einen Server, der innerhalb der ist foo.localDomäne, aber wenn eine myserver.testVerbindung zu myotherserver.foo.locales dann in der stecken bleibt .testDomäne.

Alles in allem, hier ist meine /etc/krb5.confDatei (die ich mehr als glücklich bin zu lernen, ist schlecht konfiguriert):

[libdefaults] default_realm = FOO.LOCAL  [realms] FOO.LOCAL = { kdc = foo-dc01.foo.local }  TEST = { kdc = foo-dc02.test } 

Das Leben ist gut, wenn man sich mit den Servern im Inneren verbindet foo.localund in der Tat sind meine kinitArbeiten ein Genuss. Testnicht so viel.

myLogin$ kinit -V mylogin@test mylogin@test's password:  kinit: krb5_get_init_creds: unable to reach any KDC in realm test, tried 0 KDCs 

Also fragen:

1) Welche Schritte fehlen mir, um mich bei der Testdomäne zu authentifizieren - wie konfiguriere ich kinitdie Verwendung des foo-dc02.testDomänenservers zur Authentifizierung (oder sogar, wenn meine Windows-Anmelde-ID und mein Kennwort identisch sind)?

2) Wenn ich fertig bin, wie kann ich sicherstellen, dass bei der Verbindung myserver.testdas Token verwendet wird, das kinit mylogin@testbeim Versuch einer Verbindung abgeleitet wurde?

Systeminfo: Alle AD-Server sind Windows. Derzeit werden meine POC-Tests von meinem MacBook durchgeführt, aber alle Clients, die unter Windows, Macs und Linux ausgeführt werden, müssen letztendlich funktionieren.

0
Alle Server sind virtuell, wir haben alle Server kopiert und in verschiedenen physischen Hosts aktiviert und Routing bereitgestellt, um von .foo.local zu .test zu gelangen. Meine Frage bezieht sich nicht so sehr auf das Klonen, aber "Wie bekommen wir Token von der .test-Domain"? Rachel Ambler vor 5 Jahren 0
Ich habe den obigen Kommentar gemacht, weil ein Benutzer gefragt hat, wie die Umgebungen geklont wurden. Leider löschte diese Person anschließend ihre Frage und führte mein Bergwerk. Halten Sie es dort, um Kontext zu bieten. Rachel Ambler vor 5 Jahren 0

1 Antwort auf die Frage

0
grawity

Zum Beispiel hat myserver.foo.local eine IP-Adresse von 10.250.20.10 und myserver.test hat in der Domäne foo.local eine IP-Adresse von 10.253.20.10, in der .test-Domäne jedoch 10.250.20.10.

Die Adressierung ist im Allgemeinen für Kerberos nicht relevant, solange Clients die DNS-Namen auflösen und mit den Servern sprechen können (Senden / Empfangen von IP-Paketen).

myLogin $ kinit -V mylogin @ test
mylogin @ test's Kennwort:
kinit: krb5_get_init_creds: KDC kann im Realm-Test nicht erreicht werden, 0 KDCs wurden versucht

Sie versuchen sich bei dem testBereich zu authentifizieren . Für Kerberos ist dies nicht dasselbe wie der TESTBereich, den Sie in krb5.conf haben. Im Gegensatz zu DNS-Domänen oder AD-Domänen ist bei einem Kerberos-Bereichsnamen die Groß- und Kleinschreibung zu beachten.

Da sich der testRealm in Kleinbuchstaben nicht in [Realms] in Ihrer krb5.conf befindet, verwendet kinit andere Methoden, um den KDC-Server zu finden. Er sucht nach DNS-SRV- _kerberos._udp.<realm>Einträgen, nachdem er den Realm zurück in eine DNS-Domäne übersetzt hat.

Wenn Sie sich beispielsweise gegen …@testoder authentifizieren, …@TESTund es keinen passenden Unterabschnitt [Realms] gibt, benötigen Sie _kerberos._udp.testmindestens SRV-Einträge . (Active Directory sollte diese automatisch hinzufügen.)

Verwenden Sie entweder kinit mylogin@TESTden richtigen Fall oder passen Sie die Konfiguration der [Realms] an, oder stellen Sie sicher, dass SRV-Einträge in Ihrer testDNS-Domäne auf den Domänencontroller verweisen.

(Übrigens: Wenn Sie die Kleinbuchstaben verwenden kinit mylogin@test, Active Directory KDCs wird die Klein Form erkennen, aber die zurückgegebenen Karten haben das Reich in kanonischer Groß sowieso und die meisten kinit Versionen werden die unpassende Antwort ablehnen Sie können Kanonisierung verwenden. kinit -C.)

Wenn Ihre Client-Software MIT Krb5 ist, können Sie export KRB5_TRACE=/dev/stderrweitere Informationen dazu erhalten. (macOS verwendet wahrscheinlich Heimdal.)

2) Wenn ich fertig bin, wie kann ich sicherstellen, dass beim Verbindungsaufbau zu myserver.test das vom kinit mylogin @ test abgeleitete Token verwendet wird, wenn eine Verbindung hergestellt wird?

Prüfen Sie, welcher Cache-Typ für Berechtigungsnachweise verwendet wird (siehe klist"Ticket-Cache" oder in der Umgebungsvariablen $ KRB5CCNAME festgelegt).

Der herkömmliche Cache "FILE:" kann an erster Stelle nur Tickets für einen Client-Principal enthalten. Wenn Sie sich als mylogin @ TEST bezeichnen, werden Sie immer Tickets für mylogin @ TEST verwenden. In diesem Fall müssen Sie manuell zwischen verschiedenen Caches wechseln, indem Sie $ KRB5CCNAME auf verschiedene Pfade setzen.

$ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_prod" && kinit user@PROD && klist $ export KRB5CCNAME="FILE:/tmp/krb5cc_1000_test" && kinit user@TEST && klist  $ kset() { export KRB5CCNAME="FILE:/tmp/krb5cc_$(id -u)_$1"; } $ kset prod && kinit user@PROD && klist 

Bei Verwendung von MIT Krb5 unterstützen die Berechtigungscaches "DIR:" und (unter Linux) "KEYRING:" mehrere Client-Principals gleichzeitig. Sie können einfach mehrere Male kinitieren und dann den 'aktiven' Principal wechseln kswitchoder benutzerdefinierte Regeln in der ~/.k5identityDatei definieren (man 5 k5identity).

Leider können einige wichtige Programme (wie smbclient oder Apache Directory Studio) "DIR:" noch nicht zwischenspeichern (oder etwas anderes als FILE: eigentlich).

Wenn Sie macOS verwenden, gilt dasselbe wie oben, aber ich glaube, der Standard-Cache-Typ für Berechtigungsnachweise ist "KCM:", der möglicherweise mehrere Client-Principals enthalten kann. Oder vielleicht nicht ¯ \ _ (ツ) _ / ¯

Windows funktioniert anders. Der Ticket-Cache ist eng an Ihre Anmeldesitzung gebunden und unterstützt (wieder) nur einen Client-Principal. Um Programme als einen anderen Principal ohne vollständige Abmeldung / Login zu starten, verwenden Sie runas /netonly:

runas /netonly /user:mylogin@test cmd 
Danke für die Feuer nach dem Kampf jetzt, also müssen wir später nachsehen. Rachel Ambler vor 5 Jahren 0