Upgrade OpenLDAP-Server unter Opensuse auf Leap 42.2 – Fehler – OLC-Konfiguration für Datenbank Backends

Heute bin ich endlich eine Aufgabe angegangen, dass ich schon seit einem Jahr vor mir her schiebe: Ich habe einen LDAP-Server, der noch unter Opensuse 13.1 lief auf Opensuse Leap 42.2 umgestellt.

Die Umstellung habe ich schrittweise abgewickelt : OS 13.1 => OS 13.2 => Leap 42.1 => Leap 42.2. Beschreibungen eines generellen Upgrade-Vorgehensmodell auf Basis von “zypper” für Opensuse finden sich hier:

https://www.unixmen.com/upgrade-opensuse-13-2-opensuse-13-1/
https://www.unixmen.com/how-to-upgrade-to-opensuse-42-1-from-opensuse-13-2/
http://www.2daygeek.com/how-to-upgrade-from-opensuse-leap-42-1-to-opensuse-leap-42-2/2/

Die Paket-Updates liefen (bis auf bekannte Kleinigkeiten) eigentlich ganz gut ab; jede neue erzielte Opensuse-Version konnte erfolgreich gebootet werden. Auch praktisch alle Services liefen – mit Ausnahme eines bekannten Apache-Problems, das nach den Updates ein Eingreifen in bestimmte Konfigurationseinstellungen erfordert. Und eben auch bis auf den LDAP-Service; nach dem letzten Update musste ich schnell zur Kenntnis nehmen, dass es da ein gravierendes Problem gab.

Nach Upgrade zu Leap 42.2 war kein Login mehr auf anderen Servern möglich

Nach dem Übergang von Leap 42.1 zu Leap 42.2 konnte ich mich mit definierten UIDs (außer root) nicht mehr auf Server-Systemen in unserem LAN einloggen. Praktisch alle unsere Server beziehen Authentifizierungsinformationen eben vom zwischenzeitlich upgegradeten OpenLDAP-Server.

Die Authentifizierung läuft dabei über eine Kombination aus SSSD-Services und OpenLDAP (unter TLS). Zunächst dachte ich deshalb, dass ggf. der SSSD-Dämon auf dem OpenLDAP Server nicht laufen würde. Der erfreute sich aber selbst nach den drei Updates bester Gesundheit:

serv:~ # rcsssd status
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-06-01 15:21:30 CEST; 1h 9min ago
  Process: 1249 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 1294 (sssd)
    Tasks: 4 (limit: 512)
   CGroup: /system.slice/sssd.service
           ├─1294 /usr/sbin/sssd -D -f
           ├─1297 /usr/lib/sssd/sssd_be --domain default --uid 0 --gid 0 --debug-to-files
           ├─1298 /usr/lib/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
           └─1299 /usr/lib/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files

Jun 01 15:21:27 serv systemd[1]: Starting System Security Services Daemon...
Jun 01 15:21:29 serv sssd[1294]: Starting up
Jun 01 15:21:29 serv sssd[be[1297]: Starting up
Jun 01 15:21:29 serv sssd[1299]: Starting up
Jun 01 15:21:29 serv sssd[1298]: Starting up
Jun 01 15:21:30 serv systemd[1]: Started System Security Services Daemon.

Vom OpenLDAP-Service ließ sich das dagegen nicht behaupten; so zeigte ein Blick in das systemd Journal mittels
“journalctl -xe” :

Jun 01 15:48:17 serv systemd[1]: Starting OpenLDAP Server Daemon...
-- Subject: Unit slapd.service has begun start-up
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit slapd.service has begun starting up.
Jun 01 15:48:17 serv slapd[15835]: @(#) $OpenLDAP: slapd 2.4.44 $
                                          opensuse-buildservice@opensuse.org
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBCACHESIZE" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBCHECKPOINT" inserted.
Jun 01 15:48:17 serv slapd[15835]
: UNKNOWN attributeDescription "OLCDBCONFIG" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBIDLCACHESIZE" inserted.
Jun 01 15:48:17 serv slapd[15835]: UNKNOWN attributeDescription "OLCDBINDEX" inserted.
Jun 01 15:48:17 serv slapd[15835]: config error processing olcDatabase={1}hdb,cn=config:
Jun 01 15:48:17 serv slapd[15835]: DIGEST-MD5 common mech free
Jun 01 15:48:17 serv slapd[15835]: slapd stopped.
Jun 01 15:48:17 serv slapd[15835]: connections_destroy: nothing to destroy.
Jun 01 15:48:17 serv start[15835]: Starting ldap-server
Jun 01 15:48:17 serv systemd[1]: slapd.service: Control process exited, code=exited status=1
Jun 01 15:48:17 serv systemd[1]: Failed to start OpenLDAP Server Daemon.
-- Subject: Unit slapd.service has failed
-- Defined-By: systemd
-- Support: http://lists.freedesktop.org/mailman/listinfo/systemd-devel
-- 
-- Unit slapd.service has failed.
-- 
-- The result is failed.
Jun 01 15:48:17 serv systemd[1]: slapd.service: Unit entered failed state.
Jun 01 15:48:17 serv systemd[1]: slapd.service: Failed with result 'exit-code'.

Auch ein manueller Start von OpenLDAP mittels

serv:/etc/openldap/slapd.d # /usr/sbin/slapd -u ldap -h ldap://127.0.0.1:389/ -d 256

lieferte die gleichen Fehlermeldungen. Der Grund für die fehlgeschlagenen Logins lag also schlicht darin, dass ausgerechnet der OpenLDAP-Service, über den in unserem LAN User und Gruppen verwaltet werden, nach den Upgrades – genauer: nach dem letzten Upgrade – nicht mehr lief.

Eigenschaften der LDAP “Datenbank Backends” wurden offenbar nicht erkannt

Die Fehlermeldungen deuteten an, dass Eigenschaften des eingesetzten Datenbank-Backends (in meinem Fall hdb) dem System nicht bekannt waren. Daraus ergibt sich die Frage: Weiß die neue OpenLDAP-Installation unter Laep 42.2 überhaupt irgendetwas von ihren Backends?

Wenn man sich ein wenig mit LDAP beschäftigt hat, hat man sicher mitbekommen, dass die Datenbank-Backends in neueren OpenLDAP-Versionen (wie andere LDAP-Komponenten auch) über Module geladen und konfiguriert werden können. In früheren Versionen haben dagegen Build-Optionen bei der Erzeugung der LDAP-Programme dafür gesorgt, dass diverse Backends von Haus verfügbar waren. Einträge in der “slapd.conf” dienten dann der Auswahl der konkret heranzuziehenden Datenbank-Variante.

Man kann Backends aber eben auch dynamisch nachladen. Typischerweise sollte das in der Grundkonfiguration von OpenLDAP geschehen; was wenn das aber unter Leap 42.2 nicht der Fall ist?

Mit ein wenig Recherche im Internet findet man genügend Hinweise, wie man Datenbank-Backend-Module lädt und dass das tatsächlich in etlichen Installationen der Fall ist: Siehe etwa

http://vaab.blog.kal.fr/2010/03/06/how-to-add-a-schema-in-openldap-24/
(siehe dort den Abschnitt (“How to add a database?”)).

https://www.digitalocean.com/community/tutorials/how-to-configure-openldap-and-perform-administrative-ldap-tasks
http://nodedirector.bigsister.ch/refdoc/group__ref__cfg–director__slapd__conf.html
https://github.com/yast/yast-auth-server/blob/master/package/yast2-auth-server.changes
https://cat.pdx.edu/~nibz/openldap/openldap-server.html
und
http://www.openldap.org/doc/admin24/backends.html
http://www.openldap.org/doc/admin24/
slapdconf2.html

Im letzteren Artikel siehe insbesondere Absatz 5.2.2.

Die genannten Artikel deuten an, dass man die Direktive “olcModuleLoad” in der sogenannten OLC-Grundkonfiguration des LDAP-Servers einsetzen soll.

Dass in meiner aktuellen LDAP-Konfiguration tatsächlich Module geladen werden, zeigte folgender Befehl:

  
serv:/etc/openldap/slapd.d # grep -r ModuleLoad .
./cn=config/cn=module{0}.ldif:olcModuleLoad: {0}back_monitor.la

Leider handelt es sich hier aber nicht um ein Datenbank-Backend-Modul! Die nächste Frage war also: Welche Datenbank-Module werden denn überhaupt benutzt?

  
serv:/etc/openldap/slapd.d/cn=config # grep -r olcDatabase .
./olcDatabase={2}monitor.ldif:dn: olcDatabase={2}Monitor
./olcDatabase={2}monitor.ldif:objectClass: olcDatabaseConfig
./olcDatabase={2}monitor.ldif:olcDatabase: {2}Monitor
./olcDatabase={-1}frontend.ldif:dn: olcDatabase={-1}frontend
./olcDatabase={-1}frontend.ldif:objectClass: olcDatabaseConfig
./olcDatabase={-1}frontend.ldif:olcDatabase: {-1}frontend
./olcDatabase={-1}frontend.ldif:structuralObjectClass: olcDatabaseConfig
./olcDatabase={0}config.ldif:dn: olcDatabase={0}config
./olcDatabase={0}config.ldif:objectClass: olcDatabaseConfig
./olcDatabase={0}config.ldif:olcDatabase: {0}config
./olcDatabase={0}config.ldif:structuralObjectClass: olcDatabaseConfig
./olcDatabase={1}hdb.ldif:dn: olcDatabase={1}hdb
./olcDatabase={1}hdb.ldif:objectClass: olcDatabaseConfig
./olcDatabase={1}hdb.ldif:olcDatabase: {1}hdb

Aha, ich hatte die LDAP-Datenbanken bei der ursprünglichen Servereinrichtung unter OS 13.1 offenbar als “hdb”-Banken aufgesetzt. Es lag daher nahe, mal versuchsweise das entsprechende Backend-Modul zu laden.

Ergänzungen in slapd.conf sind nicht hinreichend, wenn zur Konfiguration OLC [cn=config] benutzt wird

Dummerweise bin ich bei den Recherchen dann aber auch über folgenden Ratschlag gestolpert:

https://forums.opensuse.org/showthread.php/522385-SlapD-will-nach-Update-von-42-1-nicht-mehr?p=2817944#post2817944

Dem bin ich dann naiverweise gefolgt – und habe zunächst lediglich die “slapd.conf” so ergänzt, dass alle Backends geladen werden:

# Load backend modules such as database engines
modulepath /usr/lib64/openldap
moduleload back_mdb.la
moduleload back_hdb.la
moduleload back_bdb.la

Das reichte in meinem Fall natürlich aber nicht ! Warum? Ich hatte die LDAP-Konfiguration beim Aufsetzen des LDAP-Servers unter Opensuse 13.1 mittels OLC, also über Einträge unter “cn=config“, vorgenommen! (Für weniger LDAP-Kundige: Die Konfigurationseinträge unter OLC sind ganz im Stil von LDAP-Datenbank-Records gehalten.)

Unter Opensuse wird die Verwendung der sog. Online-[OLC]-Konfiguration des OpenLDAP-Servers in der Datei “/etc/sysconfig/openldap” über die Option

OPENLDAP_CONFIG_BACKEND= “files|ldap”

festgelegt. In meinem Fall:

OPENLDAP_CONFIG_BACKEND=”ldap”

Das steuert dann den Aufruf des LDAP-Services und den Start des zugehörigen Programms. Letzteres wird dann die Konfigurationseinstellungen unter dem Verzeichnis “/etc/openldap/slapd.d/cn=config” auslesen und zur Anwendung bringen.

Die OLC-Konfiguration des OpenLDAP-Servers kann selbst über LDIF-Dateien oder LDAP-CLI-Kommandos (“ldapadd”, “ldapmodify”) angepasst werden. Damit werden dann die Einträge unter “cn=config” passend modifiziert.

Die notwendige initiale Datenbank-Konfiguration beim Starten des LDAP-Servers erfolgt unter dem Verzeichnis “cn=config” übrigens über folgende LDIF-Datei:

/etc/
openldap/slapd.d/cn=config/olcDatabase\=\{0\}config.ldif

Eine andere Stelle, die grundsätzlich auch für das Laden von Modulen mit Hilfe von “olcLoadModule”-Statements in Frage käme, wäre die grundlegende Konfigurationsdatei für Module:

/etc/openldap/slapd.d/cn=config/cn=module{0}.ldif

Sie hat in meinem Fall den Inhalt:

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 5b49ffc3
dn: cn=module{0}
objectClass: olcModuleList
cn: module
cn: module{0}
structuralObjectClass: olcModuleList
entryUUID: 49b0aac8-614a-1032-8c55-83b54eef05ad
creatorsName: cn=config
createTimestamp: 20130604100720Z
olcModuleLoad: {0}back_monitor.la
entryCSN: 20130604100720.232512Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130604100720Z

Ein möglicher Weg zur Ergänzung von Statements, mit denen man alle üblichen Datenbank-Module laden würde, sähe hierfür in etwa so aus:

serv:/etc/openldap/slapd.d # ldapadd -Y EXTERNAL -H ldapi:///
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib64/openldap
olcModuleLoad: back_bdb.la
olcModuleLoad: back_hdb.la
olcModuleLoad: back_mdb.la          

Würde das im vorliegenden Fehlerfall funktionieren? Natürlich nicht – der OpenLDAP-Server läuft ja überhaupt nicht und ein “ldapadd”-Befehl könnte deshalb gar nicht umgesetzt werden!

Direktes Editieren der Konfiguration?

Manche mutige Zeitgenossen wagen es bei kleineren Änderungen (und nach einem vorherigen Sicherheits-Backup der LDAP-Konfiguration), die Einträge in den LDIF-Dateien unter dem Verzeichnis “/etc/openldap/slapd.d/cn=config” auch direkt über Editor-Befehle zu modifizieren. An dieser Stelle muss allerdings gesagt werden, dass die offiziellen OpenLDAP Aministrationshandbücher davon streng abraten. Na ja …

In meinem Fall war eigentlich nur eine Ergänzung erforderlich (s.o.). Ich verhielt mich also mutig; nach einem

serv:/etc/openldap/slapd.d/cn=config # vi olcDatabase\=\{0\}config.ldif 

habe ich die folgende Zeile in der genannten Datei hinzugefügt:

olcModuleLoad: {0}back_hdb

Insgesamt sieht die entsprechende Konfigurationsdatei “olcDatabase\=\{0\}config.ldif” nun so aus:

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 a4b13d6e
dn: olcDatabase={0}config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcRootDN: cn=config
structuralObjectClass: olcDatabaseConfig
entryUUID: 14a9819c-624a-1032-8687-49710846e729
creatorsName: cn=config
createTimestamp: 20130604100551Z
entryCSN: 20130604100551.266001Z#000000#000#000000
modifiersName: cn=config
modifyTimestamp: 20130604100551Z
olcModuleLoad: {0}back_hdb

Man sieht nebenbei: Mein OpenLDAP-Server ist schon was älter. Nach der obigen Modifikation lief und läuft er jedoch auch unter Leap 42.2 wieder und verrichtet nun erneut seinen wichtigen Dienst im Netz:

serv:/etc/openldap/slapd.d/cn=config # systemctl start slapd.service 
serv:/etc/openldap/slapd.d/cn=config # systemctl status slapd.service 
● slapd.service - OpenLDAP Server Daemon
   Loaded: loaded (/usr/lib/systemd/system/slapd.service; enabled; vendor preset: disabled)
   Active: active (running) since Thu 2017-06-01 16:32:38 CEST; 2h 28min ago
  Process: 2632 ExecStart=/usr/lib/openldap/start (code=exited, status=0/SUCCESS)
 Main PID: 2735 (slapd)
    Tasks: 5 (limit: 512)
   CGroup: /system.slice/slapd.service
           └─2735 /usr/sbin/slapd -h ldap:/// ldaps:/// ldapi:/// -F /etc/openldap/slapd.d -u ldap -g ldap -o slp=off

Jun 01 19:00:25 serv slapd[2735]: conn=1304 op=37 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(
objectClass=posixAccount)(uid=*)(uidNumber=*)(gidNumber=*))"
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SRCH attr=objectClass uid userPassword uidNumber gidNumber gecos homeDirectory loginShell krbPrincipalName cn memberOf entryuuid modi...
Jun 01 19:00:49 serv slapd[2735]: conn=1325 op=6 SEARCH RESULT tag=101 err=0 nentries=5 text=
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SRCH attr=objectClass cn userPassword gidNumber member entryuuid modifyTimestamp modifyTimestamp
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=7 SEARCH RESULT tag=101 err=0 nentries=0 text=
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SRCH base="dc=superduper,dc=de" scope=2 deref=0 filter="(&(objectClass=ipService)(cn=*)(ipServicePort=*)(ipServiceProtocol=*))"
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SRCH attr=objectClass cn ipServicePort ipServiceProtocol modifyTimestamp
Jun 01 19:00:50 serv slapd[2735]: conn=1325 op=8 SEARCH RESULT tag=101 err=0 nentries=0 text=
Hint: Some lines were ellipsized, use -l to show in full.

Ich rate dennoch zur Vorsicht! Wer lieber nicht mutig sein will und eher einen sauberen Weg bevorzugt, findet einen alternativen Vorschlag in den Diskussionsbeiträgen unter folgender Bug-Meldung:
https://bugzilla.opensuse.org/show_bug.cgi?id=1011582.

Viel Spass mit OpenLDAP unter Opensuse Leap 42.2 !

SASL mit PAM, SSSD, LDAP unter Opensuse – II

Im ersten Teil “SASL mit PAM, SSSD, LDAP unter Opensuse – I” dieser kleinen Beitragsserie zur Nutzung von SASL, PAM, SSSD im Zusammenhang mit einem (einfachen) LDAP-System hatte ich dargestellt, was man grundsätzlich tun muss, um eine Authentifizierung im Rahmen der Kette

SASLAUTHD => PAM => SSSD => LDAP

zu realisieren.

Den Host, auf dem ein Service “saslauthd” nutzt, nennen wir nachfolgend “c-serv“; der LDAP-Server im Netz heiße dagegen “ldap-serv“. Beide liegen in einer Domaine “anraconx.de“.

So schön das verkettete Auth-Verfahren auch sein mag – es hat in der bisher dargestellten Form einen gravierenden Nachteil:

Nach der beschriebenen Einrichtung von PAM, SSSD und LDAP als Auth-Backend ist es jedem User, der einen gültigen Eintrag auf dem LDAP-Server hat, möglich, sich auf jedem Host, auf dem die PAM-SSSD-LDAP-Kette eingerichtet wurde, einzuloggen und eine Shell zu nutzen. Dabei würde sogar ein Home-Verzeichnis eingerichtet werden. Dieses Verhalten ist für dedizierte Server, die nur einen bestimmten Dienst – wie etwa einen Mail-Dienst – anbieten, aber gar nicht wünschenswert. Der Grund liegt natürlich in Sicherheitsaspekten: Man sollte keine Rechte einräumen, wenn dies zur Nutzung eines bestimmten Serverdienstes gar nicht erforderlich ist.

Wir müssen uns daher bzgl. des Zugangs zum Serverhost etwas andere Ziele stecken und diese mit möglichst geringem Aufwand realisieren.
Wir diskutieren eine Vorgehensvariante nachfolgend am Beispiel eines IMAP-Dienstes, der auf “c-serv” angeboten wird.

Ziele der Authentifizierungskette auf dem Server-Host “c-serv”

  • Die User, die auf dem LDAP-System hinterlegt sind, sollen nicht autorisiert werden, sich auf dem Host “c-serv” normal einzuloggen. Sie dürfen keinen Shell-Zugang erhalten.
  • Die im LDAP verwalteten User sollen sich aber sehr wohl für die Nutzung eines bestimmten Serverdienstes – wie etwa eines IMAP-Dienstes – authentifizieren können und zwar letztlich durch einen sog. “Simple Bind” auf dem LDAP-System.
  • Dabei soll die Verbindung zwischen “c-serv” und “ldap-serv” wie bereits früher beschrieben mit TLS abgesichert aufgebaut werden.
  • Über spezielle Einträge auf dem LDAP-Server soll der Zugang zum Host “c-serv” für bestimmte User auch generell ausgeschlossen werden können.

Auf unserem “c-serv”-Server sollen ein Login und eine Shell-Nutzung nur für den User “root” und ggf. für dedizierte, lokal angelegte User (wie etwa “cyrus”, den Admin des Cyrus IMAP-Dienstes) möglich sein. Verdeutlicht wird dies durch folgende beispielhafte Abbildung:

cserv_600

Aus der Skizze wird bereits der Lösungsansatz erkennbar, den wir nun schrittweise umsetzen. Zwei explizite Warnungen sind angebracht:

Warnung 1:
Die vorgeschlagenen Konfigurationsänderungen können bei Fehlern dazu führen, dass sich auch root nicht mehr auf “c-serv” einloggen kann. Also bitte Vorsicht walten lassen und das ganze Verfahren zunächst auf einem Spielsystem testen, bevor man es auf produktive Systeme
anwendet !

Warnung 2:
Wir werden LDAP als Authentifizierungs-Backend abschalten und dann etliche grundlegende Konfigurationsdateien ändern. Danach darf man die YaST-Konfigurationstools für den LDAP-Client oder für die Backend-Einrichtung zur User-Authentifizierung nicht ohne Wissen um die Konsequenzen nutzen – denn YaST stellt u.a. bei einem Aktivieren des LDAP-Clients zu viele Dinge parallel und automatisch um und würde unsere vorgenommenen Einstellungen ggf. wieder zunichte machen. Also Backups der eigenen Konfigurationsdateien anlegen.

Schritt 1: LDAP-Backend für die User-Authentifizierung abstellen

Als erstes stellen wir mittels “YaST2 => User und Group Administration => Reiter “Authentication Settings” => LDAP” und durch den entsprechenden Radiobutton im Dialogfenster die Benutzung von LDAP als Auth-Backend für das System ab. YaST stoppt dann u.a. den sog. “LDAP-Client”, indem es SSS (besser den SSSD-Dämon) deaktiviert; dies entspricht einem

systemctl stop sssd.service;   systemctl disable sssd.service    .

Die Einstellungen der Datei “/etc/sssd/sssd.conf” bleiben dabei aber erhalten. Das ist aber nicht ganz das, was wir uns wünschen:
Wir wollen ja, dass der Cyrus IMAP-Service später den “SSSD-Service” nutzen soll. Aber im Zuge einer “normalen” Login-Authentifizierung soll sich PAM auf die Prüfung lokaler Informationsquellen beschränken. Deshalb müssen wir noch weitere Schritte durchführen, bevor wir SSSD wieder aktivieren.

Schritt 2 – SSS aus der “Name Service Switch-Konfiguration” entfernen

Wir entfernen die “sss”-Einträge in der Datei “/etc/nsswitch.conf”. Also:

#passwd: compat sss
#group: compat sss
passwd: compat
group: compat

Diese Einstellung entspricht dem blockierenden roten Längsstrich im NSS-Block der Skizze.

Schritt 3 – “pam_sss.so”-Modul aus den PAM “common”-Dateien entfernen

Dann entfernen wir zusätzlich alle “pam_sssd.so“- Referenzen in den Dateien

“/etc/pam.d/common-auth”,
“/etc/pam.d/common-account”,
“/etc/pam.d/common-password”,
“/etc/pam.d/common-session”.

Betroffen ist pro Datei jeweils eine der folgenden Zeilen:

auth required pam_sss.so try_first_pass
account required pam_sss.so use_first_pass
password required pam_sss.so use_authtok
session optional pam_sss.so

Diese Einstellung sorgt dafür, dass PAM für viele vorgegebene Dienste auf einem Standard Opensuse-System nurmehr lokale Informationsquellen prüft.

Schritt 4 – “pam_sss.so”-Modul in die PAM-Datei für die Dienste eintragen, die per SSSD eien LDAP-Prüfung durchführen sollen

Wir demonstrieren dieses Vorgehen am Beispiel der service-spezifischen Datei “/etc/pam.d/imap” für den IMAP-Dienst und ersetzen deren Inhalt durch folgenden:

c-serv:/etc/pam.d # cat imap
#%PAM-1.0
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass
auth required pam_sss.so use_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account sufficient pam_localuser.so
session required pam_limits.so
session required pam_unix.so try_first_pass
session optional pam_sss.so
c-serv:/etc/pam.d #

Oder
alternativ:

#%PAM-1.0
auth sufficient pam_sss.so
auth required pam_env.so
auth required pam_unix.so try_first_pass
account sufficient pam_sss.so use_first_pass
account required pam_unix.so try_first_pass
account required pam_localuser.so
session optional pam_sss.so
session required pam_limits.so
session required pam_unix.so try_first_pass

Wichtig ist in jedem Fall die Reihenfolge der Statements. Warum die komplizierte Abfolge aus “required”- und “sufficient”-Bedingungen?

Weil wir wollen, dass neben den LDAP-Usern auch lokale User auf den angebotenen Dienst zugreifen dürfen. Dieser Bedarf besteht im falle von IMAP mindestens mal für den User “cyrus“; dieser muss ja den IMAP-Dienst und im Besonderen auch die Mailboxen verwalten dürfen. Dazu muss er eine Zugriffsberechtigung erhalten.
Es bleibt dem geneigten Leser überlassen zu überlegen und ggf. zu testen (ein Blick in “/var/log/messages” lohnt sich), warum man dann die vorgegebene Reihenfolge für die PAM-Module einhalten muss.

Schritt 5 – den “sssd.service” wieder aktivieren und Zugriffe testen

Nun enablen wir erneut den “SSSD-Dämon” und starten ihn:

systemctl enable sssd.service
systemctl start sssd.service

Wir können nun durch z.B. einen ssh-Zugriff prüfen, dass für die Testuserin “tarja” (s. den erste Beitrag der Serie) kein Login mehr möglich ist:

c-serv:~ # testsaslauthd -s login -u tarja -p TARJAPWD
0: NO “authentication failed”

und :

c-serv:~ # su – tarja
su: user tarja does not exist
c-serv:~ #

bzw. remote:

user@tux:~> ssh tarja@c-serv
Permission denied (publickey,keyboard-interactive).
user@tux:~>

Dagegen:

c-serv:~ # testsaslauthd -s imap -u tarja -p TARJAPWD
0: OK “Success.”

Wir löschen nun das Verzeichnis “/home/tarja” (soweit vorhanden). Sicherstellen müssen wir noch, dass “root” handlungsfähig ist und ins System kommt :

user@tux:~> ssh root@c-serv
Password:
Last login: Wed Mar 12 17:50:39 2014 from tux.anraconx.de
Have a lot of fun…
c-serv:~ #

und

c-serv:~ # testsaslauthd -u cyrus -p CYRUSPW
0: OK “Success.”

Sieht alles OK aus. 🙂 Was haben wir erreicht ?

Die im LDAP vorhandene “tarja” wie jeder andere im LDAP hinterlegte User kann sich nicht mehr auf dem System “c-serv” einloggen, aber “saslauthd” authentifiziert potentielle Benutzer des IMAP-Dienstes trotzdem über den LDAP-Server! Zudem kann auch der lokale User “cyrus” auf den IMAP-Dienst zugreifen.

Unterbinden des Zugriffs auf den Server-Host für bestimmte User

Die oben verfolgte Politik ist bislang immer noch eine, die allen Nutzern, die im LDAP hinterlegt sind, auch einen Zugriff auf IMAP-Dienste zugesteht. Dennoch will man i.d.R. einige Benutzer explizit nicht an unsern Server-Host “c-serv” (oder zumindest nicht an spezielle Dienste wie IMAP) heranlassen. Welche Möglichkeiten hat man dazu?

Variante 1: “host”-Attribut in den LDAP-User-Einträgen setzen und auswerten
Alternativ kann man bei den User-Einträgen, die man ausschließen will, auf dem LDAP-System das Attribut “host” hinzufügen und SSSD so konfigurieren, dass dieses Feld abgefragt wird. Siehe zu Letzterem:
https://access.redhat.com/site/
documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/config-sssd-domain-access.html

Wie man das Attribut “host” dem User-Eintrg hinzufügt, wenn man den Zweig “ou=people,dc=anraconx,dc=de” ursprünglich mit YaST angelegt hatte, habe ich unter
Opensuse 12.1 – LDAP V
beschrieben. (anraconx ist hier nur eine Beispielname und durch die eigene Domain zu ersetzen).

Wir nehmen mal einen User “rmu”, der auf dem LDAP-System vorhanden sei. Ich ergänze mit Hilfe des Tools “gq” wie in Opensuse 12.1 – LDAP V beschrieben, seine ObjectClasses um “extensibleObject” und füge dann das Attribut “host” zum Satz hinzu:

Als Wert des Feldes gebe ich dann – im Gegensatz zur Abbildung! – zunächst “c-serv.anraconx.de” an. Der FQDN muss natürlich auf dem netzwerkeigenen DNS-Server bekannt sein. (In der Praxis würde man statt mit “gq” natürlich mit LDIF-Dateien für alle betroffenen User arbeiten.)
Dann ändern wir auf “c-serv” die Standard-SSSD-Konfiguration, die wir gem. SASL mit PAM, SSSD, LDAP unter Opensuse – I angelegt hatten:

[sssd]
config_file_version = 2
services = nss,pam
domains = default
 
[nss]
filter_groups = root
filter_users = root
 
[pam]
 
# Section created by YaST
[domain/default]
ldap_uri = ldap://ldap-serv.anraconx.de
ldap_search_base = dc=anraconx,dc=de
ldap_schema = rfc2307bis
id_provider = ldap
ldap_user_uuid = entryuuid
ldap_group_uuid = entryuuid
ldap_id_use_start_tls = False
enumerate = True
cache_credentials = False
ldap_tls_cacertdir = /etc/ssl/certs
ldap_tls_cacert = /etc/ssl/certs/YaST-CA.pem
chpass_provider = ldap
auth_provider = ldap
 
access_provider = ldap
ldap_access_order = host

Wichtig und neu sind lediglich die zwei letzten Zeilen. Infos zur Bedeutung der Parameter findet man hier:
http://manpages.ubuntu.com/manpages/precise/en/man5/sssd-ldap.5.html

Neustarten des sssd.service nicht vergessen:

c-serv:~ # systemctl restart sssd.service

Dann versuchen wir einen Login auf c-serv

tux:~ # ssh -X rmu@c-serv
Password:
Last login: Sat Mar 15 16:06:56 2014 from tux.anraconx.de
Have a lot of fun…
rmu@c-serv:~>

Nun ändern wir den Wert des LDAP-Attributs “host” auf “!c-serv.anraconx.de” ab !
Das führt zu:

tux:~ # ssh -X rmu@c-serv
Password:
Permission denied (publickey,keyboard-interactive).
tux:~ #

Aha ! Hosts schließen wir explizit mit einem “!” aus, das dem FQDN im “host”-Attribut auf dem LDAP-Server vorangestellt wird. SSSD prüft erst auf solche Einträge, danach auf explizit freigegebene Hosts.

Lassen wir unsere “sssd.conf” nun aber so, wie sie ist, kommt allerdings auch unsere Testuserin “tarja” nicht mehr aufs System, wenn wir nicht auch bei ihr das “host”-Attribute mit “c-serv.anraconx.de” füllen. Analog für alle anderen User. Es wird also Zeit, dies mit passenden LDIF-Dateien anzugehen. Eine mögliche Einstellung im “host”-Attribut ist übrigens auch “allow_all“.

Erweiterte Variante 2 : Zusätzlich das Attribut “ldap_user_authorized_service” abfragen
Man kann mit SSSD aber offenbar noch feingranularer arbeiten und den Host zulasssen, nicht aber den Zugriff eine bestimmten Service wie “imap”. Hierzu dient
die Abfrage eines Attributs “ldap_user_authorized_service”. Hierzu muss allerdings auf dem LDAP-Server zusätzlich das “ldapns”-Schema geladen werden. Wie man dafür auf einem Openldap-System 2.4 vorgeht, findet man hier:
http://grungelabs.com/guides/2012/06/08/ha-openldap-debian/
http://wiki.ubuntuusers.de/OpenLDAP_ab_Precise

Ich habe das aber selbst nicht für LDAP-Server getestet, die mit YaST eingerichtet wurden. Es mag daher Inkompatibilitäten geben. Wenn ich Zeit finde, behandle ich das mal in einem separaten Beitrag.