Pour éviter à d’autres de chercher, voici comment résoudre un problème de synchronisation SLAPD entre un LDAP master et ses slaves. Dans mon cas mon master était un Debian Lenny et j’avais 2 slaves en Lenny et tous mes autres slave en Wheezy. Des ajouts de machines ou d’utilisateurs étaient répliqués sur les Lenny mais pas sur les Wheezy.

Utilisez le bon loglevel

Dans mon cas, c’est ldapsync qui ne fonctionnait pas correctement, il faut donc mettre :

loglevel        16384

Attention que les niveau de logs peuvent d’additionner pour afficher plusieurs catégories de logs en même temps, pour avoir le 16384 et le 2, on notera 16386 par exemple. Voir la page man pour les différents logs.

Solution du problème de synchronisation SLAPD

Ma première solution a été de forcer une réplication. Pour cela il faut éteindre slapd sur un slave et supprimer le contenu de /var/lib/ldap/. Je vous conseille de faire un tgz avant juste au cas Mais tous les éléments du ldap n’était pas répliqué. Pour vérifier  rapidement, on peut compter les lignes et comparer la dernière entrée :

slapcat | wc -l

slapcat | tail -n 30

Après avoir cherché dans les logs /var/log/debug, j’ai remarqué ceci :

do_syncrepl: rid=173 rc -1 retrying (9 retries left)

Et plus loin ceci est retenté avec un nouveau code :

do_syncrepl: rid=173 rc 21 retrying (7 retries left)

Un élément bloque la synchronisation, il a fallut chercher lequel.

En s’attardant sur les logs, on peut y voir ceci :

slapd[22822]: syncrepl_message_to_entry: rid=173 DN: uid=user1,ou=namedAccount,o=test, UUID: 8a477882-f0e3-102d-9ca7-3b8502e11a
15

slapd[22822]: syncrepl_message_to_entry: rid=173 mods check (postalAddress: value #0 invalid per syntax)

Cela vient du faite que dans certains champs « postalAddress » du LDAP, un caractère non autorisé est apparu, il s’agit du backslash « \ ». Cela est apparu lorsque quelqu’un à faire un import de données MySQL sans vérifier cela.

Le fait que mes serveurs LDAP slave en Lenny n’aient pas eu de souci avec ce caractère vient des schémas utilisés. Ce sont des machines Lenny comme mon LDAP master, alors que les autres sont des Wheezy. Les schémas ont changés entre ces 2 versions…

TODO

Pour que ce problème ne se repose plus à l’avenir il faut :
– soit faire attention aux champs entrés qui ne doivent pas contenir ce \
– soit analyser les schémas de part et d’autres et modifier ceux des slaves en conséquence, mais cela peut prendre du temps.

L’article SLAPD problème de synchronisation entre master et slaves est apparu en premier sur Mon linux.

Pour cela, il est préférable que chaque membre de son équipe utilise son propre couple login/password pour se connecter aux serveurs Linux. De plus on pourra donner des droits différents par utilisateur ou groupe…

L’authentification LDAP se fait au moyen de service LDAP/PAM/NSSWITCH/SUDO.

Un moyen simple de donner accès à son équipe aux serveurs sans révéler le nom de passe est l’utilisation de clé SSH. Les clés SSH c’est pratique mais tout le monde ne les utilisent pas, et puis cela permet juste de donner le même droit à tout le monde si on l’associe au compte root.

Nous allons voir comment créer un environnent d’authentification multi-utilisateurs basé sur un LDAP existant. Nous utiliseront PAM, NSSWITCH et SUDO.

Contexte

Nous avons déjà un serveur contenant notre base de données LDAP. Nous l’utiliserons pour se connecter sur d’autres serveurs Linux. Dans mon cas, j’ai validé cette manipulation sous Debian Wheezy (7.4). Des points infos sont disposées pour Debian Lenny également.

Authentification avec un utilisateur LDAP

On installe des dépenses nécessaires :

#apt-get update
#apt-get install libnss-ldap libpam-ldap sudo

Voici les données d’exemples utilisées :

LDAP server URI: ldap://SERVER
Distinguished name of the search base: la base LDAP
LDAP version to use: 3
LDAP account for root: un utilisateur ayant des droits RO sur le LDAP
LDAP root account password:
Allow LDAP admin account to behave like local root? No
Does the LDAP database require login? No

On Vérifie que les données sont correctes :

#sed -e '/^[ ]*#/d' -e '/^$/d' /etc/libnss-ldap.conf
 base o=test,dc=local
 uri ldap://pdc
 ldap_version 3
 rootbinddn uid=replicant,ou=namedAccount,o=test,dc=local
#sed -e '/^[ ]*#/d' -e '/^$/d' /etc/pam_ldap.conf
 base o=test,dc=local
 uri ldap://ldap-for-proxy
 ldap_version 3
 pam_password crypt
#cat /etc/libnss-ldap.secret

On ajoute « ldap » au fichier /etc/nsswitch.conf :

passwd:         compat ldap
group:          compat ldap
shadow:         compat ldap

On modifie PAM :

#echo -e "#allow auth with pam_access\nauth\trequired\t\t\tpam_access.so" >> /etc/pam.d/common-auth

Remarque : étape supplémentaire pour Debian Lenny

Editer /etc/pam.d/common-auth :

auth        sufficient    pam_unix.so        nullok_secure
auth        sufficient    pam_ldap.so        use_first_pass
auth        required      pam_deny.so
#allow auth with pam_access
auth    required                        pam_access.so

Editer /etc/pam.d/common-account:

account     sufficient      pam_unix.so
account     sufficient      pam_ldap.so
account     required      pam_deny.so

Editer /etc/pam.d/common-password :

password    sufficient      pam_unix.so         nullok obscure md5
password    sufficient      pam_ldap.so
password    required      pam_deny.so

Editer /etc/pam.d/common-session :

session     required      pam_unix.so
session     required      pam_mkhomedir.so
session     optional      pam_ldap.so

Pour plus d’infos sur LDAP et Lenny, voici un article intéressant : OpenLDAP client on Debian lenny.

On configure les connexions autorisées pour PAM. Dans notre cas, le groupe « ict » peut se connecter sur le réseau (10.0.0.0/8) et en face de la machine (LOCAL). Pour l’utilisateur « adminlocal », il sert uniquement d’utilisateur de secours quand on est en face de la machine et que le LDAP n’est pas joignable.

vim /etc/security/access.conf
 #admin local autorisé uniquement en local
 + : adminlocal : LOCAL
 # groupe ict uniquement en interne
 + : ict : 10.0.0.0/8 LOCAL
 # root toujours autorisé
 -:ALL EXCEPT root :ALL

On ajoute cet utilisateur, on redémarre NSCD, on test et on attribue un mot de passe à cet utilisateur :

# adduser --home /tmp --no-create-home --ingroup users --shell /bin/bash --uid=30000 adminlocal

# /etc/init.d/nscd restart

#id testictgroup
 uid=91(testictgroup) gid=14(testictgroup) groups=07(ict),14(testictgroup)

#passwd adminlocal

Autorisation

Voici un cas simple : les utilisateurs du groupe « ict » et un utilisateur « adminlocal » ont tous accès à toutes les commandes root, sans avoir à taper leur mots de passe 2 fois. Ils se loggent sur le serveur et c’est parti à coup de « sudo commande » ou « sudo su » pour passer en shell root.

Mais l’on peut très bien créer des « rôles » opérateurs avec des droits customisés.

# visudo

On ajout à la fin :

#allow user adminlocal to do everything
adminlocal    ALL=(ALL:ALL) NOPASSWD: ALL

#allow group ict to do everything
%ict    ALL=(ALL:ALL) NOPASSWD: ALL

Remarque : sous Lenny pour ceux qui l’on encore, c’est cette syntaxe qui est à utiliser :

# allow user adminlocal to do everything
adminlocal      ALL=(ALL) NOPASSWD: ALL# allow group ict to do everything
%ict      ALL=(ALL) NOPASSWD: ALL

L’article Authentification LDAP centralisée sous Debian Wheezy est apparu en premier sur Mon linux.