SSSD / realmd / adcli: Unterschied zwischen den Versionen
Chris (Diskussion | Beiträge) |
Chris (Diskussion | Beiträge) |
||
| Zeile 34: | Zeile 34: | ||
==== adcli ==== | ==== adcli ==== | ||
Domain Join: | |||
<pre> | <pre> | ||
/usr/sbin/adcli join --verbose --domain ad.intern.darkrealm.dyndns.org --domain-realm AD.INTERN.DARKREALM.DYNDNS.ORG --domain-controller 192.168.2.200 --computer-name fs-neorealm.ad.intern.darkrealm.dyndns.org --login-type user --login-user domain.admin --stdin-password | /usr/sbin/adcli join --verbose --domain ad.intern.darkrealm.dyndns.org --domain-realm AD.INTERN.DARKREALM.DYNDNS.ORG --domain-controller 192.168.2.200 --computer-name fs-neorealm.ad.intern.darkrealm.dyndns.org --login-type user --login-user domain.admin --stdin-password | ||
</pre> | |||
Domain Leave: | |||
<pre> | |||
/usr/sbin/adcli delete-computer --verbose --domain ad.intern.darkrealm.dyndns.org --domain-realm AD.INTERN.DARKREALM.DYNDNS.ORG --domain-controller dc-neorealm.ad.intern.darkrealm.dyndns.org --login-user domain.admin | |||
</pre> | </pre> | ||
Version vom 18. September 2022, 22:24 Uhr
Beschreibung
realmd ist ein Frontend zu adcli welches wiederum als Frontend für sssd oder winbind agiert. realmd installiert die benötigten Pakete für den DomainJoin automatisch wenn packagekit installiert ist.
DomainJoin
Es gibt 3 Möglichkeiten einen Linux-Client ans Active Directory anzubinden:
- Über realmd (realm join)
- Über adcli
- Über winbind (traditionelles net ads join)
realmd
Funktioniert nur wenn networkmanager installiert ist, prüft _ldap._tcp.<domain>-Einträge. Die <domain> ist der von DHCP übergebene Domainname welcher mit networkmanager herausgefunden wird:
realm discover -v
Frägt nach dem Passwort von Administrator:
realm join -v
Ergebnis: Schlägt fehl weil das Passwort nicht stimmt.
Mit domain.admin joinen:
realm join -v -U domain.admin
Ergebnis: Schlägt fehl da der Principal ldap/dc-neorealm.intern.neorealm.dyndns.org@AD.INTERN.DARKREALM.DYNDNS.ORG nicht gefunden wird. Abhilfe: In /etc/krb5.conf im Abschnitt [libdefaults] rdns = false setzen (wird mittlerweile sogar so empfohlen).
adcli
Domain Join:
/usr/sbin/adcli join --verbose --domain ad.intern.darkrealm.dyndns.org --domain-realm AD.INTERN.DARKREALM.DYNDNS.ORG --domain-controller 192.168.2.200 --computer-name fs-neorealm.ad.intern.darkrealm.dyndns.org --login-type user --login-user domain.admin --stdin-password
Domain Leave:
/usr/sbin/adcli delete-computer --verbose --domain ad.intern.darkrealm.dyndns.org --domain-realm AD.INTERN.DARKREALM.DYNDNS.ORG --domain-controller dc-neorealm.ad.intern.darkrealm.dyndns.org --login-user domain.admin
/etc/krb5.smb erstellen:
- Wird (sollte) normal beim DomainJoin erstellt
Manuell erstellen:
Auf dem samba-dc:
samba-tool domain exportkeytab cortexreaver.keytab --principal=CORTEXREAVER$ scp cortexreaver.keytab root@cortexreaver:/etc/krb5.smb
Voraussetzungen
SSSD braucht eine /etc/krb5.smb Keytab, dadrin muss stehen:
cortexreaver /var/log/sssd # klist -kte /etc/krb5.smb Keytab name: FILE:/etc/krb5.smb KVNO Timestamp Principal ---- ------------------- ------------------------------------------------------ 4 15.09.2022 11:03:48 CORTEXREAVER$@AD.INTERN.DARKREALM.DYNDNS.ORG (aes256-cts-hmac-sha1-96) 4 15.09.2022 11:03:48 CORTEXREAVER$@AD.INTERN.DARKREALM.DYNDNS.ORG (aes128-cts-hmac-sha1-96) 4 15.09.2022 11:03:48 CORTEXREAVER$@AD.INTERN.DARKREALM.DYNDNS.ORG (DEPRECATED:arcfour-hmac)
Fehler
SSSD updated nicht den Dyndns-Eintrag des Hosts
- samba-dnsupdate --verbose --all-names ausführen
- Bei Fehler "tkey is unacceptable*:
- Rechte von /var/lib/samba/private/dns.keytab prüfen, BIND braucht Leserechte darauf
Auto-discovered Realm nsupdate schlägt lt. Logfile fehl
Workaround: explizit dyndns_server = samba-dc.ad.intern.darkrelam.dyndns.org in sssd.conf angeben. SSSD versucht zwar immer noch über den auto-discovered realm zu gehen, nimmt dann aber im Anschluss den dyndns_server-Eintrag.
Befehl um Logeinträge zu überprüfen:
cat /var/log/sssd/sssd_AD.INTERN.DARKREALM.DYNDNS.ORG.log | grep nsupdate -A10
/etc/krb5.smb ist plötzlich leer
SSSD versucht über adcli das Maschinenpasswort zu updaten. Dies schlägt jedoch mit einem permission denied auf die /tmp/adcli-krb5-XXXXX/krb5.conf fehl. Workaround: adcli deinstallieren. Fehlerbehebung: adcli patchen so dass adcli umask 0700 und nicht 0600 nimmt.
Befehl um Logeinträge zu prüfen:
cat /var/lib/sssd/sssd_AD.INTERN.DARKREALM.DYNDNS.ORG.log | grep adcli -A5