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.
**************************************************************************
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.
Haben Sie mal versucht, diese URL z.B. mit curl aufzurufen?
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.
Danke, dass Sie sich die Zeit genommen haben für eine Antwort.
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.
Nein, hatte ich nicht. Aber es funktioniert, wie ein schneller Test zeigt.
univention-ldapsearch findet den Administrator-Eintrag. Login mit ssh und univention-ssh funktioniert.
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.
Eine Rolle muß angegeben werden, aber den Join kann man bei der Installation auslassen.
Die Kommandozeilenoptionen für univention-join stehen in Univention Corporate Server, 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. 42948 – Improve entry about TCP / UDP ports 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:
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.
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
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
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.
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!
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>
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.