Ldap limitations

fr
en

#1

Version française plus bas.

My YunoHost configuration

Hardware: x64 vps
Internet access: ethernet at home
**YunoHost version: **
yunohost: 3.2.2
yunohost-admin: 3.2.1
moulinette: 3.2.0
ssowat: 3.2.0
Have you personalized your yunohost with some specifics configurations or do you use only the yunohost cli/webadmin tool ? basic

Description of my problem

Hello,

I have to change some settings in OpenLdap configuration. Activate MembeOf and change olcSizeLimit.
Using this commands should be possible with root account.
ldapmodify -Y EXTERNAL -H ldapi:/// -f someFile.ldif
https://wiki.debian.org/LDAP/OpenLDAPSetup

But it is not. Command returns an error for insufficient credentials.
How to change this behavior ?


Configuration de mon YunoHost

Matériel: x64 vps
Accès Internet: ethernet à la maison
YunoHost version:
yunohost: 3.2.2
yunohost-admin: 3.2.1
moulinette: 3.2.0
ssowat: 3.2.0
As tu modifié ton yunohost avec des configuration spécifiques ou bien utilise tu uniquement la web administration et/ou la ligne de commande yunohost ? basique

Description de mon problème

Bonjour,

Je dois changer des paramètres dans la config de OpenLdap. Activer MembeOf et changer olcSizeLimit.
Utiliser cette commande devrait être possible avec le compte root…
ldapmodify -Y EXTERNAL -H ldapi:/// -f unFichier.ldif
https://wiki.debian.org/LDAP/OpenLDAPSetup

Mais ce n’est pas possible. La commande renvoie une erreur pour droits insuffisants…
Comment modifier ce comportement ?


#2

Hello,

To be clear in LDAP there are 2 database : the main database which contain all data related to yunohost (user, domain, etc) and the config database which contain all schema, ACL, overlay (like memberof).

You are not allowed to update the LDAP config database by this command in yunohost. The only way to update the config database and the schema is to use :

slapadd -n0 -l someFile.ldif

Or if you want tu update the main database you could also use :

ldapadd -h localhost -D "cn=admin,dc=yunohost,dc=org" -w YOUR_ADMIN_PASSWORD -b dc=yunohost,dc=org
or
ldapvi -h ldapi:/// -D "cn=admin,dc=yunohost,dc=org" -w YOUR_ADMIN_PASSWORD -d

Note that I’m working on an implementation of some new feature (user permission and group management) in Yunohost and I might do many change in LDAP. And probably I will enable the “memberOf” overlay.


#3

Hello,

and thanks for your help again. :slight_smile:

I created a simple ldif file

dn: cn=config
changetype: modify
replace: olcSizeLimit
olcSizeLimit: 1000

When using
slapadd -n0 -l myFile.ldif
I get this error :
str2entry: str2ad(changetype): attribute type undefined

I read I should use ldapadd but I have this error
ldapadd -h localhost -D “cn=admin,dc=yunohost,dc=org” -W -f sizelimit.ldif
Enter LDAP Password:
modifying entry “cn=config”
ldap_modify: Insufficient access (50)

Finally, ldapvi does not permit to change /etc/ldap/slapd.d/cn=config.ldif


#4

I think you should check your file myFile.ldif

It’s normal that ldapvi is not allowed to edit the config database.


#5

The file only contains these lines.


#6

Essaye simplement :

dn: cn=config
olcSizeLimit: 1000

#7

Cela donne :

slapadd -n0 -l sizelimit.ldif
slapadd: dn="cn=config" (line=1): no objectClass attribute
_#################### 100.00% eta   none elapsed            none fast!         
Closing DB...

Je continue à chercher de mon côté…


#8

Bon je pense que il te faut de diriger vers la sytaxe suivante que tu avait donné :

dn: cn=config
changetype: modify
replace: olcSizeLimit
olcSizeLimit: 1000

Dans tous les cas la seule commande qui pourrait fonctionner ca sera slap… (comme slapadd) qui permet de modifier directement la bd sans authentification. Toutes les commandes ldap… (comme ldapvi, ldapadd, etc) doivent avoir une authentification et comme tu peut le constater personne est autorisé à modifier cette bd. Voici un extrait de la bd config :

dn: olcDatabase={0}config,cn=config
objectClass: olcDatabaseConfig
olcDatabase: {0}config
olcAccess: {0}to *  by * none
olcAddContentAcl: TRUE
olcLastMod: TRUE
olcMaxDerefDepth: 15
olcReadOnly: FALSE
olcRootDN: cn=config
olcSyncUseSubentry: FALSE
olcMonitoring: FALSE
structuralObjectClass: olcDatabaseConfig

#9

Ça, ça ne marche pas.
Il y a deux problèmes.

  1. On ne peut pas modifier une entrée qui n’existe pas. Et olcSizeLimit n’est pas dans le fichier de conf
  2. J’ai lu qu’on ne pouvait pas créer ce type d’entrée avec un ldif et slapadd

#10

J’ai trouvé finalement une solution qui permet d’allouer les droit de modifier la config avec l’admin :

ATTENTION d’une modification très déconseillée et risquée !!

Editer le fichier /etc/ldap/slapd.d/cn\=config/olcDatabase\=\{0\}config.ldif et ajouter/modifier les ligne suivante :

...
olcDatabase: {0}config
olcAccess: {0}to * by dn.base="cn=admin,dc=yunohost,dc=org" write by dn.base="cn=admin,dc=yunohost,dc=org" read
olcAccess: {1}to *  by * none
olcAddContentAcl: TRUE
...

On modifie le olcAccess : {0}to * by * none à 1 et on ajoute la ligne :
olcAccess: {0}to * by dn.base="cn=admin...

On ajoute donc un accès de modification au user admin. Ensuite il suffit de faire “service slapd restart” pour que les modification soient prises en compte.

Ensuite tu doit être capable d’utiliser ldapadd ou ldapvi etc. pour la bd de config.

Je conseille d’autre part fortement de remettre le paramètre précédent une foi les modification effectuée


#11

Bonjour,

Modifier cela suppose de regénérer l’encodage CRC32.
Ça veut dire copier le contenu sans les deux premières lignes. Le passer à CRC32 pour avoir un nouveau code. Rajouter les deux premières lignes avec le nouveau code.
Ce fichier est sensé être modifié par ldapmodify et pas avec un éditeur de texte.

# AUTO-GENERATED FILE - DO NOT EDIT!! Use ldapmodify.
# CRC32 46a58fcf

#12

Oui je sais que on est pas sensé le faire. L’idée c’est ce modifier temporairement pour obtenir les droit et ensuite remettre la config initiale. Personnellement dans mon cas ca à fonctionné.


#13

C’est étrange que cela ait fonctionné car si le CRC32 n’est pas bon, ldap ne redémarre pas. J’avais procédé de cette manière pour modifier le ldif de config. Et ce n’est vraiment pas pratique.

Je ne comprend pas très bien pourquoi les commandes ldapmodify et ldapadd sont bloquées pour le compte root qui accède déjà au ldap d’une façon différente. Tant qu’à faire une modification « dangereuse », je préfèrerai faire celle qui remet en place ce fonctionnement standard. Je peux comprendre que ce soit verrouillé par défaut, afin d’éviter de graves accidents, mais on devrait pouvoir retrouver un mode classique d’administration si nécessaire.
Aucun des tutoriels que l’on trouve sur le web ne fait référence aux paramètres ni aux fichiers à modifier. À chaque fois il est supposé que l’on puisse utiliser ldapmodify et ldapadd par le compte root. Comme indiqué sur le Wiki de Debian.
https://wiki.debian.org/LDAP/OpenLDAPSetup

Pour le paramètre olcSizeLimit je peux faire comme précédemment. Avec jouglage de CRC32. Mais pour ajouter memberOf, ça a l’air plus complexe et nécessiter la modification de plus de fichiers.

Autoriser la modification à root me parait moins problématique que de l’autoriser au compte admin. C’est à discuter je pense… :slight_smile:


#14

Cela à du à simplement aux règles ACL définies. Comme dit précédement ici : Ldap limitations, il n’y a aucune règle qui autorise un quelconque utilisateur à faire une quelconque modification. Les commandes ldapmodify et ldapadd passent par le processus d’authentification qui implique l’application de tous les ACL. Je comprends que c’est une config qui n’est pas du tout judicieuse, peut être qu’il serait bien modifier cela un jours. Tous les tutoriels sur le web partent du principe qu’il y a certainement des ACL déférents que uniquement : to * by * none. C’est expliqué notamment ici : https://serverfault.com/questions/556629/unknown-ldap-cn-config-admin-password

Je pense que la solution ça serait d’ajouter une ligne dans ce style (a tester biensûr) :

olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external
  ,cn=auth manage by * break

Après pour memberOf, j’ai réussi avec slapadd ca marche très bien. Juste pas oublier de remettre les droit d’accès à l’utilisateur openldap pour le répertoir /etc/openldap, sinon slapd refuse de démarrer.