Anmeldung am Nagios-Webinterface nicht möglich

Hallo,

nach einigem Suchen im Forum muss ich doch wieder um Hilfe bitten:

Auf dem Master ist die Anmeldung am Nagios Webinterface (fqdn/nagios) nicht möglich. Ich verwende den User Administrator, mit dem ich mich auch ohne Probleme in der UMC anmelden kann. Wenn Apache die Authentifizierung versucht, gibt es aber Probleme (s.u.), die sich etwas unterscheiden, wenn ich die Anmeldung mit oder ohne Domänenangabe versuche.

Systeminfos vorab:

[quote]root@projects:/var/log/samba# ucr get server/role
domaincontroller_master
root@projects:/var/log/samba# ucr search --brief version
repository/mirror/version/end:
repository/mirror/version/start:
repository/online/component/.*/version:
repository/online/component/3.1-0-errata/version: 3.1
repository/online/component/3.1-1-errata/version: 3.1
repository/online/component/xrdp-errata/version: current
repository/online/component/xrdp/version: current
update/umc/nextversion: true
version/erratalevel: 149
version/patchlevel: 1
version/releasename: Findorff
version/security-patchlevel:
version/version: 3.1
[/quote]

Ich nutze Samba4, keinen separaten Heimdal-Kerberos.

kinit Administrator an der Kommandozeile funktioniert:

root@projects:/var/log/samba# kinit Administrator Administrator@BE-TEAM.ORG's Password:

Bei der Anmeldung via Browser bei Zugriff auf Administrator@BE-TEAM.ORG angebe. Ohne Angabe der Domäne geht es nicht:

==> /var/log/auth.log <== Jul 30 16:17:33 projects python2.6: nss_ldap: reconnected to LDAP server ldap://projects.be-team.org:7389 after 1 attempt Jul 30 16:17:33 projects python2.6: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=Administrator Jul 30 16:17:33 projects python2.6: pam_krb5(univention-management-console:auth): user Administrator authenticated as Administrator@BE-TEAM.ORG Jul 30 16:18:01 projects CRON[19443]: pam_unix(cron:session): session opened for user root by (uid=0) Jul 30 16:18:13 projects CRON[19443]: pam_unix(cron:session): session closed for user root Jul 30 16:18:52 projects smbd[19544]: pam_unix(samba:session): session closed for user NT AUTHORITY+ANONYMOUS LOGON Jul 30 16:18:57 projects unix_chkpwd[19549]: check pass; user unknown Jul 30 16:18:57 projects unix_chkpwd[19549]: password check failed for user (Administrator) Jul 30 16:18:57 projects apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.12.100 user=Administrator Jul 30 16:18:57 projects apache2: pam_krb5(nagios:auth): failed authorization check; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.12.100

Seit einiger Zeit liefert mein s4-connector Fehler (siehe auch [url]Probleme bei samba4-Ldap-bind ach Upgrade auf 3.1-1]). Könnte das die Ursache für mein Problem sein?

==> /var/log/univention/connector-s4.log <== File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) OBJECT_CLASS_VIOLATION: {'info': "attribute 'sambaNTPassword' not allowed", 'desc': 'Object class violation'}

Habe vorsichtshalber auch noch einmal das Passwort für den Administrator neu gesetzt, um expiration-Probleme auszuschließen. Leider ohne Erfolg: Anmeldung an UMC problemlos, am Nagios Webinterface Fehlanzeige.

Danke für Tipps!
be-team

Nachtrag:

Folgender Eintrag im Apache error.log unmittelbar nach dem Eingeben des Passworts im Browser:

[Tue Jul 30 18:35:56 2013] [notice] child pid 6912 exit signal Segmentation fault (11), possible coredump in /tmp/apache-coredumps

Hatte dazu folgenden Eintrag in die apache2.conf zugefügt:

CoreDumpDirectory /tmp/apache-coredumps

Das Verzeichnis entsprechend angelegt mit owner/group www-data. Die core-Datei war entsprechend zu finden, aber ohne Symbole wenig aufschlussreich:

Core was generated by `/usr/sbin/apache2 -k start'. Program terminated with signal 11, Segmentation fault. #0 0x00007f78216c7df0 in ?? () (gdb)

Die Installation von apache2-dbg funktionierte nicht (Paket ist wahrscheinlich aus gutem Grund nicht im Repository?). Ist es eine gute Idee, die Debugsymbole dennoch zu installieren?

be-team

Hallo,

der Reject im S4-Connector ist vermutlich auf ein Konto ohne Samba Option zurückzuführen ([bug]28410[/bug]).

Das Paket apache2-dbg ist in unmaintained. Siehe 7.5.4. Configuration of the repository server for updates and package installations.

Für die Fehlersuche des eigentlichen Problems wäre es noch möglich, die Authentifizierungskette durchzugehen.
Relevant ist /etc/pam.d/nagios. Dort wird /etc/pam.d/common-auth und die durch dir UCR-Variablen auth/nagios/* erzeugte Liste /etc/security/access-nagios.conf inkludiert. Unter Umständen ist ja eine dieser Konfigurationsdateien nicht korrekt erzeugt bzw. manuell geändert.

Viele Grüße,
Dirk Ahrnke

Hallo und danke,

das Administrator-Konto hat den Haken im Optionsfeld “Samba-Konto”. Der reject müsste also auf ein anderes Konto zurückzuführen sein. Aus dem Logs entnehme ich, dass hier wohl ein Computer-Konto das Problem ist (der Callstack ist ganz ähnlich wie der im genannten Bug #28410:

31.07.2013 15:16:22,4 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=horst-pro,CN=Computers,DC=be-team,DC=org 31.07.2013 15:16:22,49 LDAP (PROCESS): sync to ucs: [windowscomputer] [ modify] cn=horst-pro,cn=computers,dc=be-team,dc=org 31.07.2013 15:16:22,160 LDAP (ERROR ): failed in post_con_modify_functions 31.07.2013 15:16:22,168 LDAP (ERROR ): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 1323, in sync_to_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/password.py", line 783, in password_sync_s4_to_ucs_no_userpassword password_sync_s4_to_ucs(s4connector, key, ucs_object, modifyUserPassword=False) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/password.py", line 774, in password_sync_s4_to_ucs s4connector.lo.lo.modify(ucs_object['dn'], modlist) File "/usr/lib/pymodules/python2.6/univention/uldap.py", line 505, in modify self.lo.modify_s(dn, ml) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 322, in modify_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) OBJECT_CLASS_VIOLATION: {'info': "attribute 'sambaNTPassword' not allowed", 'desc': 'Object class violation'}

Testweise habe ich im LDAP-Verzeichnis dem entsprechenden Computerkonto den Haken “Samba-Konto” verpasst, und der python-Stacktrace taucht nicht mehr auf. Prima soweit. Eine mögliche Fehlerursache ausgeschlossen. Danke!

Das connector-log sagt jetzt nur noch:

31.07.2013 15:23:46,173 LDAP (PROCESS): sync to ucs: Resync rejected dn: CN=horst-pro,CN=Computers,DC=be-team,DC=org

Das hat aber eher nichts mit dem nagios-Anmeldeproblem zu tun. Das besteht unverändert.

Die Authentifizierungskette habe ich an keiner Stelle modifiziert - das müsste also passen.

/etc/pam.d/nagios:

[code]@include common-auth
account required pam_access.so accessfile=/etc/security/access-nagios.conf listsep=, maxent=0x400001

@include common-account
@include common-session
@include common-password
[/code]

Hier noch die UCR-Variablen mit nagios-Bezug:

root@projects:/etc/nagios# ucr shell | grep nagios auth_nagios_accessfile='' auth_nagios_group_Domain_Admins=yes auth_nagios_restrict=yes auth_nagios_user_Administrator=yes nagios_client_allowedhosts='' nagios_client_autoregister='' nagios_client_autostart=yes nagios_client_checkraid=no nagios_common_defaultservices_autocreate=yes nagios_plugin_check_nrpe_timeout=10 nagios_server_authenticate=yes nagios_server_autostart=yes nagios_server_checkexternalcmd=no nagios_server_hostcheck_enable=yes nagios_server_hostcheck_notificationinterval=180 nagios_server_refreshrate=90 nagios_server_theme=nuvola nagios_server_user_allcmd='*' nagios_server_user_allinfo='*' nagios_server_user_configinfo='*' nagios_server_user_systemcmd='*' nagios_server_user_systeminfo='*'

Ich werde jetzt einmal apache2-dbg aus dem unmaintained-Repository installieren. Kann natürlich gut sein, dass der eigentliche Fehler außerhalb von apache liegt.

Bei Anmeldung mit “Administrator” ohne weitere Angaben zur Domäne sagt auth.log:

Jul 31 15:06:02 projects unix_chkpwd[18989]: check pass; user unknown Jul 31 15:06:02 projects unix_chkpwd[18989]: password check failed for user (Administrator) Jul 31 15:06:02 projects apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.12.100 user=Administrator Jul 31 15:06:02 projects apache2: pam_krb5(nagios:auth): failed authorization check; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.12.100

Das verstehe ich nicht so recht, weil der Test “kinit Administrator” an der Kommandozeile ja funktioniert (Samba4, apache, nagios und meine ssh-Session laufen alle auf demselben physischen Server - Timingprobleme dürfte es also nicht geben).

Wenn ich "Administrator@BE-TEAM.ORG" als Benutzer im Anmeldepopup angebe, kommt es zum Dump.

[Wed Jul 31 15:09:28 2013] [error] [client 192.168.12.100] PAM: user 'Administrator@BE-TEAM.ORG' - not authenticated: User not known to the underlying authentication module, referer: https://projects.be-team.org/ucs-overview/de.html [Wed Jul 31 15:09:28 2013] [notice] child pid 15449 exit signal Segmentation fault (11), possible coredump in /tmp/apache-coredumps

Melde mich später mit Ergebnissen bzgl. core-Analyse.

be-team

Ob mich das mit der core-Analyse weiterbringt? Ursprünglich konnte ich mich schließlich am Nagios-Webinterface ohne den Zusatz der Domäne nur mit dem User “Administrator” anmelden.

In /var/log/user.log habe ich zum Anmeldezeitpunkt auch immer die Meldung stehen:

Jul 31 15:38:17 projects apache2: pam_ldap: ldap_search_s No such object

Wie kann ich apache bzw. pam_ldap dazu bringen, mir zu verraten, welches Objekt er gerade sucht und nicht findet? Läuft die LDAP-Abfrage denn mit dem user www-data oder mit einem anderen? Habe auf Verdacht mal als user www-data die Befehle “ldapsearch uid=Administrator” und “kinit Administrator” ausgeführt. Beides funktioniert.

Mit Authentifizierungsketten kenne ich mich nicht aus und habe da auch nichts gedreht (bin mir zumindest keiner Schuld bewusst - muss ja nichts heißen).

Verwirrt,
be-team

Hallo,

ein neuer Versuch und ein neuer Blick auf /var/log/auth.log zeigt, dass Administrator offensichtlich ein Berechtigungsproblem hat und kein Authentifizierungsproblem:

Aug 1 10:50:33 projects apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.12.100 user=Administrator Aug 1 10:50:33 projects apache2: pam_krb5(nagios:auth): failed authorization check; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.12.100

Welche Berechtigungen fehlen dem Administrator denn noch? Meine nagios-Einstellungen habe ich bei den Standardwerten belassen (ucr-Variablen siehe mein Post von gestern, 15:30). Im Handbuch habe ich nur gefunden, dass standardmäßig alle “Domain Admins” zugreifen dürfen. Das ist bei Administrator ja gegeben.

be-team

Hallo,
bei einem Anmeldeversuch eines nicht auf Nagios berechtigten Nutzers erscheint so etwas:

Aug  1 11:11:33 master apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=172.20.20.20  user=username
Aug  1 11:11:33 master apache2: pam_krb5(nagios:auth): user username authenticated as username@REALM
Aug  1 11:11:33 master apache2: pam_access(nagios:account): access denied for user `username' from `172.20.20.20'

Hier scheint also noch etwas bei der Kerberos-Konfiguration krumm zu sein. Wenn ich mir selbst nicht sicher bin, ob die Konfigurationsdateien sauber sind, mache ich immer ein pauschales “ucr commit”. Ich weiß aber nicht, ob ich Ihnen dazu an dieser Stelle raten kann.

Vielleicht könnten Sie ja mal zum Abgleich den Inhalt der /etc/krb5.conf, die Ausgabe von “ktutil -k /etc/krb5.keytab list” und den Inhalt von /etc/pam.d/common-auth posten?

Viele Grüße,
Dirk Ahrnke

So,

erst einmal danke für die Vorschläge! Anbei die fraglichen Dateien. Habe “ucr commit” ausgeführt, da ich es bewusst vermeide, die Konfigurationsdateien manuell zu “frisieren” (passt nicht zu UCR-Konzept). Der Fehler bleibt. Im syslog steht zum fraglichen Zeitpunkt

Aug  1 13:44:07 projects apache2: pam_ldap: ldap_search_s No such object

Nur weiss ich leider nicht, welches Objekt gesucht wird und wie ich pam_ldap dazu bringe, diese Infos zu loggen. tcpdump macht ja wohl wenig Sinn, da die LDAP-Anfragen verschlüsselt laufen, korrekt?

be-team
Archiv.zip (1.5 KB)

Hallo,

wie bereits gestern per PM mitgeteilt: die Konfigurationsdateien sehen für mich normal aus.

Der pam_ldap Fehler im syslog könnte auch eine Folgefehler der fehlgeschlagenen Kerberos-Authentifizierung sein.

Sie erhalten mehr Informationen in den Logs , wenn Sie /etc/pam.d/common-auth in den fraglichen “auth”-Zeilen durch “debug” ergänzen.

Viele Grüße,
Dirk Ahrnke

Hallo zurück,

das habe ich schon versucht. pam_ldap gibt sich bei mir aber nicht auskunftsfreudig :frowning:

man pam_ldap.conf sagt ganz trocken:

[quote] debug
Specifies the debug level used for logging by the LDAP client library. This feature is not supported by all client libraries, and does not apply to the nss_ldap and pam_ldap modules themselves (debugging, if any, is
configured separately and usually at compile time).
[/quote]

Hatte jetzt eigentlich nicht vor, das Modul neu zu kompilieren…

@univention: Hat jemand noch einen Tipp für mich, wo/wie ich weiter komme?

@ahrnke: Danke für alle Tipps - jetzt erst einmal Schönes Wochenende!
be-team

Hallo,

ich hatte gehofft, durch die Debug-Option bei pam_krb5 mehr Informationen zum fehlschlagenden Kerberos-Login zu bekommen.

Viele Grüße,
Dirk Ahrnke

Hallo,

[quote=“be-team”]Ob mich das mit der core-Analyse weiterbringt? Ursprünglich konnte ich mich schließlich am Nagios-Webinterface ohne den Zusatz der Domäne nur mit dem User “Administrator” anmelden.[/quote]welche Änderungen gab es denn am System seit Sie sich nicht mehr am Frontend anmelden können? Haben Sie ggf. mal die /var/log/dpkg.log geprüft und/oder geschaut welche Konfigurationsdateien verändert wurden seit das Problem auftritt? Was hat die Analyse des Core-File ergeben?

Jul 31 15:38:17 projects apache2: pam_ldap: ldap_search_s No such objectDiesbezüglich würde ich einmal prüfen ob die PAM-LDAP Konfiguration in Ordnung ist (/etc/pam_ldap.conf). Evtl. ist keine verschlüsselte Verbindung möglich und/oder der LDAP-Bind mit dem Hostaccount wird abgelehnt.

Könnten Sie bitte auch einmal prüfen welche Berechtigungen aktuell für das Heimatverzeichnis des Administrators vergeben sind (ls -ld /home/Administrator/)? Funktioniert die Anmeldung mit einem anderen Benutzer?

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

seit wann es nicht mehr funktioniert, kann ich leider nicht genau sagen - das System läuft alles in allem gut, und ich schaue nur sehr sporadisch ins Nagios. Habe leider keinen Vollzeit-Sysadmin :frowning: Die Upgrade-Logs hatte ich erst kürzlich nach dem 3.1-Upgrade geprüft und nichts Auffälliges gefunden.

Home-Verzeichnis von Administrator:

root@projects:/etc# ls -ld /home/Administrator/ drwx--x--x 28 Administrator Domain Admins 4096 12. Aug 16:03 /home/Administrator/

Eine Anmeldung mit einem anderen User ist auch nicht möglich. Habe jetzt mal einen ldapsearch ohne weitere Parameter als user www-data versucht, da die pam_ldap-Meldung “no such object” ja vom apache2 ausgelöst wird:

root@projects:/etc# su - www-data Univention DC Master 3.1-1: $ ldapsearch SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: The context has expired (Success)

Ist hier der Hund begraben, oder ist das o.k. so?

Bei “univention-ldapsearch” hat www-data keinen Zugriff auf die machine.secret. Das soll aber so sein - da darf nur root ran, korrekt?

[quote]$ univention-ldapsearch
/etc/machine.secret: Permission denied
[/quote]

Beste Grüße
be-team

Hallo,

das eine anonyme Suche im LDAP nicht möglich ist, ist für ein 3.x System normal, die Berechtigungen von /etc/machine.secret ebenfalls.
Was hat die Auswertung des Core-File ergeben?

Könnten Sie bitte mal prüfen ob eine Anmeldung möglich ist wenn Sie auf das Heimatverzeichnis des Administrators chmod 0755 setzen?

Mit freundlichen Grüßen
Janis Meybohm

Hallo Herr Meybohm,

sorry für die Verzögerung - ich war unterwegs. Die Änderung auf 0755 für das Verzeichnis /home/Administrator hat noch keinen Erfolg gebracht. Müssen noch weitere Dateien (.profile o.ä.) group-readable sein? Das wollte ich jetzt nicht rekursiv vergeben.

Die core-Analyse mit gdb bringt mangels Debug-Symbolen nur eine Hex-Adresse, und ich hatte gehofft, mir das Installieren von apache2-dbg und das Rekompilieren von pam_ldap mit Debugging-Optionen zu ersparen:

Program terminated with signal 11, Segmentation fault. #0 0x00007f78216c7df0 in ?? () (gdb)

In auth.log finde ich

Aug 16 08:14:27 projects apache2: pam_unix(nagios:auth): authentication failure; logname= uid=xx euid=xx tty= ruser= rhost=192.168.12.xxx user=Administrator 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.xxx

“kinit Administrator” läuft sauber durch.

Aus /var/log/apache2/error.log bekomme ich mit den aktuellen Log-settings:

[code]ber_scanf fmt ({iAA) ber:
ber_dump: buf=0x7fcbaa5513a0 ptr=0x7fcbaa5513a3 end=0x7fcbaa5513ac len=9
0000: 65 07 0a 01 20 04 00 04 00 e… …
ber_scanf fmt (}) ber:
ber_dump: buf=0x7fcbaa5513a0 ptr=0x7fcbaa5513ac end=0x7fcbaa5513ac len=0

ldap_err2string
[Fri Aug 16 08:14:29 2013] [error] [client 192.168.12.100] PAM: user ‘Administrator’ - not authenticated: User not known to the underlying authentication module
ldap_unbind
ldap_free_connection 1 1
ldap_send_unbind
ber_flush2: 7 bytes to sd 18
0000: 30 05 02 01 04 42 00 0…B.
tls_write: want=74, written=74
0000: 17 03 01 00 20 a4 57 bc 8e 86 9e 5e c0 8e 6a bb … .W…^…j.
0010: 12 c1 ec 60 6a 45 b4 72 8c 48 83 52 b3 cf bb cb …`jE.r.H.R…
0020: a6 2c 06 8e 87 17 03 01 00 20 59 2a 1f a5 d7 66 .,… Y*…f
0030: 9a cd be 6f 01 ae 30 47 a9 da a1 18 74 d2 13 9d …o…0G…t…
0040: 63 fc b6 a5 ff 68 b3 20 c7 bc c…h. …
ldap_write: want=7, written=7
0000: 30 05 02 01 04 42 00 0…B.
tls_write: want=37, written=37
0000: 15 03 01 00 20 f0 58 5b 7a 33 0e ec 7b d2 c7 06 … .X[z3…{…
0010: 00 a9 10 5d 9b 5e e5 db 38 44 19 e4 ad d1 54 51 …].^…8D…TQ
0020: af 83 1a 71 13 …q.
TLS trace: SSL3 alert write:warning:close notify
ldap_free_connection: actually freed
tls_read: want=5 error=Bad file descriptor
[/code]

Sieht so aus, als ob die LDAP-Suche unter www-data in die Binsen geht. Wie kann ich das an der Kommandozeile genauer analysieren?

be-team

Hallo,

die Berechtigungen für das Heimatverzeichnis waren nur eine Vermutung da es in der Vergangenheit mal Probleme bei holen von Kerberos Tickets durch den Apache gab wenn das Heimatverzeichnis nicht gelistet werden konnte. Sie können die Berechtigungen jetzt gerne wieder zurück setzen.

Ohne Debug Symbole ist der Backtrace natürlich nicht hilfreich. Die Apache Debug Symbole zu installieren sollte allerdings kein Problem darstellen. Nachdem Sie einen Backtrace generiert haben (gdb /usr/sbin/apache2 coreFile --batch -ex “set pagination off” -ex “thread apply all bt”) , können Sie das Paket auch wieder deinstallieren.

Um zu prüfen ob der Nagios PAM-Stack korrekt durchlaufen werden kann, können Sie folgendes Versuchen:sed 's/passwd/nagios/' </usr/share/doc/python-pam/examples/pamtest.py >/tmp/pamtest.py su - www-data python /tmp/pamtest.py Administrator

Ggf. notwendige LDAP-Anfragen werden verschlüsselt gegen den lokalen LDAP-Server gerichtet. Für die Authentifikation wird der Rechneraccount verwendet. Testen können Sie dies z.B. mit:eval "$(ucr shell)" ldapsearch -xLLL -Z -H ldaps://$(hostname -f):7636 -D $ldap_hostdn -y /etc/machine.secret uid=Administrator dn

Mit freundlichen Grüßen
Janis Meybohm

Hallo,

gibt es inzwischen neue Erkenntnisse? Ich habe heute festgestellt, daß die Authenfizierung bei einem zu “UCS 2.4”-Zeiten angelegtem SVN-Repo Probleme macht (die Konfiguration für Apache und PAM wurde der Anleitung für Trac aus dem Wiki entlehnt).
Mit einem Gast-Konto kann man sich erfogreich authenfizieren, mit den anderen nicht. Es kommen dann die Meldungen:

[error] [client IP] (9)Bad file descriptor: Could not open password file: (null) [Sun Sep 01 22:15:35 2013] [error] [client 192.168.10.4] PAM: user 'username' - not authenticated: User not known to the underlying authentication module
Der Test mit dem Python-Script zeigt die selben Ergebnisse bzgl. Erfolg bzw. Mißerfolg bei der Authenfizierung.

EDIT: Inwiefern spielen eigentlich die UCR-Variablen unter auth/* da mit rein? Kann es dadurch Probleme geben?

Also ich hab das Script noch mal mit root ausprobiert: Damit gehts.

Hat vermutlich nichts damit zu tun, aber mir ist aufgefallen, daß der Administrator auf dem UCS, wenn er sich auf der konsole einloggt, kein Ticket bekommt (kinit geht aber). Ist das so gewollt?

Also bei mir gehts, wenn ich “anonymous bind” für die Server-IP erlaube. Es scheint also wohl Probleme mit dem Bind am LDAP zu geben. Ich verstehe nur nicht wieso es mit dem Gastaccount auch so geht.

[quote=“SirTux”]Also bei mir gehts, wenn ich “anonymous bind” für die Server-IP erlaube. Es scheint also wohl Probleme mit dem Bind am LDAP zu geben. Ich verstehe nur nicht wieso es mit dem Gastaccount auch so geht.[/quote]Zumindest für die Authentifikation an Nagios wird zuerst Kerberos verwendet, anschließend (als Fallback) ldap. Die Authentifikation am LDAP sollte aber natürlich auch ohne “anonymous bind” funktionieren, hier könnten Sie einmal prüfen ob die Credentials aus /etc/pam_ldap.conf und /etc/pam_ldap.secret (sollte ein Symlink auf /etc/machine.secret sein) korrekt sind.

[quote=“SirTux”]Hat vermutlich nichts damit zu tun, aber mir ist aufgefallen, daß der Administrator auf dem UCS, wenn er sich auf der konsole einloggt, kein Ticket bekommt (kinit geht aber). Ist das so gewollt?[/quote]Das ist so normal, ja.

[quote=“SirTux”]EDIT: Inwiefern spielen eigentlich die UCR-Variablen unter auth/* da mit rein? Kann es dadurch Probleme geben?[/quote]Für die dort definierten Services (z.B. “auth/nagios” kann der Zugriff natürlich über die Variablen gesteuert werden. Wenn Sie die “auth/methods” verändern wird sich dies auf viele Anmeldeverfahren auswirken da die “common”-Stacks verändert werden.

Mit freundlichen Grüßen
Janis Meybohm

Mastodon