Nagios-Anmeldung nicht möglich

UCS - Univention Corporate Server
1

Hallo zusammen,

mein Server läuft zur Zeit als DC Master in der Version 3.2-0 errata 67.
Seit einiger Zeit bekomme ich keinen Zugriff mehr auf die Nagios-Weboberfläche. An der UMC kann ich mich hingegen mit dem selben Administrator-Account anmelden.

In /var/log/auth finden sich nach erfolgloser Anmeldung:

Mar 10 18:56:05 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for update Mar 10 18:56:05 server1 apache2: pam_tally(nagios:auth): Error opening /var/log/faillog for read Mar 10 18:56:05 server1 unix_chkpwd[5811]: check pass; user unknown Mar 10 18:56:05 server1 unix_chkpwd[5811]: password check failed for user (Administrator) Mar 10 18:56:05 server1 apache2: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.xxx.xxx user=Administrator Mar 10 18:56:05 server1 apache2: pam_krb5(nagios:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.xxx.xxx
Den Tipp aus einem gleichlautenden Thread aus 2012 ([url]Nagios-Anmeldung nicht möglich]), das Passwort für den Administrator neu zu setzen, habe ich bereits probiert. Dies brachte leider keine Veränderung.

Was könnte der Fehler sein?

Gruß
Uwe

2

Den kennst du auch? Speziell die Berechtigungen des Administrator-Homes würde ich überprüfen.

3

Hallo SirTux,

wie im genannten Thread vorgeschlagen habe ich nun einige Tests durchgeführt:

/etc/pam.d/nagios sieht aus wie dort beschrieben,
die UCR-Variablen mit nagios-Bezug ebenfalls,
auth.log sagt bei Anmeldung mit “Administrator”:Mar 10 22:46:59 server1 python2.6: pam_unix(univention-management-console:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=Administrator Mar 10 22:46:59 server1 python2.6: pam_krb5(univention-management-console:auth): authentication failure; logname=Administrator uid=0 euid=0 tty= ruser= rhost= Eine Anmeldung an Nagios mit “Administrator@fqdn” ist auch nicht möglich

ls -ld /home/Administrator/ ergibt:drwx--x--x 4 Administrator Domain Admins 4096 4. Mär 2013 /home/Administrator/
Jedoch kinit Administrator liefert:kinit: krb5_get_init_creds: unable to reach any KDC in realm XXX.DEDas ist aber eher nicht ok, oder?
Die /etc/krb5.conf und sie /etc/pam.d/common-auth sehen aus wie dort gepostet.

Helfen diese Informationen bei der weiteren Suche?

Gruß
Uwe

4

Da hätte ich gesagt versuchs mal mit

chmod +x /home/Administrator

[quote]Jedoch kinit Administrator liefert:kinit: krb5_get_init_creds: unable to reach any KDC in realm XXX.DEDas ist aber eher nicht ok, oder?
Die /etc/krb5.conf und sie /etc/pam.d/common-auth sehen aus wie dort gepostet.[/quote]

Aber das sieht mir dann doch eher nach einem allgemeineren Kerberos-Problem aus. Geht das auf anderen Systemen? Läuft da Heimdal oder Samba4?

5

Hallo SirTux!

Das Problem ist gelöst. In der UMC unter Systemdienste war heimdal-kdc gestoppt, bei Startart war “nie” eingetragen, warum kann ich nicht sagen. Nach dem Neustart funktioniert der Zugriff auf Nagios wieder einwandfrei. Die Startart habe ich nun auf “automatisch” geändert.

Vielen Dank für die Hilfe!

Gruß
Uwe

6

Sofern Samba 4 im Einsatz ist war das wohl keine gute Idee.

7

Hallo SirTux!

Ok, wenn ich das richtig verstehe darf also heimdal-kdc nicht parallel mit samba4 laufen. Ich habe also wie beschrieben mitucr set kerberos/autostart=no /etc/init.d/heimdal-kdc stopden vorhergehenden Zustand wieder hergestellt.

Leider habe ich dann auch wieder keinen Zugriff auf die Nagios-Weboberfläche. Laut dem Kommentar dort bringt Samba4 seinen eigenen Kerberos mit. Läuft der denn dann bei mir nicht korrekt?

In der weiteren Problembeschreibung im anderen Thread wird die Datei /var/log/samba/log.samba angesprochen. Hierin findet sich bei mir:[2014/03/12 19:38:49.217081, 0, pid=25536] ../source4/smbd/server.c:372(binary_smbd_main) samba version 4.1.0-Debian started. Copyright Andrew Tridgell and the Samba Team 1992-2013 [2014/03/12 19:38:51.146669, 0, pid=25537] ../source4/smbd/server.c:501(binary_smbd_main) samba: using 'standard' process model [2014/03/12 19:38:52.881852, 0, pid=25553] ../source4/smbd/service_stream.c:346(stream_setup_socket) Failed to listen on 0.0.0.0:389 - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED [2014/03/12 19:38:52.882140, 0, pid=25553] ../source4/ldap_server/ldap_server.c:821(add_socket) ldapsrv failed to bind to 0.0.0.0:389 - NT_STATUS_ADDRESS_ALREADY_ASSOCIATED [2014/03/12 19:38:52.882260, 0, pid=25553] ../source4/smbd/service_task.c:35(task_server_terminate) task_server_terminate: [Failed to startup ldap server task] [2014/03/12 19:38:52.930298, 0, pid=25537] ../source4/smbd/server.c:213(samba_terminate) samba_terminate: Failed to startup ldap server task
Gruß
Uwe

8 
samba_terminate: Failed to startup ldap server task

Scheint, daß der ganze Samba 4 nicht läuft. Laut dem würde ich jetzt vermuten, daß der OpenLDAP den Standard-LDAP-Port belegt.

9

Scheint so, als würde da etwas kollidieren.

Die UCR-Variablen sind wie folgt gesetzt:
sladp/port = 7389,389
sladp/port/ldaps = 7636,636

Samba4 belegt aber wohl auch die Ports 389 und 636. Kann ich einfach in den beiden Variablen die von Samba benötigten Ports entfernen?

10

Ich weiß nicht, wie es mit Samba 4 normalerweise ausshen sollte. Aber ich denke ein Test sollte nicht schaden.

11

Hallo SirTux,

ich habe die beiden Variablen sladp/port = 7389 und sladp/port/ldaps = 7636 gesetzt und anschliessend den Server neu gestartet. Seitdem funktioniert die Anmeldung an Nagios sowie der Zugriff auf Samba-Freigaben tadellos. Scheinbar waren die Samba-Ports 389 und 636 doppelt belegt.

Vielen Dank für die Hilfe!

Gruß
Uwe