Nagios anmeldung schlägt fehl

twinkie · March 17, 2015, 9:04am

Hallo,

nun sind zumindest die Zeilen wieder aktiv. Allerdings geht die Anmeldung immer noch nicht. Nun kommt im error log vom apache ein pam Fehler:

PAM: user 'Administrator' - not authenticated: Authentication service cannot retrieve authentication info, referer:

Hier ist ein ganz böses Ei drin. Das letzte was an diesem Server getan wurde, war ein großes Update auf 4.0. Ich denke hier wird nicht alles korrekt aktualisiert.

Ich habe ein “ucr commit” ausgeführt um alles neu zu lesen.

/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]

/etc/security/access-nagios.conf:

+:Administrator,Domain Admins:ALL -:ALL:ALL

Nun bin ich ein wenig ratlos.

viele Grüße,
Daniel

twinkie · March 17, 2015, 9:18am

mittlerweile scheint es jemanden mit demselben Problem zu geben: HTACCESS und PAM - broken nach Update
Bei mir schaut es im auth.log haargenauso aus.

ahrnke · March 24, 2015, 12:48pm

[quote=“twinkie”]mittlerweile scheint es jemanden mit demselben Problem zu geben: HTACCESS und PAM - broken nach Update
Bei mir schaut es im auth.log haargenauso aus.[/quote]

Ich habe im genannten Thread gerade eine Vermutung geäußert. Können Sie das bitte auch mal prüfen?

Viele Grüße,
Dirk Ahrnke

twinkie · March 24, 2015, 3:55pm

Hallo,

die Einstellungen und Berechtigungen sehen alle genauso aus.
Kleiner funfact am Rande: mit dem Administrator kann ich mich erfolgreich per ssh oder an der UCS Management Konsole anmelden. Nur am Nagios nicht.
Die Pam scheint also grundsätzlich in der Lage zu sein den Account zu behandeln. Nur nicht über den apache und pam.d/nagios.

Gruß,
Daniel

ahrnke · March 24, 2015, 4:53pm

Hallo,

in dem anderen Thread terminiert die Authentifizierung beim Kerberos. Man sollte durchaus mal prüfen, ob ein “kinit Administrator” funktioniert.

Ansonsten kann man an die in Frage kommenden “auth”-Zeilen in /etc/pam.d/common-auth mal ein “debug” hängen und sieht dann etwas mehr in auth.log.

Viele Grüße,
Dirk Ahrnke

SirTux · March 24, 2015, 4:57pm

Schau dir mal das noch an

twinkie · March 25, 2015, 8:55am

Der Kerberos Dienst war der entscheidende Hinweis! Nun funktioniert es wieder. Das debug in der pam zeigte einen nicht erreichbaren kdc.

[server] ~ #  /etc/init.d/heimdal-kdc restart
kdc-kpasswdd disabled by ucr var kerberos/autostart=no
[server] ~ # ucr set kerberos/autostart=yes
Setting kerberos/autostart
[server] ~ #  /etc/init.d/heimdal-kdc start
Starting Heimdal KDC: heimdal-kdc.
Starting Heimdal password server: kpasswdd.

Problem gelöst.

Warum nun allerdings der autostart auf “no” gesetzt war ist mir ein Rätsel. Man kann nur hoffen das nicht noch andere Dienste verstellt sind.

Großen Dank für die Hilfe!

Gruß,
Daniel

ahrnke · March 25, 2015, 9:32am

Hallo,

es ist an dieser Stelle anzumerken, dass “kerberos/autostart=no” bei Systemen, auf denen Samba 4 installiert ist, absichtlich gesetzt wird. Dort wird der Kerberos-Dienst durch Samba selbst bereitgestellt. Wenn man zusätzlich den Heimdal-KDC einschaltet, wird es Probleme geben.

Viele Grüße,
Dirk Ahrnke

StephanT · July 26, 2015, 2:28pm

Hallo,
ich hatte das selbe Problem: Anmeldung an Nagios nicht möglich.
Mit der geänderten Autostart-Einstellung funktioniert’s jetzt.

Gruß
Stephan

StephanT · July 27, 2015, 7:29pm

Hallo,

nachdem ich mit mit der Änderung bei Nagios anmelden kann, ist eine Anmeldung als Nutzer in der Domäne nicht mehr möglich.
Nachdem ich die Autostart-Funtkion wieder ausgeschaltet habe, ist eine Domänenanmeldung möglich, aber eine Nagios-Anmeldung nicht mehr.

Hat jemand hierzu einen Tipp, wie man beide Anmeldungen ermöglichen kann.

Viele Grüße
Stephan

ahrnke · July 29, 2015, 3:17pm

Hallo StephanT,

wie bereits von mir angemerkt, ist die Deaktivierung des Heimdal-Kerberos bei einer Umgebung mit Samba4 durchaus beabsichtigt.
Sollte bei Ihnen die Nagios-Anmeldung ebenfalls an der Kerberos-Authentifizierung scheitern - was zunächst anhand der Logs geprüft werden müsste - sollte man wie beschrieben mit den Kerberos-Tools (z.B. kinit) testen, ob sich das Problem eingrenzen lässt.
Es gibt hier auch Querverweise zu anderen Threads die hilfreich sein könnten.

Viele Grüße,
Dirk Ahrnke

StephanT · July 30, 2015, 8:10pm

Hallo Herr Ahrnke,

leider kenne ich mich Kerberos und allem was dazu gehört nicht so gut aus.
Der Aufruf kinit ergibt folgende Ausgabe:

                         kinit: krb5_get_init_creds: unable to reach any KDC in realm ZUHAUSE.XX

Es scheint mir, als ist der KDC nicht erreichbarin meiner Domäne.
Wie kann man dieses Problem beheben?

Viele Grüße
Stephan

ahrnke · July 31, 2015, 9:29am

Hallo,

bevor wir nach dem Kerberos schauen, sollten wir uns überzeugen, dass die Anmeldeprobleme wirklich dort ihre Ursache haben. Das sollte man z.B. in /var/log/auth.log sehen.

Bzgl. Kerberos müssen wir wissen, ob auf Ihrem System Samba 4 (Active Directory-kompatibler Domänencontroller) installiert ist. Das sähe dann so aus:

root@m:~# ucr get kerberos/autostart
no
root@m:~# netstat -tulpen | grep :88
tcp        0      0 0.0.0.0:88              0.0.0.0:*               LISTEN      0          9499191     17597/samba     
tcp6       0      0 :::88                   :::*                    LISTEN      0          9499183     17597/samba     
udp        0      0 172.25.3.1:88        0.0.0.0:*                              0          9499198     17597/samba     
udp        0      0 0.0.0.0:88              0.0.0.0:*                           0          9499192     17597/samba     
udp6       0      0 :::88                   :::*                                0          9499184     17597/samba

Ohne Samba, dafür mit Heimdal:

root@d:~# ucr get kerberos/autostart yes root@d:~# netstat -tulpen | grep :88 tcp 0 0 172.25.2.1:88 0.0.0.0:* LISTEN 0 12300 2771/kdc tcp 0 0 127.0.0.1:88 0.0.0.0:* LISTEN 0 12299 2771/kdc tcp6 0 0 ::1:88 :::* LISTEN 0 12296 2771/kdc udp 0 0 172.25.2.1:88 0.0.0.0:* 0 12298 2771/kdc udp 0 0 127.0.0.1:88 0.0.0.0:* 0 12297 2771/kdc udp6 0 0 ::1:88 :::* 0 12295 2771/kdc

Viele Grüße,
Dirk Ahrnke

StephanT · August 3, 2015, 1:49pm

Hallo Herr Ahrnke,

auf dem System ist Samba 4 installiert:
root@server:/var/log# ucr get kerberos/autostart
no
root@server:/var/log# netstat -tulpen | grep :88
tcp 0 0 192.168.1.10:88 0.0.0.0:* LISTEN 0 402079 24465/samba
udp 0 0 192.168.1.10:88 0.0.0.0:* 0 402080 24465/samba

Eine versuchte Anmeldung an Nagios ergibt in /var/log/auth.log folgende Meldungen:

Aug 3 15:42:08 server php-mapi[6250]: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.1.32 user=Administrator
Aug 3 15:42:08 server php-mapi[6250]: pam_krb5(nagios:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.1.32

Helfen diese Infos weiter?

Viele Grüße
Stephan Thul

ahrnke · August 3, 2015, 4:32pm

Hallo,

bei Ihnen:

Aug 3 15:42:08 server php-mapi[6250]: pam_unix(nagios:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=192.168.1.32 user=Administrator Aug 3 15:42:08 server php-mapi[6250]: pam_krb5(nagios:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=192.168.1.32
in HTACCESS und PAM - broken nach Update:

Jan 27 19:46:17 home apache2: pam_unix(login:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=178.83.193.96 user=Administrator Jan 27 19:46:17 home apache2: pam_krb5(login:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=178.83.193.96

Ich frag mich gerade, was die PHP-Mapi von Zarafa in diesem Kontext zu suchen hat.
Leider habe ich gerade keine derartige Konfiguration zur Hand.

Vielleicht liest ja jemand mit, der Zarafa+S4+Nagios erfolgreich auf einem System betreibt und Informationen beisteuern kann.

Viele Grüße,
Dirk Ahrnke

ahrnke · August 3, 2015, 6:01pm

Noch ein Nachtrag zum Kerberos:

Mit “samba-tool domain info ip-des-servers” sieht man die konfigurierte AD-Domain. Diese sollte m.E. in der UCRV kerberos/realm als auch letztendlich in /etc/krb5.conf auftauchen. In letzterer ist der KDC angegeben. Bei meiner Umgebung zu Hause zeigt es “kdc = 127.0.0.1”. Wenn ich mich recht erinnere, wird bei “kinit Administrator” (also ohne Angabe des Kerberos-Realms der default_realm aus /etc/krb5.conf benutzt.

StephanT · August 4, 2015, 7:42pm

Hallo Herr Ahrnke,

die Konfigurationsdatei sind wie von Ihnen beschrieben ok.

Der Aufruf “kinit Administrator” ergibt, dass kein KDC gefunden wird:

root@server:~# kinit Administrator
Administrator@ZUHAUSE.XX’s Password:
kinit: krb5_get_init_creds: unable to reach any KDC in realm ZUHAUSE.XX

Sind evtl. irgendwelche Konfigurationsdateien anzupassen?

Gruß
Stephan Thul

ahrnke · August 4, 2015, 8:25pm

Hallo,

können Sie bitte mal Ihre krb5.conf posten, meinetwegen mit geändertem Realm?
Und mal folgendes probieren (angenommen, als kdc ist 127.0.0.1 angegeben):

# nc -v -z 127.0.0.1 88 Connection to 127.0.0.1 88 port [tcp/kerberos] succeeded!
“nc” muß ggf. installiiert werden.

Viele Grüße,
Dirk Ahrnke

StephanT · August 5, 2015, 5:12pm

Hallo Herr Ahrnke,

der Befehlt nc zeigt folgendes Ergebnis:
root@server:~# nc -v -z 127.0.0.1 88
nc: connect to 127.0.0.1 port 88 (tcp) failed: Connection refused

Hier die krb5.conf:

[color=#FF0000][libdefaults]
default_realm = ZUHAUSE.XX
default_tgs_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
default_tkt_enctypes = arcfour-hmac-md5 des-cbc-md5 des3-hmac-sha1 des-cbc-crc des-cbc-md4 des3-cbc-sha1 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
permitted_enctypes = des3-hmac-sha1 des-cbc-crc des-cbc-md4 des-cbc-md5 des3-cbc-sha1 arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96
krb4_get_tickets=no
allow_weak_crypto=true
dns_lookup_kdc = true
dns_lookup_realm = false
forwardable = true
proxiable = true
kdc_timesync = 1
debug = false
[realms]
ZUHAUSE.XX = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
kdc = 127.0.0.1
admin_server = server.zuhause.xx
kpasswd_server = 127.0.0.1
}

ZUHAUSE = {
kdc = 127.0.0.1
admin_server = server.zuhause.xx
default_domain = zuhause.xx
}

[kdc]
hdb-ldap-create-base = cn=kerberos,dc=zuhause,dc=xx
v4-realm = ZUHAUSE.XX

[kadmin]
v4-realm = ZUHAUSE.XX

database = {
label = {
acl_file = /var/lib/heimdal-kdc/kadmind.acl
dbname = ldap:dc=zuhause,dc=xx
realm = ZUHAUSE.XX

	log_file = /var/log/heimdal-database.log
	mkey_file = /var/heimdal/m-key
}

}[/color]

Viele Grüße
Stephan Thul

ahrnke · August 6, 2015, 1:25pm

Hallo,

damit wäre klar, warum kinit nicht geht (als kdc ist localhost definiert, da lauscht aber nichts). Das stand auch schon in einem früheren Post, ich habs aber nicht gesehen, sorry.

Im Normalfall horcht der Kerberos vom Samba auf Port 88 von allen IP-Adressen.
Ich kann mir aktuell nur 2 Situationen vorstellen, dass nur die IP(s) von ethx genommen werden:

Zum Startzeitpunkt von samba war etwas anderes auf Port 88 aktiv.
Zum Beispiel Heimdal. Das sollte sich ändern, wenn Samba mal neu gestartet wird.
Eine Konfiguration verhindert, dass Samba auf localhost horcht.
Originaldokumentation: Prevent Samba from listening on all interfaces.
Umsetzung in UCS über UCR-Variablen:

# ucr search samba/interfaces samba/interfaces/bindonly: <empty> If this variable is set to 'yes', Samba only listens to requests on the network interfaces specified in the variable 'samba/interfaces'. If the variable is unset, Samba listens on all interfaces. samba/interfaces: <empty> If the variable 'samba/interfaces/bindonly' is set to 'yes', Samba only binds to the interfaces listed in this variable. Multiple entries need to be separated by blanks.

Viele Grüße,
Dirk Ahrnke