HTACCESS und PAM - broken nach Update

Guten Tag,

Wir verwenden für die Identifikation via .htaccess PAM

Leider taucht seit dem Update ein Fehler auf:

[Fri Jan 23 16:27:47 2015] [error] [client 178.83.193.96] PAM: user 'Administrator' - not authenticated: Authentication service cannot retrieve authentication info,

Wie ist hier vorzugehen?

Danke & Gruss,
Michael Hofmann

Hallo,

hier fehlen ein paar Details um zielführende Ansätze geben zu können.
Update von welcher zu welcher Version?
Wie genau wird PAM in der .htaccess eingesetzt?

Sie können auch Ihre Konfiguration mal mit der aus /var/www/statistik/.htaccess vergleichen. Oder halt mal in der Nagios-Integration (/etc/apache2/conf.d/nagios3.conf) nachsehen, die ist geringfügig anders.

Viele Grüße,
Dirk Ahrnke

Hallo,

Danke für den Input.

PAM wird genau gleich verwendet wie /var/www/statistik, das leider auch nicht mehr geht.

/var/log/auth.log

Jan 27 19:46:17 home unix_chkpwd[6489]: check pass; user unknown
Jan 27 19:46:17 home unix_chkpwd[6489]: password check failed for user (Administrator)
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

Der Server ist auf AWS und nach einem Update gingen die Logins leider nicht mehr.

Irgend einen Vorschlag, wie weiter vorzugehen ist?
Besten Dank!

Gruss,
Michael Hofmann

Hallo,

“statistik” benutzt den PAM-Service “login”, dieser wiederum includiert “common-auth”.
Die Definitionen stehen jeweils in /etc/pam.d und werden aus Templates generiert.
Es wäre vielleicht sinnvoll, hier nachzusehen, ob nicht doch irgendwelche manuellen Änderungen an den Templates vorliegen.

“univention-check-templates” kann da helfen.

Viele Grüße,
Dirk Ahrnke

Hallo,

Das geht leider immer noch nicht. /var/www/statistik auch nicht.

Mar 13 15:01:25 home unix_chkpwd[8518]: check pass; user unknown
Mar 13 15:01:25 home unix_chkpwd[8518]: password check failed for user (Administrator)
Mar 13 15:01:25 home apache2: pam_unix(login:auth): authentication failure; logname= uid=33 euid=33 tty= ruser= rhost=178.83.205.33  user=Administrator
Mar 13 15:01:25 home apache2: pam_krb5(login:auth): authentication failure; logname=Administrator uid=33 euid=33 tty= ruser= rhost=178.83.205.33

Eventuell sind die Ports zu restriktive gesetzt.
Welche Ports müssen in jedem Fall offen sein?
ssh 22, http 80, https 443, ldap 389/7389, sldap 636/7636
Sonst noch einer?

Besten Dank,
Michael Hofmann

Hallo,

Ports werden durch die Pakete beim Installieren immer selbst geöffnet, wenn sie benötigt werden. Welche momentan offen sind, kann man mit

ucr search --brief packetfilter

abfragen; welche Ports durch UCS benutzt werden, liest man in der Supportdatenbank. In dieser Richtung würde ich nicht weiter forschen oder vermuten. Wenn mit einem UCS-Update solch eine Katastrophe passiert (PAM nicht nutzbar), dann wäre es sicher sehr schnell an vielen Stellen aufgefallen. Was zu der Frage zurück führt: was konkret wurde denn da aktualisiert?

Zurück zum eigentlichen Problem. “nach einem Update” und “PAM geht nicht mehr” klingt für mich eher so, als sei die PAM Konfiguration durch das Update überschrieben worden. Wie Dirk Ahrnke schon geschrieben hatte, der Befehl

univention-check-templates

würde dies zutage fördern. Was ist da für ein Ergebnis herausgekommen?

viele Grüße
Frank Greif.

Hallo,

“univention-check-templates” gibt einen leeren Output zurück.
Ist das so ok?

Ich habe die folgenden Links gefunden, die sehr ähnlich aussehen:
github.com/canweriotnow/rpam-ruby19/issues/5 (Redmine mit Passenger ist installiert)
revolutionanalytics.zendesk.com … 6-5-on-AWS (DeployR wäre hier www-data)

Wie soll ist weiter vorgehen?
Besten Dank.

Gruss,
Michael Hofmann

Hallo,

wenn “univention-check-templates” keine Ausgabe liefert, sind die Templates unverändert.

Ihre Fundstellen mit ähnlichen Problemen sind eher auf lokale Authentifizierung bezogen. Das würde ich hier nicht als Ursache sehen. Zur Sicherheit sei aber angemerkt, dass /etc/shadow 640 root:shadow sein sollte.

Wenn man sich die Templates für common-auth ansieht, findet man eine wesentliche UCR-Variable für die Authentifizierungsmethoden:

# ucr search auth/methods auth/methods: krb5 ldap unix This variable configures which authentication methods should be used in the PAM configuration besides pam_unix. The list must be space-separated. Possible values are 'ldap' (pam_ldap), 'krb5' (pam_krb5.so), 'winbind' (pam_winbind.so) and 'cache' (pam_passwdcache.so from the package univention-passwd-cache).

Das wäre zumindest mal einen Blick wert.

Viele Grüße,
Dirk Ahrnke

Hallo,

im Thread nagios anmeldung schlägt fehl ist eine mögliche Lösung zu finden.

Viele Grüße,
Dirk Ahrnke

Hallo,

Ich vermute, das hat mit der Kerberos-Auth zu tun - die Anmeldung klappt nicht:

root@home:/var/log/univention# kinit Administrator Administrator@SIOUXAPP.COM's Password: kinit: krb5_get_init_creds: unable to reach any KDC in realm SIOUXAPP.COM root@home:/var/log/univention# klist klist: No ticket file: /tmp/krb5cc_0

Ist das möglich und hätten Sie mir eventuell ein paar Links?

Danke & Gruss,
Michael Hofmann

Hallo,

wenn auf dem System kein Samba 4 läuft, prüfen Sie bitte zunächst analog zum referenzierten Thread, ob der Heimdal-KDC läuft und Port 88 hört und auf Autostart steht.

Viele Grüße,
Dirk Ahrnke

Hallo,

Leider stimmt alles (autostart=yes, heimdal läuft, port 88).

Gruss,
Michael Hofmann

Hallo,

wenn ich das richtig in Erinnerung habe, ist /etc/krb5.conf in diesem Fall so gebaut, dass der KDC aus dem DNS ermittelt wird (dns_lookup_kdc = true).

Das müsste dann ähnlich aussehen wie bei unserem Demosystem:

$ dig +short -t SRV _kerberos._tcp.it25.de @showroom.it25.de 0 100 88 showroom.it25.de.

Sie können das natürlich auch in der UMC bei den DNS-Einstellungen Ihrer Domain prüfen und wenn nötig verändern.

Viele Grüße,
Dirk Ahrnke

Mastodon