Ich versuche, einen Ubuntu 14.04-Server einer Windows 2003 R2-Domäne hinzuzufügen. Mein Administrator sagt, dass er von der Controllerseite aus Teil der Domäne ist. Aber SSSD lässt sich anscheinend nicht starten und das DNS-Update schlägt fehl.
Ich habe viele verschiedene Anleitungen befolgt, um es zum Laufen zu bringen, aber keine davon ist mir ohne Fehler gelungen.
Ubuntu Server-Handbuch
KiloRoot
NetNerds
Fedora SSSD-Handbuch
Discovery scheint einwandfrei zu funktionieren:
kyle@Server21:~$ realm discover COMPANYNAME.LOCAL
CompanyName.Local
type: kerberos
realm-name: COMPANYNAME.LOCAL
domain-name: companyname.local
configured: kerberos-member
server-software: active-directory
client-software: sssd
required-package: sssd-tools
required-package: sssd
required-package: libnss-sss
required-package: libpam-sss
required-package: adcli
required-package: samba-common-bin
login-formats: %U
login-policy: allow-realm-logins
companyname.local
type: kerberos
realm-name: COMPANYNAME.LOCAL
domain-name: companyname.local
configured: no
realmdsagt, dass ich auch der Domäne beigetreten bin:
kyle@Server21:~$ realm join COMPANYNAME.LOCAL
realm: Already joined to this domain
Kerberos hat die Authentifizierung meines Administrators übernommen:
kyle@Server21:~$ kinit -V administrator
Using default cache: /tmp/krb5cc_0
Using principal: [email protected]
Password for [email protected]:
Authenticated to Kerberos v5
Doch beim Beitritt schlägt das DNS-Update fehl:
kyle@Server21:~$ sudo net ads join -k
Using short domain name -- COMPANYNAME
Joined 'SERVER21' to dns domain 'CompanyName.Local'
No DNS domain configured for server21. Unable to perform DNS Update.
DNS update failed: NT_STATUS_INVALID_PARAMETER
Und SSSD hat immer noch ein Startproblem:
kyle@Server21:~$ systemctl status sssd.service
● sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Wed 2016-06-22 09:57:57 EDT; 37min ago
Process: 16027 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=1/FAILURE)
Jun 22 09:57:55 Server21 sssd[16038]: Starting up
Jun 22 09:57:55 Server21 sssd[16041]: Starting up
Jun 22 09:57:55 Server21 sssd[16042]: Starting up
Jun 22 09:57:56 Server21 sssd[be[16043]: Starting up
Jun 22 09:57:57 Server21 sssd[be[16043]: Failed to read keytab [default]: No such file or directory
Jun 22 09:57:57 Server21 sssd[16031]: Exiting the SSSD. Could not restart critical service [COMPANYNAME.LOCAL].
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Control process exited, code=exited status=1
Jun 22 09:57:57 Server21 systemd[1]: Failed to start System Security Services Daemon.
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Unit entered failed state.
Jun 22 09:57:57 Server21 systemd[1]: sssd.service: Failed with result 'exit-code'.
Der einzige Teil, krb5.confder für mich spezifisch ist, ist [libdefaults]:
kyle@Server21:~$ cat /etc/krb5.conf
[libdefaults]
default_realm = COMAPNYNAME.LOCAL
Bei einer früheren Installation dachte ich jedoch, dass da noch etwas anderes drin ist, [realms]aber ich kann mich nicht erinnern, was. Im Fedora-Handbuch wird davon gesprochen, dort etwas hinzuzufügen, wenn DNS-Lookups nicht funktionieren, aber es geht nicht detailliert genug darauf ein, damit ich genau herausfinden kann, was da sein soll.
Meine Änderungen an smb.conf:
[global]
## Browsing/Identification ###
# Change this to the workgroup/NT-domain name your Samba server will part of
workgroup = COMPANYNAME
client signing = yes
client use spnego = yes
kerberos method = secrets and keytab
realm = COMPANYNAME.LOCAL
security = ads
Meinsssd.conf
kyle@Server21:~$ sudo cat /etc/sssd/sssd.conf
[sssd]
services = nss, pam
config_file_version = 2
domains = COMPANYNAME.LOCAL
[domain/COMPANYNAME.LOCAL]
id_provider = ad
access_provider = ad
override_homedir = /home/%d/%u
Und da im Ubuntu-Handbuch steht, dass Eigentumsrechte und Berechtigungen wichtig sind:
kyle@Server21:~$ sudo ls -la /etc/sssd
total 12
drwx--x--x 2 sssd sssd 4096 Jun 21 14:34 .
drwxr-xr-x 103 root root 4096 Jun 22 10:21 ..
-rw------- 1 root root 172 Jun 21 14:22 sssd.conf
Im Ubuntu-Handbuch wird auch erwähnt, dass die hostsDatei Probleme bei der DNS-Aktualisierung verursachen könnte, aber ich glaube, ich habe das Beispiel richtig befolgt:
kyle@Server21:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 Server21
192.168.XXX.XXX Server21 Server21.COMPANYNAME.LOCAL
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Was mache ich hier falsch? Der Domänencontroller sagt, dass er Teil der Domäne ist. Apache und OpenSSH sind beide aktiv und zugänglich. Aber dieser Server muss noch viel mehr tun, und deshalb möchte ich sicherstellen, dass alles richtig konfiguriert ist, bevor ich weitermache.
Bearbeiten:
Ich habe meine hostsDatei geändert auf Anraten vondiese Seiteso dass es jetzt so aussieht:
kyle@Server21:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 Server21.COMPANYNAME.LOCAL Server21
192.168.11.11 Server21.COMPANYNAME.LOCAL Server21
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
Gibt jetzt getentzurück:
kyle@Server21:~$ sudo getent hosts Server21
127.0.1.1 Server21.COMPANYNAME.LOCAL Server21 Server21
192.168.11.11 Server21.COMPANYNAME.LOCAL Server21 Server21
Und net ads joinjetzt hat eine andere Fehlermeldung:
kyle@Server21:~$ sudo net ads join -k
Failed to join domain: failed to lookup DC info for domain 'COMPANYNAME.LOCAL' over rpc: An internal error occurred.
Der einzige Rat, den ich bisher zu diesem Fehler gefunden habe, besagt, dass man sicherstellen soll, dass der AD-Server vorhanden ist resolv.confund seine IP der einzige Eintrag ist.
kyle@Server21:~$ cat /etc/resolv.conf
# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
# DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
nameserver 192.168.XXX.XXX
So beantworten Sie einen Kommentar:
kyle@Server21:~$ nslookup -type=SRV _ldap._tcp.companyname.local
Server: 192.168.XXX.XXX
Address: 192.168.XXX.XXX#53
_ldap._tcp.companyname.local service = 0 100 389 companynamedc.companyname.local.
Irgendwann konnte SSSD gestartet werden und ist jetzt aktiv. Ich bin mir jedoch nicht sicher, was ich getan habe, um das Problem zu beheben.
Antwort1
Das Problem scheint darin zu liegen, dass mein Administrator einen Eintrag auf dem Domänencontroller für diesen Server erstellt hatte. Dies verursachte offenbar einen Konflikt, der dazu führte, dass Kerberos beim Versuch, sich anzumelden, den folgenden Fehler auslöste:
kyle@Server21:~$ sudo net ads join -k
Failed to join domain: failed to lookup DC info for domain 'COMPANYNAME.LOCAL' over rpc: An internal error occurred.
Ich bin nicht sicher, ob dieser Fehler vollständig zutreffend war, da mein Administrator sagte, der Server sei auf seiner Seite der Domäne beigetreten und realmdangab, dass ich ebenfalls beigetreten sei:
kyle@Server21:~$ realm join COMPANYNAME.LOCAL
realm: Already joined to this domain
Für einen erfolgreichen Kerberos-Beitritt habe ich die folgenden Schritte ausgeführt:
- Der Administrator hat den Eintrag im Domänencontroller entfernt
- Führen Sie die Kerberos-Konfiguration erneut aus mit:
sudo dpkg-reconfigure krb5-config - Wählen Sie die Optionen in der Konfiguration, um den Domänencontroller explizit zum
[realms]Abschnitt von hinzuzufügenkrb5.conf - Der Hostname wurde geändert, um sicherzustellen, dass ein neuer Datensatz erstellt wurde
- Habe ein neues Ticket gezogen mit
kinit - Bin der Domäne beigetreten mit
sudo net ads join -k
Endergebnis:
kyle@SERV21:~$ sudo net ads join -k
Using short domain name -- COMPANYNAME
Joined 'SERV21' to dns domain 'CompanyName.Local'
Antwort2
versuchen Sie dies auf Server21:
realm leave -v -U [your admin username] COMPANYNAME.LOCAL
Dann
realm join -v -U [your admin username] COMPANYNAME.LOCAL