Gestion des utilisateurs avec LDAP/Active Directory

La création d'une connexion à un serveur compatible LDAP nécessite un utilisateur disposant d'une autorisation de lecture sur le serveur. Au minimum, il doit disposer d'une autorisation de lecture pour les personnes et les groupes qu'il doit synchroniser. Dans l'exemple suivant, cet utilisateur s'appelle check_mk.

Sous Setup > Users > LDAP & Active Directory > Add connection, une nouvelle connexion peut être créée. Dans le formulaire, saisissez d’abord l’IDe de votre choix pour la connexion dans la case « General Properties ». Un titre simple et significatif peut être saisi facultativement dans la case « Description ». Comme toujours, l’IDe doit être unique et ne peut pas être modifié ultérieurement. Il ne peut être composé que de lettres, de chiffres, de tirets et de traits de soulignement, et doit commencer par une lettre ou un trait de soulignement.

Ensuite, sous « LDAP Connection », vous pouvez définir le serveur LDAP, ainsi qu’un ou plusieurs serveurs de failover s’ils sont disponibles. Il ne reste alors plus qu’à sélectionner le « Directory type » et à définir les données utilisateur pour l’accès en lecture sous « Bind credentials ». Notez que le nom d’utilisateur doit être saisi avec son chemin d’accès LDAP complet. La distinction entre majuscules et minuscules n’a pas d’importance. La configuration devrait alors ressembler à ceci :

Checkmk prend en charge bien plus qu’Active Directory. Pour changer de répertoire, par exemple pour OpenLDAP, sélectionnez-le dans le champ « Directory type » — les modifications de configuration supplémentaires résultant de cette action n’affectent que quelques emplacements.

Les serveurs de secours sont utilisés lorsque le serveur principal n’est pas accessible ou lorsqu’un délai a été dépassé. Cela s’avère utile lorsqu’aucun serveur local n’est utilisé, mais qu’il est souhaitable de créer une connexion redondante.

La connexion de Checkmk au serveur LDAP est toujours maintenue jusqu’à ce que le serveur LDAP ne soit plus accessible en raison d’un timeout ou d’autres problèmes. Ce n’est qu’alors que le basculement vers le serveur de failover est effectué. Il en va de même après le basculement : La connexion ne reviendra vers le serveur actuellement configuré que si le serveur de failover devient indisponible.

Ensuite, les chemins d'accès aux utilisateurs et aux groupes seront définis, et les filtres configurés. Dans « User base DN », saisissez d'abord le chemin d'accès par lequel les utilisateurs doivent être trouvés. Assurez-vous ici que l'unité opérationnelle (OU) est configurée de manière à inclure tous les utilisateurs souhaités et le moins d'autres utilisateurs possible. Plus le nombre d'utilisateurs interrogés est élevé, plus la synchronisation sera lente à traiter.

Définissez ensuite l’option « Search scope ». Vous pouvez ici filtrer de manière récursive tous les utilisateurs situés dans l’OU et dans les unités qui lui sont subordonnées, ou limiter la recherche à ceux situés directement dans cette OU. Si vous avez saisi un utilisateur directement dans le chemin d’accès, vous devez sélectionner « Search only the entry at the base DN » — seul cet utilisateur sera alors inclus.

À l’aide de l’option « Search filter », vous pouvez affiner encore davantage la sélection des utilisateurs à importer. Si, par exemple, vous souhaitez synchroniser uniquement les utilisateurs appartenant à un groupe spécifique, définissez une requête LDAP comme indiqué dans la capture d’écran suivante. La condition préalable est que les utilisateurs possèdent l’attribut « memberof ». Vous trouverez ci-dessous comment filtrer par appartenance à un groupe, sans cet attribut.

Le filtre standard peut également être combiné avec l'attribut memberof ou avec d'autres filtres :

(&(objectclass=user)(objectcategory=person)(memberof=cn=cmk-admins,ou=groups,dc=mycompany,dc=org))

Comme le montre la case « Users », d’autres options sont disponibles pour la recherche d’utilisateurs. L’option « User-ID attribute » permet de spécifier l’attribut que l’utilisateur doit utiliser comme login dans Checkmk. L’utilisateur utilisera ensuite cet login lors de sa connexion. En règle générale, dans Active Directory, il s’agit de l’attribut « sAMAccountName », qui est utilisé par défaut dans Checkmk. Sous OpenLDAP, il s’agit souvent de l’attribut « uid ».

Les options Lower case User-IDs vous permettent de convertir les identifiants synchronisés en lettres minuscules. Cela peut s’avérer judicieux, car, comme déjà mentionné, Active Directory/LDAP ne fait pas la distinction entre les majuscules et les minuscules, contrairement à Checkmk. Cela peut entraîner une confusion que cette option permet de résoudre.

L'option Umlauts in User-IDs (deprecated) n'a été fournie que pour des raisons de compatibilité et ne devrait plus être utilisée ni modifiée.

Enfin, l'option « Create users only on login » vous permet de créer de nouveaux utilisateurs uniquement une fois qu'ils ont effectué le login sur Checkmk, plutôt que lors de la synchronisation avec LDAP.

L'option « Filter group » ne doit être utilisée que si le serveur LDAP n'est pas un Active Directory et que l'attribut dynamique « memberof » n'est pas disponible dans les données utilisateur. Dans de tels cas, le filtrage des utilisateurs s'effectue directement dans Checkmk. Au cours de ce processus, il est possible que de nombreux utilisateurs soient interrogés, puis écartés par la suite. Le module LDAP de Checkmk permet d'éviter en grande partie ce type de scénario.

Si vous devez toutefois recourir à cette option, le chemin d'accès complet du groupe à filtrer doit être saisi ici :

Si vous souhaitez filtrer les utilisateurs par groupe, définissez le chemin d’accès au groupe afin qu’une correspondance puisse être établie. Cela peut être effectué de la même manière que pour les utilisateurs : lorsqu’un groupe est spécifié directement, l’option « Search only the entry at the base DN » peut être utilisée sous « Search scope » ; sinon, la recherche sera effectuée soit directement dans l’unité organisationnelle (OU), soit en incluant également ses unités subordonnées.

Ici aussi, l’option Search filter permet de préciser comment le nom du groupe doit être défini dans Checkmk. Vous pouvez en outre spécifier le nom de l’attribut (Member attribute) dans lequel les membres du groupe sont enregistrés. Checkmk utilise par défaut member. Sous OpenLDAP, il peut également s’agir de uniqueMember. Modifiez l’option en conséquence.

La configuration initiale est désormais terminée. À des fins de diagnostic, vous pouvez maintenant enregistrer la configuration et la tester à l’aide du bouton « Save & test ».

Il n’est pas nécessaire de spécifier des groupes pour obtenir une configuration fonctionnelle. Toutefois, si l’unité d’organisation (OU) ne contient que des utilisateurs pour Checkmk, il est judicieux de restreindre la sélection à l’aide d’un ou plusieurs groupes.

Enfin, vous pouvez également définir la fréquence à laquelle les utilisateurs doivent être synchronisés automatiquement. Dans un environnement où les changements sont rares, la fréquence par défaut est peut-être trop élevée. Le délai ne doit toutefois pas être trop long, afin que tout changement puisse être pris en compte rapidement dans Checkmk.

Une synchronisation peut être lancée manuellement à tout moment dans Setup > Users > Users > Synchronize users. De plus, un utilisateur sera synchronisé si nécessaire lorsqu’il tentera de se connecter et n’aura pas encore été synchronisé.

Il n’est pas très utile de pouvoir créer automatiquement tous les utilisateurs s’il faut ensuite les attribuer manuellement à des groupes de contacts. Checkmk offre la possibilité d’utiliser les groupes du serveur LDAP pour permettre l’attribution à des groupes de contacts. Pour cela, activez l’option « Attribute sync plugins > Contactgroup Membership » :

Pour qu’une attribution soit réussie, le nom du groupe (cn) sur le serveur LDAP doit être identique à celui de Checkmk — c’est-à-dire que le groupe oracle_admins ne sera attribué à un utilisateur que s’il figure également dans le groupe oracle_admins sur LDAP. Si, au lieu de cela, il figure dans les groupes oracle-admins ou ORACLE_admins, l’attribution ne fonctionnera pas. Veillez donc à respecter la syntaxe correcte et à utiliser les majuscules et les minuscules de manière appropriée si des problèmes surviennent dans cette situation.

Les rôles peuvent également être attribués automatiquement de manière similaire, et la fonction « Groupes imbriqués » s’utilise ici de la même façon. Un ou plusieurs groupes peuvent être définis pour chaque rôle. Sélectionnez le rôle pour lequel une connexion doit être créée et saisissez le chemin d'accès complet vers le groupe. Par défaut, une recherche sera effectuée dans les groupes trouvés dans le filtre de groupes. D’autres connexions peuvent toutefois être recherchées afin d’utiliser les groupes qui s’y trouvent. Sélectionnez les connexions à rechercher dans la liste.

Avec les paramètres indiqués dans l'image ci-dessus, tous les utilisateurs du groupe désigné seront attribués au rôle « Administrator », à condition qu'ils soient également synchronisés par le filtre d'utilisateurs. Comme le montre la capture d'écran, vous pouvez également sélectionner vos propres rôles configurés et les associer à des groupes LDAP.

Pour la synchronisation d’autres informations utilisateur, il suffit en règle générale d’activer le plugin correspondant sous «Attribute Sync Plugins», et éventuellement de saisir l’attribut qui fournit ces informations. Vous trouverez ci-dessous un tableau répertoriant les plugins et les attributs utilisés (s’ils ne sont pas définis manuellement), ainsi qu’une brève description. Certains de ces attributs se trouvent également dans le menu «Utilisateur» d’un utilisateur.