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.96Der 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.33Eventuell 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 packetfilterabfragen; 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-templateswü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