Debian-Fremdsysteme und UCS 3.0

Hallo miteinander,

ich suche nach genaueren Informationen zum Zusammenspiel von Debian-basierten Desktops (im konkreten Ubuntu 10.04 LTS) und dem UCS 3.0.

Hintergrund: Wir möchten unser altes, simples aber leider chronisch unsicheres NIS+NFS System endlich ausmisten und als Ersatz kommt na klar LDAP+Kerberos+NFS in Frage. Da wir gerne ein fertig integriertes System auf Debian-Basis mit gutem Support hätten, testen wir eben gerade den UCS 3.0 aus (auch mit Hinblick auf die noch ausstehende Zentralisierung der übrigen verwaisten Windows und Mac Workstations). Der UCS wird dabei momentan eher “small scale” gefahren, heißt es läuft nur ein DC Master in einer mit Libvirt verwalteten KVM VM und auch das Netzwerkmanagement soll dieser nicht übernehmen. Die Replikations- und Join-Thematik fällt demnach ebenfalls erstmal unter den Tisch, viel mehr geht es uns erst mal um die funktionierende Anbindung von Desktop-Clients an den UCS.

Soweit so gut, die Installation des UCS steht soweit und zur Anbindung der Clients an LDAP findet sich ja: sdb.univention.de/1095 Allerdings würde ich hierzu gerne erfahren inwieweit die dortigen Informationen noch für den UCS 3.0 gültig sind. Beispielsweise wird nach der Einrichtung von “/etc/ldap.conf” und “/etc/nsswitch.conf” angegeben, dass beispielsweise mittels “getent passwd” sofort die Benutzerdaten aus dem LDAP abgefragt werden können. AFAIK kann das aber doch nur scheitern, da noch keine Credentials und ähnliches ausgetauscht wurden, die dem Client einen solchen Zugriff überhaupt erlauben würden.

Vielen Dank im voraus! :slight_smile:

Hallo,

der SDB-Artikel Einrichtung von Fremdsystemen auf Basis von Debian und Ubuntu zur Anbindung an LDAP und Kerberos wurde für UCS 2.x geschrieben, daher fehlen derzeit noch Hinweise zur Einrichtung der Systeme gegen einen LDAP-Server der keinen anonymous bind zulässt (UCS 3.0 Standard).
Generell reicht es vermutlich aus die libnss-ldap und pam-ldap Konfiguration so zu erweitern, dass der bind über einen Host-Account (dieser müsste für die Systeme vorab, z.B. als Managed Client, im UDM hinterlegt werden) durchgeführt wird, z.B. (libnss-ldap.conf):

[code]uri ldap://:7389 ldap://:7389
rootbinddn cn=,cn=computers,

base
ldap_version 3
scope sub
ssl start_tls
tls_checkpeer no
nss_initgroups_ignoreusers roo[/code]Das Passwort des Host-Accounts müsste dann entsprechend in einer Datei, "libnss-ldap.secret ", abgelegt werden.

Alternativ kann der anonymous bind für einzelne oder alle Systeme erlaubt werden, Hinweise dazu finden Sie z.B. im Wiki-Artikel [wiki]UCS 3.0 LDAP[/wiki].

Mit freundlichen Grüßen
Janis Meybohm

Vielen Dank für die Aufklärung.

Nachdem ich nun den Client als “Managed Client” in UMC (ucs-testclient-1004) samt Rechnername, IP und Passwort hinterlegt habe, stoße ich aber dennoch auf Probleme mit der Abfrage des ebenfalls erstellten Testbenutzers (ldaptest). So führen zwar die ersten unter [wiki]UCS_3.0_LDAP[/wiki] beschriebenen Abfragebefehle auf dem UCS unter root zum Erfolg:

ldapsearch -x -H ldapi:/// uid=ldaptest
univention-ldapsearch uid=ldaptest

Der “manuelle” Test mit ldapsearch schlägt aber selbst auf dem UCS als root fehl:

ldapsearch -x -D cn=ucs-testclient-1004,cn=computers,dc=DOMAIN,dc=local -w ucs-testclient-1004.secret uid=ldaptest ldap_bind: Invalid credentials (49)

Die Secrets-Datei (ucs-testclient-1004.secret) habe ich überprüft, sie liegt im momentanen Verzeichnis, hat ausreichende Leserechte, keinen Zeilenumbruch und enthält das natürlich nur das vergebene Passwort für den Client.

Gibt es hier noch bekannte und gern übersehene Stolpersteine? Bzw. wo finden sich weitere Informationen zum debuggen auf dem 3.0 Release, beispielsweise zu relevanten Logdateien auf dem UCS und zum Einsatz von ldapsearch als hauptsächlichem Testwerkzeug (um gar nicht erst mögliche Probleme mit libnss-ldap und pam-ldap auf dem Client ins Spiel zu bringen)?

Abermals besten Dank!

Hm das ändert zwar vermutlich nichts an deinem Problem, aber soweit ich Herrn Meybohm verstanden hab sollstest du den Host-Account für den Bind verwwenden.

Hallo,

der ldapsearch Parameter “-w” erwartet das Passwort auf der Kommandozeile, der Befehl müsste also entweder:

ldapsearch -x -D cn=ucs-testclient-1004,cn=computers,dc=DOMAIN,dc=local -y ucs-testclient-1004.secret uid=ldaptest

oder

ldapsearch -x -D cn=ucs-testclient-1004,cn=computers,dc=DOMAIN,dc=local -w$(cat ucs-testclient-1004.secret) uid=ldaptest

lauten.

Mit freundlichen Grüßen
Janis Meybohm

Oops, da haben Sie natürlich Recht, prompt funktioniert die Abfrage auf dem UCS :slight_smile:

Auch das übertragen des Befehl auf den Client funktioniert nachdem ich alle von “ldapsearch” automatisch angenommen Parameter ergänzt habe, Knackpunkte waren die “searchbase” und der “extravagante” Port 7389:

ldapsearch -x -D cn=ucs-testclient-1004,cn=computers,dc=DOMAIN,dc=local -b dc=DOMAIN,dc=local -h ucs.DOMAIN.local -p 7389 -y ucs-testclient-1004.secret uid=ldaptest

Bei etwaigen Aktualisierung des SDB-Artikels könnte man den OpenLDAP Port besonders hervorheben, hat doch Windows mittels Samba hier mal wieder den Vorzug erhalten :wink:

Vielen Dank für die Hilfe, nun kann es weiter gehen. Sollte ich noch auf Probleme oder Stolpersteine stoßen werde ich sie hier wieder kundtun.

Hallo,

die Basis-Einstellungen für LDAP-Abfragen (per ldapsearch etc.) sollten Sie auf den meisten Systemen über eine ldap.conf (z.B. unter /etc/ldap.conf oder /etc/ldap/ldap.conf) vorgeben können, z.B.:

TLS_CACERT <Path to UCS CAcert.pem>
HOST <UCS FQDN>
BASE dc=DOMAIN,dc=local
PORT 7389

Mit freundlichen Grüßen
Janis Meybohm

Den Beitrag zu NFSv4 habe ich in ein neues Thema übernommen.

Mit freundlichen Grüßen
Janis Meybohm

Weitere, evt. hilfreiche Informationen gibt es mitlerweile auch unter dem Wiki-Artikel Inclusion of CentOS.

Eine weitere Beschreibung:
[wiki]Inclusion of Ubuntu[/wiki]

Viele Grüße
Stefan Gohmann

Mastodon