☰

SSSD: So zwingen Sie Benutzer in verschiedenen Gruppen, unterschiedliche Shells zu verwenden

tag-icon • tag-icon active-directory sssd
SSSD: So zwingen Sie Benutzer in verschiedenen Gruppen, unterschiedliche Shells zu verwenden

Ich habe ein Active Directory, das als ID-, Zugriffs- und Authentifizierungsanbieter für meine CentOS 7-Server mit SSD arbeitet. Ich habe dies verfolgtPostum Benutzer aus verschiedenen Gruppen beim Anmelden unterschiedliche Shells verwenden zu lassen, aber ich habe einige Probleme. Hier ist meine sssd.confDatei:

[sssd]
domains = dev, domain.local
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/dev]
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
ad_server = adserver.domain.local
id_provider = ad
access_provider = ad
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
override_shell = /bin/tcsh
ldap_user_search_base = cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local #According to sssd-ldap man page ldap_user_search_filter is deprecated


[domain/domain.local]
ad_server = adserver.domain.local
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad


Die Idee ist, dass wenn sich jemand aus der Entwicklergruppe anmeldet, die Shell tcsh ist und wenn sich jemand anderes anmeldet, wird bash verwendet. Das Problem ist, dass ich mich mit dieser Konfiguration erfolgreich mit Smith, einem Mitglied der Entwicklergruppe, anmelden kann und tcsh erfolgreich erreicht wird. Wenn ich mich jedoch mit John anmelde, der ebenfalls Mitglied der Domäne, aber kein Mitglied der Entwicklergruppe ist, passiert Folgendes:

  • Beim Überprüfen /var/log/secureerhalte ich zuerst eine Authentifizierungsfehlermeldung von pam_unix und dann eine Erfolgsmeldung von pam_sss
  • Zuerst meldet sich der Benutzer als an johnund erhält die Shell tcsh (obwohl es bash sein sollte). Zweitens meldet sich der Benutzer als an [email protected]und erhält bash. Drittens meldet sich der Benutzer erneut als an johnund erhält jetzt die richtige Shell (bash).

Offenbar speichert sssd nach der Überprüfung der zweiten Domäne mit dem FQDN die Benutzer-Shell im Cache und macht es bei der dritten Anmeldung richtig.
Welches ist die richtige Konfiguration, um jeden Benutzer bei seiner entsprechenden Shell anzumelden?

AKTUALISIEREN:
Es sieht so aus, als ob der Anmeldevorgang manchmal nur über PAM-Module und manchmal über SSDD-GPO-basierte Richtlinien aus dem Active Directory läuft. Ich habe mehrmals versucht, den Filter zu deaktivieren und SSDD neu zu starten, und bei einem dieser Versuche stand Folgendes im Protokoll:

Aug 28 15:42:43 co-proy-02 sssd[be[dev.domain.local]]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode.

Bei deaktiviertem Filter erhalten Benutzer Smithaus devGruppen erfolgreich tcsh, aber auch john. Bei aktiviertem Filter erhalten beide bash.

UPDATE2
Anscheinend gibt es ein Paket namens sssd-tools, das einen Befehl enthält, mit dem Sie die Shell eines beliebigen Benutzers überschreiben können. Nach dem Ausprobieren dieser Lösung erhalte ich jedoch immer noch kein geeignetes Ergebnis. Hier ist der Befehl, aber zumindest bei mir funktioniert er nicht so, wie er sollte:
sss_override user-add smith -s /usr/bin/sh

Antwort1

Nach langer Suche und mit Hilfe von @ChristopheDrevet-Droguet mit dem Filter ou=Domain,dc=domain,dc=local?subtree?(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=domain,dc=local)als Grundlage fehlte nur noch ein Baum von Objekten zum Parsen, also, in denen der Benutzer gefunden werden konnte.
Damit dies funktioniert (zumindest bei mir), sollte die SSD wie folgt aussehen:

[sssd]
domains = dev, domain.local
config_file_version = 2
services = nss, pam

[nss]
default_shell = /bin/bash

[domain/dev]
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
ad_server = adserver.domain.local
id_provider = ad
access_provider = ad
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
override_shell = /bin/tcsh
ldap_user_search_base = dc=domain,dc=local??(&(memberOf=cn=dev,ou=Security Groups,ou=Domain,dc=veritran,dc=local)(objectClass=*))


[domain/domain.local]
ad_server = adserver.domain.local
ad_domain = domain.local
krb5_realm = DOMAIN.LOCAL
realmd_tags = manages-system joined-with-adcli
cache_credentials = True
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u
access_provider = ad
ldap_user_search_base = dc=domain,dc=local??(&(memberOf=cn=other,ou=Security Groups,ou=Domain,dc=veritran,dc=local)(objectClass=*))

verwandte Informationen