Mais OpenLDAP est une base de données. Elle n'est pas compatible SQL, voilà tout.
Mais... Le truc super, c'est que les classes de base sont bien définies et ont peu bougé depuis des années, idem pour les protocoles réseau, ce qui donne un niveau d'interopérabilité incroyable sur des systèmes hétérogènes, comparativement à d'autres mécanismes plus souples.
Classes bien définies... mais pas forcément bien pratiques pour autant : on a par exemple des composants qui veulent du posixGroup/posixUser et d'autres du Group/inetOrgPerson, alors que les deux sont incompatibles. La solution est donc d'avoir les informations en doublon si tu veux vraiment tout baser sur LDAP.
D'autre part, plein de logiciels acceptent LDAP... mais sans donner beaucoup de possibilité pour configurer. Si tu as un LDAP qui n'est pas accessible anonymement en lecture et que tu ne fais que de l'authentification sans mot de passe (avec Kerberos), c'est possible mais presque personne ne prévoit ce cas.
[^] # Re: C'est vrai :)
Posté par flan (site web personnel) . En réponse au lien Travailler avec LDAP en 2022 : Un peu comme les bases de données, mais en moins pratique.... Évalué à 2. Dernière modification le 01 septembre 2022 à 08:53.
Mais OpenLDAP est une base de données. Elle n'est pas compatible SQL, voilà tout.
Classes bien définies... mais pas forcément bien pratiques pour autant : on a par exemple des composants qui veulent du posixGroup/posixUser et d'autres du Group/inetOrgPerson, alors que les deux sont incompatibles. La solution est donc d'avoir les informations en doublon si tu veux vraiment tout baser sur LDAP.
D'autre part, plein de logiciels acceptent LDAP... mais sans donner beaucoup de possibilité pour configurer. Si tu as un LDAP qui n'est pas accessible anonymement en lecture et que tu ne fais que de l'authentification sans mot de passe (avec Kerberos), c'est possible mais presque personne ne prévoit ce cas.