authorisatie met openldap i.p.v. /etc/passwd

[Marinus]

Goedemiddag allen,

Ik ben wat met openldap aan het experimenteren waarbij ik een
Debian-Lenny server heb met openldap. Het is een stand-alone server met
een paar gebruikers aangemaakt en is alleen toegankelijk via mijn lan.

Mijn bedoeling is om met een ubuntu 10.4 LTS desktop-client verbinding
te maken met de server en de authorisatie moet dan met de openldapserver
plaatsvinden i.p.v. met bestand /etc/passwd

Ik heb op zowel op de ubuntu client en op de debian-server een paar
gebruikers aangemaakt die qua naam overeenkomen op de client en de
server. Verder natuurlijk nog de nodige bestanden op de client
geinstalleerd voor openldap.

Met een gebruiker op de client opnieuw ingelogd en het viel me op dat
het nu wat langer duurde.

voor controle heb ik het commando netstat -n uitvoerd op de client
waarbij ik het volgende te zien kreeg:

Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State

tcp 0 0 192.168.100.119:38070 192.168.100.55:389 ESTABLISHED


alsmede op de server ook netstat -n uitgevoerd en daarbij te zien kreeg:

server:
***@srv55:~$ netstat -n
Active Internet connections (w/o servers)
Proto Recv-Q Send-Q Local Address Foreign Address State
tcp 0 0 192.168.100.55:389 192.168.100.119:38070
ESTABLISHED


Hoe kun je nu nog extra een check uitvoeren waarbij je kunt constateren
dat de gebruiker vanaf de client is ingelogd op de server en dat de
authorisatie concreet / geslaagd is. Normaal kun je bv met who, who -u,
users, checken wie er ingelogd is en eventueel met een cat
/var/log/auth.log.



M.v.g.,
Marinus

[tjoen]

Post by Marinus
Mijn bedoeling is om met een ubuntu 10.4 LTS desktop-client verbinding
te maken met de server en de authorisatie moet dan met de openldapserver
plaatsvinden i.p.v. met bestand /etc/passwd

Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Post by Marinus
Hoe kun je nu nog extra een check uitvoeren waarbij je kunt constateren
dat de gebruiker vanaf de client is ingelogd op de server en dat de
authorisatie concreet / geslaagd is.

/var/log/messages

In /ets/syslog.conf:
local4.* /var/log/ldaplogs

In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

[richard lucassen]

On Mon, 05 Jul 2010 15:55:21 +0200

Post by tjoen

Post by Marinus
Mijn bedoeling is om met een ubuntu 10.4 LTS desktop-client
verbinding te maken met de server en de authorisatie moet dan met
de openldapserver plaatsvinden i.p.v. met bestand /etc/passwd

Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Post by Marinus
Hoe kun je nu nog extra een check uitvoeren waarbij je kunt
constateren dat de gebruiker vanaf de client is ingelogd op de
server en dat de authorisatie concreet / geslaagd is.

/var/log/messages
local4.* /var/log/ldaplogs
In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

En dan wel even testen of je aan de console er nog wel in komt als root
als de ldap gestopt is. Dar is errug belangrijk. In RedHat zat vroeger
die bug: LDAP gestopt of een fout in de slapd.conf en dan stond je wel
buiten de deur.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by richard lucassen
On Mon, 05 Jul 2010 15:55:21 +0200

Post by tjoen

Post by Marinus
Mijn bedoeling is om met een ubuntu 10.4 LTS desktop-client
verbinding te maken met de server en de authorisatie moet dan met
de openldapserver plaatsvinden i.p.v. met bestand /etc/passwd

Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Post by Marinus
Hoe kun je nu nog extra een check uitvoeren waarbij je kunt
constateren dat de gebruiker vanaf de client is ingelogd op de
server en dat de authorisatie concreet / geslaagd is.

/var/log/messages
local4.* /var/log/ldaplogs
In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

En dan wel even testen of je aan de console er nog wel in komt als root
als de ldap gestopt is. Dar is errug belangrijk. In RedHat zat vroeger
die bug: LDAP gestopt of een fout in de slapd.conf en dan stond je wel
buiten de deur.

inderdaad, kwam mij bekend voor en ik heb het gelezen

Bedankt voor je reactie / support,

M.v.g.,
Marinus

[Marinus]

Post by tjoen

Post by Marinus
Mijn bedoeling is om met een ubuntu 10.4 LTS desktop-client verbinding
te maken met de server en de authorisatie moet dan met de openldapserver
plaatsvinden i.p.v. met bestand /etc/passwd

Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Post by Marinus
Hoe kun je nu nog extra een check uitvoeren waarbij je kunt constateren
dat de gebruiker vanaf de client is ingelogd op de server en dat de
authorisatie concreet / geslaagd is.

/var/log/messages
local4.* /var/log/ldaplogs

op debian-lenny is dat:
/etc/rsyslog.conf

waarin ik
local4.* /var/log/ldaplogs
toegevoegd heb.

waarvan dit het resultaat is:
-----------------------------
srv55:/home/marinus# cat /var/log/ldaplogs
Jul 5 16:57:56 srv55 slapd[2208]: @(#) $OpenLDAP: slapd 2.4.11 (Nov 26
2009 09:17:06)
$#012#***@SD6-Casa:/tmp/buildd/openldap-2.4.11/debian/build/servers/slapd
Jul 5 16:57:57 srv55 slapd[2225]: slapd starting
Jul 5 16:59:47 srv55 slapd[2225]: conn=0 fd=14 ACCEPT from
IP=192.168.100.119:44345 (IP=0.0.0.0:389)
Jul 5 16:59:47 srv55 slapd[2225]: conn=0 op=0 BIND
dn="cn=manager,dc=m31galaxy,dc=nl" method=128
Jul 5 16:59:47 srv55 slapd[2225]: conn=0 op=0 RESULT tag=97 err=49 text=
Jul 5 16:59:47 srv55 slapd[2225]: conn=0 op=1 UNBIND
Jul 5 16:59:47 srv55 slapd[2225]: conn=0 fd=14 closed
Jul 5 16:59:47 srv55 slapd[2225]: conn=1 fd=14 ACCEPT from
IP=192.168.100.119:44346 (IP=0.0.0.0:389)
Jul 5 16:59:47 srv55 slapd[2225]: conn=1 op=0 BIND
dn="cn=manager,dc=m31galaxy,dc=nl" method=128
Jul 5 16:59:47 srv55 slapd[2225]: conn=1 op=0 RESULT tag=97 err=49 text=
Jul 5 16:59:47 srv55 slapd[2225]: conn=1 op=1 UNBIND
Jul 5 16:59:47 srv55 slapd[2225]: conn=1 fd=14 closed
Jul 5 16:59:48 srv55 slapd[2225]: conn=2 fd=14 ACCEPT from
IP=192.168.100.119:44347 (IP=0.0.0.0:389)
Jul 5 16:59:48 srv55 slapd[2225]: conn=2 op=0 BIND
dn="cn=manager,dc=m31galaxy,dc=nl" method=128
Jul 5 16:59:48 srv55 slapd[2225]: conn=2 op=0 RESULT tag=97 err=49 text=
Jul 5 16:59:48 srv55 slapd[2225]: conn=2 op=1 UNBIND
Jul 5 16:59:48 srv55 slapd[2225]: conn=2 fd=14 closed
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 fd=14 ACCEPT from
IP=192.168.100.119:44350 (IP=0.0.0.0:389)
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 op=0 BIND
dn="cn=manager,dc=m31galaxy,dc=nl" method=128
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 op=0 RESULT tag=97 err=49 text=
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 op=1 BIND
dn="cn=manager,dc=m31galaxy,dc=nl" method=128
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 op=1 RESULT tag=97 err=49 text=
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 op=2 UNBIND
Jul 5 17:00:02 srv55 slapd[2225]: conn=3 fd=14 closed



zoals je weet , worden de logfiles , configfiles afgebroken bij
verzenden van mail / berichten

-----------------------------

Post by tjoen
In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

op debian-lenny (debian5) is dat:

/etc/ldap/slapd.conf
waarin ik
loglevel 256 heb toegevoegd

Volgens mij lijkt het goed te gaan maar ik vind op de server geen
berichten van een gebruiker marinus terug in het bestand /var/log/messages.

Bedankt voor je reactie / support

M.v.g.,
Marinus



http://www.m31galaxy.nl

[Richard Lucassen]

On Mon, 05 Jul 2010 17:45:28 +0200

Post by Marinus

Post by tjoen
In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

/etc/ldap/slapd.conf
waarin ik
loglevel 256 heb toegevoegd
Volgens mij lijkt het goed te gaan maar ik vind op de server geen
berichten van een gebruiker marinus terug in het
bestand /var/log/messages.

Probeer eens 768 ipv 256
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
On Mon, 05 Jul 2010 17:45:28 +0200

Post by Marinus

Post by tjoen
In /etc/openldap/slapd.conf moet dacht ik
loglevel 256

/etc/ldap/slapd.conf
waarin ik
loglevel 256 heb toegevoegd
Volgens mij lijkt het goed te gaan maar ik vind op de server geen
berichten van een gebruiker marinus terug in het
bestand /var/log/messages.

Probeer eens 768 ipv 256

heb ik gedaan, maar nog steeds geen naam van gebruiker te lezen in
/var/log/messages van de openldap-server

nog effetjes voor de zekerheid, onderstaande is toch van toepassing op
de client?.....

Post by Richard Lucassen
Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

M.v.g.,
Marinus

[Richard Lucassen]

On Mon, 05 Jul 2010 22:57:24 +0200

Post by Marinus

Post by Richard Lucassen
Probeer eens 768 ipv 256

heb ik gedaan, maar nog steeds geen naam van gebruiker te lezen in
/var/log/messages van de openldap-server

Je moet slapd wel een schop geven. En anders moet je 65536 gebruiken...
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[tjoen]

Post by Marinus
heb ik gedaan, maar nog steeds geen naam van gebruiker te lezen in
/var/log/messages van de openldap-server
nog effetjes voor de zekerheid, onderstaande is toch van toepassing op
de client?.....

Post by tjoen
Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Dat is verklaring afwezige meldingen /var/log/messages.
Moet op server

[Marinus]

Post by tjoen

Post by Marinus
heb ik gedaan, maar nog steeds geen naam van gebruiker te lezen in
/var/log/messages van de openldap-server
nog effetjes voor de zekerheid, onderstaande is toch van toepassing op
de client?.....

Post by tjoen
Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Dat is verklaring afwezige meldingen /var/log/messages.
Moet op server

waarschijnlijk heb je het over een andere linux distro
ik heb geen meldingen gevonden in /var/log/messages

Op Debian-Lenny (Debian5) is dat /var/log/ldaplogs

Jul 14 10:28:57 srv55 slapd[2311]: slapd starting
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 fd=15 ACCEPT from
IP=192.168.100.119:52598 (IP=0.0.0.0:389)
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 op=0 BIND dn="" method=128
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 op=0 RESULT tag=97 err=0 text=
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 op=1 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=shadowAccount)(uid=marinus))"
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 op=1 SRCH attr=uid
userPassword shadowLastChange shadowMax shadowMin shadowWarning
shadowInactive shadowExpire shadowFlag
Jul 14 10:29:29 srv55 slapd[2311]: conn=0 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 14 10:29:29 srv55 slapd[2311]: conn=1 fd=17 ACCEPT from
IP=192.168.100.119:52599 (IP=0.0.0.0:389)
Jul 14 10:29:29 srv55 slapd[2311]: conn=1 op=0 BIND dn="" method=128
Jul 14 10:29:29 srv55 slapd[2311]: conn=1 op=0 RESULT tag=97 err=0 text=
Jul 14 10:29:29 srv55 slapd[2311]: conn=1 op=1 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0 filter="(uid=marinus)"
Jul 14 10:29:29 srv55 slapd[2311]: <= bdb_equality_candidates: (uid) not
indexed
Jul 14 10:29:29 srv55 slapd[2311]: conn=1 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 14 10:29:30 srv55 slapd[2311]: conn=1 op=2 UNBIND
Jul 14 10:29:30 srv55 slapd[2311]: conn=1 fd=17 closed
Jul 14 10:29:30 srv55 slapd[2311]: conn=0 op=2 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=shadowAccount)(uid=marinus))"
Jul 14 10:29:30 srv55 slapd[2311]: conn=0 op=2 SRCH attr=uid
userPassword shadowLastChange shadowMax shadowMin shadowWarning
shadowInactive shadowExpire shadowFlag
Jul 14 10:29:30 srv55 slapd[2311]: conn=0 op=2 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 14 10:29:37 srv55 slapd[2311]: conn=0 op=3 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=shadowAccount)(uid=marinus))"
Jul 14 10:29:37 srv55 slapd[2311]: conn=0 op=3 SRCH attr=uid
userPassword shadowLastChange shadowMax shadowMin shadowWarning
shadowInactive shadowExpire shadowFlag



M.v.g.,
Marinus


http://www.m31galaxy.nl

[tjoen]

Post by Marinus

Post by tjoen

Post by Marinus
heb ik gedaan, maar nog steeds geen naam van gebruiker te lezen in
/var/log/messages van de openldap-server
nog effetjes voor de zekerheid, onderstaande is toch van toepassing op
de client?.....

Post by tjoen
Toevoegen aan /etc/pam.d/login
auth sufficient pam_ldap.so
account sufficient pam_ldap.so
password required pam_ldap.so

Dat is verklaring afwezige meldingen /var/log/messages.
Moet op server

waarschijnlijk heb je het over een andere linux distro
ik heb geen meldingen gevonden in /var/log/messages

in /var/log/messages zie je de PAM-meldingen
Mijn syslog.conf:
*.info /var/log/messages

Mijn fout dat ik "op de server" noemde.
Eigenlijk moet die gebruikt worden waar van pam_ldap
gebruik wordt gemaakt.

[Marinus]

Post by Marinus
Hoe kun je nu nog extra een check uitvoeren waarbij je kunt constateren
dat de gebruiker vanaf de client is ingelogd op de server en dat de
authorisatie concreet / geslaagd is. Normaal kun je bv met who, who -u,
users, checken wie er ingelogd is en eventueel met een cat
/var/log/auth.log.
M.v.g.,
Marinus

n.a.v. deze url
http://www.debuntu.org/ldap-server-and-linux-ldap-clients

heb ik geprobeerd om ldap-authorisatie van een client te realiseren op
een debian5 server.

enige aanpassingen gedaan natuurlijk m.b.t. Default / Base
$DEFAULT_MAIL_DOMAIN = "m31galaxy.nl";
$DEFAULT_BASE = "dc=m31galaxy,dc=nl";

Waar het mis is gegaan is bij het punt
Then export the values:
# ./migrate_group.pl /etc/group ~/group.ldif
# ./migrate_passwd.pl /etc/passwd ~/passwd.ldif

de (perl)scripts werken niet naar behoren om de bestanden te maken in
/etc/group.ldif en /etc/passwd.ldif

dus heb ik ze zelf maar gemaakt (aangepast naar eigen situatie)
dn: ou=People, dc=m31galaxy, dc=nl
ou: People
objectclass: organizationalUnit

dn: ou=Group, dc=m31galaxy, dc=nl
ou: Group
objectclass: organizationalUnit

ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/people_group.ldif
gaat goed zonder foutmeldingen

maar deze 2 gaan fout.
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/passwd.ldif

vanwege een syntaxfout

vandaar dat het niet goed lukt om aan te melden op de ldapserver

omdat die laatste 2 scripts niet goed werken met het converteren heb ik
gewoon de inhoud van /etc/group en /etc/passwd gewoon gekopieerd en een
group.ldif en passwd.ldif gemaakt door ze te copieren met cat, echter
die vlieger gaat niet op helaas.

M.v.g.,
Marinus

www.m31galaxy.nl

[Richard Lucassen]

On Wed, 07 Jul 2010 13:44:33 +0200

Post by Marinus
maar deze 2 gaan fout.
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/passwd.ldif

En als je alle ldif files aan elkaar cat, en in 1 keer aan slapadd
voert, gaat het dan wel goed?
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
On Wed, 07 Jul 2010 13:44:33 +0200

Post by Marinus
maar deze 2 gaan fout.
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/passwd.ldif

En als je alle ldif files aan elkaar cat, en in 1 keer aan slapadd
voert, gaat het dan wel goed?

hoe zou zo'n commando eruit moeten zien dan?
( want mijn ervaring met unix / linux commando's is (nog) niet groot.)


wat ik wel geprobeerd heb is:

pico /etc/ldap/schema/people.ldif
-----------------------------
dn: ou=People,dc=m31galaxy,dc=nl
objectclass: top
objectclass: organizationalUnit
ou: People

ldapadd -x -D "cn=admin,dc=m31galaxy,dc=nl" -W -f people.ldif -c

hierbij kreeg ik geen foutmeldingen, er werd dus netjes om een ww
gevraagd en daarna werd er een entry toegevoegd.


en i.p.v. passw.ldif heb een ik individuele gebruiker aangemaakt:
-----------------------------------------------------------------
pico /etc/ldap/schema/jdoe.ldif
---------------------------
dn: cn=John Doe,ou=People,dc=m31galaxy,dc=nl
objectclass: inetOrgPerson
cn: John Doe
givenname: John
sn: Doe
mail: ***@m31galaxy.nl

toen het w.w. op onderstaande manier toegevoegd.

echo -n "userPassword: " >> jdoe.ldif
slappasswd >> jdoe.ldif

ldapadd -x -D "cn=admin,dc=m31galaxy,dc=nl" -W -f jdoe.ldif -c

ging ook prima. je zou zeggen dat dan het converteren van het bestand
/etc/passwd naar passwd.ldif niet meer nodig is, immers het w.w. is op
bovenstaande manier voor gebruiker jdoe is aanwezig in het bestand
jdoe.ldif op volgende manier:
{SSHA}vMp4mXjW4VfdGzU+XzQxxxxxjo2Vok

(bovengenoemd wijze is afkomstig van FreeBSD)
echter , deze manier bleek toch niet te werken helaas.

het zit'm dus in de syntax van passwd.ldif en group.ldif
en die is dus anders dan de inhoud van /etc/passwd en /etc/group

Misschien kan iemand van jullie mij een voorbeeld geven over hoe die
syntax van de passwd.ldif en group.ldif eruit moet zien want normaal
gesproken zouden die bestanden gemaakt moeten worden door die
migrationtools (perlscripts) en dan kan ik wellicht aanpassen op de
manier die voor mijn domein van toepassing is.

M.v.g.,
Marinus

[Bas Janssen]

Post by Marinus

Post by Richard Lucassen
On Wed, 07 Jul 2010 13:44:33 +0200

Post by Marinus
maar deze 2 gaan fout.
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/passwd.ldif

En als je alle ldif files aan elkaar cat, en in 1 keer aan slapadd
voert, gaat het dan wel goed?

hoe zou zo'n commando eruit moeten zien dan?
( want mijn ervaring met unix / linux commando's is (nog) niet groot.)
pico /etc/ldap/schema/people.ldif
-----------------------------
dn: ou=People,dc=m31galaxy,dc=nl
objectclass: top
objectclass: organizationalUnit
ou: People
ldapadd -x -D "cn=admin,dc=m31galaxy,dc=nl" -W -f people.ldif -c
hierbij kreeg ik geen foutmeldingen, er werd dus netjes om een ww
gevraagd en daarna werd er een entry toegevoegd.
-----------------------------------------------------------------
pico /etc/ldap/schema/jdoe.ldif
---------------------------
dn: cn=John Doe,ou=People,dc=m31galaxy,dc=nl
objectclass: inetOrgPerson
cn: John Doe
givenname: John
sn: Doe
toen het w.w. op onderstaande manier toegevoegd.
echo -n "userPassword: " >> jdoe.ldif
slappasswd >> jdoe.ldif
ldapadd -x -D "cn=admin,dc=m31galaxy,dc=nl" -W -f jdoe.ldif -c
ging ook prima. je zou zeggen dat dan het converteren van het bestand
/etc/passwd naar passwd.ldif niet meer nodig is, immers het w.w. is op
bovenstaande manier voor gebruiker jdoe is aanwezig in het bestand
{SSHA}vMp4mXjW4VfdGzU+XzQxxxxxjo2Vok
(bovengenoemd wijze is afkomstig van FreeBSD)
echter , deze manier bleek toch niet te werken helaas.
het zit'm dus in de syntax van passwd.ldif en group.ldif
en die is dus anders dan de inhoud van /etc/passwd en /etc/group
Misschien kan iemand van jullie mij een voorbeeld geven over hoe die
syntax van de passwd.ldif en group.ldif eruit moet zien want normaal
gesproken zouden die bestanden gemaakt moeten worden door die
migrationtools (perlscripts) en dan kan ik wellicht aanpassen op de
manier die voor mijn domein van toepassing is.

Deze misschien eens proberen?

http://freshmeat.net/projects/yap2lc/

[m@rinu$]

On 07/08/2010 03:59 PM, Bas Janssen wrote:
~
~

Post by Bas Janssen
Deze misschien eens proberen?
http://freshmeat.net/projects/yap2lc/

bedankt voor de link, heb het net gedownload en benieuwd of het de
gewenste resultaat zal opleveren.

M.v.g.,
Marinus

[richard lucassen]

On Thu, 08 Jul 2010 16:37:40 +0200

Post by ***@rinu$

Post by Bas Janssen
Deze misschien eens proberen?
http://freshmeat.net/projects/yap2lc/

bedankt voor de link, heb het net gedownload en benieuwd of het de
gewenste resultaat zal opleveren.

En nu je toch bezig bent op een Debian systeem:

apt-get install gq

Maar dan moet je wel een grafische interface hebben. Gebruik geen
versie hoger dan 1.06, die crasht heel soms, maar als je liever een gq
gebruikt die 3 keer per minuut een segfault heeft neem dan gq hoger dan
1.06 ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Paul van der Vlis]

Post by richard lucassen
On Thu, 08 Jul 2010 16:37:40 +0200

Post by ***@rinu$

Post by Bas Janssen
Deze misschien eens proberen?
http://freshmeat.net/projects/yap2lc/

bedankt voor de link, heb het net gedownload en benieuwd of het de
gewenste resultaat zal opleveren.

apt-get install gq
Maar dan moet je wel een grafische interface hebben. Gebruik geen
versie hoger dan 1.06, die crasht heel soms, maar als je liever een gq
gebruikt die 3 keer per minuut een segfault heeft neem dan gq hoger dan
1.06 ;-)

gq zit helemaal niet meer in Debian stable, testing of backports.

Wel in unstable en oldstable overigens, maar dat gebruikt Marinus vast niet!

Met vriendelijke groet,
Paul van der Vlis.

[richard lucassen]

On Fri, 09 Jul 2010 10:21:36 +0200

Post by Paul van der Vlis
gq zit helemaal niet meer in Debian stable, testing of backports.
Wel in unstable en oldstable overigens, maar dat gebruikt Marinus vast niet!

Ja. Lees m'n fijne bugreport maar. Volgens mij is-ie daar ook uit
verdwenen. Maar zet even de deb-src in de sources.list op de etch of de
sarge repository (let op: sinds een week of twee zit etch op
archive.debian.org) en dan:

apt-get update
cd /tmp
apt-get -b source gq
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Paul van der Vlis

Post by richard lucassen
On Thu, 08 Jul 2010 16:37:40 +0200

Post by ***@rinu$

Post by Bas Janssen
Deze misschien eens proberen?
http://freshmeat.net/projects/yap2lc/

bedankt voor de link, heb het net gedownload en benieuwd of het de
gewenste resultaat zal opleveren.

apt-get install gq
Maar dan moet je wel een grafische interface hebben. Gebruik geen
versie hoger dan 1.06, die crasht heel soms, maar als je liever een gq
gebruikt die 3 keer per minuut een segfault heeft neem dan gq hoger dan
1.06 ;-)

gq zit helemaal niet meer in Debian stable, testing of backports.
Wel in unstable en oldstable overigens, maar dat gebruikt Marinus vast niet!

klopt, gebruik ik niet, stable dus.

Post by Paul van der Vlis
Met vriendelijke groet,
Paul van der Vlis.

[Marinus]

Post by Bas Janssen
Deze misschien eens proberen?
http://freshmeat.net/projects/yap2lc/

ik heb het geinstalleerd en uitgeprobeerd. Echter , mijn voorkeur gaat
uit naar de packages van Debian zelf. Dit i.v.m. upgrades /
systeemonderhoud. Losse packages brengen mij teveel extra werk met zich mee.

Heb dus nieuwe installatie gedaan van ldapserver en de migrationtools
gebruikt. Deze keer ging het goed met de files /etc/passwd en /etc/group
naar *.ldif formaat

alsnog bedankt voor het meedenken / reactie

Groet,
Marinus

[Paul van der Vlis]

Post by Marinus

Post by Richard Lucassen
On Wed, 07 Jul 2010 13:44:33 +0200

Post by Marinus
maar deze 2 gaan fout.
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f ~/passwd.ldif

En als je alle ldif files aan elkaar cat, en in 1 keer aan slapadd
voert, gaat het dan wel goed?

hoe zou zo'n commando eruit moeten zien dan?
( want mijn ervaring met unix / linux commando's is (nog) niet groot.)

Ik denk dat Richard zoiets bedoeld:

cat group.ldif > alles.ldif
cat passwd.ldig >> alles.ldif
(...)

Zodat alles bijelkaar komt in 1 groot bestand.

Met vriendelijke groet,
Paul van der Vlis.

[richard lucassen]

On Thu, 08 Jul 2010 17:48:38 +0200

Post by Paul van der Vlis
cat group.ldif > alles.ldif
cat passwd.ldig >> alles.ldif
(...)
Zodat alles bijelkaar komt in 1 groot bestand.

cat file1 file2 file3 file4 > outputfile

Ik weet niet zeker of je hiermee genomineerd kan worden voor "The
Useless Use Of Cat" Award ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Marinus
Goedemiddag allen,

Vanmiddag nieuwe installatie uitgevoerd van openldap-server van
Debian-packages zelf waarbij de migrationtools ook zijn geinstalleerd
en daarvan gebruik gemaakt. Deze keer ging het goed met het converteren
van de /etc/passwd, /etc/group naar *.ldif formaat.

cd /usr/share/migrationtools/

nano migrate_common.ph
-----------------------
DEFAULT_MAIL_DOMAIN = "m31galaxy.nl";
DEFAULT_BASE = "dc=m31galaxy,dc=nl";

daarna:

nano /etc/xxxx/xxxx/nodes.ldif
---------------------
and paste in the following

dn: ou=People, dc=m31galaxy, dc=nl
ou: People
objectclass: organizationalUnit

dn: ou=Group, dc=m31galaxy, dc=nl
ou: Group
objectclass: organizationalUnit

./migrate_group.pl /etc/group /etc/xxxx/xxxx/group.ldif

Post by Marinus
dn: cn=marinus,ou=Group,dc=m31galaxy,dc=nl
objectClass: posixGroup
objectClass: top
cn: marinus
userPassword: {crypt}x
gidNumber: 1xxx
dn: cn=test1,ou=Group,dc=m31galaxy,dc=nl
objectClass: posixGroup
objectClass: top
cn: test1
userPassword: {crypt}x
gidNumber: 1xxx
dn: cn=test2,ou=Group,dc=m31galaxy,dc=nl
objectClass: posixGroup
objectClass: top
cn: test2
userPassword: {crypt}x
gidNumber: 1xxx

./migrate_group.pl /etc/passwd /etc/xxxx/xxxx/passwd.ldif

Post by Marinus
dn: cn=marinus,ou=Group,dc=m31galaxy,dc=nl
objectClass: posixGroup
objectClass: top
cn: marinus
userPassword: {crypt}x
gidNumber: 1xxx
memberUid: 1xxx

vervolgens:
-----------

ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f /etc/xxx/xxxx/nodes.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f /etc/xxx/xxxx/group.ldif
ldapadd -x -W -D "cn=admin,dc=m31galaxy,dc=nl" -f /etc/xxx/xxxx/passwd.ldif


herstart van ldapserver
herstart van client

ik kreeg daarna de gnome inlogscherm waarbij ik 2x een ww moest invullen
waaronder ook ww voor ldapserver wat bij mijn eerste pogingen niet het
geval was

dat kwam omdat er bij de client ldapconfiguratie met pam iets niet goed
geconfigureerd was, n.l.,

nano /etc/pam.d/common-account
deze 2 regels over het hoofd gezien
account sufficient pam_ldap.so
account required pam_unix.so

nano /etc/pam.d/common-password
alsmede deze regel
password sufficient pam_ldap.so


kreeg daarna met netstat -n | less ook te zien dat poort 389 verbonden
stond met server / client.



M.v.g.,
Marinus


http://www.m31galaxy.nl

[Richard Lucassen]

On Mon, 12 Jul 2010 14:51:30 +0200

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop

en dan inloggen als root op een tweede tty, gaat dat dan nog?
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[m@rinu$]

Post by Richard Lucassen
On Mon, 12 Jul 2010 14:51:30 +0200

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop
en dan inloggen als root op een tweede tty, gaat dat dan nog?

nee dus.

als het inloggen niet mogelijk is (op de ldapserver) gaat het pam
mechanisme waarschijnlijk gewoon over op lokaal inloggen op de ubuntu
werkstation (met gnome) omdat er geen connectie gemaakt kan worden met
de server.

hier nog een stuk van /var/log/ldaplogs van de ldapserver toen ik zelf
inlogde vanaf ubuntu werkstation op de server
--------------------------------------------------------------
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 fd=15 ACCEPT from
IP=192.168.100.119:43015 (IP=0.0.0.0:389)
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=0 BIND dn="" method=128
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=0 RESULT tag=97 err=0 text=
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=1 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=marinus))"
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=2 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=posixGroup)(memberUid=marinus))"
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=2 SRCH attr=gidNumber

daarna:
/etc/init.d/slapd stop

en weer vanaf het werkstation met root proberen in te loggen

M.v.g.,
Marinus

[m@rinu$]

Post by ***@rinu$

Post by Richard Lucassen
On Mon, 12 Jul 2010 14:51:30 +0200

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop
en dan inloggen als root op een tweede tty, gaat dat dan nog?

nee dus.
als het inloggen niet mogelijk is (op de ldapserver) gaat het pam
mechanisme waarschijnlijk gewoon over op lokaal inloggen op de ubuntu
werkstation (met gnome) omdat er geen connectie gemaakt kan worden met
de server.
hier nog een stuk van /var/log/ldaplogs van de ldapserver toen ik zelf
inlogde vanaf ubuntu werkstation op de server
--------------------------------------------------------------
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 fd=15 ACCEPT from
IP=192.168.100.119:43015 (IP=0.0.0.0:389)
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=0 BIND dn="" method=128
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=0 RESULT tag=97 err=0 text=
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=1 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=posixAccount)(uid=marinus))"
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=1 SEARCH RESULT tag=101
err=0 nentries=0 text=
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=2 SRCH
base="dc=m31galaxy,dc=nl" scope=2 deref=0
filter="(&(objectClass=posixGroup)(memberUid=marinus))"
Jul 13 08:31:39 srv55 slapd[2278]: conn=17 op=2 SRCH attr=gidNumber
/etc/init.d/slapd stop
en weer vanaf het werkstation met root proberen in te loggen
M.v.g.,
Marinus

Trouwens ik heb nog een vraag m.b.t. de group id
en user id

op mijn werkstation had ik dus al een aantal gebruikers gemaakt die elk
hun eigen bovengenoemde id's hebben. Maar als ik dezelfde gebruikers ook
aanmaak op de server dan hebben ze niet dezelfde user id en group id die
overeenkomen op het werkstation.

hoe zit dat dan met inloggen op de ldapserver met de gebruikers van het
werkstation op de server m.b.t. de id's ?

b.v. ik het gebruiker test1 en test2 later aangemaakt op de server dan
op het werkstation, dus , de bovengenoemde id's zullen verschillen.

M.v.g.,
Marinus

[Richard Lucassen]

On Tue, 13 Jul 2010 10:10:21 +0200

Post by ***@rinu$
Trouwens ik heb nog een vraag m.b.t. de group id
en user id
op mijn werkstation had ik dus al een aantal gebruikers gemaakt die
elk hun eigen bovengenoemde id's hebben. Maar als ik dezelfde
gebruikers ook aanmaak op de server dan hebben ze niet dezelfde user
id en group id die overeenkomen op het werkstation.
hoe zit dat dan met inloggen op de ldapserver met de gebruikers van
het werkstation op de server m.b.t. de id's ?
b.v. ik het gebruiker test1 en test2 later aangemaakt op de server
dan op het werkstation, dus , de bovengenoemde id's zullen
verschillen.

De user-id's zul je overal gelijk moeten houden, dat zou tegen het
centrale beheer ingaan. Met "vipw" kun je je paswordfile editten en de
id's veranderen (wees voorzichtig). Daarna de homedirs opnieuw chownen:

cd /home
chown -R user1.user1 user1/

Anders zie je zoiets:

drwxr-sr-x 5 user2 group2 4096 Jul 29 2007 user1
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
On Tue, 13 Jul 2010 10:10:21 +0200

Post by ***@rinu$
Trouwens ik heb nog een vraag m.b.t. de group id
en user id
op mijn werkstation had ik dus al een aantal gebruikers gemaakt die
elk hun eigen bovengenoemde id's hebben. Maar als ik dezelfde
gebruikers ook aanmaak op de server dan hebben ze niet dezelfde user
id en group id die overeenkomen op het werkstation.
hoe zit dat dan met inloggen op de ldapserver met de gebruikers van
het werkstation op de server m.b.t. de id's ?
b.v. ik het gebruiker test1 en test2 later aangemaakt op de server
dan op het werkstation, dus , de bovengenoemde id's zullen
verschillen.

De user-id's zul je overal gelijk moeten houden, dat zou tegen het
centrale beheer ingaan. Met "vipw" kun je je paswordfile editten en de
id's veranderen (wees voorzichtig).

inderdaad , anders is inloggen niet meer mogelijk.

Post by Richard Lucassen
cd /home
chown -R user1.user1 user1/
drwxr-sr-x 5 user2 group2 4096 Jul 29 2007 user1

duidelijk

handiger zou zijn om daarvoor een script te hebben die dat voor je kan
doen. je zou maar te maken hebben met een bedrijf waar 100 en meer
mensen werken.

met het aanmaken van nieuwe users op de ldapserver kun je in principe
toch bepalen welke user-id en group-id ze krijgen, als je dan weet welke
id's ze hebben gekregen, dan maak je toch op de werkstion(s) ook de
nieuwe users aan met dezelfde user en group-id

dat zou je dus op meerder werkstations moeten doen indien je wilt dat je
werknemers/huisgenoten op meerdere werkstations moeten kunnen inloggen.
(Roaming)


M.v.g.,
Marinus

[Richard Lucassen]

On Tue, 13 Jul 2010 11:23:54 +0200

Post by Marinus
handiger zou zijn om daarvoor een script te hebben die dat voor je
kan doen. je zou maar te maken hebben met een bedrijf waar 100 en
meer mensen werken.

uiteraard

Post by Marinus
met het aanmaken van nieuwe users op de ldapserver kun je in principe
toch bepalen welke user-id en group-id ze krijgen, als je dan weet
welke id's ze hebben gekregen, dan maak je toch op de werkstion(s)
ook de nieuwe users aan met dezelfde user en group-id
dat zou je dus op meerder werkstations moeten doen indien je wilt dat
je werknemers/huisgenoten op meerdere werkstations moeten kunnen
inloggen. (Roaming)

Er is ook nog een module die automagisch de juiste homedir aanmaakt op
het moment dat een user voor de eerste keer inlogt. Geen idee hoe dat
ook alweer gaat, maar een jaar of wat terug kon je dat ook ergens in de
pam.d dir aangeven.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
On Tue, 13 Jul 2010 11:23:54 +0200

Post by Marinus
handiger zou zijn om daarvoor een script te hebben die dat voor je
kan doen. je zou maar te maken hebben met een bedrijf waar 100 en
meer mensen werken.

uiteraard

Post by Marinus
met het aanmaken van nieuwe users op de ldapserver kun je in principe
toch bepalen welke user-id en group-id ze krijgen, als je dan weet
welke id's ze hebben gekregen, dan maak je toch op de werkstion(s)
ook de nieuwe users aan met dezelfde user en group-id
dat zou je dus op meerder werkstations moeten doen indien je wilt dat
je werknemers/huisgenoten op meerdere werkstations moeten kunnen
inloggen. (Roaming)

Er is ook nog een module die automagisch de juiste homedir aanmaakt op
het moment dat een user voor de eerste keer inlogt. Geen idee hoe dat
ook alweer gaat, maar een jaar of wat terug kon je dat ook ergens in de
pam.d dir aangeven.

ik ga het verder uitzoeken met ldap wat betreft de mogelijkheden etc

m'n eerstvolgende project(en) is/zijn om nfs-server / samba en openldap
samen te laten werken. nfs-server draaid inmiddels al en de mounts zijn
al vanaf de client bereikbaar. Nu nog die /etc/ldap/schema/nfs.ldif
o.i.d. bewerken

Bedankt voor je reactie's / support tot dusver.



M.v.g.
Marinus



http://www.m31galaxy.nl

[Richard Lucassen]

On Tue, 13 Jul 2010 17:15:27 +0200

Post by Marinus
ik ga het verder uitzoeken met ldap wat betreft de mogelijkheden etc
m'n eerstvolgende project(en) is/zijn om nfs-server / samba en
openldap samen te laten werken. nfs-server draaid inmiddels al en de
mounts zijn al vanaf de client bereikbaar. Nu nog
die /etc/ldap/schema/nfs.ldif o.i.d. bewerken

Er was destijds ook een project dat heette directory-administrator,
speciaal voor ldap gestuurde samba servers. En je hebt ook phpldapadmin
o.i.d. waar je ook dat soort fratsen mee uithaalde. Of het allemaal nog
bestaat weet ik niet en ik ben te druk/lui om te zoeken nu ;-)
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
Er was destijds ook een project dat heette directory-administrator,
speciaal voor ldap gestuurde samba servers.

ik hierover iets gevonden:
http://www.ldapadministrator.com/

En je hebt ook phpldapadmin

Post by Richard Lucassen
o.i.d. waar je ook dat soort fratsen mee uithaalde. Of het allemaal nog
bestaat weet ik niet en ik ben te druk/lui om te zoeken nu ;-)

die staat hier nu geinstalleerd, dat gemigreerde bestand group.ldif waar
ik moeite mee had om het om te zetten van /etc/group naar ldif formaat,
daarvan is te inhoud terug te vinden in phpldapadmin.

m.v.g.,
Marinus

[Marinus]

Post by Richard Lucassen
On Tue, 13 Jul 2010 17:15:27 +0200

Post by Marinus
ik ga het verder uitzoeken met ldap wat betreft de mogelijkheden etc
m'n eerstvolgende project(en) is/zijn om nfs-server / samba en
openldap samen te laten werken. nfs-server draaid inmiddels al en de
mounts zijn al vanaf de client bereikbaar. Nu nog
die /etc/ldap/schema/nfs.ldif o.i.d. bewerken

Er was destijds ook een project dat heette directory-administrator,
speciaal voor ldap gestuurde samba servers. En je hebt ook phpldapadmin
o.i.d. waar je ook dat soort fratsen mee uithaalde. Of het allemaal nog
bestaat weet ik niet en ik ben te druk/lui om te zoeken nu ;-)

ik heb hierover iets gevonden:
http://www.ldapadministrator.com/


phpldapadmin staat hier nu geinstalleerd, dat gemigreerde bestand
group.ldif waar ik moeite mee had om het om te zetten van /etc/group
naar ldif formaat, daarvan is te inhoud terug te vinden in phpldapadmin.

m.v.g.,
Marinus

[Joost de Heer]

Post by Richard Lucassen
Er is ook nog een module die automagisch de juiste homedir aanmaakt op
het moment dat een user voor de eerste keer inlogt. Geen idee hoe dat
ook alweer gaat, maar een jaar of wat terug kon je dat ook ergens in de
pam.d dir aangeven.

amd met homedirs op NFS?

[Richard Lucassen]

On Tue, 13 Jul 2010 18:47:23 +0200

Post by Joost de Heer

Post by Richard Lucassen
Er is ook nog een module die automagisch de juiste homedir aanmaakt
op het moment dat een user voor de eerste keer inlogt. Geen idee
hoe dat ook alweer gaat, maar een jaar of wat terug kon je dat ook
ergens in de pam.d dir aangeven.

amd met homedirs op NFS?

Het was een pam module IIRC. En of het nou over NFS was dat maakt
volgens mij niets uit. De module keek simpelweg of $HOME bestond en zo
niet dan kopieerde hij /etc/skel/ naar /home/$USER. Simpel ding, erg
handig destijds. Maar OTOH, het is alweer eeuwen geleden voor mij dus
wellicht is het allemaal anders tegenwoordig.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Richard Lucassen]

On Tue, 13 Jul 2010 10:02:41 +0200

Post by ***@rinu$

Post by Richard Lucassen

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop
en dan inloggen als root op een tweede tty, gaat dat dan nog?

nee dus.

Dat is ernstig vind ik. Maar het is alweer jaren terug dat ik daarmee
gespeeld heb, waarschijnlijk moet je nog een van de files in /etc/pam.d
moeten editten, ik zou je zo niet kunnen zeggen welke en wat daarin
moet.
R.
--
___________________________________________________________________
It is better to remain silent and be thought a fool, than to speak
aloud and remove all doubt.

+------------------------------------------------------------------+
| Richard Lucassen, Utrecht |
| Public key and email address: |
| http://www.lucassen.org/mail-pubkey.html |
+------------------------------------------------------------------+

[Marinus]

Post by Richard Lucassen
On Tue, 13 Jul 2010 10:02:41 +0200

Post by ***@rinu$

Post by Richard Lucassen

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop
en dan inloggen als root op een tweede tty, gaat dat dan nog?

nee dus.

Dat is ernstig vind ik. Maar het is alweer jaren terug dat ik daarmee
gespeeld heb,

was dat in de periode van debian etch of woody ?

waarschijnlijk moet je nog een van de files in /etc/pam.d

Post by Richard Lucassen
moeten editten, ik zou je zo niet kunnen zeggen welke en wat daarin
moet.
R.

oeps

na herstart van de ldapserver was het inloggen gewoon weer mogelijk dus.

ik moet nog maar es effetjes googlen m.b.t. pam.d en verder de man van
ldapserver bestuderen.

maar goed in tussentijd is er waarschijnlijk het een en ander veranderd
aan het inlogmechanisme van pam.d

ik zou het in ieder geval wel een logische zet vinden dat wanneer het
inloggen op de ldapserver niet lukt omdat het (tijdelijk) niet
bereikbaar is, dat je dan wel lokaal kunt inloggen op het werkstation.
anders zou je als bedrijf muurvast komen te zitten met je werknemers
omdat die niet meer kunnen inloggen op hun werkstation en hun werk dus
niet kunnen voortzetten.

M.v.g.,
Marinus

[Paul van der Vlis]

Post by Marinus
ik zou het in ieder geval wel een logische zet vinden dat wanneer het
inloggen op de ldapserver niet lukt omdat het (tijdelijk) niet
bereikbaar is, dat je dan wel lokaal kunt inloggen op het werkstation.
anders zou je als bedrijf muurvast komen te zitten met je werknemers
omdat die niet meer kunnen inloggen op hun werkstation en hun werk dus
niet kunnen voortzetten.

Verkeerde gedachte. Je komt juist hopeloos in de war als mensen ook
lokaal kunnen inloggen en dan weer andere userID's en groepsrechten
hebben. Verder wil je helemaal niet alle users ook lokaal aanmaken.

Als je meer veiligheid wilt als bedrijf, dan kun je een tweede LDAP
server neerzetten en die repliceren.

Wat je wel wilt, is dat root lokaal inlogt.

Met vriendelijke groet,
Paul van der Vlis.

[Marinus]

Post by Paul van der Vlis

Post by Marinus
ik zou het in ieder geval wel een logische zet vinden dat wanneer het
inloggen op de ldapserver niet lukt omdat het (tijdelijk) niet
bereikbaar is, dat je dan wel lokaal kunt inloggen op het werkstation.
anders zou je als bedrijf muurvast komen te zitten met je werknemers
omdat die niet meer kunnen inloggen op hun werkstation en hun werk dus
niet kunnen voortzetten.

Verkeerde gedachte. Je komt juist hopeloos in de war als mensen ook
lokaal kunnen inloggen en dan weer andere userID's en groepsrechten
hebben. Verder wil je helemaal niet alle users ook lokaal aanmaken.
Als je meer veiligheid wilt als bedrijf, dan kun je een tweede LDAP
server neerzetten en die repliceren.

inderdaad, heel logisch,

vergelijkbaar met pdc en bdc (uit vervlogen tijd van windows NT4 server)

Post by Paul van der Vlis
Wat je wel wilt, is dat root lokaal inlogt.

zeker weten.


M.v.g.,
Marinus

[Marinus]

Post by Richard Lucassen
On Tue, 13 Jul 2010 10:02:41 +0200

Post by ***@rinu$

Post by Richard Lucassen

Post by tjoen
account sufficient pam_ldap.so
account required pam_unix.so

/etc/init.d/slapd stop
en dan inloggen als root op een tweede tty, gaat dat dan nog?

nee dus.

Dat is ernstig vind ik. Maar het is alweer jaren terug dat ik daarmee
gespeeld heb, waarschijnlijk moet je nog een van de files in /etc/pam.d
moeten editten, ik zou je zo niet kunnen zeggen welke en wat daarin
moet.
R.

herstel, het is wel mogelijk om in te loggen op een 2e tty als root

M.v.g.,
Marinus