Es sieht soweit alles in Ordnung aus. Das ändern der Berechtigungen von /etc/machine.secret ändert übrigens nichts.
[code]uri ldap://dcmaster.top2.top1:7389
rootbinddn cn=dcmaster,cn=dc,cn=computers,dc=top2,dc=top1
base dc=top2,dc=top1
ldap_version 3
scope sub
pam_password crypt
ssl start_tls
[/code]
So, melde mich nach längerer Tauchphase zurück. Ich muss mich entschuldigen, auf die guten Beiträge nicht mehr geantwortet zu haben.
War auch etwas frustriert von der aufwändigen Fehlersuche und habe auf Upgrades gehofft. Inzwischen bei UCS 3.1-1 errata level 194 und der Fehler bleibt mir treu. Dafür wachsen die Anzahl von Systemen und Diensten fleissig weiter, und ich brauche jetzt wirklich den nagios-Zugriff. Mit Re-Install der Nagios-Komponenten, Join-Skript Re-Run usw. kam ich nicht weiter.
Werde jetzt also pam_ldap mit Debug-Optionen kompilieren. Muss ich dazu die sources.list anpassen und ein src-Paket laden oder läuft das über ein svn checkout?
Habe nun die Python-Tests durchgeführt, die Herr Meybohm vorgeschlagen hatte:
root@projects:~/pam_ldap_debug# sed 's/passwd/nagios/' </usr/share/doc/python-pam/examples/pamtest.py >/tmp/pamtest.py
root@projects:~/pam_ldap_debug# less /tmp/pamtest.py
root@projects:~/pam_ldap_debug# su - www-data
$ python /tmp/pamtest.py Administrator
Password:
Go away! (('User not known to the underlying authentication module', 10))
$ python /tmp/pamtest.py root
Password:
Go away! (('User not known to the underlying authentication module', 10))Im Syslog steht dazu:
Jan 3 18:54:18 projects python: pam_ldap: ldap_search_s No such object
Jan 3 18:54:56 projects python: pam_ldap: ldap_search_s No such object
Wäre jetzt dankbar für einen Tipp, wie ich die passenden Quellen für libpam_ldap an den Start bringen kann.
Stand auf meinem System ist:
ii libpam-ldap 184-8.5.20.201110290926 Pluggable Authentication Module for LDAP
ii apache2-dbg 2.2.16-6.74.201303050805 Apache debugging symbols
ii apache2-mpm-prefork 2.2.16-6.74.201303050805 Apache HTTP Server - traditional non-threaded model
ii apache2-utils 2.2.16-6.74.201303050805 utility programs for webservers
ii apache2.2-bin 2.2.16-6.74.201303050805 Apache HTTP Server common binary files
ii apache2.2-common 2.2.16-6.74.201303050805 Apache HTTP Server common files
ii libapache2-mod-auth-pam 1.1.1-8.24.201107131721 module for Apache2 which authenticate using PAM
ii libapache2-mod-php5 5.3.3-7.181.201308291557 server-side, HTML-embedded scripting language (Apache 2 module)
ii univention-apache 5.0.14-1.153.201301040920 UCS - Apache2 configurationbe-team
Hallo,
ein paar Rückfragen mit Bezug zu den “ldap_search_s No such object”-Meldungen sind bisher unbeantwortet geblieben. Bitte prüfen Sie eine mit dem Rechnerkonto authentifizierte LDAP Suche nach dem Administrator und melden Sie die Ausgabe zurück: eval "$(ucr shell)"
ldapsearch -xLLL -Z -H ldaps://$(hostname -f):7636 -D $ldap_hostdn -y /etc/machine.secret uid=Administrator dn
Außerdem hängen Sie bitte einmal den Inhalt der Datei /etc/pam_ldap.conf an.
Mit freundlichen Grüßen
Janis Meybohm
Hallo Herr Meybohm,
bei der ldapsearch Abfrage werden TLS-Meldungen ausgegeben:
ldap_start_tls: Operations error (1)
additional info: TLS already started
dn: uid=Administrator,cn=users,dc=be-team,dc=org
MfG
be-team
pam_ldap.conf.txt (607 Bytes)
Hallo,
der Operations Error könnte an der doppelt definierten TLS-Verbindung (-Z und -H ldaps) liegen - nur um sicherzugehen: Bitte wiederholen Sie den Befehl noch einmal folgendermaßen (ohne explizites -Z):
ldapsearch -xLLL -H ldaps://$(hostname -f):7636 -D $ldap_hostdn -y /etc/machine.secret uid=Administrator dnMit freundlichen Grüßen,
Tim Petersen
Hallo Herr Petersen,
das läuft blitzsauber durch:
root@projects:~# eval "$(ucr shell)"
root@projects:~# ldapsearch -xLLL -H ldaps://$(hostname -f):7636 -D $ldap_hostdn -y /etc/machine.secret uid=Administrator dn
dn: uid=Administrator,cn=users,dc=be-team,dc=org
Beste Grüße
be-team
Hallo Herr Petersen,
anbei noch aktuelle Log-Ausgaben als Anhang, das die Aktiväten von slapd mit debug-Level 385 (acl+stats+trace) zeigt. Können Sie daran das Problem identifizieren? Dem Log unmittelbar vorangegangen war der Aufruf von ucs-server.company.tld/nagios - http-Login-Prompt von Firefox beantwortet mit Administrator + Passwort.
Beste Grüße
be-team
2014-02-06-logging.txt (8.05 KB)
Hallo,
noch einmal kurz generell, nachdem ich mir den kompletten Thread durchgelesen habe: Bitte testen Sie die Anmeldung stets als “Administrator”, ohne Angabe der Domain. Dass es hier zu einem Apache Coredump kommt sollten wir nicht weiter beachten, da es erstmal nicht vorgesehen ist, dort “Administrator@domain” als Benutzername zu verwenden.
Weiterhin gehe ich davon aus, dass folgende Zeile aus der auth.log entscheidend ist:
Aug 16 08:14:27 projects apache2: pam_krb5(nagios:auth): failed authorization check; logname=Administrator uid=xx euid=xx tty= ruser= rhost=192.168.12.xxxWenn ich die Situation korrekt verstanden habe, dann erhalten Sie dies bei jedem Anmeldeversuch an Nagios als Benutzer Administrator, korrekt?
In meinen bisherigen Tests wird stets pam_krb5 erfolgreich und sufficient verwendet, wenn ich mich mit dem Administrator an Nagios anmelde. Daher sollten wir uns darauf konzentrieren, weshalb dies bei Ihnen nicht der Fall ist.
Bitte lassen Sie uns einmal die Ausgabe der folgenden Befehle zukommen:
kinit Administrator
klist
kadmin -l
get Administrator
exit
ucr search --brief kerberos
Mit freundlichen Grüßen,
Tim Petersen
Hallo Herr Petersen,
die Ausgabe der Befehle habe ich per Mail an Sie gesendet. Ja, ich melde mich nur als “Administrator” an. Die Anmeldung mit Domänenname war nur ein Versuch. Ja, den Apache-Fehler bekomme ich bei jeder Anmeldung als Administrator an Nagios.
Wie kann ich für Nagios pam_krb5/sufficient einstellen? Gibt es dazu eine ucr-Variable?
[quote=“be-team”]
die Ausgabe der Befehle habe ich per Mail an Sie gesendet. Ja, ich melde mich nur als “Administrator” an. Die Anmeldung mit Domänenname war nur ein Versuch. Ja, den Apache-Fehler bekomme ich bei jeder Anmeldung als Administrator an Nagios.
Wie kann ich für Nagios pam_krb5/sufficient einstellen? Gibt es dazu eine ucr-Variable?[/quote]
Die Ausgaben von der Befehlr (kadmin get, klist, etc.) sieht soweit OK aus, ebenso die UCR Variablen.
Wir sollten uns nochmal genauer mit der eigentlichen Fehlermeldung beschäftigen:
apache2: pam_krb5(nagios:auth): failed authorization check; logname=AdministratorLaut manpage (pam_krb5) gibt es einen einfachen “authorization check” bei der Authentifizierung über pam_krb5. Dort wird geprüft, ob
[ul]
[li] (a) der Principal des Benutzers (Administrator@BE-TEAM.ORG) in der Datei .k5login im Home-Verzeichnis des Benutzers aufgelistet ist, bzw,[/li]
[li] (b) falls .k5login nicht existiert, ob der Principal des Benutzers in der default REALM ist. (Über Optionen in der Kerberos Konfiguration /etc/krb5.conf können aber auch weitere Mappings für den “authorization check” definiert werden, die das Verhalten nochmals ändern)[/li][/ul]
Haben Sie eine Datei .k5login im Home-Verzeichnis des Benutzers Administrator? Falls ja, diese bitte einmal posten.
Falls es nicht an der .k5login liegt, können Sie bitte einmal die Datei /etc/krb5.conf posten.
In einem kurzen Test konnte ich die obige Fehlermeldung bei der Anmeldung am Nagios provozieren, nachdem ich in /home/Administrator/.k5login einen dummy Eintrag (Administrator@TEST.BLA) in /home/Administrator/.k5login oder nach dem Löschen der .k5login konnte ich mich wieder erfolgreich Anmelden.
Mit freundlichen Grüßen
Felix Botner
Hallo Herr Botner,
eine .k5login existiert nicht im Home-Verzeichnis von “Administrator”.
Die krb5.conf habe ich per Upload bereitgestellt: upload_QjJa4G.asc
Beste Grüße
be-team
Hallo,
ich hab ja ein ähnliches mit SVN. Da ja die Rede von einer .k5login war, habe ich mir mal die Berechtigungen der home-Verzeichnisse angesehen: Das von Gast (bei den ging der Login) war es für alle lesbar, das der anderen nicht. Und wenn ich die Berechtigungen entsprechend ändere klappt der Login auch bei den anderen bzw. auch beim Gast nicht. Ich schätze mal beim nagios wirds ähnlich sein.
Hallo,
die krb5.conf sieht soweit gut aus. Wenn es keine Datei ~/.k5login sollte auch der “authorization check” nicht fehlschlagen. Es sei denn, der Kerberos Dienst kommt nicht in das Home des Benutzers. Sie haben dies zwar im Laufe dieses Threads schon einmal geprüft, aber können Sie mit folgendem Befehl nochmals die Berechtigungen des Administrator-Home prüfen (dort sollte rwx–x--x gesetzt sein).
ls -ld "$(getent passwd Administrator | awk -F : {'print $6'})"Alternativ könnten Sie noch folgendes testen. Den “authorization check” in der PAM KRB5 Authentifizierung kann man mit der Option i"gnore_k5login" deaktivieren. Klappt die Authentifizierung wenn Sie “ignore_k5login” in “/etc/pam.d/common-auth” und “/etc/pam.d/common-account” am Ende der “pam_krb5.so” Zeile setzen?
Mit freundlichen Grüßen
Felix Botner
Hallo Herr Botner,
bingo! Und da habe ich mir fünf Wochen Zeit gelassen, Ihren Lösungsvorschlag umzusetzen (Asche auf mein Haupt).
Mit dieser /etc/pam.d/common-account geht es:
# - isn't aware of the user, proceed with the next service
account sufficient pam_krb5.so ignore_k5login
account required pam_ldap.soSo sieht jetzt die /etc/pam.d/common-auth aus:
# Warning: This file is auto-generated and might be overwritten by
# univention-config-registry.
# Please edit the following file(s) instead:
# Warnung: Diese Datei wurde automatisch generiert und kann durch
# univention-config-registry überschrieben werden.
# Bitte bearbeiten Sie an Stelle dessen die folgende(n) Datei(en):
#
# /etc/univention/templates/files/etc/pam.d/common-auth.d/10univention-pam_header
# /etc/univention/templates/files/etc/pam.d/common-auth.d/30univention-pam_local
# /etc/univention/templates/files/etc/pam.d/common-auth.d/50univention-pam_general
# /etc/univention/templates/files/etc/pam.d/common-auth.d/70univention-pam_env
#
auth requisite pam_nologin.so
# local unix authentification; do not cache passwords
auth sufficient pam_unix.so
# remote authentification; if a service
# - fails, we will fall back to cache authentification
# - is successful, cache the password
# - is not aware of the user, proceed with the next service
auth [success=done new_authtok_reqd=ok user_unknown=ignore service_err=die authinfo_unavail=die default=ignore] pam_krb5.so use_first_pass ignore_k5login
auth [success=done new_authtok_reqd=ok user_unknown=die service_err=die authinfo_unavail=die default=die] pam_ldap.so use_first_pass
auth required pam_env.soJetzt bin ich mir nur nicht sicher, ob das so bleiben darf. Aus man pam_krb5 werde ich da auch nicht wirklich schlau bzw. ich überblicke die Implikationen nicht:
[quote] ignore_k5login
Never look for a .k5login file in the user’s home directory. Instead, only check that the Kerberos principal maps to the local account
name. The default check is to ensure the realm matches the local realm and the user portion of the principal matches the local account
name, but this can be customized by setting up an aname to localname mapping in krb5.conf.
This option can be set in krb5.conf and is only applicable to the auth and account groups.
[/quote]
In welcher UCR-Variable kann ich das ggf. dauerhaft einstellen?
Danke und Gruß
be-team
Hallo,
leider kann man die “ignore_k5login” Einstellung nicht per UCR konfigurieren. Sie müssten diese Option direkt in den pam-Dateien oder in den Templates setzen. Aber zumindest wissen wir jetzt, dass am KRB5 “authorization check” während der Authentifizierung liegt. Eigentlich kann ich mir da jetzt nur zwei Ursachen vorstellen. (1) Die Datei ~/.k5login des Benutzers ist fehlerhaft oder (2) der Benutzer kommt nicht in sein HOME Verzeichnis. (1) Hatten wir ja schon geprüft und ausgeschlossen. Könnten Sie mir nochmals die Berechtigungen des HOME Verzeichnis des Benutzers Administrator auf dem Nagios-Server zukommen lassen?
ls -la "$(getent passwd Administrator | awk -F : {'print $6'})"Mit freundlichen Grüßen
Felix Botner
Hallo Herr Botner,
Ausgabe des Befehls kommt als PN! edit Upload ist upload_Gk7jDE.asc
Beste Grüße
be-team
Hallo,
gut, ich glaube das Problem ist das “…” Verzeichnis (also das übergeordnete Verzeichnis), also wahrscheinlich /home (falls das HOME des Administrators /home/Administrator ist). Dort hat nur die Gruppe “Authenticated Users”, alle anderen haben keine Berechtigungen. Bitte geben Sie diesem Verzeichnis einmal die “x” Rechte für alle:
chmod o+x /home/Ich könnte mir vorstellen, dass bei der Authentifizierung der Benutzer “www-data”, unter dem der Apache Prozess läuft, zumindest das Recht in das Benutzer-HOME zu wechseln haben muss, damit das KRB5 PAM Modul prüfen kann, ob die Datei ~/.k5login existiert.
Mit freundlichen Grüßen
Felix Botner
Hallo Herr Botner,
es funktioniert jetzt auch ohne “ignore_k5login”, nachdem ich
# chmod o+x /home/ausgeführt habe. Prima!
be-team