Probleme beim Beitritt zu einer Active Directory-Domäne


9

Ich versuche, einen Ubuntu 16.04-Server mit einer Windows 2003 R2-Domäne zu verbinden, indem ich dem Ubuntu SSSD- und Active Directory-Handbuch folge . Mein Administrator sagt, dass es von der Controllerseite Teil der Domäne ist. Aber SSSD scheint nicht zu starten und net ads joinschlägt fehl.

Das krb5.confwurde vom Installer geändert und hat nun folgendes:

kyle@Server21:~$ cat /etc/krb5.conf
[libdefaults]
        default_realm = COMAPNYNAME.LOCAL

Bei einer früheren Installation dachte ich, [realms]dass während der Installation noch etwas anderes gefragt wurde, aber ich kann mich nicht erinnern, was und diesmal wurde es nicht gefragt.

Mein 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

Mein sssd.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

Obwohl der SSSD-Dienst scheinbar nicht gestartet werden kann:

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'.

Und da der Leitfaden besagt, dass Eigentum 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

Mein nsswitch.conf:

kyle@Server21:~$ cat /etc/nsswitch.conf
# /etc/nsswitch.conf
#
# Example configuration of GNU Name Service Switch functionality.
# If you have the `glibc-doc-reference' and `info' packages installed, try:
# `info libc "Name Service Switch"' for information about this file.

passwd:         compat sss
group:          compat sss
shadow:         compat sss
gshadow:        files

hosts:          files dns
networks:       files

protocols:      db files
services:       db files sss
ethers:         db files
rpc:            db files

netgroup:       nis sss
sudoers:        files sss

Mein hosts:

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

Hier beginnt der Ärger. Verwenden Sie sudo, um kinitErgebnisse wie folgt auszuführen :

kyle@Server21:~$ sudo kinit adminstrator
kinit: Client 'adminstrator@COMPANYNAME.LOCAL' not found in Kerberos database while getting initial credentials

Es wird authentifiziert, wenn ich das aber fallen sudolasse:

kyle@Server21:~$ kinit -V administrator
Using default cache: /tmp/krb5cc_1000
Using principal: administrator@COMPANYNAME.LOCAL
Password for administrator@COMPANYNAME.LOCAL:
Authenticated to Kerberos v5

Und ich kann das Ticket überprüfen:

kyle@Server21:~$ klist
Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: administrator@COMPANYNAME.LOCAL

Valid starting       Expires              Service principal
06/23/2016 13:41:55  06/23/2016 23:41:55  krbtgt/COMPANYNAME.LOCAL@COMPANYNAME.LOCAL
        renew until 06/24/2016 13:41:48

Aber wenn ich versuche, der Domain beizutreten:

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 hatte zuvor die NT_STATUS_UNSUCCESSFULim Handbuch erwähnte Nachricht erhalten, konnte diese jedoch durch Ändern meiner hostsDatei beheben .

In diesem Handbuch wird überprüft, ob das Computerkonto im Active Directory erstellt wurde. Und mein Administrator sagt, dass er die Maschine gut sehen kann, also glaube ich, dass das in Ordnung ist. Die zweite Überprüfungsoption sagt mir nicht, was ich von diesem Befehl zurückbekommen soll, aber ich erhalte nichts, also denke ich, dass es nicht funktioniert.

Wo gehe ich hier falsch?


Bearbeiten:

Ich bin nicht sicher, was ich getan habe, aber SSSD läuft jetzt.


Ubuntu 14.04 verwendet Upstart, nicht systemd. Diese Ausgabe ist faul.
Muru

@muru Entschuldigung für den Tippfehler. Ich bin am 16.04. Frage wurde bearbeitet.
embedded.kyle

Antworten:


3

Das Problem scheint gewesen zu sein, dass mein Administrator einen Eintrag auf dem Domänencontroller für diesen Server erstellt hat. Dies führte anscheinend zu einem Konflikt, bei dem Kerberos beim Beitrittsversuch auf folgenden Fehler stieß:

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 mir nicht sicher, ob dieser Fehler vollständig korrekt war, da mein Administrator sagte, dass der Server an seinem Ende der Domain beigetreten ist und realmdangab, dass ich ebenfalls beigetreten bin:

kyle@Server21:~$ realm join COMPANYNAME.LOCAL
realm: Already joined to this domain

Die Schritte, die ich befolgt habe, um einen erfolgreichen Kerberos-Join zu erhalten, waren wie folgt:

  1. Der Administrator hat den Eintrag im Domänencontroller entfernt
  2. Reran Kerberos-Konfiguration mit: sudo dpkg-reconfigure krb5-config
  3. Wählen Sie die Optionen in der Konfiguration aus, um den Domänencontroller explizit zum [realms]Abschnitt von hinzuzufügenkrb5.conf
  4. Der Hostname wurde geändert, um sicherzustellen, dass ein neuer Datensatz erstellt wurde
  5. Ich habe ein neues Ticket mit gezogen kinit
  6. Beitritt zur Domain 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'

0

Ich denke, Sie vermissen das Keytab. Sie können es über das Kadmin-Tool erstellen. Geben Sie kadmin und in der Eingabeaufforderung geben Sie Hilfe , um zu sehen , wie die keytab hinzuzufügen.


/etc/krb5.keytabexistiert bereits und hat einige verschlüsselte Sachen, die mit dem Servernamen und dem Domainnamen durchsetzt sind. Muss ich eine zusätzliche erstellen?
embedded.kyle
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.