Vorgeschichte: die User authentifizieren sich über NIS (Version 2.12). Der gesamte Bestand wurde erfolgreich vom ursprünglichen (SUSE-9.2) auf einen neuen (Debian-4.0) Rechner gezogen (NIS Version 2.19) — die User können sich weiterhin einloggen, können weiterhin arbeiten wie gehabt. Jedoch funktionieren auf den Fedora-Maschinen (!) keinerlei Cron-Jobs mehr…
Das Logfile ist mit diesen Meldungen hier gespickt:
„`text
Dec 10 10:45:01 rechner crond[23968]: CRON (dau) ERROR: failed to open PAM security session: Success
Dec 10 10:45:01 rechner crond[23968]: CRON (dau) ERROR: cannot set security context
Dec 10 10:45:01 rechner crond[23969]: Authentication service cannot retrieve authentication info
„`
Entgegen allem, was man per Google so findet, passiert das auch auf einer Maschine, auf der SELinux nicht aktiviert ist. Prüfen lässt sich das übrigens folgendermaßen:
„`bash
$ /usr/sbin/getenforce
Disabled
„`
Und die /etc/nsswitch.conf ist ebenfalls korrekt (die User können sich ja einloggen):
„`text
passwd: files nis compat
shadow: files nis compat
group: files nis compat
„`
Auch die Schaltung von PAM in den Debug-Modus bringt keine Erleuchtung:
„`text
auth.log:Dec 9 11:34:01 www crond[10964]: pam_unix(crond:account): could not identify user (from getpwnam(dau))
auth.log:Dec 9 11:34:01 www crond[10965]: pam_unix(crond:account): could not identify user (from getpwnam(dau))
„`
Unzweifelhaft ist jedoch, dass es ausschließlich die NIS-User betrifft — die Cron-Jobs der lokalen User laufen nach wie vor fehlerfrei. Die Fehlermeldung kann unter anderem auch dann auftreten, wenn für den User der entsprechende Eintrag in der shadow fehlt oder er nicht zugreifbar ist… Gewissheit bringt hier
„`bash
$ ypcat shadow.byname | grep dau
dau:$1$Oiiblafaselblafas.ely4t3GSbtmF/:14222:0:99999:7:::
„`
(Beachtet hierzu bitte die Fußnote!)
Was man per Google so findet ist der Tip: NIS platt machen und komplett neu aufsetzen. Die User danken einem sowas und die Chefs sowieso! Geht aber auch einfacher, schaut euch mal die /etc/pam.d/crond eures Fedora-Systems an:
„`text
auth sufficient pam_rootok.so debug
auth required pam_env.so debug
auth include system-auth debug
account required pam_access.so debug
account required pam_permit.so debug
account include system-auth debug
session required pam_loginuid.so debug
session include system-auth debug
„`
Nun bewegt die Datei mal da weg (mv /etc/pam.d/cond /etc/pam.d/crond.WEG) und legt eine neue /etc/pam.d/crond an mit folgendem Inhalt (geklaut von einem Debian-System, auf dem der Quatsch reibungslos funktioniert):
„`text
account required pam_unix.so
auth required pam_unix.so nullok
auth required pam_env.so
session required pam_unix.so
„`
Wenn ihr es debuggen wollt, setzt das Keyword debug an jedes Zeilenende. Aha — urplötzlich tut crond wieder, was er soll! Und das ganz ohne plattmachen und User verärgern…
Und jetzt die Fußnote: auch den httpd kann man darauf trimmen, User-Authentifizierung per pam_unix.so zuzulassen; eine entsprechende /etc/pam.d/httpd kann in etwa so aussehen:
„`text
auth required pam_unix.so
account required pam_unix.so
„`
Wenn das dann dennoch nicht funktioniert und der NIS-Server immer wieder sowas hier vermeldet…
„`text
Dec 9 17:17:36 ypservhost ypserv[11784]: refused connect from 192.168.1.1:51815 to procedure ypproc_match ($NISDOMAIN,shadow.byname;-1)
„`
… dann schaut mal, ob in der /etc/ypserv.conf die folgende Zeile ein- oder auskommentiert ist:
„`text
* : * : shadow.byname : port
„`
Ist die Anweisung aktiv (sprich: keine Raute am Zeilenanfang), so wird der Zugriff auf shadow.byname gesperrt; in dem Falle bekommt ihr bei der ypcat shadow.byname-Anfrage auch keine Antwort. Zeile auskommentieren und Dienst durchstarten schafft hier Abhilfe, aber seid euch im Klaren, was das für die Sicherheit des Systems gegebenenfalls bedeuten kann!
