La source collecteur Active Directory permet d’interroger un serveur Active Directory afin de récupérer toutes les informations disponibles.
Une fois ces informations récupérées, la source va définir les hôtes ou groupes d'hôte, utilisateurs ou groupes d'utilisateurs Shinken qui seront proposés au Synchronizer.
La source fonctionne de la manière suivante :
Vous pourrez utiliser les mappings par défaut ou définir les vôtres.
Un mapping est une correspondance entre un attribut LDAP et une propriété ou une donnée. |
Vous pouvez définir vos propres règles.
Les modèles sont ajoutés si les champs collectés sur le serveur Active Directory correspondent aux critères d'activation d'une règle.
Une fois les informations du serveur Active Directory récupérées, la source va proposer au Synchronizer :
Vous trouverez la procédure de mise en place et de configuration dans la page suivante Module de source de type ldap-import ( pour Active Directory )
Lorsque vous aurez mis en place votre propre source en suivant la procédure décrite dans la page Module de source de type ldap-import ( pour Active Directory ), vous devrez configurer les fichiers suivants ( le chemin variera en fonction du répertoire que vous avez choisi ) :
| Property | Value | Description |
|---|---|---|
| not_stored_properties | < liste de champs > | Ce paramètre permet de définir un ou plusieurs champs qui ne seront pas importés dans shinken. Cela peut être utile pour exclure une propriété ou bien utiliser des champs personnalisés utiles pour la gestion de vos fichiers .cfg |
| connection_configuration_file | /etc/shinken-user/source-data/source-data-active-directory-sample/_configuration/active-directory-connection.json | Connexion LDAP Information de connexion à l'annuaire LDAP. |
| mapping_configuration_file | /etc/shinken-user/source-data/source-data-active-directory-sample/_configuration/active-directory-mapping.json | Règles de mapping |
| rules_configuration_file | /etc/shinken-user/source-data/source-data-active-directory-sample/_configuration/active-directory-rules.json | Règles de configuration |
| Veuillez donc tout d'abord modifier le fichier active-directory-connection.json : |
| Propriété | Défaut | Obligatoire | Description |
|---|---|---|---|
| url | OUI | Adresse de votre serveur Active Directory | |
| ldap_protocol | 3 | OUI | Version du protocole LDAP ( par défaut à 3 si pas spécifié ) |
| base | OUI | OU ( Organisation Unit ) base pour la découverte de vos objets | |
| username | OUI | Utilisateur utilisé pour la connexion au serveur Active Directory | |
| password | OUI | Mot de passe utilisé pour la connexion au serveur Active Directory | |
| hosts_base | OU ( Organisation Unit ) base pour la découverte de vos hôtes. Si ce paramètre est absent ou vide, aucun hôte ne sera découvert. | ||
| hosts_filter | (|(objectClass=device)(objectClass=computer)) | Filtre au format ldap utilisé pour découvrir uniquement certains hôtes. | |
| hosts_filter_with_group | Permets de ne filtrer que les hôtes présents dans des groupes définis. | ||
| contacts_base | OU (Organisation Unit) base pour la découverte de vos contacts. Si ce paramètre est absent ou vide, aucun contact ne sera découvert. | ||
| contacts_filter | (|(objectClass=InetOrgPerson)(objectClass=user)) | Filtre au format ldap utilisé pour découvrir uniquement certains contacts. | |
| contacts_filter_with_group | Permets de ne filtrer que les contacts présents dans des groupes définis. | ||
| hostgroups_base | OU ( Organisation Unit ) base pour la découverte de vos groupes d'hôtes. Si ce paramètre est absent ou vide, aucun groupe d'hôte ne sera découvert. | ||
| hostgroups_filter | (|(objectclass=group) | Filtre au format ldap utilisé pour découvrir uniquement certains groupes d'hôtes. | |
| contactgroups_base | OU ( Organisation Unit ) base pour la découverte de vos groupes de contacts. Si ce paramètre est absent ou vide, aucun groupe de contacts ne sera découvert. | ||
| contactgroups_filter | (|(objectclass=group) | Filtre au format ldap utilisé pour découvrir uniquement certains groupes de contacts. |
Si vous ne souhaitez pas importer d'objets Active Directory "computer" et donc de ne pas créer d'hôte en "nouveau" dans Shinken, vous pouvez ne pas définir la propriété hosts_base ou bien la laisser vide. |
{
# Mandatory
"url": "ldap://192.168.1.240",
"ldap_protocol":3,
"base": "dc=shinkendom,dc=local",
"username": "shinkendom/administrateur",
"password": "P@ssword1",
# Optionnal
"hosts_base": "OU=Serveurs,dc=shinkendom,dc=local",
"hosts_filter": "(|(objectClass=device)(objectClass=computer))",
"hosts_filter_with_group":"",
"contacts_base": "OU=Users,dc=shinkendom,dc=local",
"contacts_filter": "(|(objectClass=InetOrgPerson)(objectClass=user))",
"contacts_filter_with_group": "",
"hostgroups_base": "OU=Serveurs,dc=shinkendom,dc=local",
"hostgroups_filter": "(|(objectclass=group)(objectclass=groupofnames)(objectclass=groupofuniquenames))",
"contactgroups_base": "OU=Users,dc=shinkendom,dc=local",
"contactgroups_filter": "(|(objectClass=groupOfUniqueNames)(objectClass=groupOfNames)(objectClass=posixGroup))"
} |
Le compte utilisé pour envoyer des requêtes LDAP au serveur n'a besoin que d'un accès en "lecture seule". Vous devriez créer un compte de service Active Directory dédié à cet accès Shinken. |
Il est possible que l'utilisateur ldap utilisé soit soumis à certaines limites ( nombre d'entrées, délai, taille ... ). Si cette limite est rencontrée, aucun objet ne sera importé. |
Il est possible de faire correspondre certaines propriétés Active Directory avec des propriétés ou données d'un élément Shinken. Il existe un "mapping" par défaut pour Active Directory, mais il est possible de personnaliser les correspondances.
Si besoin ( facultatif ), modifiez le fichier active-directory-mapping.json
Chaque ligne de ce fichier définit une correspondance entre une propriété ou donnée Shinken avec une propriété LDAP. Les paramètres peuvent donc être nombreux.
Par exemple la ligne suivante définit une correspondance entre le nom de l'hôte dans Shinken et sa propriété dans LDAP:
"host.host_name": "name", |
Elle est définie par :
Si ce format n'est pas respecté, l'import se déroulera sans cette ligne et un message d'avertissement vous indiquera qu'il y a une erreur de syntaxe |
Il vous est donc possible de faire correspondre les propriétés ldap avec les propriétés shinken de votre choix. Si vous ne définissez pas ce fichier, un mapping par défaut sera utilisé. Voici ses valeurs.
| Propriété Shinken | Propriété Active Directory | Description |
|---|---|---|
| host.host_name | name | La propriété ldap "name" sera utilisée pour le nom des hôtes |
| host.display_name | sAMAccountName | La propriété ldap "sAMAccountName" sera utilisée pour la description des hôtes |
| host.address | ipHostNumber | La propriété ldap "ipHostNumber" sera utilisée pour l'adresse des hôtes |
| hostgroup.hostgroup_name | cn | La propriété ldap "cn" ( CommonName ) sera utilisée pour le nom des groupes d'hôtes |
| contact.contact_name | name | La propriété ldap "name" sera utilisée pour le nom des contacts |
| contact.email | La propriété ldap "mail" sera utilisée comme adresse mail du contact | |
| contact.display_name | displayName | La propriété ldap "displayName" sera utilisée comme description du contact |
| contact._PHONE | telephoneNumber | La propriété ldap "telephoneNumber" sera conservée dans la donnée _PHONE du contact |
| contact._MOBILE | mobile | La propriété ldap "mobile" sera conservée dans la donnée _MOBILE du contact |
| contact._COUNTRY | co | La propriété ldap "co" ( Country ) sera conservée dans la donnée _COUNTRY du contact |
| contact._CITY | l | La propriété ldap "l" ( localityName ) sera conservée dans la donnée _CITY du contact |
| contact._COMPANY | company | La propriété ldap "company" sera conservée dans la donnée _COMPANY du contact |
| contactgroup.contactgroup_name | cn | La propriété ldap "cn" ( CommonName ) sera utilisée pour le nom des groupes d'hôtes |
Si vous ne souhaitez pas importer les propriétés par défaut, vous devez définir un fichier de "mapping" avec la clé souhaitée et sa valeur à vide |
{
# You can map any ldap attribut in a Data (start with a _ and in MAJ)
# -- Hosts
# mandatory
"host.host_name": "name",
"host.display_name": "sAMAccountName",
"host.address": "ipHostNumber",
# -- Hostgroups
# mandatory
"hostgroup.hostgroup_name": "cn",
# -- Contacts
# mandatory
"contact.contact_name": "name",
"contact.email": "mail",
"contact.display_name":"displayName",
"contact._MEMBER": "uniqueMember",
"contact._PHONE":"telephoneNumber",
"contact._MOBILE":"mobile",
# Co: for country
"contact._COUNTRY":"co",
# l: for city
"contact._CITY":"l",
"contact._COMPANY":"company",
# -- Contactgroups
# mandatory
"contactgroup.contactgroup_name": "cn"
}
|
Pour des raisons de compatibilité avec les versions inférieures à la 02.06.03, les propriétés suivantes sont toujours fonctionnelles :
| Ancienne propriété | Nouvelle propriété Shinken correspondante | Description |
|---|---|---|
| host.name | host.host_name | Contient le nom de l'élément. |
| host.dNSHostName | host.address | L'adresse de l'élément. |
| host.operatingSystem | host._OS | Le système d'exploitation sera conservé dans une donnée de l'hôte |
| host.operatingSystemServicePack | host._OS_SP | Le service pack de du système d'exploitation sera conservé dans une donnée |
| host.distinguishedName | host.display_name | Le nom distingué de l'hôte correspondra à la description de l'hôte |
| contact.name | contact.contact_name | Contient le nom de l'utilisateur |
| contact.mail | contact.email | Contient l'adresse email de l'utilisateur |
| contact.displayName | contact.display_name | Contient la description de l'utilisateur |
| contact.telephoneNumber | contact._PHONE | Le numéro de téléphone de l'utilisateur sera conservé dans une donnée |
| contact.mobile | contact._MOBILE | Le numéro de mobile de l'utilisateur sera conservé dans une donnée |
| contact.co | contact._COUNTRY | Le pays de l'utilisateur sera conservé dans une donnée |
| contact.l | contact._CITY | La ville de l'utilisateur sera conservée dans une donnée |
| contact.company | contact._COMPANY | La société de l'utilisateur sera conservée dans une donnée |
| hostgroup.name | hostgroup.hostgroup_name | Contient le nom du groupe |
| contactgroup.name | contactgroup.contactgroup_name | Contient le nom du groupe |
| contact.member | contactgroup.members | Dans les précédentes versions, les groupes de contact n'étaient pas importés. Désormais ils le sont les et liens avec les utilisateurs sont conservés |
Les filtres sur les types d'éléments étaient présents dans le fichier de mapping : "host.filter", "contact.filter", "hostgroup.filter" et "contactgroup.filter". Ceux-ci doivent désormais se trouver dans le fichier de connexion sous les noms : "hosts_filter", "contacts_filter", "hostgroups_filter" et "contactsgroups_filter".
|
Les paramètres "contact.classFilter" et "contact.categoryFilter" sont dépréciés et seront supprimés dans une version ultérieure. Veuillez utiliser le paramètre contacts_filter du fichier de connexion pour remplacer ce filtre. Exemple : "contacts_filter" : "(objectClass=InetOrgPerson)" |
Ce fichier est utilisé pour appliquer des modèles d'hôtes et des modèles d'utilisateurs sur les hôtes et utilisateurs durant l'import, provenant d'OU ciblées.
Ce fichier permet également de filtrer les utilisateurs à importer dans Shinken en se basant sur les membres d'un ou de plusieurs groupes d'utilisateurs de l'annuaire Active Directory ciblé.
| Veuillez donc enfin modifier le fichier active-directory-rules.json Attention, la modification de ce fichier est obligatoire, car certaines propriétés contenant des chemins Active Directory ne permettront pas un import valide si elles ne sont pas modifiées. |
Les règles doivent être définies dans le fichier "rules", encadré par des accolades "{ ... }". Il est possible de définir plusieurs types de règles..
Il est possible d'ajouter un même modèle sur tous les hôtes ou contacts importés par la source. Par exemple pour ajouter le modèle "ldap-host" à tous les hôtes et le modèle "ldap-user" à tous les contacts, il faut configurer les lignes suivantes :
"hosts_template": "ldap-host", "contacts_template": "ldap-user" |
Il est possible d'ajouter un modèle pour tous les hôtes ou contacts qui sont dans une OU spécifique. Par exemple pour ajouter le modèle d'hôte WindowsServer à tous les hôtes présent dans l'OU "ou=WindowsServer,ou=Datacenter,dc=shinkendom,dc=local", et le modèle "Bordeaux" à tous les contacts présents dans l'OU "ou=Users,ou=Bordeaux,ou=Datacenter,dc=shinkendom,dc=local", il faut configurer les lignes suivantes :
"hosts_template_WindowsServer": "ou=WindowsServer,ou=Datacenter,dc=shinkendom,dc=local", "contacts_template_ldapAdmins": "ou=Users,ou=Bordeaux,ou=Datacenter,dc=shinkendom,dc=local" |
Il est possible d'ajouter des modèles sur des éléments dont une propriété correspond à une valeur définie.
Cette règle est divisée en 5 parties : un préfixe, un modèle, type d'élément, le nom de la propriété, la valeur de la propriété.
Voici un exemple et son explication :
exemple : "AddLast_template_(France)_to_contact_matching_[_COUNTRY]": "France" explication : | Préfixe |modèle| type d'élément |propriété| valeur | |
Pour ajouter un modèle sur un élément présent dans un groupe, il faut utiliser la règle précédente avec la propriété memberOf.
Dans LDAP, il est possible qu'un objet possède plusieurs fois la même propriété. Dans ce cas, il est possible de mettre en place des règles sur ces propriétés. Par exemple, on considère un objet qui a plusieurs propriétés "l" (location) (un utilisateur qui travaille à plusieurs endroits par exemple). On peut alors mettre en place la règle suivante:
Cette règle est activée lorsque l'utilisateur possède une de ses propriétés "l" qui est égale à "Bordeaux". Dans ce cas, le modèle d'utilisateur "bordeaux" est utilisé pour cet utilisateur. |
Dans cet exemple nous allons ligne par ligne :
{
"hosts_template": "linux",
"hosts_template_centos": "OU=centos,OU=serveurs,dc=shinken,dc=local",
"AddLast_template_(Datacenter_01_Bordeaux)_to_host_matching_[location]": "FRBXDC01",
"contacts_template": "generic-contact",
"AddFirst_template_(domain-admins)_to_contact_matching_[memberOf]": "cn=Domain Admins,ou=Users,dc=shinken,dc=local",
}
|
Pour ne définir aucune règle, vous pouvez créer un fichier vide avec seulement les accolades ouvrantes et fermantes ou ne pas préciser de fichier dans la définition de la source. |
Pour importer des objets, allez sur la page d'accueil de l'UI de configuration, si votre configuration est bonne, vous devriez avoir un message "OK: la source LDAP a été correctement chargée."
Maintenant, faîtes un "Forcer l'import" en cliquant sur 
Dans le panneau "Elements >" vous verrez les nouveaux éléments apparaître (Hôtes et Contacts).
|
La prochaine étape sera alors d'importer ces nouveaux éléments dans Shinken.
| Dans le fichier active-directory-connection.json |
Modifiez le paramètre hosts_filter
"hosts_filter": "(&(objectClass=computer)(sAMAccountName=*SERVER_NAME*))", |
Changez SERVER_NAME par le nom de serveur vous voulez importer.
Avec la source Active Directory, il est donc possible d'importer des utilisateurs de la base contacts_base spécifiée dans le fichier active-directory-connection.json mais on peut aussi les filtrer afin de n'importer que ceux qui sont dans un ou plusieurs groupes différents de l'annuaire LDAP.
Dans le fichier active-directory-connection.json |
Dans contacts_filter_with_group, ajouter le Distinguished Name (DN) des différents groupes d'utilisateurs séparés par un pipe ("|")
"contacts_filter_with_group": "CN=shinken_admins,OU=utilisateurs,DC=shinkendom,DC=local | CN=shinken_users,OU=utilisateurs,DC=shinkendom,DC=local", |
Cette source inclut également d'autres paramètres qui permettent d'appliquer des modèles automatiquement suivant le type d'objets :
Il est également possible d'ajouter un modèle sur les hôtes sur leur OU ( Organization Unit ) en utilisant le paramètre hosts_template_*
Par exemple, si vous voulez ajouter le modèle exchange à tous les serveurs qui sont dans l'OU: OU=Email Collaboration Servers,OU=DataCenter Servers,DC=YOUR,dc=DOMAIN,dc=com, utilisez le paramètre suivant:
"hosts_template_exchange": "OU=Email Collaboration Servers,OU=DataCenter Servers,DC=YOUR,dc=DOMAIN,dc=com" |
Les clés de synchronisation sont des propriétés des objets utilisées pour les identifier dans les sources.
Le fonctionnement et l'utilité des clés de synchronisation sont décrits de manière plus détaillée dans la page de documentation dédiée: Précision technique sur le fonctionnement de l'import des sources.
Dans notre cas le nom de l'élément est automatiquement ajouté dans les clés de synchronization. Les clés supplémentaires suivantes sont ajoutées :