PAM configuratie problemen

[The Flying Dutchman]

Ik krijg een door mij gewenste configuratie met geen mogelijkheid voor elkaar en ik hoop dat hier toevallig iemand rondloopt die me verder kan helpen. Eerst een situatie schets:

Ik heb een server (Ubuntu Feisty Fawn, samba met LDAP backend) in een thuisnetwerkje. Hierop wil ik met zowel windows als linux clients kunnen aanmelden (unified logon) waarbij de home directories natuurlijk netjes gemount worden. De windows clients heb ik prima werkend. Echter bij de Linux clients wil het nog niet helemaal lukken. Ik gebruik pam_ldap om aan te melden en dat werkt. Daarnaast wil ik pam_mount gebruiken om de homedirectories en de shares te mounten (voor de linux clients doe ik dat met nfs). Op zich werkt dat ook... maar... nu wil ik het zo configureren dat pam_mount niet gebruikt wordt als een lokale user zich aanmeld. Dus gebruiker 'Pietje' is een lokale user op client A, maar is geen netwerk gebruiker. Als Pietje zich aanmeld op client A, dan wordt op dit moment pam_mount aangeroepen. In het geval dat zich op de server ook een gebruiker Pietje bevind (een lokale gebruiker van de server) met hetzelfde wachtwoord als de lokale Pietje van client A, dan wordt zijn homedir gemount (nou is dit misschien een wat ver gezochte situatie, maar daar gaat het me even niet om), dat wil ik graag voorkomen.

Wat heb ik zoal geprobeerd? Ten eerste, ik heb PAM, pam_ldap, pam_mount en alle andere benodigde dingen geinstalleerd via apt-get. Daarnaast heb ik alleen de volgende bestanden bewerkt:

• /etc/pam.d/common-account
• /etc/pam.d/common-auth
• /etc/pam.d/common-password
• /etc/pam.d/common-session

Het bestand '/etc/pam.d/common-pammount' is leeg.
Hieronder volgen een aantal verschillende configuraties die ik geprobeerd heb:

code:

## /etc/pam.d/common-account:
# deze configuratie blijft steeds zoals die is
account   requisite    pam_unix.so
account   sufficient   pam_localuser.so
account   required     pam_ldap.so

code:

## /etc/pam.d/common-auth:
# deze configuratie blijft steeds zoals die is
# als eerste wordt 'pam_mount' geauthenticeerd, dit lijkt (zover ik weet)
# de enige manier om meerdere request voor wachtwoorden te voorkomen
# 'use_first_pass' lijkt niet te werken voor 'pam_mount.so'
auth    required      pam_mount.so
auth    sufficient  pam_ldap.so use_first_pass
auth    required      pam_unix.so nulluk_secure use_first_pass

Nu volgen verschillende configuraties die ik voor '/etc/pam.d/common-session' geprobeerd heb. Eerst een aantal waarbij ik gebruik probeer te maken van de module 'pam_localuser.so':

1.

code:

## /etc/pam.c/common-session:
session   optional      pam_foreground.so
session   requisite     pam_unix.so
# onderstaande regel slaat de 'pam_mount.so' regel over, zoals verwacht,
# maar dat gebeurt uiteraard voor alle gebruikers (dus ook de NIET-lokale)
session   [default=1]   pam_localuser.so
session   required      pam_mount.so
session   required      pam_ldap.so

Uit bovenstaand voorbeeld blijkt dus dat het wel degelijk mogelijk is om de regel 7 over te slaan.

2.

code:

## /etc/pam.c/common-session:
session   optional     pam_foreground.so
session   requisite    pam_unix.so
# de volgende regel lijkt geen effect te hebben, mijn verwachting was dat een
# lokale gebruiker door de control 'sufficient' niet verder verwerkt zou worden,
# maar zowel lokale als ldap gebruikers gaan verder met mounten
session   sufficient   pam_localuser.so
session   required     pam_mount.so
session   required     pam_ldap.so

3.

code:

## /etc/pam.c/common-session:
session   optional                             pam_foreground.so
session   requisite                            pam_unix.so
# onderstaande regel geeft de foutmelding 'su: Module is unknown'
# na het invullen van een wachtwoord
session   [user_unknown=ignore default=done]   pam_localuser.so
session   required                             pam_mount.so
session   required                             pam_ldap.so

4.

code:

## /etc/pam.c/common-session:
session   optional                             pam_foreground.so
session   requisite                            pam_unix.so
# de onderstaande regel volgt altijd de default, er wordt
# dus niets gemount (niet voor lokale gebruikers en ook niet
# voor ldap gebruikers)
session   [user_unknown=ok/ignore default=2]   pam_localuser.so
session   required                             pam_mount.so
session   required                             pam_ldap.so

Tenslotte nog een configuratie waarbij ik gebruik probeer te maken van de 'pam_succeed_if.so' module (in dit geval maak ik gebruik van de user id, ik heb het ook geprobeerd met group id's, dit gaf hetzelfde effect):

5.

code:

## /etc/pam.c/common-session:
session   optional                     pam_foreground.so
# de bedoeling hier: als de uid groter is dan 2000, doe dan niets
# (gebruikers in de ldap hebben een uid groter dan 2000)
# als het kleiner is dan 2000, sla de volgende twee dan over
# De regels worden echter ALTIJD over geslagen
session   [default=2 success=ignore]   pam_succeed_if.so quiet uid > 2000
session   required                     pam_mount.so
session   sufficient                   pam_ldap.so
session   required                     pam_unix.so

Verder heb ik nog geprobeerd gebruik te maken van de 'pam_ldap.so' module, door te proberen de regels over te slaan als de gebruiker niet voorkwam in de ldap server:

code:

session   [user_unknown=2 default=ok]   pam_ldap.so

Ook dit had geen effect (default werd altijd gekozen). Bij mijn weten heb ik zo'n beetje alles nagelopen, ik heb mijn probleem ook al voorgelegd op de pam mailinglist. De meeste informatie over de gebruikte modules heb ik uit de The Linux-PAM System Administrators' Guide gehaald. Configuratie voorbeeld 5, waarbij de uid gebruikt wordt om een stap over te slaan, komt daar bijvoorbeeld letterlijk uit.

In de mailinglist werd opgemerkt dat de 'pam_localuser.so' module niet in een 'session' stack kan werken, echter dit wordt tegengesproken door de hierboven genoemde administrators guide. Voor alle gebruikte modules heb ik in die guide gekeken of ze in de betreffende stack gebruikt kunnen worden. Daarnaast staan alle gebruikte modules in /lib/security, dus dat kan het probleem ook niet zijn.

Ik ben nu al 3 dagen continu aan het puzzelen en ben ondertussen bijna ten einde raad. Is hier iemand die me kan vertellen waarom mijn configuraties niet werken en wat ik eventueel nog zou kunnen proberen?

[The Flying Dutchman]

Geen PAM specialisten aanwezig hier?

[Verwijderd]

Je kan ook automounts gebruiken. Dat is volgens mij de traditionele manier van homedirs over een NFS share mounten.

[MikeN]

En als je het andersom doet?

code:

session [success=2 default=ignore]      pam_unix.so
session required        pam_mount.so
session required        pam_ldap.so
session required        pam_permit.so

[ Voor 4% gewijzigd door MikeN op 02-08-2007 11:23 ]

[The Flying Dutchman]

Verwijderd schreef op donderdag 02 augustus 2007 @ 08:55:
Je kan ook automounts gebruiken. Dat is volgens mij de traditionele manier van homedirs over een NFS share mounten.

Ik heb het ondertussen inderdaad opgelost met autofs, die de mountpoints uitleest vanuit de LDAP server. Ik kreeg het met geen mogelijkheid voor elkaar met pam_mount.

MikeN schreef op donderdag 02 augustus 2007 @ 11:22:
En als je het andersom doet?

code:

session [success=2 default=ignore]      pam_unix.so
session required        pam_mount.so
session required        pam_ldap.so
session required        pam_permit.so

Dit heb ik ook geprobeerd, werkt helaas ook niet. Schijnt ook dat pam_unix.so ook voor LDAP entries succesvol is, omdat pam_unix.so dmv nsswitch.conf ook de LDAP server bekijkt. pam_unix.so is dus NIET equivalent met lokale gebruikers, maar met iedere gebruiker die geauthenticeerd kan worden. Als je in nsswitch.conf configureert dat je in files en in de ldap moet kijken, dan zal pam_unix.so ook in de ldap kijken. Wil je wel lokale gebruikers, dan moet je 'pam_localuser.so' gebruiken (maar dat deed bij mij dus ook niet wat ik verwachtte...).

Ik heb het ondertussen dus opgegeven, maar ik begrijp nog steeds niet waarom het niet wilde werken.Het is nu anders (en afdoende) opgelost, maar mocht iemand nog kunnen uitleggen waarom deze configuraties niet deden wat ik in gedachten had, dan hoor ik het heel graag!