Auf unseren AIX- und Linux-Servern wird eine grundlegende Kennwortauthentifizierung gegenüber einem Windows AD unter Verwendung von Kerberos ausgeführt. Es handelt sich also um lokale Benutzer mit einem Benutzernamen, der mit ihrem sAMAccountName im AD identisch ist, und es wird lediglich die Kennwortprüfung durchgeführt.
Beide Betriebssysteme verwenden eine einfache krb5.conf
[libdefaults]
default_realm = COMPANYA.COM
[realms]
COMPANYA.COM {
kdc = ad.companya.com:88
admin_server = ad.companya.com:749
}
[domain_realm]
.companya.com = COMPANYA.COM
companya.com = COMPANYA.COM
Dies funktioniert auf beiden Betriebssystemen problemlos.
Wir haben nun die Situation, dass es eine Firma B und damit auch einen 2. AD geben wird. Ein Benutzer wird nie auf beiden ADs erreichbar sein, sondern nur auf einem.
Ich habe also zunächst mit AIX begonnen, da ich dachte, dass es am schwierigsten sein würde, dieses System zum Laufen zu bringen.
Die Datei krb5.conf wurde aktualisiert
[libdefaults]
default_realm = COMPANYA.COM
[realms]
COMPANYA.COM {
kdc = ad.companya.com:88
admin_server = ad.companya.com:749
}
COMPANYB.COM {
kdc = ad.companyb.com:88
admin_server = ad.companyb.com:749
}
[domain_realm]
.companya.com = COMPANYA.COM
companya.com = COMPANYA.COM
.companyb.com = COMPANYB.COM
companyb.com = COMPANYB.COM
Nach ein wenig Recherche schien es, als müsste ich nur noch
chuser auth_domain=COMPANYB.COM <user>
Dadurch wird die Datei /etc/security/user aktualisiert und die Kennwortüberprüfung mit dem AD der Firma B durchgeführt. Ich war also angenehm überrascht, wie einfach das war.
Als nächstes kam Linux (Ubuntu-Boxen). Habe dasselbe mit krb5.conf gemacht, aber leider kann ich den entsprechenden Befehl für chuser unter Ubuntu nicht finden, um diesen bestimmten Benutzer auf das andere AD zu verweisen.
Was ich finden kann, sind Seiten über die Verwendung von SSDD und den Beitritt zum Realm (Linux SSSD mit zwei AD Domänenund/oderhttps://ubuntu.com/server/docs/service-sssd-ad), aber das ist alles mehr als nötig (den Bereichen beitreten).
was ich bisher mit tcpdump und kinit herausgefunden habe, ist Folgendes:
kinit [email protected]
<password>
kinit: KDC reply did not match expectations while getting initial credentials
kinit [email protected]
<password>
<no error>
login [email protected]
<password>
access denied
login [email protected]
<password>
access denied
Da „kinit“ mit Großbuchstaben funktionierte, hatte ich vermutet, dass auch die Anmeldung funktionieren würde, aber leider war dies nicht der Fall.
aktualisieren: anmelden[email geschützt]funktioniert, wenn der Benutzer auf der Linux-Box als erstellt wird[email geschützt], immer noch nicht ganz zufrieden damit
(dabei wird die Tatsache vergessen, dass es nicht realistisch ist, von Benutzern zu verlangen, ihre Domain in Großbuchstaben zu schreiben)
Kurz gesagt: So verweisen Sie bestimmte Benutzer auf ein anderes AD als das Standard-AD in der Datei krb5.conf.
Grüße,
Antwort1
nun, ich bin letzte Woche ein bisschen weitergekommen und es scheint zu funktionieren. Allerdings schaue ich mir immer noch die genauen Details an, wie PAM funktioniert.
/etc/pam.d/common-auth aktualisiert/geändert
Original
auth [success=2 default=ignore] pam_krb5.so minimum_uid=1000
auth [success=1 default=ignore] pam_unix.so nullok try_first_pass
neue Version
auth sufficient pam_krb5.so minimum_uid=1000 realm=COMPANYA.COM
auth sufficient pam_krb5.so minimum_uid=1000 realm=COMPANYB.COM
auth sufficient pam_unix.so nullok try_first_pass
Beim Anmelden als Benutzer der Firma A prüft es die AD der Firma A und da der Benutzer dort vorhanden ist, wird das Passwort verifiziert. Beim Anmelden als Benutzer der Firma B prüft es die AD der Firma A. Der Benutzer existiert dort nicht. Anschließend wird Firma B geprüft und da der Benutzer dort vorhanden ist, wird das Passwort verifiziert.
es ist nicht so schön wie AIX, aber es funktioniert trotzdem.
Grüße,