AD -> UCS Sync = Failed to lookup S4 LDAP base

german

#1

Hallo an alle,

wir versuchen eine Synchronisierung zwischen einem Win Server 2012 mit AD Forest 2012 (local.de) -> UCS 4.1-4 Master (local.de) zu erreichen.
Wir wählen die Option:

UCS als Teil einer Active Directory-Domäne konfigurieren (empfohlen).

Nach “AD-Domäne beitreten” läuft der Prozess an und der UCS konfiguriert sich.
Der Prozess scheitert allerdings beim Samba Join.

AD-Verbindung - Ein Fehler trat auf

Ein Fehler trat während des Beitritts von UCS zur Active Directory-Domäne auf. Die folgenden Informationen enthalten weitere Details über das genauere Problem.

Ein unerwarteter Fehler trat auf: 26univention-samba.inst failed

Das join.log ist recht leer:

583582a0 OVER: Loading Translog Overlay
583582a0 OVER: db_init
583582a0 OVER: Configuring Translog Overlay
583582a0 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
583582a0 OVER: db_close
583582a0 OVER: db_destroy

Die connector.log führt einige (aber weitem nicht alle) Einträge, welche vom AD zum UCS gesynct wurden.

24.11.16 12:39:59.042  LDAP        ( PROCESS ) : Renaming 'cn=Domain Guests,cn=groups,dc=local,dc=de' to 'Domänen-Gäste' in UCS LDAP.
24.11.16 12:39:59.042  LDAP        ( WARN    ) : rename cn=Domänen-Gäste

connectors-s4.log

23.11.2016 13:00:51,702 MAIN        (------ ): DEBUG_INIT
23.11.2016 13:00:51,751 LDAP        (PROCESS): Building internal group membership cache
23.11.2016 13:00:51,781 LDAP        (PROCESS): Internal group membership cache was created
23.11.2016 13:07:55,120 MAIN        (------ ): DEBUG_INIT
23.11.2016 13:07:55,143 LDAP        (ERROR  ): Failed to lookup S4 LDAP base, using UCR value.
23.11.2016 13:09:04,628 MAIN        (------ ): DEBUG_INIT
23.11.2016 13:09:04,684 LDAP        (PROCESS): Building internal group membership cache
23.11.2016 13:09:04,717 LDAP        (PROCESS): Internal group membership cache was created
23.11.2016 15:17:12,587 MAIN        (------ ): DEBUG_INIT
23.11.2016 15:17:12,610 LDAP        (ERROR  ): Failed to lookup S4 LDAP base, using UCR value.

connector-s4-status.log

Thu Nov 24 12:38:45 2016
--------------------------------------
try to sync 0 changes from UCS
done:
Changes from UCS: 0 (0 saved rejected)
--------------------------------------
--------------------------------------
try to sync 0 changes from S4
done:
Changes from S4:  0 (0 saved rejected)
--------------------------------------
- sleep 5 seconds (8/10 until resync) -

connector-status.log

Wed Nov 23 16:58:54 2016
connector/ad/ldap/host not set

Ab diesem Prozedere können wir uns nicht mal als UCS Administrator anmelden, komischerweise funktioniert die Anmeldung des Domänen-Admins der Win AD Domäne.
Nach der Anmeldung kommt die UCS Meldung:

Nicht alle installierten Komponenten wurden registriert. Bitte rufen Sie das Modul "Domänenbeitritt" auf um alle verbliebenen Komponenten zu registrieren.

In der Liste ist der Samba-Join als Ausstehend markiert.
Führen wir den Join nochmals aus, steht folgendes im join.log

583582a0 OVER: Loading Translog Overlay
583582a0 OVER: db_init
583582a0 OVER: Configuring Translog Overlay
583582a0 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
583582a0 OVER: db_close
583582a0 OVER: db_destroy

univention-run-join-scripts started
Do 24. Nov 12:59:20 CET 2016

RUNNING 26univention-samba.inst
2016-11-24 12:59:20.314613275+01:00 (in joinscript_init)
Not updating samba/role
Setting samba/domain/security
Multifile: /etc/samba/smb.conf
Setting samba/autostart
Multifile: /etc/samba/smb.conf
Not updating samba/autostart
Stopping the Winbind daemon: winbind.
Setting samba/user
Not updating samba/user/pwdfile
Multifile: /etc/samba/smb.conf
Setting stored password for "cn=ucs,cn=dc,cn=computers,dc=local,dc=de" in secrets.tdb
setting idmap secret for '*' from /etc/machine.secret
Secret stored
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
Object modified: cn=ucs,cn=dc,cn=computers,dc=local,dc=de
Failed to join domain: failed to find DC for domain LOCAL - Undetermined error
Bad SMB2 signature for message
[0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
[0000] 38 08 10 92 9B 8C D6 63 36 24 E6 7B 9D 5D 8B 79 8......c 6$.{.].y
Failed to join domain: failed to lookup DC info for domain 'LOCAL' over rpc: Access denied
Bad SMB2 signature for message
[0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
[0000] 72 03 0D C6 52 4A 05 4C F7 FF 20 AC 5F 07 34 98 r...RJ.L .. ._.4.
Failed to join domain: failed to lookup DC info for domain 'LOCAL' over rpc: Access denied
ERROR: Failed to join via net rpc join. Please check your Samba DCs and your DNS and WINS configuration.
EXITCODE=1

Do 24. Nov 12:59:34 CET 2016
univention-run-join-scripts finished

Auffällig ist der Error failed to lookup DC info for domain ‘LOCAL’ over rpc: Access denied

Haben wir etwas nicht beachtet?
Funktioniert der Sync von einem UCS Master mit einem Win AD überhaupt?


#2

Hallo,

zunächst: ist das ein neuer UCS in eine bestehende Domäne oder müssen hier ggf. bereits bestehende Einstellungen auf dem UCS mit in die Analyse einberechnet werden?

Es ist möglich einen UCS master in eine bestehende AD Domäne einzubinden, genutzt wird dafür “UCS als Teil einer Active Directory-Domäne konfigurieren” - das ist also soweit korrekt. Wir haben dafür eine Dokumentation bereitgestellt die den sogenannten “Membermode” erklärt: http://docs.software-univention.de/manual-4.1.html#ad-connector:ad-member-einrichtung Die Voraussetzungen sind dort ebenfalls erklärt. Unter anderem ist das:

The AD member mode can only be configured on a master domain controller. The name of the DNS domain of the UCS systems must match that of the AD domain. The host name must of course be different. All the AD and UCS servers in a connector environment must use the same time zone.

Ist der AD DC vom UCS master grundsätzlich erreichbar, per DNS, IP, etc.?

Gruß,
Jens Thorp-Hansen


#3

Hallo!

[quote=“Thorp-Hansen”]
zunächst: ist das ein neuer UCS in eine bestehende Domäne oder müssen hier ggf. bereits bestehende Einstellungen auf dem UCS mit in die Analyse einberechnet werden? [/quote]
Es ist ein neuer UCS mit derselben Domäne wie die des Windows AD Server.

[quote=“Thorp-Hansen”]
Es ist möglich einen UCS master in eine bestehende AD Domäne einzubinden, genutzt wird dafür “UCS als Teil einer Active Directory-Domäne konfigurieren” - das ist also soweit korrekt. Wir haben dafür eine Dokumentation bereitgestellt die den sogenannten “Membermode” erklärt: http://docs.software-univention.de/manual-4.1.html#ad-connector:ad-member-einrichtung Die Voraussetzungen sind dort ebenfalls erklärt.[/quote]
Genau nach dieser Anleitung setzen wir den UCS auf.

Der UCS ist als Master Server eingerichtet.
Die UCS Domäne ist gleiche wie die des Windows AD, der Hostname ist unterschiedlich.
Die Zeitzone ist bei beiden identisch.


#4

Okay, aus der Ferne ist es natürlich nicht so leicht die Ursache für das Klopfen dieses Motors herauszubekommen. :slight_smile:

Können Sie bitte zunächst wie in folgendem Beitrag beschrieben (letzter Post von mir) vorgehen um alle Seiteneffekte auszuschliessen? [url]UCS AD Conncetor and Windows 2012 Domain]

[quote]- Install a new 4.1-4

  • At the IP Konfiguration choose an IP and set the DNS Server to the AD Server (and no other! The own IP as nameserver will be automatically set after the join-process)
  • “Install in existing AD Domain” -> the setup should now do a lookup for the AD server and present you with: “bebw12mtasvrp1.bebconsultingservices.com” as server to join to
  • Give the AD Administrator and Password
  • At the name configuration set “bebucsmtasvrp5” as local name
  • Install “Active Directory Connection” and proceed with the process [/quote]

Sie sollten dann zur Sicherheit auch einen anderen Namen als den bisher benutzten wählen. Grundsätzlich besagen die MEldungen, das skeine Verbindung zu einem S4 DC aufgebaut werden konnte - ggf. sind also auch Netzwerkissues zu beachten oder ähnliches.

Gruß,
Jens Thorp-Hansen


#5

Leider funktioniert die beschriebene Prozedur bei uns auch nicht.

Die connector-status.log zeigt folgendes an:

Mon Nov 28 11:21:01 2016
connector/ad/ldap/host not set

Die join.log zeigt folgendes an:

Mon Nov 28 11:08:29 CET 2016: starting /usr/share/univention-join/univention-join -dcaccount admin -dcpwd /tmp/tmp.dcLi6rX4q8
ssh: connect to host dc1.local.de port 22: Connection refused
Mon Nov 28 11:08:29 CET 2016: finish /usr/share/univention-join/univention-join

Mir ist unklar, wieso der Windows AD DC per SSH (Port 22) angesprochen wird.
Das macht doch nur bei Linux (UCS) Systemen Sinn.


#6

“dc1” ist vermutlich der master, den Sie zuerst versucht haben zu installieren, richtig? Sie haben im Moment die Situation, dass der master durch die vormaligen Fehlversuche bereits im System bekanntgemacht wurde. Ein neu installiertes System versucht nun automatisch dem master und nicht mehr dem AD zu joinen (das geht natürlich über den angegebenen Weg). Es ist nun leider notwendig, dass Sie das AD von jeder Information bereinigen, die noch den Namen des alten masters beinhaltet - ziemlich sicher werden das Einträge im DNS Dienst sein. Erst wenn das AD den alten master nicht mehr kennt, können Sie einen neuen Versuch nach meiner Anleitung mit einem neuen Namen versuchen.

Gruß,
Jens Thorp-Hansen


#7

So ganz kann ich leider dem nicht folgen.
Der DC1 ist unser Windows AD DC der aktuellen Produktivumgebung, der von dem neu aufgesetzten UCS System (Backup Mode) versucht wird zu kontaktieren.
Deswegen mein Stutzen bei SSH zum Windows System.

Der Windows AD DC, der vermutlich mit Master bei Ihnen gemeint ist, kann im neuen UCS System nicht bekannt sein, da ja neu aufgesetzt.

Allerdings haben wir von früher einen DNS-Eintrag (laut Dokumentation) mit “_domaincontroller_master” erstellt, der auf den dc1.local.de (also den Windows AD DC) zeigt.
Das sollte aber kein Problem sein, oder?


#8

[quote=“ryul”]Allerdings haben wir von früher einen DNS-Eintrag (laut Dokumentation) mit “_domaincontroller_master” erstellt, der auf den dc1.local.de (also den Windows AD DC) zeigt.
Das sollte aber kein Problem sein, oder?[/quote]

Doch genau der ist das Problem.


#9

[quote=“SirTux”][quote=“ryul”]Allerdings haben wir von früher einen DNS-Eintrag (laut Dokumentation) mit “_domaincontroller_master” erstellt, der auf den dc1.local.de (also den Windows AD DC) zeigt.
Das sollte aber kein Problem sein, oder?[/quote]

Doch genau der ist das Problem.[/quote]

Jop, der ist das Problem.

Edit:

Es ist wichtig den folgenden Punkt zu verinnerlichen: der UCS wird als “master” in die Windows AD Domäne gejoint. Das heisst, der Windows DC ist der Primary Domaincontroller für alle Windows Geräte und den (singular!) UCS. Der UCS ist wiederum der (einzige!) “master” für alle weiteren UCS Systeme. Der UCS wird nur “Lesen” und der Windows PDC gibt alle Informationen an den UCS master zur weiteren Verwendung. Wenn Sie also einen “master” Eintrag machen im AD, werden die nachfolgendend gejointen Systeme das AD fragen “Hey, wer ist mein master?” und das AD wird sagen: “Schau hier: _domaincontroller_master”. Die nachfolgend zu joinenden Systeme sehen dass Sie bei der Installation nicht als master joinen müssen, da bereits einer existiert (im UCS Umfeld gibt es im Moment nicht die Möglichkeit für mehrere master) und kontaktieren den “master” wie sie es gewohnt sind.

Ich schlage vor, dass AD zu bereinigen und noch einmal von vorn zu beginnen. Beachten Sie meine obige Ausführung, dann sollte der Vorgang durchlaufen (wenn die Konnectivität gegeben ist).

Gruß,
Jens Thorp-Hansen


#10

Das Löschen des Eintrags führt leider zum selben Ergebnis.

Die UCS Konsole warnt mich nun in Folge dessen mit der Meldung:

[code]DNS-Check
Achtung! Der DNS Service Record für den UCS Master wurde nicht im DNS Server gefunden.

Details sind in der Support Database erklärt.[/code]

Der Link führt dann zur bekannten Seite mit dem “_domaincontroller_masterhttp://sdb.univention.de/1299

Die connector.log meldet nach einigen Umbennungseinträgen nun folgendes:

28.11.2016 13:50:03,779 MAIN        (------ ): DEBUG_INIT
28.11.2016 13:50:03,840 LDAP        (ERROR  ): Failed to lookup AD LDAP base, using UCR value.

connector-status.log

Mon Nov 28 13:57:04 2016
 --- connect failed, failure was: ---

Traceback (most recent call last):
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 290, in main
    connect()
  File "/usr/share/pyshared/univention/connector/ad/main.py", line 184, in connect
    baseConfig['%s/ad/listener/dir' % CONFIGBASENAME])
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 696, in __init__
    self.open_ad()
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 887, in open_ad
    self.get_kerberos_ticket()
  File "/usr/lib/pymodules/python2.7/univention/connector/ad/__init__.py", line 866, in get_kerberos_ticket
    raise kerberosAuthenticationFailed('The following command failed: "%s"' % string.join(cmd_block))
kerberosAuthenticationFailed: The following command failed: "kinit --no-addresses --password-file=/etc/machine.secret ucs-6651$"

 ---     retry in 30 seconds      ---

connector-s4-status.log

Mon Nov 28 13:45:32 2016
--------------------------------------
try to sync 14 changes from UCS
done: 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Changes from UCS: 13 (1 saved rejected)
--------------------------------------
--------------------------------------
try to sync 1 changes from UCS
done: 1
Changes from UCS: 0 (1 saved rejected)
--------------------------------------
--------------------------------------
try to sync 1 changes from S4
done: 1
Changes from S4:  1 (0 saved rejected)
--------------------------------------
--------------------------------------
try to sync 0 changes from S4
done:
Changes from S4:  0 (0 saved rejected)
--------------------------------------
- sleep 5 seconds (1/10 until resync) -

join.log

583c2521 OVER: Loading Translog Overlay
583c2521 OVER: db_init
583c2521 OVER: Configuring Translog Overlay
583c2521 OVER: Configured Translog Overlay to use file "/var/lib/univention-ldap/listener/listener"
583c2521 OVER: db_close
583c2521 OVER: db_destroy

Edit:

Um kurz nochmal zu erläutern, was eigentlich unser Ziel ist:

  • wir wollen einen UCS, der Daten vom Windows AD DC -> UCS kopiert
  • Apps vom UCS sollen diese Daten (Konten) nutzen können, um neue Services für den Nutzer zu bieten

Werden vom UCS während des Joins andere Einträge im Windows AD DC erstellt / geändert, die nun den Join beim neu aufsetzen verhindern?
(außer dem schon genannten und gelöschten “_domaincontroller_master”)


#11

Hallo,
ich glaube wir reden aneinander vorbei oder uns fehlen wichtige System-Umstände, die jegliche Lösungsvorschläge unsererseits nicht hilfreich machen.

Der Eintrag “domaincontroller_master” ist dem UCS master vorbehalten. Den gibt es natürlich nicht, wenn dieser zuerst in eine Domäne gejoint wird und wird dann unter anderem durch die Joinscripte angelegt. Des weiteren sollten auf dem Windows DNS Server aber auf jeden Fall die Einträge _kerberos, _kpasswd, _ldap, etc. auf den Windows AD zeigen. Die Ausgangssituation muss sich also folgendermaßen darstellen:

  • Windows Server 2003, 2008 oder 2012 als Domaincontroller konfiguriert
  • Anmeldung für Windows Clients an diesem AD ist ohne weiteres möglich
  • DNS ist ohne Workarounds, etc. möglich
  • Es gibt keine Verweise auf den UCS Server (bitte sicherstellen)

Erst wenn das gegeben ist, kann der UCS neu installiert werden. Der DNS Domainname der auf dem UCS konfiguriert wird muss dabei dem der Windows AD Domäne entsprechen. Der Computername muss unterschiedlich sein und darf im Netz nicht ein weiteres Mal verwendet werden. Bei der Grundinstallation des UCS wird eine IP Adresse aus dem AD Adressbereich verwendet und der DNS Server auf den des AD gesetzt. Es wird ausgewählt der AD Domäne beizutreten - es darf nun !keine! Auswahl nach der Server-Rolle auftreten (wenn diese auftritt, glaubt das AD, es hätte noch einen UCS master im System) - der UCS wird automatisch als master beitreten. Nachfolgend wird noch die Active-Directory Verbindung (!nicht der AD Controller!) bei der Auswahl der zu installierenden Pakete gewählt und die Installation sollte ohne weiteres durchlaufen - ich konnte das nun schon mehrere Male in der Testumgebung verifizieren.

Falls das nicht klappen sollte, gibt es noch Umstände die nicht bekannt sind, dann müssten Sie bitte die Umgebung genauer beschreiben.

Gruß,
Jens Thorp-Hansen


#12

Vielen Dank für Ihre Mühe und die Hinweise!

Wir werden eine Win AD Testdomain erstellen und dort ein UCS Join probieren.
Wir gehen auch von speziellen “Netzproblemen” bei uns aus, die uns bisher verborgen sind.
Das AD ist soweit ich mich erinnere von NT Zeiten immer wieder “geupgradet” worden, mögliche Probleme können dort überall sein.


#13

Nachtrag -> Fehler gefunden!

Hallo nochmal,

wir haben den “Fehler” gefunden und ich will hier kurz beschreiben was die Ursache für den nicht erfolgreichen Domänen-Join war.

1.)
Wir haben immer ein Domänen-Admin Konto für die Anmeldung im UCS Domänen-Join (“Active Directory-Verbindung”) genutzt.
Eigentlich logisch, warum sollte das auch nicht klappen.
Nun, im Log management-console-module-adconnector.log ist ja der Join-Prozess detailliert dokumentiert.
Dort stand dann folgendes:

18.01.17 09:49:40.745  MODULE      ( PROCESS ) : Einrichten des Administrator-Kontos...
18.01.17 09:49:40.945  MODULE      ( PROCESS ) : Prepare administrator account
18.01.17 09:49:41.321  MODULE      ( PROCESS ) : Ausführen des Samba Join-Skripts...
18.01.17 09:49:41.525  MODULE      ( PROCESS ) : Running samba join script
18.01.17 09:49:52.769  MODULE      ( PROCESS ) : 2017-01-18 09:49:41.559282945+01:00 (in joinscript_init)
Create samba/role
Multifile: /etc/samba/smb.conf
INFO: ad/member is true, will join as memberserver into an AD domain
Create samba/domain/security
Multifile: /etc/samba/smb.conf
Setting samba/share/home
File: /etc/samba/base.conf
Multifile: /etc/samba/smb.conf
Setting samba/autostart
Multifile: /etc/samba/smb.conf
Not updating samba/autostart
Stopping the Winbind daemon: winbind.
Create samba/user
Create samba/user/pwdfile
Multifile: /etc/samba/smb.conf
Setting stored password for "cn=ucs-dc1,cn=dc,cn=computers,dc=local,dc=de" in secrets.tdb
setting idmap secret for '*' from /etc/machine.secret
Secret stored
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
Permission denied.

18.01.17 09:49:52.769  MODULE      ( ERROR   ) : 26univention-samba.inst failed with 3
18.01.17 09:49:52.769  MODULE      ( ERROR   ) : Join process failed [sambaJoinScriptFailed]: 26univention-samba.inst failed

Der Punkt Permission denied. machte uns hier stutzig.
Eigentlich sollten die Berechtigungen kein Problem sein.
Wir haben dann als Test einen Domänen-Admin namens “Administrator” in unserer Domäne erstellt, dieser existierte nämlich vorher nicht
Wir haben andersnamigen Domänen-Admin Konten genutzt.

Da wir eine virtuelle Umgebung nutzen, haben wir den UCS DC per Snapshot wieder zurückgesetzt.
Beim nächsten Join-Versuch passierte dann folgendes:

18.01.17 09:58:05.079  MODULE      ( PROCESS ) : Einrichten des Administrator-Kontos...
18.01.17 09:58:05.280  MODULE      ( PROCESS ) : Prepare administrator account
18.01.17 09:58:05.666  MODULE      ( PROCESS ) : Ausführen des Samba Join-Skripts...
18.01.17 09:58:05.870  MODULE      ( PROCESS ) : Running samba join script
18.01.17 09:58:17.257  MODULE      ( PROCESS ) : 2017-01-18 09:58:05.904157665+01:00 (in joinscript_init)
Create samba/role
Multifile: /etc/samba/smb.conf
INFO: ad/member is true, will join as memberserver into an AD domain
Create samba/domain/security
Multifile: /etc/samba/smb.conf
Setting samba/share/home
File: /etc/samba/base.conf
Multifile: /etc/samba/smb.conf
Setting samba/autostart
Multifile: /etc/samba/smb.conf
Not updating samba/autostart
Stopping the Winbind daemon: winbind.
Create samba/user
Create samba/user/pwdfile
Multifile: /etc/samba/smb.conf
Setting stored password for "cn=ucs-dc1,cn=dc,cn=computers,dc=local,dc=de" in secrets.tdb
setting idmap secret for '*' from /etc/machine.secret
Secret stored
Stopping Samba daemons: nmbd smbd.
Starting Samba daemons: nmbd smbd.
Object modified: cn=ucs-dc1,cn=dc,cn=computers,dc=local,dc=de
Failed to join domain: Invalid configuration ("workgroup" set to 'local', should be 'LOCAL1') and configuration modification was not requested
ERROR: Failed to join to AD DC via net ads join. Please check your Samba DCs and your DNS and WINS configuration.

18.01.17 09:58:17.257  MODULE      ( ERROR   ) : 26univention-samba.inst failed with 1
18.01.17 09:58:17.257  MODULE      ( ERROR   ) : Join process failed [sambaJoinScriptFailed]: 26univention-samba.inst failed

Oha, kein Permission denied. mehr, also war wirklich ein Konto mit dem Namen “Administrator” notwendig.

  1. Fehler also gefunden.

2.
Failed to join domain: Invalid configuration (“workgroup” set to ‘local’, should be ‘LOCAL1’) and configuration modification was not requested

Eine schnelle Google Suche brachte mich zu einem Univention Bug Eintrag von 2015 -> https://forge.univention.org/bugzilla/show_bug.cgi?id=37460#c3

Das sollte eigentlich gefixt sein, aber man kann es ja mal versuchen.
Wieder den UCS DC per Snapshot zurückgesetzt.
Und siehe da, es hat geklappt!
Der UCS konnte unserem AD erfolgreich joinen und synct jetzt alle Einträge ordnungsgemäß.


Ucs <-> ad sync Authentication failed
UCS Member - App Installation -> Insufficient access (50)