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