# Gruppenmitgliedschaft und NIS/LDAP

## tomiondrums

Hi!

Die Datei /etc/group legt ja bekanntlich fest, wie eine Gruppe heißt, welche GID sie hat und wer alles Mitglied in ihr ist. Ein Benutzer der die Audio-Devices am Rechner verwenden will, sollte in der Gruppe 'audio' sein, damit ihn sein System das auch lässt....

Jetzt kommt es aber vor, daß man einen Teil seiner Benutzer im Netzwerk zentral verwalten will/muß und benutzt dazu NIS oder LDAP oder ähnliches. Auch dort gibts das Konzept mit den Gruppen und ihren Mitgliedern. Ich möchte beispielsweise die Mitglieder der Gruppe 'audio' zentral mit LDAP verwalten und hab deswegen unter Anderem meinen Benutzer 'tomi' auf dem LDAP zu einem Mitglied von 'audio' gemacht. (Daß der Client das auch mitkriegt zeigt mir 'getent group', indem es den Benutzer 'tomi' als eines der Mitglieder von 'audio' anzeigt)

Soweit so schön!

Der Haken an der ganzen Sache ist nur, daß ich als Benutzer 'tomi' in der Praxis nicht die Rechte bekommen, die mir als 'audio'-Mitglied zustehen, d.h. z.B. ich kann von der KDE aus keine Musik hören, die Laustärkeregelung nicht benutzen und bekommen X Fehlermeldungen diesbetreffend.

Ich glaube mittlerweile daß es sich hierbei um ein Problem im Zusammenhang mit PAM handelt, weil ich schon früher, als ich noch mit NIS rumgemurkst hab, mir die Zähne an dem Problem ausgebissen hab. Im Moment behelfe ich mir indem ich wie gesagt, die Gruppen alle trotzdem lokal (/etc/group) anlege und dort auch die über LDAP importierten Nutzer eintrage, was natürlich LDAP vollkommen sinnfrei macht.

Woran könnte das o.g. Problem liegen? Was kann ich dagegen tun?

Vielen herzlichen Dank schonmal für alle Ideen!

MfG

 Tom

----------

## tomiondrums

ich hab grad die ganze Sache auch nochmal vereinfacht und folgendes ausprobiert:

ein Verzeichnis /testdir erstellt

dessen Lese/Schreibrechte auf die Gruppe beschränkt und es mit 'chown root:audio /testdir' Root und der Gruppe audio übereignet

'ls -la' sagt jetzt:

```

...

d---rwx---   2 root audio      4096 Jun 24 00:41 testdir

...

```

die Zeile für die Gruppe 'audio' in der '/etc/group' gelöscht (wofür mich udev bei Neustart gleich mal heftig bestraft hat... :-/ )

 mich mit getent versichert, daß mein Benutzer auch in der Gruppe 'audio' drin ist

```

# getent group |grep 18

dhcp:x:1018:

audio:*:18:anja,gabi,reinhold,tomi

```

(Der Benutzer 'tomi' wird vom LDAP-Server bezogen und ein Login damit auf dem Client funktioniert wunderbar)

Probiert ob ich mit 'tomi' auch in das Verzeichnis reinkomme:

```

tomi@dual / $ cd testdir/

bash: cd: testdir/: Permission denied

```

Wie man sieht passt da was nicht... Woran kanns liegen?

Meine /etc/pam.d/system-auth

```

auth            required        pam_env.so

auth            required        pam_unix.so try_first_pass likeauth nullok

auth            sufficient      pam_ldap.so use_first_pass

account         sufficient      pam_ldap.so

account         required        pam_unix.so

password        required        pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 try_first_pass retry=3

password        required        pam_unix.so try_first_pass use_authtok nullok md5 shadow

password        sufficient      pam_ldap.so use_authtok use_first_pass

session         required        pam_limits.so

session         required        pam_env.so

session         required        pam_unix.so

session         optional        pam_ldap.so

```

Kanns auch sein, daß ich noch an einer anderen Datei in /etc/pam.d was hätte ändern sollen?

Meine /etc/nsswitch.conf

```

# /etc/nsswitch.conf:

# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      files ldap

shadow:      files ldap

group:       files ldap

#passwd:    compat

#shadow:    compat

#group:     compat

hosts:       files ldap dns

#hosts:       files dns

networks:    files dns

services:    db files

protocols:   db files

rpc:         db files

ethers:      db files

netmasks:    files

netgroup:    files

bootparams:  files

automount:   files

aliases:     files

```

----------

## STiGMaTa_ch

 *tomiondrums wrote:*   

> Meine /etc/nsswitch.conf
> 
> ```
> 
> # /etc/nsswitch.conf:
> ...

 

Aendert es was, wenn du ldap vor files nimmst in nsswitch.conf?

```

# /etc/nsswitch.conf:

# $Header: /var/cvsroot/gentoo/src/patchsets/glibc/extra/etc/nsswitch.conf,v 1.1 2006/09/29 23:52:23 vapier Exp $

passwd:      ldap files

shadow:      ldap files

group:       ldap files

```

Lieber Gruss

STiGMaTa

----------

## tomiondrums

das kann ich leider nicht machen (es bringt im Übrigen auch nix), weil dadurch udev beim Bootvorgang in eine Endlosschleife (bzw. einen Lock) gerät (udev fragt Gruppeninfos ab -> kontaktiert zuerst LDAP -> LDAP benötigt Netzwerkanbindung -> Netzwerk ist noch down -> Netzwerk soll gestartet werden -> Anfrage an udev -> ....). Ziemlich haarig das ganze.

Es auch sehr merkwürdig, daß ja die Benutzerauflösung über LDAP einwandfrei funktioniert. Sogar die Änderung von Passwörtern seitens eines Benutzers läuft einwandfrei. Nur dieses elende Gruppenzeug krieg ich nicht hin und das schon seit Jahren.

Außerdem versteh ich nicht so ganz, was das mit dem '*' und dem 'x' bei 'getent group' hinter dem Gruppennamen soll. Wenns eine Entsprechung zur /etc/group sein sollte, dann müsste dort ja das verschlüsselte Gruppenpasswort stehen. In meiner lokalen /etc/group siehts bei Gruppen ohne Passwort aber folgendermaßen aus 'gruppenname::0815:mitglied1,mitglied2'. Heißt '*' oder 'x' wohl auch, daß die Gruppe einfach kein Passwort hat, oder ist das ein Fehler?

----------

## tomiondrums

Ich hab's!

Der Teufel sitzt wie immer im Detail:

 Das genannte Problem wird nämlich weder von einer der hier genannten Dateien noch von PAM oder sonst einem Fehler in der NSS-LDAP-Software verursacht. Im Gentoo-OpenLDAP-Leitfaden steht, daß man auf den Clients in der /etc/ldap.conf unter anderem folgende Zeilen eintragen soll:

```
pam_member_attribute memberuid
```

Die Schreibung des Attributs passt aber nicht mit den im Verzeichnis abgelegten Daten zusammen, weil dort heißt das Attribut nämlich memberUid

Wenn man außerdem noch 

```
nss_connect_policy persist
```

 einträgt und neustartet, sodaß NSS die Infos über die Gruppen neu vom Server abholen muß, dann läufts.

----------

## Tiberian

 *tomiondrums wrote:*   

> das kann ich leider nicht machen (es bringt im Übrigen auch nix), weil dadurch udev beim Bootvorgang in eine Endlosschleife (bzw. einen Lock) gerät (udev fragt Gruppeninfos ab -> kontaktiert zuerst LDAP -> LDAP benötigt Netzwerkanbindung -> Netzwerk ist noch down -> Netzwerk soll gestartet werden -> Anfrage an udev -> ....). Ziemlich haarig das ganze.
> 
> Es auch sehr merkwürdig, daß ja die Benutzerauflösung über LDAP einwandfrei funktioniert. Sogar die Änderung von Passwörtern seitens eines Benutzers

 

Dagegen hilft ein 

```
bind_policy soft
```

 bzw. 

```
nss_initgroups_ignoreusers ldap,avahi,haldaemon,dbus,smmsp
```

 in der ldap.conf

Dann is das beim reboot auch weg. Zumindest war es bei mir so. Leider is die Zusammenarbeit zwischen dem udev team und dem team dass pam_ldap und nss_ldap pflegt irgendwie nicht so gelungen  :Wink: 

Grüße

Tiberian

----------

