[FreeBSD] PAM en OpenLDAP backend

[Verwijderd]

Omdat het mij handig leek om alle userinformatie centraal te houden leek het mij leuk om is te experiementeren met LDAP op me server (FreeBSD 5.1). Ports die ik hiervoor geinstalled heb zijn:

code:

nss_ldap-1.204_2 
openldap-client-2.1.23
openldap-server-2.1.23
pam_ldap-1.6.5

Dit is mij in zovere gelukt dat ik via ssh kan inloggen met een account die in de LDAP tree staat. Ook kan ik bijvoorbeeld dit doen:

code:

root@judicator:~/ > id ktf
uid=1001(ktf) gid=1001(ktf) groups=1001(ktf)

Maar nu word het "leuk" (niet echt maar ja ):

code:

root@judicator:~/ > finger ktf
finger: ktf: no such user

finger werkt dus om de een of andere reden niet. Ook als ik inlog met de LDAP account gaat het niet helemaal goed:

code:

I have no name!@judicator:~/ >

Kan volgens mij ook niet helemaal de bedoeling zijn . In het begin dacht ik dat het misschien een probleem met acl's was in LDAP. Echter als ik mijn log files bekijk zie ik dat als ik "finger" (niet doordenken mensen ), finger niet eens moeite doet om in me LDAP tree te kijken. Dit doet hij wel als ik met SSH inlog of id doe.

In me /etc/pam.d/ssh en /etc/pam.d/su heb ik de volgende regel toegevoegd:

code:

auth            sufficient      /usr/local/lib/pam_ldap.so no_warn try_first_pass

Mijn nsswitch ziet er als volgt uit:

code:

passwd:         files ldap
group:          files ldap
shadow:         files ldap

Mijn slapd.conf is al helemaal niet bijzonder:

code:

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/samba.schema

access to
        by dn="cn=Manager,dc=judicator,dc=org" write
        by dn="cn=Manager,dc=judicator,dc=org" read
        by * auth

access to *
       by * read

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

loglevel        8
database        bdb
suffix          "dc=judicator,dc=org"
rootdn          "cn=Manager,dc=judicator,dc=org"
rootpw          {MD5}<<<CENSORED>>>
directory       /var/db/openldap-data
index           objectClass     eq
index           uid             pres,eq,sub

Heeft iemand enig idee waarom finger geen contanct probeert te leggen met me LDAP server?

Meer informatie over LDAP onder linux en FreeBSD kan gevonden worden op deze sites:

http://linsec.ca/bin/view/Main/OpenLDAPAuth
http://www.cultdeadsheep...._nss_ldap_mini-HOWTO.html

[PaneVino]

'het systeem' weet niets af van de users die in ldap zitten ... is /etc/nsswitch.conf wel aangepast ?

* PaneVino denk van niet namelijk

[Verwijderd]

Jup die heb ik aangepast (staat ook in startpost )

code:

root@judicator:/etc/pam.d/ > cat /etc/nsswitch.conf 
passwd:         files ldap
group:          files ldap
shadow:         files ldap

[Verwijderd]

Verwijderd schreef op 23 december 2003 @ 16:53:
Maar nu word het "leuk" (niet echt maar ja ):

code:

root@judicator:~/ > finger ktf
finger: ktf: no such user

Hoe zit het met de rest van je pam config files?

Al je pam config files die services bedienen die via LDAP moeten gaan, moeten daar uiteraard wel van op de hoogte zijn. Je geeft al keurig aan dat je voor su en sshd al verwijzingen naar LDAP gemaakt hebt. Als je per service een file in pam.d hebt staan behoor je het daar dus ook aan te passen, evenals het bestand dat gebruikt wordt indien er geen service file voor de betreffende service in pam.d aanwezig is.

Normaliter zet je die entries op sufficient voor LDAP, tenzij je speciale wensen hebt.
Het lijkt me dan ook verstandig dat je eens even een voorbeeldje geeft van hoe je pam.d bestanden er op dit moment uitzien als er zelf niet uitkomt.

finger werkt dus om de een of andere reden niet. Ook als ik inlog met de LDAP account gaat het niet helemaal goed:

code:

I have no name!@judicator:~/ >

Wederom een teken dat pam verkeerd gaat, aangezien je geen session info hebt.

Kan volgens mij ook niet helemaal de bedoeling zijn . In het begin dacht ik dat het misschien een probleem met acl's was in LDAP. Echter als ik mijn log files bekijk zie ik dat als ik "finger" (niet doordenken mensen ), finger niet eens moeite doet om in me LDAP tree te kijken. Dit doet hij wel als ik met SSH inlog of id doe.

Zie ^^^^^^^

In me /etc/pam.d/ssh en /etc/pam.d/su heb ik de volgende regel toegevoegd:

code:

auth            sufficient      /usr/local/lib/pam_ldap.so no_warn try_first_pass

Dat is een beetje vreemd. Wat doet die try_first_pass daar
Of heb je al een authenticatie module aangeroepen in PAM voor die regel?
Normaliter zet je pam eerst en eventuele lokale authenticatie daarachter, maar als je relatief gezien weinig accounts in de LDAP dir hebt, of je toch met een aantal lokale accounts wil blijven werken is daar niks mis mee natuurlijk

Mijn slapd.conf is al helemaal niet bijzonder:

code:

include         /usr/local/etc/openldap/schema/core.schema
include         /usr/local/etc/openldap/schema/cosine.schema
include         /usr/local/etc/openldap/schema/nis.schema
include         /usr/local/etc/openldap/schema/inetorgperson.schema
include         /usr/local/etc/openldap/schema/samba.schema

access to
        by dn="cn=Manager,dc=judicator,dc=org" write
        by dn="cn=Manager,dc=judicator,dc=org" read
        by * auth

access to *
       by * read

pidfile         /var/run/openldap/slapd.pid
argsfile        /var/run/openldap/slapd.args

loglevel        8
database        bdb
suffix          "dc=judicator,dc=org"
rootdn          "cn=Manager,dc=judicator,dc=org"
rootpw          {MD5}<<<CENSORED>>>
directory       /var/db/openldap-data
index           objectClass     eq
index           uid             pres,eq,sub

Nou....niet bijzonder?
Een paar kleine opmerkingen.

Als straks eenmaal alles werkt haal dan a.u.b. de rootdn/rootpw eruit of zorg er in ieder geval anders voor dat die DN niet fysiek beschikbaar is in de directory. Als iemand per ongeluk deze informatie zou weten te bemachten en je hebt een heel netwerk dat draait op LDAP, dan heb je een probleem, tenzij de DN alleen te vinden is in de config (of tenzij er geeneens een rootdn gespecificeerd is in de configs).
Zorg er in ieder geval voor dat je slapd.conf alleen te lezen is door de slapd daemon.

Verder is je ACL een beetje dubbelop. Als je een DN write access geeft, dan impliceer je meteen read access. Het is dus een beetje dubbelop wat je doet voor Manager.

Je bent hoop ik ervan op de hoogte dat netwerk veiligheid bij LDAP erg belangrijk is. Laat informatie zoveel mogelijk via TLS/SSL gaan richting de LDAP server en terug. Is dat niet mogelijk zorg er dan voor dat er geen gevoelige informatie over de lijn gaat in ieder geval. Ik raad je aan wat te gaan spelen met een sniffer om er zeker van te zijn dat er geen gevoelige data over de lijn gaat.
Je zou niet de eerste zijn die zo een heel netwerk open heeft liggen.

Nu gaat dit waarschijnlijk om wat "hobby"-werk, maar geloof mij maar dat er genoeg bedrijven zijn, die absoluut niet aan het laatste puntje gedacht hebben

Oh ja tot slot en zeker niet onbelangrijk.
Als straks alles naar wens werkt, installeer dan a.u.b. nscd om opgevraagde informatie te cachen. Daarmee bestook je de LDAP server niet continu voor elk dingetje dat opgevraagd wordt. Dat zijn heel wat meer aanvragen dan je op het eerste misschine zou denken. Een simpele 'ls -al' zorgt er bijvoorbeeld al voor dat je directory server even wat te doen heeft Zeker als je met meerdere clients gaat werken dan is nscd absoluut een aanrader (let er wel op dat als je actief dingen aan het veranderen bent, dat je caches wel eens niet overeen kunnen komen met de huidige sitautie).

[ Voor 9% gewijzigd door Verwijderd op 23-12-2003 18:37 ]

[_JGC_]

tja, heb ik ook, en vooralsnog denk ik niet dat er iets aan te doen is.

NSS is nieuw sinds FreeBSD 5, en nog niet elk programma kan ermee overweg qua userid resolving. Kijk maar eens naar ps aux als je wat progsels gestart hebt, staat ook alleen je userid en niet je username in.

Net zoals cd ~jan, geeft bij mij "unknown fol... ehm, laat ook maar

Ik bekijk het terwijl ik dit tik, en mn "I have no name", cd ~user, etc gevallen zijn opgelost. Ik raad je aan om je world opnieuw te bouwen met RELENG_5_1 als CVS tag, aangezien dit hier pas werkt sinds de laatste weekendcompile die mn bak gedraaid heeft (was geswitcht van een P3 naar een Duron 750, en dan werkt -march=p3 niet zo lekker meer, alles dumpte core met illegal instructions). Mn FreeBSD versie is op dit moment dus 5.1-RELEASE-p11.

Of het nou ligt aan de nieuwe world, of die 377 ports die ik opnieuw gebouwd heb weet ik niet, feit is wel dat het werkt

Reactie op nelske:
FreeBSD is wat anders dan linux hoor, en nscd bestaat voor zover ik weet niet op FreeBSD.

[ Voor 7% gewijzigd door _JGC_ op 23-12-2003 18:40 ]

[Verwijderd]

_JGC_ schreef op 23 december 2003 @ 18:37:
Reactie op nelske:
FreeBSD is wat anders dan linux hoor, en nscd bestaat voor zover ik weet niet op FreeBSD.

Meen je nou dat het wat anders is
Wist ik nog niet

Zou kunnen dat nscd voor FreeBSD er niet is, maar de rest van het verhaal is precies hetzelfde voor GNU/Linux en BSD

[serkoon]

In current is dit gefixt, dmv dynamic linked /sbin en /bin. Daardoor kunnen dingen als de shell, ls, ps, enz, dynamisch gelinkt worden met de nss libs en werkt het resolven van namen via PAM/LDAP ook

Oftewel: ff updaten naar 5.2-RC1..

[Verwijderd]

Allereerst thanks voor alle replies.

Nelske:
Inderdaad, aan me slapd.conf schort nog wel het een en ander Maar dit was een eerst opzet en ik was ff'tjes aan het rond "foolen" .

Dit is overigens mijn pam entry voor sshd:

code:

# auth
auth            required        pam_nologin.so          no_warn
auth            sufficient      /usr/local/lib/pam_ldap.so no_warn try_first_pass
auth            sufficient      pam_opie.so             no_warn no_fake_prompts
auth            requisite       pam_opieaccess.so       no_warn allow_local
auth            required        pam_unix.so             no_warn try_first_pass

# account
#account        required        pam_krb5.so
account         required        pam_login_access.so
account         required        pam_unix.so

# session
#session        optional        pam_ssh.so
session         required        pam_permit.so

# password
#password       sufficient      pam_krb5.so             no_warn try_first_pass
password        required        pam_unix.so             no_warn try_first_pass

Ook hiervoor geld allemaal work in progress ) Eigenlijk is alles standaard, behalve de LDAP entry, die heb ik zelf toegevoegd.

serkoon:
Hoop dat updaten naar current dan de oplossing bied. Een ding weet ik wel, dat zal weer ff'tjes gaan duren