Probleme beim Domänenbeitritt eines Mint-Systems

Hallo,

ich bin gerade dabei, das aktuelle UCS 4.0 zu evaluieren. Dabei hatte ich Probleme, ein frisch aufgesetztes Linux Mint 17.1 System in die Domäne zu integrieren. Vorgangen bin nach der Beschreibung auf docs.univention.de/domain-4.0.html.

Nach Abschluss der Konfiguration gemäß Kapitel 1.2. Configuration of the System Security Services Daemon (SSSD) zeigte der Client mit getent passwd und getent group keine Domänendaten an.

Nach etlichen Versuchen mittels trial and error habe ich es dann doch geschafft, den client anzubinden.

Falls also jemand hier im Forum das gleiche Problem haben sollte, hier ist meine Lösung:

Der Anleitung bis zum Kapitel 1.2 folgen, dann die Codesektion von Kapitel 1.2 durch wie folgt ersetzen:

[code]1.2. Configuration of the System Security Services Daemon (SSSD)
SSSD provides a set of daemons to manage access to remote directories and authentication mechanisms.

Become root

sudo bash

Set some environment variables

. /etc/univention/ucr_master

Install SSSD based configuration

DEBIAN_FRONTEND=noninteractive apt-get -y install sssd
libpam-sss libnss-sss sssd-tools

Create sssd.conf

cat >/etc/sssd/sssd.conf <<EOF
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, sudo
domains = $kerberos_realm

[nss]
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/$kerberos_realm]
auth_provider = krb5
krb5_kdcip = ${master_ip}
krb5_realm = ${kerberos_realm}
krb5_server = ${ldap_master}
krb5_kpasswd = ${ldap_master}
id_provider = ldap
access_provider = simple
chpass_provider = krb5
ldap_uri = ldap://${ldap_master}:7389
ldap_search_base = ${ldap_base}
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/univention/ssl/ucsCA/CAcert.pem
cache_credentials = false
enumerate = true
dns_discovery_domain = ${kerberos_realm}
ldap_default_bind_dn = cn=$(hostname),cn=computers,${ldap_base}
ldap_default_authtok_type = password
ldap_default_authtok = $(cat /etc/ldap.secret)
ldap_id_use_start_tls = true
EOF
chmod 600 /etc/sssd/sssd.conf

Install auth-client-config

DEBIAN_FRONTEND=noninteractive apt-get -y install auth-client-config

Create an auth config profile for sssd

cat >/etc/auth-client-config/profile.d/sss <<EOF
[sss]
nss_passwd= passwd: compat sss
nss_group= group: compat sss
nss_shadow= shadow: compat
nss_netgroup= netgroup: nis

pam_auth=
auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth [success=1 default=ignore] pam_sss.so use_first_pass
auth requisite pam_deny.so
auth required pam_permit.so

pam_account=
account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

pam_password=
password sufficient pam_unix.so obscure sha512
password sufficient pam_sss.so use_authtok
password required pam_deny.so

pam_session=
session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_sss.so
session required pam_unix.so
EOF
auth-client-config -n -a -p sss

Start sssd

start sssd

Exit sudo bash

exit
[/code]

Nun funktioniert getent passwd, getent group und man kann mit Kapitel 1.3 fortfahren.
Vielleicht hilft es ja dem einen oder anderen, der vor dem selben Problem steht.

Grüße

Rupi

Hallo,

vielen Dank! Ich habe diese Anregung aufgenommen (Bug #37636).

Mit freundlichen Grüße,
Tim Petersen

Update des Procederes für Linux Mint 18.2

Hallo, habe eben meine frisch installierten Linux-Mint 18.2 Clients in die UCS-Domain aufgenommen.
Da Mint 18.2 auf Ubuntu 16.04 LTS aufbaut, hat sich gegenüber dem obenstehenden Vorgehens unter 17.2. auch wieder etwas geändert…

Ausgangsbasis ist ein frisch installiertes Mint 18.2 Cinnamon.
Vor Beginn sollte sicher gestellt sein, dass der Client eine gültige IP-Adresse für das Lan hat und dass der DNS-Server auf den UCS-Domain Master zeigt.

Nun die Beschreibung unter https://docs.software-univention.de/domain-4.1.html öffnen und den Absatz
1.1. Integration into the LDAP directory and the SSL certificate authority abarbeiten.

Anschließend wird SSSD wie folgt installiert:

1.2. Configuration of the System Security Services Daemon (SSSD)

# Become root
sudo bash <<"EOF"

. /etc/univention/ucr_master

# SSSD package is unable to create user sssd upon installation so we are doing this in advance
adduser --system --group --home /var/lib/sss sssd
mkdir /etc/sssd
mkdir /etc/auth-client-config
mkdir /etc/auth-client-config/profile.d

# Create sssd.conf
cat >/etc/sssd/sssd.conf <<__EOF__
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam, sudo
domains = $kerberos_realm

[nss]
reconnection_retries = 3

[pam]
reconnection_retries = 3

[domain/$kerberos_realm]
auth_provider = krb5
krb5_kdcip = ${master_ip}
krb5_realm = ${kerberos_realm}
krb5_server = ${ldap_master}
krb5_kpasswd = ${ldap_master}
id_provider = ldap
ldap_uri = ldap://${ldap_master}:7389
ldap_search_base = ${ldap_base}
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/univention/ssl/ucsCA/CAcert.pem
cache_credentials = true
enumerate = true
ldap_default_bind_dn = cn=$(hostname),cn=computers,${ldap_base}
ldap_default_authtok_type = password
ldap_default_authtok = $(cat /etc/ldap.secret)
__EOF__

chmod 600 /etc/sssd/sssd.conf

# Create an auth config profile for sssd
cat >/etc/auth-client-config/profile.d/sss <<__EOF__
[sss]
nss_passwd=   passwd:   compat sss
nss_group=    group:    compat sss
nss_shadow=   shadow:   compat
nss_netgroup= netgroup: nis

pam_auth=
        auth [success=3 default=ignore] pam_unix.so nullok_secure try_first_pass
        auth requisite pam_succeed_if.so uid >= 500 quiet
        auth [success=1 default=ignore] pam_sss.so use_first_pass
        auth requisite pam_deny.so
        auth required pam_permit.so

pam_account=
        account required pam_unix.so
        account sufficient pam_localuser.so
        account sufficient pam_succeed_if.so uid < 500 quiet
        account [default=bad success=ok user_unknown=ignore] pam_sss.so
        account required pam_permit.so

pam_password=
        password requisite pam_pwquality.so retry=3
        password sufficient pam_unix.so obscure sha512
        password sufficient pam_sss.so use_authtok
        password required pam_deny.so

pam_session=
        session required pam_mkhomedir.so skel=/etc/skel/ umask=0077
        session optional pam_keyinit.so revoke
        session required pam_limits.so
        session [success=1 default=ignore] pam_sss.so
        session required pam_unix.so
__EOF__


# Install SSSD based configuration
DEBIAN_FRONTEND=noninteractive apt-get -y install sssd libnss-sss libnss-winbind libpam-sss libpam-winbind libsss-sudo sssd-tools

# Install auth-client-config
DEBIAN_FRONTEND=noninteractive apt-get -y install auth-client-config

auth-client-config -a -p sss

# Restart sssd
service sssd restart

EOF

Nun zeigen getent passwd und getent group die Domänendaten an.

Da Mint 18.2 nicht mehr MDM sondern lightdm nutzt, können wir jetzt die Abschnitte:
1.3. Configuring user logins und 1.4. Kerberos integration aus der
aus https://docs.software-univention.de/domain-4.1.html ausführen.

Wenn man in der Datei /etc/lightdm/lightdm.conf.d/99-show-manual-userlogin.conf die Zeile
greeter-hide-users=true durch greeter-hide-users=false
ersetzt, werden die Benutzer, die bereits einmal auf dem Client eingeloogt waren in der Benutzerliste der Anmeldung angezeigt.

Bei der ersten Anmeldung eines Domainusers auf dem Client muss also der Punkt Anmelden benutzt werden.
Dort dann den Namen eines Domänenbenutzers angeben wie er unter getent passwd angezeigt wird (also ohne mydoman/username oder username@mydomain, sondern wirklich nur der username in der Domäne)

Beim nächsten Anmelden wird dieser Domainuser dann schon in der Benutzerliste zur Auswahl angezeigt.

Wie man unter lightdm gezielt user in der Listenauswahl inkludiert oder exkludiert habe ich allerdings noch nicht herausgefunden.

Beste Grüße

Rupi, der jetzt FipsKnips heißt

1 Like

Moin,

gute Arbeit, nice.

Ich bin zwar kein regelmäßiger lightdm-User, aber das, was ich dazu gefunden habe, ist: es gibt die Konfigurationsdatei /etc/lightdm/users.conf. Hier steht z.B.:

[UserList]
minimum-uid=1000
hidden-users=nobody nobody4 noaccess
hidden-shells=/bin/false /usr/bin/nologin

Damit sollten Benutzer doch einfach auszuschließen sein. Durch minimum-uid und hidden-shells werden Systemaccounts einfach und effektiv ausgeschlossen, und mit hidden-users betreibt man dann finetuning (z.B. adminnistrator ausschließen oder wen auch immer).

Gruß,
mosu

Ich konnte LinuxMint 18.3 Clients mit der Anleitung https://docs.software-univention.de/domain-4.2.html ohne Probleme umsetzen. In der Konfiguration wird SSSD auch der Service SUDO services = nss, pam, sudo mitgeteilt.
Allerdings wir der Service nicht konfiguriert.

Ich möchte gerne als Mitglied der Gruppe Domain Admin auf den Rechnern SUDO Rechte haben, um ggf. lokale Konfigurationen durchführen zu können.

Wie ich die Konfiguration von Netzwerkdruckern, auto-mount der Home-Shares usw. zentral erledige muss ich noch rausfinden.

Moin,

Naja, sobald die LDAP-Gruppen als lokale Gruppen verfügbar sind, kann man sie problemlos in der sudo-Konfiguration nutzen. Sprich das hier sollte funktionieren:

"%Domain Admins" ALL = (ALL) ALL

Dafür gibt’s keine vorgefertigten Bausteine, das wirst du alles selber basteln müssen.

Gruß
mosu

Das habe ich jetzt manuell auf jedem Client so gemacht und funktioniert auch, aber das ist nicht das Konzept das SSSD für SUDO-Konfiguration vorsieht. Es gibt ein sudoer LDAP Schema, aus dem SSSD dies auslesen kann.

Das Paket univention-sudo-ldap setzt etwas vergleichbares für UCS-Server um, scheint aber vom Schema nicht kompatibel mit sssd-sudo.(https://linux.die.net/man/5/sssd-sudo) zu sein.

Ah, das kannte ich noch nicht. sudo selber bietet übrigens auch eigenen LDAP-Support mit eigenem Schema und so, siehe man page zu sudoers.ldap. Vielleicht nutzt univention-sudo-ldap genau das? Kann gerade nicht nachschauen, weil es trotz aktiviertem unmaintained-Repository nicht als installierbares Paket gefunden werden kann.

Ah, right, das Cool-Solutions-Repo muss aktiv sein. Dann kann ich’s auch installieren.

Jap, univention-sudo-ldap beinhaltet das Schema, das sudos eigene LDAP-Unterstützung auch nutzt. Wenn Sie also zentralisiertes Management von sudo-Regeln wünschen, dann empfehle ich, den Weg zu versuchen, und nicht den von sssd zu wählen. Man müsste dann Nicht-UCS-Systeme relativ einfach entsprechend konfigurieren können.

Ok, ich habe mir das Univention LDAP jetzt nochmal mit einem externen LDAP Browser angeschaut.
Es wird das benötigte Schema für sudoers.ldap erzeugt, welches auch von SSSD verwendet wird.
Zwar können über die UCS Web Console nicht alle Attribute gesetzt werden aber das reicht erst mal.
Ich melde mich dann mit dem Ergebnis.

Das hat funktioniert :slight_smile:
Ich musste nur eine Zeile im Schritt 1.2 der Extended Domain Services Documentation nach ldap_search_base = ${ldap_base} einfügen:

ldap_sudo_search_base = cn=sudo-ldap,cn=univention,${ldap_base}

Und eine SUDO Regel im LDAP anlegen. Zum Beispiel allen Mitgliedern der Gruppe “Domain Admins” alle Befehle per sudo auf allen Hosts zu erlauben:
Screenshot from 2018-01-30 09-28-45

Ich würde mich freuen, wenn das als ergänzender Hinweis in die Doku mit aufgenommen würde.

Fein! Solche Wünsche, gerade zur Dokumentation, können an feedback@univention.de geschickt werden.

1 Like

Hallo @jolentes,
Hallo @Moritz_Bunkus,

vielen Dank für die Anregung. Ich habe hierfür https://forge.univention.org/bugzilla/show_bug.cgi?id=46229 angelegt.

Gruß, Nico.

1 Like

Und mir ist noch aufgefallen, das die Beschreibung in der Doku zwar den TLS einsatz vorbereitet, sich dann aber nicht über LDAPS (Port 7636), sondern über LDAP (Port 7389) verbindet.

ldap_uri = ldap://${ldap_master}:7389
ldap_search_base = ${ldap_base}
ldap_tls_reqcert = never
ldap_tls_cacert = /etc/univention/ssl/ucsCA/CAcert.pem

Ich würde empfehlen hier dann auch die Verbindung über LDAPS aufzubauen.

ldap_uri = ldaps://${ldap_master}:7636

Huhu,

naja, auf dem Standardport wird dann halt direkt nach dem Verbindungsaufbau mit STARTTLS auf Verschlüsselung umgeschaltet. Nicht wirklich viel unsicherer. Das einzige, was man sich als Angriff vorstellen könnte, ist ein Man In The MIddle, der auf genau die STARTTLS-Anfrage des Clients mit “nein danke/nicht unterstützt” reagiert. Wenn der Client dann unverschlüsselt weitermacht, dann wäre das doof. Da weiß ich aber nicht, wie der sssd funktioniert — viele Clients verweigern die weitere Kommunikation, wenn STARTTLS angefragt wurde aber nicht funktioniert.

Gruß
mosu

Mastodon