Page History

Vous pouvez définir et utiliser plusieurs modules d'authentification sur l'interface de Visualisation

Vous pouvez définir et utiliser plusieurs modules d'authentification sur le Synchronizer, ce qui est très pratique si vous avez un serveur LDAP primaire et des secondaires.
Pour chaque essaie essai de connexion, les modules d'authentifications seront interrogés les uns à la suite des autres:

• Ceci permet par exemple de gérer l'indisponibilité du primaire.
• Le module suivant n'est interrogé que si le premier n'a pas répondu ou pas reconnu l'utilisateur.

define DEMON-TYPE {
    [...]
    module                   Module 1, Module 2, Module 3, auth-active-directory
    [...]
}

service shinken-synchronizer restart

#===============================================================================
# auth-active-directory
#===============================================================================
# Daemons that can load this module:
# - synchronizer
# Modules that can load this module:
# - WebUI
# This module allow to authentificate a user with an active directory server
#===============================================================================


define module {

# Shinken Enterprise. Lines added by import core. Do not remove it, it's used by Shinken Enterprise to update your objects if you re-import them.
    _SE_UUID             core-module-26a4fce25adc11e58014080027f08538
    _SE_UUID_HASH        f6daeb0b270c3d80e5649bf000991178
# End of Shinken Enterprise part

    #======== Module identity =========
    # Module name. Must be unique
    module_name     auth-active-directory-example

    # Module type (to load module code). Do not edit.
    module_type     ad_webui



    #======== Active Directory connection =========
    # ldap_uri:  uri to connect to your Active Directory server
    #  with the form:
    # - ldaps://myserver
    # - ldap://myserver
    #ldap_uri        ldaps://myserver

    # username: user to connect to the ldap(s) server
    # On active directory, this will be the userPrincipalName (the form is user@myserver.com)
    # On openldap, this will be the DN (the form is cn=user,dc=myserver,dc=com)
    username        user

    # password: to use to connect to the ldap(s) server
    password        password

    # basedn: DN top level to use for query users
    basedn          DC=google,DC=com

    # Connection mode:
    # - ad: active directory
    # - openldap: openldap. If you switch to this mode, you must configure the mapping (see option below.)
    mode            ad

    # File for additional configuration of the module behavior
    # By default, the module tries to auth a user using its ldap samaccountname and the matching contact (by contact name).
    # To change this behavior, put a working mapping file in your shinken-user directory.
    # You can copy the example at /etc/shinken-user-example/modules/auth-active-directory/mapping.json.
    # NEVER MODIFY OR USE EXAMPLES DIRECTLY as they will be overwritten without notice.
    #
    # mapping_file    /etc/shinken-user/configuration/modules/auth-active-directory/mapping.json

}  

   ...
  

Le module est présenté et paramétré par défaut pour être utilisé avec un Active Directory. Pour utiliser avec un serveur OpenLDAP ou un serveur supportant ce protocole ( Exemple : Oracle DSSE ), il faudra modifier les deux champs suivants :

• mode : il faut le mettre à la valeur "openldap". Cela change la recherche des utilisateurs qui a été optimisée pour fonctionner avec Active Directory ou OpenLDAP
• username : Avec Open LDAP, le format de ce champ est l'identifiant unique ( Distinguished Names ) sous la forme suivante : "cn=user,dc=mydomain,dc=com".

  ...
  # File for additional configuration of the module behavior
  # By default, the module tries to auth a user using its LDAP samaccountname and the matching contact (by contact name).
  # To change this behavior, put a working mapping file in your shinken-user directory.
  # You can copy the example at /etc/shinken-user-example/modules/auth-active-directory/mapping.json
  # NEVER MODIFY OR USE EXAMPLES DIRECTLY as they will be overwritten without notice.
  #
  # mapping_file /etc/shinken-user/configuration/modules/auth-active-directory/mapping.json
  ...

Les fichiers présents dans "/etc/shinken-user-example/ " sont en lecture seule. Il faut rajouter les droits en écriture après la copie dans "/etc/shinken-user/".

Les fichiers présents dans "/etc/shinken-user-example/ " sont en lecture seule. Il faut rajouter les droits en écriture après la copie dans "/etc/shinken-user/".

Image Added

define synchronizer {

    #[ ... ]
    modules             ad
Cfg_password, synchronizer-module-database-backup
     #[ File for additional configuration of the module behavior
    # By default, the module tries to auth a user using its ldap samaccountname and the matching contact (by contact name).
    # To change this behavior, put a working mapping file in your shinken-user directory.
    # You can copy the example at /etc/shinken-user-example/modules/auth-active-directory/mapping.json.
    # NEVER MODIFY OR USE EXAMPLES DIRECTLY as they will be overwritten without notice.
    #
    # mapping_file    /etc/shinken-user/configuration/modules/auth-active-directory/mapping.json

}


... ]
}

/etc/init.d/shinken-synchronizer restart

La présence simultanée des modules Cfg_password et auth-active-directory peut provoquer un fonctionnement non anticipé. Comme le module Cfg_password vérifie les mots de passe dans la base Shinken et le module auth-active-directory  dans LDAP, si les 2 modules sont chargés, l'utilisateur pourra se connecter avec les 2 mots de passe ( Shinken et LDAP ).

Si ce comportement est souhaité, il est possible d'avoir les 2 modules dans la configuration.
Les modules sont alors utilisés dans l'ordre défini dans le fichier CFG ( ici d'abord le module auth-active-directory puis le Cfg_password ) :

• Si le premier module identifie l'utilisateur, alors le processus d'identification s’arrête.
• Sinon, il essaye avec le suivant.

La présence simultanée des modules Cfg_password et auth-active-directory peut provoquer un fonctionnement non anticipé. Comme le module Cfg_password vérifie les mots de passe dans la base Shinken et le module auth-active-directory dans LDAP, si les 2 modules sont chargés, l'utilisateur pourra se connecter avec les 2 mots de passe ( Shinken et LDAP ).

Si ce comportement est souhaité, il est possible d'avoir les 2 modules dans la configuration. Les modules sont alors utilisés dans l'ordre défini dans le fichier CFG ( ici d'abord le module auth-active-directory puis le Cfg_password ) :

modules		auth-active-directory, Cfg_password, autres_modules_eventuels