# [ldap]problèmes avec un ldap (résolu)

## 22decembre

Bonjour

J'essaye de monter un ldap.

Je suis la doc : http://www.gentoo.org/doc/en/ldap-howto.xml mais j'ai toujours un problème

```
17:54 root@einstein /var/lib/openldap-data # ldapsearch -D "cn=admin,dc=22decembre,dc=eu" -W

Enter LDAP Password: 

# extended LDIF

#

# LDAPv3

# base <dc=22decembre,dc=eu> (default) with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

# search result

search: 2

result: 32 No such object

# numResponses: 1

```

le slapd.conf :

```

#

# See slapd.conf(5) for details on configuration options.

# This file should NOT be world readable.

#

include         /etc/openldap/schema/core.schema

include         /etc/openldap/schema/automount.schema

include         /etc/openldap/schema/cosine.schema

include         /etc/openldap/schema/inetorgperson.schema

include         /etc/openldap/schema/nis.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory

# service AND an understanding of referrals.

#referral       ldap://root.openldap.org

pidfile         /var/run/openldap/slapd.pid

argsfile        /var/run/openldap/slapd.args

# Load dynamic backend modules:

modulepath      /usr/lib64/openldap/openldap

moduleload      back_hdb.so

# moduleload    back_shell.so

# moduleload    back_relay.so

# moduleload    back_perl.so

# moduleload    back_passwd.so

# moduleload    back_null.so

# moduleload    back_monitor.so

# moduleload    back_meta.so

# moduleload    back_ldap.so

# moduleload    back_dnssrv.so

# Sample security restrictions

#       Require integrity protection (prevent hijacking)

#       Require 112-bit (3DES or better) encryption for updates

#       Require 63-bit encryption for simple bind

# security ssf=1 update_ssf=112 simple_bind=64

access to dn.base="" by * read

access to dn.base="cn=Subschema" by * read

access to *

        by self write

        by users read

        by anonymous auth

#######################################################################

# BDB database definitions

#######################################################################

database        hdb

suffix          "dc=22decembre,dc=eu"

#         <kbyte> <min>

checkpoint      32      30

rootdn          "cn=admin,dc=22decembre,dc=eu"

# Cleartext passwords, especially for the rootdn, should

# be avoid.  See slappasswd(8) and slapd.conf(5) for details.

# Use of strong authentication encouraged.

#rootpw         secret

password-hash {md5}

rootpw          {MD5}RwEKPe9zN3cMD8UKf5yyaQ==

# The database directory MUST exist prior to running slapd AND

# should only be accessible by the slapd and slap tools.

# Mode 700 recommended.

directory       /var/lib/openldap-data

# Indices to maintain

index   objectClass     eq

```

la requete en mode debug :

```

17:47 root@einstein ~ # ldapsearch -d 255 -D "cn=admin,dc=22decembre,dc=eu" -W

ldap_create

Enter LDAP Password: 

ldap_sasl_bind

ldap_send_initial_request

ldap_new_connection 1 1 0

ldap_int_open_connection

ldap_connect_to_host: TCP einstein.22decembre.eu:389

ldap_new_socket: 3

ldap_prepare_socket: 3

ldap_connect_to_host: Trying 127.0.0.1:389

ldap_pvt_connect: fd: 3 tm: -1 async: 0

ldap_open_defconn: successful

ldap_send_server_request

ber_scanf fmt ({it) ber:

ber_dump: buf=0x7faeed856c20 ptr=0x7faeed856c20 end=0x7faeed856c50 len=48

  0000:  30 2e 02 01 01 60 29 02  01 03 04 1c 63 6e 3d 61   0....`).....cn=a  

  0010:  64 6d 69 6e 2c 64 63 3d  32 32 64 65 63 65 6d 62   dmin,dc=22decemb  

  0020:  72 65 2c 64 63 3d 65 75  80 06 4d 61 6e 67 6f 64   re,dc=eu..Mangod  

ber_scanf fmt ({i) ber:

ber_dump: buf=0x7faeed856c20 ptr=0x7faeed856c25 end=0x7faeed856c50 len=43

  0000:  60 29 02 01 03 04 1c 63  6e 3d 61 64 6d 69 6e 2c   `).....cn=admin,  

  0010:  64 63 3d 32 32 64 65 63  65 6d 62 72 65 2c 64 63   dc=22decembre,dc  

  0020:  3d 65 75 80 06 4d 61 6e  67 6f 64                  =eu..Mangod       

ber_flush2: 48 bytes to sd 3

  0000:  30 2e 02 01 01 60 29 02  01 03 04 1c 63 6e 3d 61   0....`).....cn=a  

  0010:  64 6d 69 6e 2c 64 63 3d  32 32 64 65 63 65 6d 62   dmin,dc=22decemb  

  0020:  72 65 2c 64 63 3d 65 75  80 06 4d 61 6e 67 6f 64   re,dc=eu..Mangod  

ldap_write: want=48, written=48

  0000:  30 2e 02 01 01 60 29 02  01 03 04 1c 63 6e 3d 61   0....`).....cn=a  

  0010:  64 6d 69 6e 2c 64 63 3d  32 32 64 65 63 65 6d 62   dmin,dc=22decemb  

  0020:  72 65 2c 64 63 3d 65 75  80 06 4d 61 6e 67 6f 64   re,dc=eu..Mangod  

ldap_result ld 0x7faeed84eb40 msgid 1

wait4msg ld 0x7faeed84eb40 msgid 1 (infinite timeout)

wait4msg continue ld 0x7faeed84eb40 msgid 1 all 1

** ld 0x7faeed84eb40 Connections:

* host: einstein.22decembre.eu  port: 389  (default)

  refcnt: 2  status: Connected

  last used: Sun Jul 24 17:48:07 2011

** ld 0x7faeed84eb40 Outstanding Requests:

 * msgid 1,  origid 1, status InProgress

   outstanding referrals 0, parent count 0

  ld 0x7faeed84eb40 request count 1 (abandoned 0)

** ld 0x7faeed84eb40 Response Queue:

   Empty

  ld 0x7faeed84eb40 response count 0

ldap_chkResponseList ld 0x7faeed84eb40 msgid 1 all 1

ldap_chkResponseList returns ld 0x7faeed84eb40 NULL

ldap_int_select

read1msg: ld 0x7faeed84eb40 msgid 1 all 1

ber_get_next

ldap_read: want=8, got=8

  0000:  30 0c 02 01 01 61 07 0a                            0....a..          

ldap_read: want=6, got=6

  0000:  01 00 04 00 04 00                                  ......            

ber_get_next: tag 0x30 len 12 contents:

ber_dump: buf=0x7faeed857fa0 ptr=0x7faeed857fa0 end=0x7faeed857fac len=12

  0000:  02 01 01 61 07 0a 01 00  04 00 04 00               ...a........      

read1msg: ld 0x7faeed84eb40 msgid 1 message type bind

ber_scanf fmt ({eAA) ber:

ber_dump: buf=0x7faeed857fa0 ptr=0x7faeed857fa3 end=0x7faeed857fac len=9

  0000:  61 07 0a 01 00 04 00 04  00                        a........         

read1msg: ld 0x7faeed84eb40 0 new referrals

read1msg:  mark request completed, ld 0x7faeed84eb40 msgid 1

request done: ld 0x7faeed84eb40 msgid 1

res_errno: 0, res_error: <>, res_matched: <>

ldap_free_request (origid 1, msgid 1)

ldap_parse_result

ber_scanf fmt ({iAA) ber:

ber_dump: buf=0x7faeed857fa0 ptr=0x7faeed857fa3 end=0x7faeed857fac len=9

  0000:  61 07 0a 01 00 04 00 04  00                        a........         

ber_scanf fmt (}) ber:

ber_dump: buf=0x7faeed857fa0 ptr=0x7faeed857fac end=0x7faeed857fac len=0

ldap_msgfree

# extended LDIF

#

# LDAPv3

# base <dc=22decembre,dc=eu> (default) with scope subtree

# filter: (objectclass=*)

# requesting: ALL

#

ldap_search_ext

put_filter: "(objectclass=*)"

put_filter: simple

put_simple_filter: "objectclass=*"

ldap_build_search_req ATTRS: *

ldap_send_initial_request

ldap_send_server_request

ber_scanf fmt ({it) ber:

ber_dump: buf=0x7faeed856c20 ptr=0x7faeed856c20 end=0x7faeed856c5a len=58

  0000:  30 38 02 01 02 63 33 04  13 64 63 3d 32 32 64 65   08...c3..dc=22de  

  0010:  63 65 6d 62 72 65 2c 64  63 3d 65 75 0a 01 02 0a   cembre,dc=eu....  

  0020:  01 00 02 01 00 02 01 00  01 01 00 87 0b 6f 62 6a   .............obj  

  0030:  65 63 74 63 6c 61 73 73  30 00                     ectclass0.        

ber_scanf fmt ({) ber:

ber_dump: buf=0x7faeed856c20 ptr=0x7faeed856c25 end=0x7faeed856c5a len=53

  0000:  63 33 04 13 64 63 3d 32  32 64 65 63 65 6d 62 72   c3..dc=22decembr  

  0010:  65 2c 64 63 3d 65 75 0a  01 02 0a 01 00 02 01 00   e,dc=eu.........  

  0020:  02 01 00 01 01 00 87 0b  6f 62 6a 65 63 74 63 6c   ........objectcl  

  0030:  61 73 73 30 00                                     ass0.             

ber_flush2: 58 bytes to sd 3

  0000:  30 38 02 01 02 63 33 04  13 64 63 3d 32 32 64 65   08...c3..dc=22de  

  0010:  63 65 6d 62 72 65 2c 64  63 3d 65 75 0a 01 02 0a   cembre,dc=eu....  

  0020:  01 00 02 01 00 02 01 00  01 01 00 87 0b 6f 62 6a   .............obj  

  0030:  65 63 74 63 6c 61 73 73  30 00                     ectclass0.        

ldap_write: want=58, written=58

  0000:  30 38 02 01 02 63 33 04  13 64 63 3d 32 32 64 65   08...c3..dc=22de  

  0010:  63 65 6d 62 72 65 2c 64  63 3d 65 75 0a 01 02 0a   cembre,dc=eu....  

  0020:  01 00 02 01 00 02 01 00  01 01 00 87 0b 6f 62 6a   .............obj  

  0030:  65 63 74 63 6c 61 73 73  30 00                     ectclass0.        

ldap_result ld 0x7faeed84eb40 msgid -1

wait4msg ld 0x7faeed84eb40 msgid -1 (infinite timeout)

wait4msg continue ld 0x7faeed84eb40 msgid -1 all 0

** ld 0x7faeed84eb40 Connections:

* host: einstein.22decembre.eu  port: 389  (default)

  refcnt: 2  status: Connected

  last used: Sun Jul 24 17:48:07 2011

** ld 0x7faeed84eb40 Outstanding Requests:

 * msgid 2,  origid 2, status InProgress

   outstanding referrals 0, parent count 0

  ld 0x7faeed84eb40 request count 1 (abandoned 0)

** ld 0x7faeed84eb40 Response Queue:

   Empty

  ld 0x7faeed84eb40 response count 0

ldap_chkResponseList ld 0x7faeed84eb40 msgid -1 all 0

ldap_chkResponseList returns ld 0x7faeed84eb40 NULL

ldap_int_select

read1msg: ld 0x7faeed84eb40 msgid -1 all 0

ber_get_next

ldap_read: want=8, got=8

  0000:  30 0c 02 01 02 65 07 0a                            0....e..          

ldap_read: want=6, got=6

  0000:  01 20 04 00 04 00                                  . ....            

ber_get_next: tag 0x30 len 12 contents:

ber_dump: buf=0x7faeed84ea90 ptr=0x7faeed84ea90 end=0x7faeed84ea9c len=12

  0000:  02 01 02 65 07 0a 01 20  04 00 04 00               ...e... ....      

read1msg: ld 0x7faeed84eb40 msgid 2 message type search-result

ber_scanf fmt ({eAA) ber:

ber_dump: buf=0x7faeed84ea90 ptr=0x7faeed84ea93 end=0x7faeed84ea9c len=9

  0000:  65 07 0a 01 20 04 00 04  00                        e... ....         

read1msg: ld 0x7faeed84eb40 0 new referrals

read1msg:  mark request completed, ld 0x7faeed84eb40 msgid 2

request done: ld 0x7faeed84eb40 msgid 2

res_errno: 32, res_error: <>, res_matched: <>

ldap_free_request (origid 2, msgid 2)

# search result

search: 2

ldap_parse_result

ber_scanf fmt ({iAA) ber:

ber_dump: buf=0x7faeed84ea90 ptr=0x7faeed84ea93 end=0x7faeed84ea9c len=9

  0000:  65 07 0a 01 20 04 00 04  00                        e... ....         

ber_scanf fmt (}) ber:

ber_dump: buf=0x7faeed84ea90 ptr=0x7faeed84ea9c end=0x7faeed84ea9c len=0

ldap_err2string

result: 32 No such object

ldap_msgfree

# numResponses: 1

ldap_free_connection 1 1

ldap_send_unbind

ber_flush2: 7 bytes to sd 3

  0000:  30 05 02 01 03 42 00                               0....B.           

ldap_write: want=7, written=7

  0000:  30 05 02 01 03 42 00                               0....B.           

ldap_free_connection: actually freed

```

Pour l'instant le serveur est vide, mais la doc laisse entendre qu'il devrait au moins renvoyer un truc positif.

----------

## guilc

Y a quoi exactement dans ce ldap, que donne un slapcat ?

Si c'est vraiment vide de chez vide (slapcat fait un dump complet de l'annuaire), c'est qu'il faut créer le domaine de base et les ou dedans avant d'espérer que ldapsearch retourne quoi que ce soit ! La réponse de ldapsearch ne me semble pas aberrante ici.

Dans ce cas, tu fais un petit fichier "ldif" de ce type :

```
dn: dc=22decembre,dc=eu

objectClass: top

objectClass: dcObject

objectClass: domain

dc: 22decembre

dn: ou=TonOU,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: TonOU
```

Et tu l'injecte dans ton ldap avec un slapadd -l tonfichier.ldif

[EDIT]

Tiens au passage : peux-tu mettre ton titre du topic en conformité avec les conventions de notre forum s'il te plait ? Merci  :Smile: 

----------

## 22decembre

Merci …

D'abord, la doc semble dire que même juste configuré mais vide, l'annuaire est sensé répondre … Or j'ai essayé plusieurs fois de faire des slapadd, sans succès, j'en ais déduit que cette étape foirait.

retour des commandes:

```
20:11 root@einstein ~ # slapcat

hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/openldap-data: (2).

Expect poor performance for suffix "dc=22decembre,dc=eu".

20:23 root@einstein ~ # nano in.ldf

20:24 root@einstein ~ # slapadd -l in.ldf 

hdb_db_open: database "dc=22decembre,dc=eu": database already in use.

backend_startup_one (type=hdb, suffix="dc=22decembre,dc=eu"): bi_db_open failed! (-1)

slap_startup failed

```

le in.ldif contient juste un copier-collé du tien…

C'est quoi ce DB_CONFIG ? Personne en parle dans aucun tuto … Serait-ce le problème ?

----------

## guilc

Non, pas desouci de DB_CONFIG, au pire il manque quelques optimisations (taille de cache, etc...), mais rien de fonctionellement impactant. Si tu veux regarder a quoi ca ressemble, je crois me souvenir qu'il y a un exemple (DB_CONFIG.example) dans le repertoire des data ldap.

Donc la, ton ldap est vraiment vide de chez vide. Meme pas la racine. Le resultat du ldapsearch me semble cohérent !

Avant de faire le slapadd, coupe le ldap. C'est une opération à faire à froid (en fait comme toutes les opérations slap*, par opposition aux ldap* qui fonctionnent à chaud).

Ensuite, une fois ta racine crée, ainsi que ta première OU, le résultat du ldapsearch devrait se modifier, et tu vas pouvoir commencer à peupler ton ldap. Mais pour le moment, je ne vois rien d'anormal !

----------

## 22decembre

Bon, j'ai fait les trucs en faisant bien le distingo en ligne/hors-ligne.

Mon annuaire se construit.

Je tente maintenant d'ajouter mes premiers utilisateurs (l'ajout a lieu vers le milieu) :

```
19:52 root@einstein ~ # slapcat 

dn: ou=utilisateurs,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: utilisateurs

description:: bWVtYnJlcyBkdSBkb21haW5lIDIyZGVjZW1icmUg

structuralObjectClass: organizationalUnit

entryUUID: b481f503-62a6-4a4d-a8a3-be9ffe67df44

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174029Z

entryCSN: 20110726174029.287096Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174029Z

dn: ou=groupes,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: groupes

description: groupes

structuralObjectClass: organizationalUnit

entryUUID: 295ec4b7-3da0-4c82-be2e-e88b4d083a6f

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174029Z

entryCSN: 20110726174029.329391Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174029Z

dn: ou=contacts,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: contacts

description: contacts et amis

structuralObjectClass: organizationalUnit

entryUUID: 2937fcff-5ac0-4518-aca2-bc97af403cbe

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174029Z

entryCSN: 20110726174029.336942Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174029Z

dn: ou=services,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: services

description: services

structuralObjectClass: organizationalUnit

entryUUID: 1d3b1d2d-f4c5-4eae-bbb1-ba402d565113

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174029Z

entryCSN: 20110726174029.337351Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174029Z

dn: ou=nfs,ou=services,dc=22decembre,dc=eu

objectClass: top

objectClass: organizationalUnit

ou: nfs

description: partages nfs

structuralObjectClass: organizationalUnit

entryUUID: 09bef0c8-be35-49cf-8fd1-ed5979a17699

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174029Z

entryCSN: 20110726174029.337736Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174029Z

dn: cn=distfiles,ou=nfs,ou=services,dc=22decembre,dc=eu

automountInformation: fstype=nfs,sync einstein:/mnt/distfiles

cn: distfiles

objectClass: top

objectClass: automount

structuralObjectClass: automount

entryUUID: 30632731-f459-49b8-b008-9ef82354e11f

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174040Z

entryCSN: 20110726174040.198982Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174040Z

dn: cn=portage,ou=nfs,ou=services,dc=22decembre,dc=eu

automountInformation: fstype=nfs,sync einstein:/mnt/portage

cn: portage

objectClass: top

objectClass: automount

structuralObjectClass: automount

entryUUID: bfc2fb92-8853-4016-9f4c-ef27f785150d

creatorsName: cn=admin,dc=22decembre,dc=eu

createTimestamp: 20110726174040Z

entryCSN: 20110726174040.210068Z#000000#000#000000

modifiersName: cn=admin,dc=22decembre,dc=eu

modifyTimestamp: 20110726174040Z

19:59 root@einstein ~ # ldapadd -v -D cn=admin,dc=22decembre,dc=eu -W -f user.ldif

ldap_initialize( <DEFAULT> )

Enter LDAP Password: 

add objectClass:

        top

        posixAccount

        person

        organizationalPerson

        inetOrgPerson

add uid:

        stephane

add cn:

        Stephane Guedon

add sn:

        Guedon

add givenName:

        Stephane

add uidNumber:

        1000

add gidNumber:

        1000

add homeDirectory:

        /home/partage/stephane

add loginShell:

        /bin/zsh

add userPassword:

        zoRaTanga

add mail:

        stephane@22decembre.eu

add c:

        France

add ou:

        stephane

adding new entry "uid=stephane, ou=utilisateurs, dc=22decembre, dc=eu"

ldap_add: Invalid syntax (21)

        additional info: objectClass: value #1 invalid per syntax

19:59 root@einstein ~
```

J'ai trouvé sur un site de doc que mon erreur en dernier vient avec des espaces à la fin des lignes. J'ai vérifié mon ldif avec un bon éditeur texte (kate) et pas d'espaces à la fin…

```

dn: uid=stephane, ou=utilisateurs, dc=22decembre, dc=eu

objectClass: top

objectClass: posixAccount

objectClass: person

objectClass: organizationalPerson

objectClass: inetOrgPerson

uid: stephane

cn: Stephane Guedon

sn: Guedon

givenName: Stephane

uidNumber: 1000

gidNumber: 1000

homeDirectory: /home/partage/stephane

loginShell: /bin/zsh

userPassword: zoRaTanga

mail: stephane@22decembre.eu

c: France

ou: stephane

```

----------

## 22decembre

J'arrive bien à faire fonctionner mon ldap. C'est bon.

Par contre, j'ai du mal à comprendre comment remplir correctement l'annuaire.

J'ai exporté mes comptes système avec les outils de padl. J'ai cru comprendre qu'un objet de l'annuaire pouvait être plusieurs choses à la fois (un compte système posix mais aussi une inetorgPerson) mais je n'arrive pas à faire cette concordance dans phpldapadmin. Comment faire cela ? Ou j'ai d'autres outils (dans kde?) plus efficaces pour administrer le ldap ?

----------

## 22decembre

J'ai réussi à monter le ldap. Mais je me rend compte que ce me sera peut-être inutile. EDIT : peut-être finalement …

Néanmoins, je fournis ici les trucs :

S'assurer que le repertoire du ldap (/var/lib/openldap-data) appartient bien à ldap, ainsi que les fichiers dedans.

Un objet ldap peut-être plusieurs choses à la fois, mais ne supporte par contre qu'une seule classe structurante.

On ne peut donc avoir un "account" (compte posix, shadow...) qui soit aussi une "person" (avec une adresse courriel...). C'est un peu soulant, mais c'est comme ça !

Mon problème maintenant, c'est que lorsque mon portable est hors-ligne, tout buggue dessus (alors que je n'ai voulu monter le ldap que pour fournir les noms de groupes et accounts posix et quelques autres infos.)

----------

## 22decembre

mon ldap marche impec et les requêtes aussi.

Seulement le problème, c'est qu'un des clients ldap est un portable.

Quand le portable boote, c'est le bordel parce que dbus demande le ldap... Bref. Et c'est pareil quand je suis hors-réseau ! Impossible de démarrer l'ordinateur.

Comment faire ? Je n'ais besoin du ldap que quand je suis dans mon réseau local ! Quand je suis en dehors du réseau, le ldap est injoignable, mais je n'en ai pas besoin.

----------

## geekounet

```
bind_policy soft
```

Ajoute ça à ton ldap.conf. Ça fera fail directement au premier échec de connexion au lieu de retry indéfiniment.

----------

## 22decembre

en mettant bind_policy à soft, je peux en effet booter.

Mais le ldap n'est alors pas interrogé !

mon ldap.conf (laptop) :

```
BASE    dc=22decembre,dc=eu

URI     ldap://einstein.22decembre.eu

host einstein.22decembre.eu

suffix          "dc=22decembre,dc=eu"

#SIZELIMIT      12

#TIMELIMIT      15

#DEREF          never

#timelimit 5

#bind_timelimit 5

pam_password exop

bind_policy soft

ldap_version 3

pam_filter objectclass=posixAccount

pam_login_attribute uid

pam_member_attribute memberuid

nss_base_passwd ou=utilisateurs,dc=22decembre,dc=eu

nss_base_shadow ou=utilisateurs,dc=22decembre,dc=eu

nss_base_group  ou=groups,dc=22decembre,dc=eu

scope one

```

mon nsswitch.conf (laptop) :

```
passwd:    files ldap

shadow:    files

group:     files ldap

```

J'ai essayé avec files et compat : même résultat !

----------

## 22decembre

Finalement, j'ai résolu le bug...

J'ai mis [unavail=continue] à group et passwd dans /etc/nsswitch et j'ai mis un nom d'hôte simplifié dans mon ldap.conf :

```
passwd:      compat ldap [unavail=continue]

group:       compat ldap [unavail=continue]

```

```
BASE    dc=22decembre,dc=eu

URI     ldap://einstein

host einstein

```

 et non pas le nom d'hôte complet y compris nom de domaine.

Mon analyse (mais j'en suis pas sur) est qu'en mettant un nom de domaine, j'indiquais à mon portable d'interroger le serveur via son ip publique (88.174.xxx.zzz). La requête "sortait" donc de mon lan, puis tentait d'entrer dans le serveur par l'exterieur, et ne pouvait entrer à cause du pare-feu.

La question est : pourquoi ne tentait-il pas d'interroger le serveur en ipv6 ? (mon lan est invisible en ipv6 puisque tous mes pc sont alors directement sur le réseau mondial. Mon pare-feu est réglé pour accepter les connections depuis mes adresses ipv6).

Mais c'est résolu.

----------

