nss_ldap + pam_listfile.so Problem

[DiscoBoy]

Seit dem Update auf Lenny oder evtl. eines damit einhergegangenen Updates meiner LDAP Acls meldet pam.d immer einen 'Authentification Error' beim Openvpn-Login. Openvpn hat auf meinem System eine speparate pam.d Konfiguration, in der über pam_listfile.so abgefragt wird, ob der User in der Gruppe vpn ist. 'vpn' ist eine Gruppe im LDAP. Allerdings klappt es mit der primary Gruppe 'users' (Über gidNumber) die sich ebenfalls im LDAP befindet. Anscheinend scheitert pam.d bei der Auflösung der Gruppenzugehörigkeiten.

Versuche ich allerdings

Code: Alles auswählen

members vpn

wird mir ebenfalls der Benutzer ausgegeben mit dem ich mich versuche mich anzumelden! Ebenso bei:

Code: Alles auswählen

groups

Setze ich die Gruppe 'vpn' als Primary Gruppe für meinen User, dann klappts mit dem Login auch.

Mein Eintrag in der OpenVpn pam.d Konfiguration

Code: Alles auswählen

auth	required	pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/openvpn

An was könnte das liegen?

[DiscoBoy]

Inzwischen hab ich hiermal weiter versucht an was es liegen kann....recht interessant war mal ein Blick auf die /var/log/auth.log. Hierin finde ich:

Sep 9 00:58:47 server1 openvpn[3354]: nss_ldap: could not search LDAP server - Server is unavailable
Sep 9 00:58:47 server1 openvpn[3354]: pam_listfile(openvpn:auth): Refused user test for service openvpn
Sep 9 00:58:47 server1 openvpn[3354]: pam_unix(openvpn:auth): authentication failure; logname= uid=0 euid=0 tty= ruser= rhost= user=test

Anscheinend kann sich pam_listfile.so nicht an den lokalen LDAP Server anmelden...was bei anderen Modulen doch klappt, siehe folgendes Beispiel:

Sep 9 01:09:40 slave0 sshd[5821]: Accepted keyboard-interactive/pam for test from 192.168.10.194 port 4758 ssh2
Sep 9 01:09:40 slave0 sshd[5821]: pam_unix(sshd:session): session opened for user test by (uid=0)

Mit meinen Einstellungen für libnss_ldap.conf und ldap.conf klappt aber getent, groups, die Anzeigevon owner&group-Infos bei Dateien/Ordnern, etc...
Ich frage mich deshlab welche ldap-Einstellungen für nss_ldap gelten? /etc/ldap/ldap.conf, oder /etc/libnss_dap.conf? Warum meckert nss_ldap über ldapi://%2fvar%2frun%2fldapi/, wenn es doch prima funktioniert für getent?

[DiscoBoy]

Noch ein Versuch, da ich hier immer mehr verzweifel....und anscheinend noch nie jemand was mit pam_listfile und ldap gemacht hat...

Wenn ich an meiner pam-Konfiguration "openvpn" die Einstellungen für pam_listfile von item=group auf item=user stelle, und anstatt der VPN-Gruppe nun die erlaubten User eintrage, dann klappt es!!! pam_listfile kann sich also doch zum LDAP-Server verbinden, und dort auf die User-Profile zugreifen. Aber bei den Gruppen gibt es das beschriebene Problem - es sei denn wie weiter oben beschrieben - die Gruppe ist die Primary-Gruppe des Users und wird noch unter dem User-Profil über "gidNumber" festgelegt.

auth required pam_listfile.so onerr=fail item=user sense=allow file=/etc/security/openvpn

Das kommt, wenn sich ein "nicht-erlaubter" User anmeldet und "item=user" konfiguriert ist.

Sep 10 00:22:29 slave0 openvpn[3354]: pam_listfile(openvpn:auth): Refused user test2 for service openvpn

Für micht stellt sich also immer noch das Problem, dass ich nicht mal genau weiss welche Konfigurationsdatei nss_ldap benötigt (/etc/ldap.conf, oder /etc/ldap/ldap.conf oder /etc/nss-ldap.conf). Und dann müsste ich noch heraus bekommen, weshalb nss_ldap die Gruppen im LDAP nicht findet, oder nicht auswerten kann.

...Ich hoffe jemand erhört mich in meinem Monolog...

[DiscoBoy]

Könnte es sein, dass pam_listfile.so nur mit Support für item=user kompiliert wurde? Wo könnte ich das überprüfen, bzw. wen könnte ich da evtl. fragen?

Ich habe mittlerweile ein bisschen dem LDAP Verkehr gelauscht. Bei pam_listfile.so wird auch trotz item=group nur unter "ou=people" gesucht, ich bin mir aber nicht sicher ob dies durch pam_listfile.so oder auch erst durch pam_ldap.so ausgelöst wird, welches anschliessend aufgerufen wird in der common-auth:

auth required pam_listfile.so onerr=fail item=group sense=allow file=/etc/security/openvpn
auth required pam_tally.so onerr=fail deny=5
@include common-auth
account required pam_tally.so
account required pam_nologin.so
@include common-account
@include common-session
session required pam_limits.so
@include common-password

[Cologne4711]

Hallo,

/etc/pam_ldap.conf
LDAP Konfiguration für pam_ldap. Ermöglicht Authentifizierung (Benutzername,Passwort) über LDAP.

/etc/libnss-ldap.conf
LDAP Konfiguration für nss_ldap. Ermöglich Benutzer-, Gruppeninformationen über LDAP abzurufen (z.B. getent group)

/etc/ldap/ldap.conf
Systemweite Default-Einstellungen für LDAP-Clients - (können überschrieben werden)

Du kannst ja mal die ersten beiden Configs und die /etc/security/openvpn posten

nss_ldap: could not search LDAP server - Server is unavailable

Den Fehler kenne ich, kann aber viele Gründe haben

MfG

[DiscoBoy]

Der Inhalt der /etc/security/openvpn ist schnell erklärt! Es befindet sich eine zeile mit genau dem Namen der Gruppe darin:

cat /etc/security/openvpn
vpn

Die anderen beiden Configs werde ich später von daheim posten.
"Could not search LDAP server - Server is unavailable" ist also Fehlermeldung wirklich nicht gerade aussagekräftig...was könnten den evtl./bekannte Ursachen sein?
Meine Konfiguration hat ja auch mit pam_listfile.so mit Debian Etch einwandfrei funktioniert. Auch jetzt habe ich keinerlei Probleme mit Autentifizierung, mit der Auflistung von Usern und Gruppen (getent, ls, members, groups etc...). Merkwürdig dabei ist allerdings einzig, dass ich bei "members vpn" zwar die richtigen User aufgelistet bekomme, allerdings in der /var/log/auth.log ebenfalls und trotzdem ein "Could not search LDAP server - Server is unavailable" erscheint.

[DiscoBoy]

Hier die Konfigurationsdateien:

/etc/pam_ldap.conf

base dc=domain
uri ldaps://127.0.0.1/
ldap_version 3
rootbinddn cn=pam,ou=admin,dc=domain
port 636
ssl on
pam_login_attribute uid
pam_member_attribute memberUid
pam_min_uid 0
pam_max_uid 49999
pam_password exop

/etc/libnss-ldap.conf

base dc=domain
uri ldapi://%2fvar%2frun%2fldapi/
ldap_version 3
binddn cn=nss,ou=admin,dc=domain
bindpw xyz
nss_base_group ou=groups,dc=domain
scope sub
bind_policy soft
pam_login_attribute uid
pam_member_attribute memberUid
pam_min_uid 0
pam_max_uid 49999
pam_password exop

/etc/ldap/ldap.conf

BASE dc=domain
URI ldap://127.0.0.1
SIZELIMIT 12
TIMELIMIT 15
DEREF never
TLSCACertificateFile /etc/ssl/certs/ca.crt
TLSCertificateKeyFile /etc/ssl/keys/ldap.key
TLSCertificateFile /etc/ssl/certs/ldap.crt
TLS_REQCERT never
BIND_POLICY soft

[DiscoBoy]

Nächster Lösungsansatz: Ich habe auf meinem LDAP Server (gleiche Maschine) anonymen Zugriff gestattet und auch zu allen Sections erlaube ich Zugriff - einfach um Fehler bei den ACLs auszuschliessen. Die libnss_ldap.conf habe ich auf das nötigste reduziert!

/etc/libnss-ldap.conf

base dc=domain
host 127.0.0.1

members, genauso wie getent oder die Anzeige von Benutzerinformationen funtionieren danach genauso! Schau ich in die auth.log erscheint aber nach wie vor:

Sep 10 23:54:32 slave0 members: nss_ldap: reconnecting to LDAP server...
Sep 10 23:54:32 slave0 members: nss_ldap: reconnected to LDAP server ldap://127.0.0.1 after 1 attempt

Der Reconnect kommt natürlich daher, dass jetzt nicht mehr "soft" als bind-policy gesetzt ist in der Minimalkonfiguration von /etc/libnss-ldap.conf.
Ich tippe langsam auf einen BUG. Ich habe alle benötigten Dateien konfiguriert - im Grunde funktioniert das Setup ja für mich. Nur diese komischen nss_ldap-Fehler stören, weil sie höchstwahrscheinlich verhindern dass pam_listfile.so bei Gruppen funtioniert. Und dass kann einfach nicht sein, dass ich bestimmte Logins nicht auf bestimme Gruppen einschränken kann....irgendeine Alternative für mein Anliegen?

Vielen Dank!

[Cologne4711]

Hallo,

hast Du den denn nscd angehalten.
Ansonsten können Änderungen nicht sofort überprüft werden.


MfG

[DiscoBoy]

Der "name service cache daemon" läuft bei mir gar nicht!

[DiscoBoy]

Hier mal der LOG, was pam für Requests an den LDAP-Servr absetzt!

Sep 13 00:41:41 server0 slapd[15324]: slapd starting
Sep 13 00:41:57 server0 ovpn-server[15017]: MULTI: multi_create_instance called
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Re-using SSL/TLS context
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 LZO compression initialized
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Control Channel MTU parms [ L:1594 D:138 EF:38 EB:0 ET:0 EL:0 ]
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Data Channel MTU parms [ L:1594 D:1300 EF:62 EB:135 ET:32 EL:0 AF:3/1 ]
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Fragmentation MTU parms [ L:1594 D:1300 EF:61 EB:135 ET:33 EL:0 AF:3/1 ]
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Local Options hash (VER=V4): '4e321a9f'
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 Expected Remote Options hash (VER=V4): 'c5058fa7'
Sep 13 00:41:57 server0 ovpn-server[15017]: 192.168.10.194:1194 TLS: Initial packet from 192.168.10.194:1194, sid=20fd04e8 f03a1895
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 VERIFY OK: depth=1, /C=DE/ST=DOMAIN/L=DOMAIN/O=DOMAIN/OU=DOMAIN/CN=server0/emailAddress=root@server0
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 VERIFY OK: depth=0, /C=DE/ST=DOMAIN/L=DOMAIN/O=DOMAIN/OU=DOMAIN/CN=vpnclient/emailAddress=root@server0
Sep 13 00:41:58 server0 slapd[15324]: conn=0 fd=18 ACCEPT from PATH=/var/run/slapd/ldapi (PATH=/var/run/slapd/ldapi)
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=0 BIND dn="cn=nss,ou=admin,dc=DOMAIN" method=128
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=0 BIND dn="cn=nss,ou=admin,dc=DOMAIN" mech=SIMPLE ssf=0
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=0 RESULT tag=97 err=0 text=
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=1 SRCH base="dc=DOMAIN" scope=2 deref=0 filter="(&(objectClass=posixAccount)(uid=testuser))"
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=1 SRCH attr=uid userPassword uidNumber gidNumber cn homeDirectory loginShell gecos description objectClass
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=2 SRCH base="ou=groups,dc=DOMAIN" scope=2 deref=0 filter="(&(objectClass=posixGroup)(gidNumber=100))"
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=2 SRCH attr=cn userPassword memberUid uniqueMember gidNumber
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
Sep 13 00:41:58 server0 slapd[15324]: conn=0 op=3 UNBIND
Sep 13 00:41:58 server0 slapd[15324]: conn=0 fd=18 closed
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 PLUGIN_CALL: POST /usr/lib/openvpn/openvpn-auth-pam.so/PLUGIN_AUTH_USER_PASS_VERIFY status=1
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 PLUGIN_CALL: plugin function PLUGIN_AUTH_USER_PASS_VERIFY failed with status 1: /usr/lib/openvpn/openvpn-auth-pam.so
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 TLS Auth Error: Auth Username/Password verification failed for peer
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 Control Channel: TLSv1, cipher TLSv1/SSLv3 DHE-RSA-AES256-SHA, 2048 bit RSA
Sep 13 00:41:58 server0 ovpn-server[15017]: 192.168.10.194:1194 [vpnclient] Peer Connection Initiated with 192.168.10.194:1194
Sep 13 00:41:59 server0 ovpn-server[15017]: 192.168.10.194:1194 PUSH: Received control message: 'PUSH_REQUEST'
Sep 13 00:41:59 server0 ovpn-server[15017]: 192.168.10.194:1194 Delayed exit in 5 seconds
Sep 13 00:41:59 server0 ovpn-server[15017]: 192.168.10.194:1194 SENT CONTROL [vpnclient]: 'AUTH_FAILED' (status=1)
Sep 13 00:41:59 server0 ovpn-server[15017]: 192.168.10.194:1194 TLS Error: local/remote TLS keys are out of sync: 192.168.10.194:1194 [0]

pam_listfile.so sucht also nur nach dem User (uid=testuser) und dessen Primary Group (gidNumber=100)! Frage nur warum sucht es nicht nach anderen Gruppen? Der Quelletext von pam_listfile zeigt hier:

Code: Alles auswählen

case EI_GROUP:
userinfo = pam_modutil_getpwnam(pamh, citemp);
if (userinfo == NULL) {
	pam_syslog(pamh,LOG_ERR, "getpwnam(%s) failed",
		 citemp);
	free(ifname);
	return onerr;
}
grpinfo = pam_modutil_getgrgid(pamh, userinfo->pw_gid);
if (grpinfo == NULL) {
	pam_syslog(pamh,LOG_ERR, "getgrgid(%d) failed",
		 (int)userinfo->pw_gid);
	free(ifname);
	return onerr;
}
itemlist[0] = x_strdup(grpinfo->gr_name);
setgrent();
for (i=1; (i < (int)(sizeof(itemlist)/sizeof(itemlist[0])-1)) &&
	 ([b]grpinfo = getgrent()[/b]); ) {
	if (is_on_list(grpinfo->gr_mem,citemp)) {
	itemlist[i++] = x_strdup(grpinfo->gr_name);
	}
		}
endgrent();
itemlist[i] = NULL;
break;

Ein eigens kleines Codebeispiel mit getgrent() listet mir alle - auch die LDAP Gruppen - auf! pam_listfile.so kann also auf diese Informationen zugreifen!