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 ?
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 :
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.
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
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 :
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
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
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é.
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…
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.