Join schlägt fehl

[MasinAD]

Hi!

Ich habe in einer KVM-virtualisierten Machine UCS 4.2.3 aufgesetzt, damit es den gleichen Versionsstand hat wie unser Master. UCS sollte als Memberserver der Domäne beitretet, der NIC ist als NAT konfiguriert, Master und Member befinden sich also nicht in demselben Subnetz. Beim Versuch, den Master zu finden, muss ich dementsprechend dessen IP-Adresse als DNS-Server angeben.

Leider bricht der Join ab. In der /var/log/univention/join.log steht nur etwas davon, dass IDP-Metadaten nicht heruntergeladen werden könnten:

Could not download IDP metadata for https://ucs-sso.wikimedia.de/simplesamlphp/saml2/idp/metadata.php
'NoneType' object has no attribute 'find'
Unsetting umc/saml/idp-server
Module: setup_saml_sp
EXITCODE=3

Anschließende Versuche zum Domainjoin werden immer quittiert mit

**************************************************************************
* Join failed!                                                           *
* Contact your system administrator                                      *
**************************************************************************
* Message:  binddn for user Administrator not found. 
**************************************************************************

Irgendwelche Vorschläge?

Beste Grüße aus Berlin-Kreuzberg
Masin Al-Dujaili

[ahrnke]

Hallo,
ich versuchs mal…

Beim Versuch, den Master zu finden, muss ich dementsprechend dessen IP-Adresse als DNS-Server angeben.

Das sind schon mal nicht die besten Voraussetzungen. Jedenfalls, wenn ich diesen Satz so verstehe, dass Sie -dcname mit der IP-Adresse angegeben haben. Man sollte eher den DNS in der Konfiguration mit der Variablen nameserver1 (usw.) konfigurieren.

Could not download IDP metadata for https://ucs-sso.wikimedia.de/simplesamlphp/saml2/idp/metadata.php

Haben Sie mal versucht, diese URL z.B. mit curl aufzurufen?

* Message: binddn for user Administrator not found.

univention-join hat an dieser Stelle einen DC gefunden, aber entweder dort kein ssh-Login geschafft oder wirklich mit ldapsearch den Nutzer nicht gefunden. Letzteres ist aber eher weniger wahrscheinlich.

Sicherheitshalber verweise ich mal noch auf Auf welche TCP/UDP-Ports des UCS Masters müssen andere UCS-System zugreifen können?

hth,
Dirk Ahrnke

[MasinAD]

Hallo Dirk Ahrnke!

Danke, dass Sie sich die Zeit genommen haben für eine Antwort.

Das sind schon mal nicht die besten Voraussetzungen. Jedenfalls, wenn ich diesen Satz so verstehe, dass Sie -dcname mit der IP-Adresse angegeben haben. Man sollte eher den DNS in der Konfiguration mit der Variablen nameserver1 (usw.) konfigurieren.

Ich habe in der VM einfach das UCS-Install-ISO eingebunden und durchlaufen lassen. Wenn ich die Rolle Memberserver auswähle, beschwert sich der Installer in Folge, dass kein DC Master gefunden werden könne, man möge dessen IP doch als DNS-Server eintragen. Und so habe ich das getan.

Wenn es eine Möglichkeit gibt, erstmal nur einen blanken UCS aufzusetzen, ohne mich während der Installation für eine Rolle entscheiden zu müssen, um das danach machen zu können, hätte ich vielleicht mehr Möglichkeiten, auf den Join Einfluss zu nehmen.

Haben Sie mal versucht, diese URL z.B. mit curl aufzurufen?

Nein, hatte ich nicht. Aber es funktioniert, wie ein schneller Test zeigt.

univention-join hat an dieser Stelle einen DC gefunden, aber entweder dort kein ssh-Login geschafft oder wirklich mit ldapsearch den Nutzer nicht gefunden. Letzteres ist aber eher weniger wahrscheinlich.

univention-ldapsearch findet den Administrator-Eintrag. Login mit ssh und univention-ssh funktioniert.

Sicherheitshalber verweise ich mal noch auf Auf welche TCP/UDP-Ports des UCS Masters müssen andere UCS-System zugreifen können?

Weder 37 Timeserver noch 123 NTP sind auf dem DC Master offen. Rsync lauscht auch nicht, zumindest ist nichts auf 873. Zu den dynamischen RPC-Ports kann ich wegen der Dynamik nichts sagen. Ich habe an der Standardkonfiguration von UCS 4.1, was wir damals installiert und dann bis auf 4.2.3 aktualisiert haben, nichts geändert. Sollten diese Ports wichtig sein für einen Domainjoin, wäre die Standardkonfiguration jedenfalls für einen Join unpassend. Deswegen gehe ich erstmal nicht davon aus.

BG aus B-Kreuzberg
Masin Al-Dujaili

[ahrnke]

Hallo

Wenn es eine Möglichkeit gibt, erstmal nur einen blanken UCS aufzusetzen, ohne mich während der Installation für eine Rolle entscheiden zu müssen, um das danach machen zu können, hätte ich vielleicht mehr Möglichkeiten, auf den Join Einfluss zu nehmen.

Eine Rolle muß angegeben werden, aber den Join kann man bei der Installation auslassen.
Die Kommandozeilenoptionen für univention-join stehen in https://docs.software-univention.de/handbuch-4.3.html#domain-ldap:Nachtraeglicher_Domaenenbeitritt_mit_univention-join, es gibt auch eine Option, die die Geschwätzigkeit des Logs erhöht.

Zu dem von mir verlinkten Artikel kann ich nur sagen, dass dies eine offizielle aus der Supportdatenbank von Univention übernommene Dokumentation ist. https://forge.univention.org/bugzilla/show_bug.cgi?id=42948 schlägt Verbesserungen vor. Wegen dem NTP sollten Sie noch mal schauen, das ist UDP. Da gejointe UCS immer die Domaincontroller als Timeserver verwenden (und wegen Kerberos auch darauf angewiesen sind), ist der Standard so definiert:

security/packetfilter/package/univention-base-files/udp/123/all/en: ntp
security/packetfilter/package/univention-base-files/udp/123/all: ACCEPT

Viele Grüße,
Dirk Ahrnke

[MasinAD]

Hallo,

wenn ich auf UDP scanne, dann zeigt sich Port 123 tatsächlich offen. Ich mache gerade mal eine Neuinstallation und schaue genauer auf die ersten Fehlermeldungen. Beim ersten Durchlauf hatte ich nicht so darauf geachtet, weil ich annahm, dass mir der Fehler ja schon nochmal angezeigt werde.

…

Jetzt kriege ich angezeigt, wenn ich keinen Domänenbeitritt zum Ende der Installation möchte. Gehe ich zurück und setze den Haken, dann taucht die Fehlermeldung nicht auf. *seufz* Also erstmal wieder mit Domänenbeitritt und schauen.

BG aus B-Kreuzberg
Masin Al-Dujaili

[ahrnke]

Das 4.2.3-ISO hatte da ein Problem, siehe https://forge.univention.org/bugzilla/show_bug.cgi?id=45838

Wenn Sie 4.2 benötigen, nehmen Sie besser das 4.2.2-oder 4.2.4-Image.
Alle Images liegen auf http://updates.software-univention.de/download/ucs-cds/

[MasinAD]

Danke, @ahrnke

Das 4.2.3-ISO hatte da ein Problem, siehe https://forge.univention.org/bugzilla/show_bug.cgi?id=45838

Wenn Sie 4.2 benötigen, nehmen Sie besser das 4.2.2-oder 4.2.4-Image.

Das hat ein wenig geholfen.

Ich konnte die Installation jetzt ohne Join durchführen – so weit, so gut. Das Auffinden des binddn scheitert, weil univention-ssh /tmp/tmp.b88qcepOCl/dcpwd Administrator@kappa.wikimedia.de /usr/sbin/udm users/user list --filter uid=Administrator --logfile /dev/null scheitert. Führe ich den Befehl mit udm und so weiter direkt als Administrator auf dem DC Master aus, erhalte ich

E: Permission denied, try --logfile, --binddn and --bindpwd

Führe ich /usr/sbin/udm --logfile ~/udm.log --binddn uid=Administrator,cn=users,dc=wikimedia,dc=de --password=<passwort> aus, gibt es

authentication error: [Errno 13] Permission denied: '/etc/ldap.secret'
authentication error: [Errno 13] Permission denied: '/etc/machine.secret'

Zur Dokumentation:

Administrator@kappa:~$ ll /etc/*.secret
-rw-r----- 1 root       Backup Join     20 Mai  2  2017 /etc/backup-join.secret
-rw-r----- 1 root       DC Backup Hosts 20 Mai  2  2017 /etc/idp-ldap-user.secret
-rw-r----- 1 root       DC Backup Hosts 20 Mai  2  2017 /etc/ldap-backup.secret
-rw-r----- 1 root       Backup Join     20 Mai  2  2017 /etc/ldap.secret
lrwxrwxrwx 1 root       root            19 Mai  2  2017 /etc/libnss-ldap.secret -> /etc/machine.secret
-r--r----- 1 listfilter root            21 Aug  5 01:09 /etc/listfilter.secret
-rw------- 1 root       root            20 Aug  5 01:09 /etc/machine.secret
-rw------- 1 root       root            64 Jan  9  2018 /etc/mysql-openproject.secret
-rw------- 1 root       root             9 Jan  9  2018 /etc/mysql.secret
lrwxrwxrwx 1 root       root            19 Mai  2  2017 /etc/pam_ldap.secret -> /etc/machine.secret
-rw------- 1 root       root            64 Mär 16 14:30 /etc/postgresql-nextcloud.secret
-rw------- 1 pykota     root            20 Aug  5 01:10 /etc/pykota.secret
-rw------- 1 root       root            21 Mai  2  2017 /etc/self-service-db.secret
-rw-r----- 1 root       Slave Join      20 Mai  2  2017 /etc/slave-join.secret

Es sieht für mich so aus, als gehörte der Administrator nicht den richtigen Gruppen an. Dann wiederum sind die Rechte für /etc/machine.secret so gesetzt, dass eh nur root darauf Zugriff haben könnte, was eher darauf hinweist, dass die *.secrets falsche Berechtigungen haben.

Was wären denn die richtigen Gruppenzugehörigkeiten für den Administrator und Berechtigungen für die Secrets? Momentan ist Administrator Mitglied folgender Gruppen:

Domain Admins
Windows Hosts
Domain Users
DC Backup Hosts
DC Slave Hosts
Computers
Authenticated Users
Enterprise Domain Controllers
Schema Admins
Enterprise Admins
Group Policy Creator Owners
Denied RODC Password Replication Group
Administrators
Users

BG aus B-Kreuzberg
Masin

[ahrnke]

Nach meiner Erfahrung ist “DC Backup Hosts” die für das Joinen relevante Gruppe. Ich habe mir schon vor einiger Zeit versucht, abzugewöhnen, permanent mit dem “Administrator” zu arbeiten. Mein Admin-Konto habe ich zunächst nur in die “Domain Admins” aufgenommen, der Join funktionierte aber erst mit der zusätzlichen “DC Backup Hosts”-Gruppe.
Und genau sehe ich bei allen Maschinen mit denen ich verglichen habe, dass /etc/ldap.secret für “DC Backup Hosts” und nicht für “Backup Join” lesbar ist.

Die Rechte auf /etc/machine.secret sind wohl richtig, was der Verweis in der zitierten Fehlermeldung bedeutet kann ich nicht sagen.

[MasinAD]

Ich habe ldap.secret jetzt mal der Gruppe DC Backup Hosts übereignet – und schon geht das Joinen weiter und läuft durch. Sauber. Danke für die Unterstützung!

[damrose]

Hallo,

schön das der Join nun geklappt hat. Ein Hinweis zu dem udm Aufruf und dessen Fehlermeldung: Der Parameter --password ist in dem Fall nicht korrekt, es sollte --bindpwd oder --bindpwdfile verwendet werden, also udm user/user list --binddn=<DN> --bindpwd=<password>

[MasinAD]

Oh, danke für den Hinweis. Habe ich ganz übersehen … ohje, ohje, wer weiß, was ich mir damit hätte ersparen können …