Gestion de la sécurité/utilisateur : Configurer la fonctionnalité de connexion PAM

Document created by RSA Information Design and Development on Feb 6, 2017
Version 1Show Document
  • View in full screen mode
  

Cette rubrique explique comment configurer Security Analytics pour utiliser les modules PAM (Pluggable Authentication Modules) afin d'authentifier les connexions d'utilisateurs externes.

La fonctionnalité de connexion PAM comporte deux composants distincts :

  • PAM pour l'authentification de l'utilisateur
  • NSS pour l'autorisation de groupe

S'ils sont associés, ils offrent aux utilisateurs externes la fonctionnalité de se connecter à Security Analytics sans avoir de compte Security Analytics interne, et de recevoir des autorisations ou des rôles déterminés en mappant le groupe externe vers un rôle de sécurité Security Analytics. Les deux composants sont requis pour qu'une connexion réussisse.

L'authentification externe est un paramètre au niveau du système. Avant de configurer PAM, examinez attentivement toutes les informations ici.

Modules PAM (Pluggable Authentication Module)

PAM est une bibliothèque fournie par Linux, responsable de l'authentification des utilisateurs auprès des fournisseurs d'authentification tels que Active Directory, RADIUS ou LDAP. Pour la mise en œuvre, chaque fournisseur d'authentification utilise son propre module, qui se présente sous la forme d'un paquet de système d'exploitation, tel que pam_ldap. Security Analytics utilise la bibliothèque PAM fournie par le SE et le module que la bibliothèque PAM a configuré pour utiliser et authentifier les utilisateurs.

Remarque : Le module PAM fournit uniquement la possibilité de s'authentifier.

Name Service Switch

NSS est une fonction Linux qui fournit les bases de données que le système d'exploitation et les applications utilisent pour découvrir des informations comme les noms d'hôtes ; les attributs d'utilisateur comme le répertoire personnel, le groupe principal et le shell de connexion ; et pour répertorier des utilisateurs qui appartiennent à un groupe donné. Semblable à PAM, NSS est configurable et utilise des modules afin d'interagir avec différents types de fournisseurs. Security Analytics utilise les fonctions NSS fournies par le système d'exploitation pour autoriser les utilisateurs PAM externes en recherchant si un utilisateur est connu sur NSS et en demandant ensuite depuis NSS les groupes dont l'utilisateur est membre. Security Analytics compare les résultats de la requête au mappage de groupe externe {{SA}} et si un groupe correspondant est trouvé, l'utilisateur obtient un accès pour se connecter à SA avec le niveau de sécurité défini dans le mappage de groupe externe.

Remarque : NSS ne fournit pas d'authentification.

Association de PAM et NSS

Les opérations de PAM (authentification) et NSS (autorisation) doivent réussir pour qu'un utilisateur externe soit autorisé à se connecter à Security Analytics. La procédure de configuration et de dépannage de PAM est différente de celle de NSS. Les exemples concernant PAM dans ce guide comprennent Kerberos, LDAP et RADIUS. Les exemples de NSS incluent Samba, LDAP et UNIX. L'association de modules PAM et NSS utilisée est déterminée par les besoins du site.

Remarque : Pour les services pré-10.4 qui utilisent des connexions non fiables, tous les utilisateurs PAM doivent également être configurés dans l'ensemble des services Security Analytics Core et PAM doit être configuré sur chaque hôte Core EL6.  Bien que ce document ne traite pas de la configuration de l'authentification et des utilisateurs PAM des services Core, tels que Decoder et Concentrator, les étapes de configuration du module PAM sont identiques, sauf que les services Security Analytics Core utilisent un autre fichier de configuration PAM, /etc/pam.d/netwitness.

Tour d’horizon du processus

Pour configurer la fonction de connexion PAM, suivez les instructions de ce document pour effectuer chaque étape :

  1. Configurer et tester le module PAM.
  2. Configurer et tester le service NSS.
  3. Activer PAM dans le serveur Security Analytics.
  4. Créer des mappages de groupes dans le serveur Security Analytics.

Conditions préalables

Cette fonctionnalité est uniquement disponible pour EL6 basé sur Security Analytics, version 10.4 ou ultérieure.

Avant de commencer la configuration de PAM, passez en revue la procédure et recueillez les détails du serveur d'authentification externe en fonction du module PAM que vous souhaitez mettre en œuvre.

Avant de commencer la configuration de NSS, passez en revue la procédure, identifiez les noms des groupes que vous allez utiliser dans le mappage de groupe externe, puis recueillez les détails du serveur d'authentification externe, selon le service NSS utilisé.

Si vous avez acheté un nouvel hôte avec Security Analytics 10.4 ou version ultérieure installé, les paquets rpm nécessaires pour Kerberos, LDAP, Radius et Samba sont installés par défaut.

Avant de commencer la configuration de PAM dans Security Analytics, identifiez les noms des groupes que vous allez utiliser dans le mappage de groupe externe. Lors du mappage des rôles, le rôle dans Security Analytics doit correspondre à un nom de groupe qui existe dans le serveur d'authentification externe.

Configurer et tester le module PAM

Choisissez l'une des sections suivantes pour installer et configurer le composant PAM :

  • PAM Kerberos
  • PAM LDAP
  • PAM Radius
  • SecurID

PAM Kerberos

Ports de communication Kerberos - TCP 88

Remarque : Si le serveur Security Analytics et Security Analytics Malware Analysis partagent le même serveur, lorsque vous configurez le Kerberos PAM, la configuration de Malware Analysis Samba (SMB) est désactivée.

Pour configurer l'authentification PAM avec Kerberos :

  1. Si vous avez effectué une mise à niveau vers Security Analytics 10.6, exécutez la commande suivante. Sinon, ignorez cette étape :
    yum --enablerepo=nwupdates install krb5-workstation pam_krb5  
  2. Modifiez les lignes suivantes dans le fichier de configuration Kerberos /etc/krb5.conf. Remplacez les variables, qui sont délimitées par des <crochets>, par vos valeurs et en omettant les crochets. La mise en majuscules est obligatoire aux emplacements indiqués.

    [libdefaults]
    default_realm = <DOMAIN.COM>
    dns_lookup_realm = true
    dns_lookup_kdc = true
    ticket_lifetime = 24h
    renew_lifetime = 7d
    forwardable = true

    [realms]
    <DOMAIN.COM> = {
    kdc = <SERVER.DOMAIN.COM>
    admin_server = <SERVER.DOMAIN.COM>
    }

    [domain_realm]
    <domain.com> = <DOMAIN.COM>
    <.domain.com> = <DOMAIN.COM>

    [appdefaults]
    pam = {
       debug = true    ticket_lifetime = 36000
        renew_lifetime = 36000
       forwardable = true
       krb4_convert = false
      }
  3. Testez la configuration Kerberos avec la commande : 
    kinit <user>@<DOMAIN.COM>
    S'il n'y a aucune sortie après la saisie du mot de passe, c'est que l'opération a réussi.
  4. Modifiez le fichier de configuration PAM du serveur Security Analytics /etc/pam.d/securityanalytics pour ajouter la ligne suivante. Si le fichier n'existe pas, créez-le et ajoutez la ligne suivante :
    auth sufficient pam_krb5.so no_user_check

Ceci termine la configuration de PAM Kerberos. Maintenant, passez à la section suivante, Configurer et tester le service NSS.

PAM LDAP

LDAP Communication Ports - TCP 389 or TCP 636 

TCP 389 peut être utilisé pour à la fois le trafic déchiffré et dans la plupart des cas, le trafic chiffré, ce qui suffit souvent. La plupart des implémentations LDAP modernes prennent en charge la commande start_tls lors de la connexion du port 389, qui met à niveau la connexion d'un état déchiffré en passant à l'état chiffré. Dans cette instance, les URI LDAP commencent toujours avec ldap:// même en utilisant start_tls.

TCP 636 est utilisé uniquement dans les instances où le serveur LDAP ne prend pas en charge la commande start_tls. Dans ce cas, les URI LDAP commencent par ldaps:// et la commande start_tls n'est pas utilisée.

Pour configurer l'authentification PAM avec LDAP :

  1. Si vous avez effectué une mise à niveau vers Security Analytics 10.6, exécutez la commande suivante. Sinon, ignorez cette étape :
    yum --enablerepo=nwupdates install openldap-clients
  2. Modifiez les fichiers de configuration LDAP, /etc/pam_ldap.conf et /etc/openldap/ldap.conf, comme indiqué dans les exemples suivants

Remarque : Les deux fichiers de configuration LDAP visent des objectifs différents. Le fichier pam_ldap.conf est utilisé par le module PAM uniquement. Le fichier openldap/ldap.conf est utilisé par les outils clients openldap, tels que ldapsearch, qui est utilisé pour résoudre les problèmes des communications LDAP de base. Remplacez les variables, qui sont délimitées par des <crochets>, par vos valeurs et en omettant les crochets. La mise en majuscules est obligatoire aux emplacements indiqués.

Exemple /etc/pam_ldap.conf d'entrées de fichier

base <dc=domain,dc=com>
uri ldap://<server.domain.com>
binddn <binduser@domain.com>
bindpw <secret>

nss_map_objectclass posixAccount user
nss_map_objectclass shadowAccount user
nss_map_attribute uid sAMAccountName
nss_map_attribute homeDirectory unixHomeDirectory
nss_map_attribute shadowLastChange pwdLastSet
nss_map_objectclass posixGroup group
nss_map_attribute uniqueMember member
pam_login_attribute sAMAccountName
pam_filter objectclass=User

Exemple /etc/openldap/ldap.conf d'entrées de fichier

URI ldap://<server.domain.com>
BASE <DC=domain,DC=com>
TLS_CACERTDIR /etc/openldap/certs

  1. (Facultatif) Pour activer le transport sécurisé pour la communication LDAP avec vérification de certificat homologue (plus fiable), ajoutez les lignes indiquées ci-dessous dans /etc/pam_ldap.conf et /etc/openldap/ldap.conf:
    Lignes à ajouter à /etc/pam_ldap.conf :
    ssl start_tls
    tls_cacertfile /etc/openldap/certs/myca.pem


    Lignes à ajouter à /etc/openldap/ldap.conf :
    ssl start_tls
    tls_cacert /etc/openldap/certs/myca.pem

    myca.pem
    est un fichier qui contient un certificat x.509 au format dencodage PEM/Base64 pour l'autorité de certification racine (pas l'autorité de certification émettrice) de la chaîne de certificat qui a émis le certificat LDAP sécurisé des contrôleurs de domaine. Contactez votre administrateur Active Directory pour obtenir ce certificat d'autorité de certification racine. Le certificat doit être au format PEM.

Remarque : Les contrôleurs de domaine Windows n'activent pas par défaut le transport LDAP sécurisé. Ils requièrent l'installation d'un certificat de serveur pour l'authentification serveur. L'obtention et l'installation de ce certificat en CC ne sont pas traités dans le cadre de ce document. Quelques indications à ce sujet sont disponibles à l'adresse https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx.

  1. (Facultatif) Pour activer le transport sécurisé pour la communication LDAP sans certificat homologue, ajoutez ces lignes dans /etc/pam_ldap.conf et /etc/openldap/ldap.conf :
    Lignes à ajouter à /etc/pam_ldap.conf
    ssl start_tls
    tls_reqcert never


    Lignes à ajouter à /etc/openldap/ldap.conf
    ssl start_tls
    tls_checkpeer no
  2. Pour tester la configuration LDAP, exécutez la commande suivante :
    ldapsearch -x -D <user>@<domain.com> -W
  3. Pour effectuer un test avancé ou pour dépanner votre utilisateur de liaison, connectez-vous en tant qu'utilisateur de liaison (par exemple Mike Cool) et recherchez l'utilisateur, vérifiez son nom unique (DN) et utilisez cette valeur comme binddn dans pam_ldap.conf, par exemple :
    1. ldapsearch -b "dc=domain,dc=com" -D mcool@domain.com -h server.domain.com -W "(cn=Cool*)" |grep Cool
      Le GREP permet de masquer l’invite de mot de passe (-W)
    2. Saisissez le mot de passe, puis appuyez sur ENTRÉE :
  4. Modifiez le fichier de configuration PAM du serveur Security Analytics /etc/pam.d/securityanalytics pour ajouter la ligne suivante. Si le fichier n'existe pas, créez-le et ajoutez la ligne suivante :
    auth sufficient pam_ldap.so

Ceci termine la configuration de PAM LDAP. Maintenant, passez à la section suivante, Configurer et tester le service NSS.

PAM Radius

Ports de communication Radius- UDP 1812 ou UDP 1813

Pour configurer l'authentification PAM à laide de Radius, vous devez ajouter le serveur Security Analytics à votre liste de client de serveur Radius et configurer un secret partagé. Contactez l'administrateur du serveur Radius pour cette procédure.

Pour configurer l'authentification PAM avec LDAP :

  1. Si vous avez effectué une mise à niveau vers Security Analytics 10.6, exécutez la commande suivante. Sinon, ignorez cette étape :
    yum --enablerepo=nwupdates install pam_radius_auth
  2. Éditez le fichier de configuration radius, /etc/raddb/server comme suit :
    # server[:port] shared_secret  timeout (s)
    server          secret         3
  3. Modifiez le fichier de configuration PAM du serveur Security Analytics /etc/pam.d/securityanalytics pour ajouter la ligne suivante. Si le fichier n'existe pas, créez-le et ajoutez la ligne suivante :
    auth sufficient pam_radius_auth.so

Les modules PAM et les services associés information envoient des informations à /var/log/messages et /var/log/secure. Ces sorties peuvent être utilisées pour aider à résoudre des problèmes de configuration.

Ceci termine la configuration de PAM Radius. Maintenant, passez à la section suivante, Configurer et tester le service NSS.

Agent PAM pour SecurID

Port de communication PAM - UDP 5500

Conditions préalables
Le module RSA SecurID PAM est pris en charge uniquement dans les conditions suivantes :

  1. Tous les services core Security Analytics du déploiement doivent exécuter au moins la version 10.4.0. Security Analytics 10.3.x ou antérieure n’est pas compatible.
  2. Les connexions approuvées doivent être activées et fonctionner entre Security Analytics et les services core Security Analytics.

Tour d’horizon du processus 

Voici les étapes générales de configuration du module SecurID PAM :

  1. Configurez Authentication Manager :
    a. Ajouter un agent d'authentification.
    b. Télécharger le fichier de configuration.
  2. Configurer le serveur Security Analytics :
    a. Copiez le fichier de configuration à partir d'Authentication Manager et personnalisez-le.
    b. Installez le module PAM SecurID.
  3. Tester la connectivité et l'authentification.

Suivez ensuite les procédures restantes dans les sections qui suivent :

  • Configurez NSS.
  • Activer PAM dans Security Analytics.
  • Configurer des mappages de groupes dans le serveur Security Analytics.

Pour configurer Authentication Manager :

  1. Connectez-vous à RSA Authentication Manager.
    La Console de sécurité s’affiche.
  2. Dans la console de sécurité, ajoutez un nouvel agent d'authentification.
    Cliquez sur Accès > Agents d'authentification > Ajouter nouveau.
    La page Ajouter un nouvel agent d'authentification s'affiche.
  3. Dans le champ Nom d'hôte, saisissez le nom d'hôte du serveur Security Analytics.
  4. Cliquez sur Résoudre IP.
    L'adresse IP du serveur Security Analytics s'affiche automatiquement dans le champ Adresse IP.
  5. Conservez les paramètres par défaut et cliquez sur Enregistrer.
  6. Générez un fichier de configuration.
    Cliquez sur Accès > Agents d'authentification > Générer le fichier de configuration.
    La page Générer le fichier de configuration s'affiche.

  7. Conservez les valeurs par défaut et cliquez sur Générer le fichier de configuration.
    Cela crée AM_Config.zip, qui contient deux fichiers.
  8. Cliquez sur Téléchargez maintenant.

Pour installer et configurer le module SecurID PAM :

Remarque : Dans la version 10.4 ou ultérieure, les OVA et les ISO d'installation pré-installent le paquet SecurID. Si cela s'applique à votre environnement, ignorez cette procédure.

  1. Dans le serveur Security Analytics, créez un répertoire :
    mkdir /var/ace
  2. Dans le serveur Security Analytics, copiez sdconf.rec du fichier .zip sur /var/ace.
  3. Créez un fichier texte sdopts.rec dans le répertoire /var/ace.
  4. Insérez la ligne :
    CLIENT_IP=<adresse IP du serveur Security Analytics>
  5. Installez l'agent d'autorisation SecurID pour PAM, qui est disponible dans le dépôt yum :
    yum install sid-pam-installer
  6. Exécutez le script d'installation :
    /opt/rsa/pam-agent-installer/install_pam.sh
  7. Suivez les instructions pour accepter ou modifier les valeurs par défaut. 
  8. Modifiez le fichier de configuration PAM du serveur Security Analytics, /etc/pam.d/securityanalytics en ajoutant la ligne suivante :
    auth required pam_securid.so
    Si le fichier n'existe pas, créez-le et ajoutez cette ligne :
    auth sufficient pam_securid.so

Ceci termine l'installation du module PAM SecurID.  Ensuite, testez la connectivité et l'authentification. Puis suivez les procédures de Configurer et tester le service NSS.

Remarque : Après l'installation, vérifiez que VAR_ACE dans le fichier /etc/sd_pam.conf pointe vers l'emplacement correct du fichier sdconf.rec. Il s'agit du chemin vers les fichiers de configuration. L'ensemble du chemin doit disposer de l'autorisation racine -rw------- root.

Pour tester la connectivité et l'authentification :

  1. Exécutez /opt/pam/bin/64bit/acetest, saisissez le nom d'utilisateur et le code secret
  2. (Facultatif) Si acetest échoue, activez le débogage :
    vi/etc/sd_pam.conf
    RSATRACELEVEL=15
  3. Exécutez /opt/pam/bin/63bit/acestatus. Sortie ci-dessous

Limites du serveur/RSA ACE
---------------------
Version de configuration : 15 Client Retries : 5 
Client Timeout : 5 DES Enabled : Oui

Informations statiques/RSA ACE
--------------------------
Service : securid Protocol : udp Port Number : 5500

Informations dynamiques/RSA ACE
---------------------------
Version du serveur : 8.1.0.0 Communication : 5

Liste de serveurs/RSA ACE
-------------------
Nom du serveur :           auth81.netwitness.local
Adresse du serveur :        192.168.100.10
Adresse du serveur active : 192.168.100.10
Maître : Yes Slave : No Primary : Oui 
Usage : Available for Authentications

  1. (Facultatif) Pour résoudre les problèmes du serveur Authentication Manager,
    Cliquez sur Création de rapports > Moniteurs d’activité en temps réel > Moniteur d’activité d’authentification. 
    Ensuite, cliquez sur Démarrer le moniteur.
  2. Si vous avez modifié le paramètre, réinitialisez RSATRACELEVEL sur 0 :
    vi/etc/sd_pam.conf
    RSATRACELEVEL=0

Ceci termine la configuration de l'agent PAM pour SecurID. Maintenant, passez à la section suivante, Configurer et tester le service NSS.

Configurer et tester le service NSS

Choisir un service NSS

Il existe trois options de service NSS : Samba, LDAP et UNIX.  Les trois comportent des avantages et des inconvénients.

                         
Avantages de NSS SambaInconvénients de NSS Samba
Objectif construit pour Active DirectoryNe peut être utilisé avec des back-ends non-AD
Peu ou pas de configuration doit être effectuée dans Active DirectoryPotentiellement plus difficile à configurer et dépanner
Pas de comptes utilisateurs spéciaux nécessairesNécessite que la machine de serveur SA soit associée au domaine Active Directory
 Utilise de nombreux ports pour communiquer avec Active Directory ; plus difficile à mettre en œuvre au travers des pare-feux et proxys

 

                         
Avantages de NSS LDAPInconvénients de NSS LDAP
La configuration de base est simplePeut nécessiter une configuration et des rôles supplémentaire à l'intérieur de Active Directory
Peut communiquer avec toute mise en œuvre de LDAPNécessite la configuration d'un compte de liaison LDAP
Utilise un seul port TCP pour la communication - plus facile de travailler avec des pare-feux et proxyPlus difficile d'activer le transport sécurisé à moins de le configurer pour ne pas valider les certificats de serveur
Ne nécessite pas d'associer un hôte SA au domaine AD 

NSS UNIX

Aucune configuration n'est nécessaire pour activer le module NSS UNIX ; il est activé dans le système d'exploitation hôte par défaut. Pour autoriser un utilisateur pour un groupe spécifique, il suffit de l'ajouter au système d'exploitation et de l'ajouter à un groupe :

  1. Créez un groupe de systèmes d'exploitation à ajouter à votre utilisateur externe avec cette commande :
    groupadd <groupname>
  2. Ajoutez l'utilisateur externe au système d'exploitation avec cette commande :
    adduser -G <groupname> -M -N <externalusername>

Remarque : Notez que cette opération ne permet PAS ni autorise l'accès à la console du serveur SA.

Ceci termine la configuration de NSS UNIX. Ensuite, passez à la section Tester la fonctionnalité NSS.

NSS Samba

Remarque : Si le serveur Security Analytics et Security Analytics Malware Analysis partagent le même serveur, lorsque vous configurez NSS Samba, la configuration de Malware Analysis Samba (SMB) est désactivée.

Ports de communication Winbind AD

Les ports suivants sont les ports minimums. Les tests internes indiquent qu'ils doivent être ouverts pour autoriser la fonctionnalité NSS Samba.  Ces informations sont fournies uniquement à titre de référence.

TCP 88 - Kerberos
TCP 139 - Netbios
TCP 389 - LDAP
UDP 53 - DNS
UDP 88 - Kerberos
UDP 389 - LDAP

Des ports supplémentaires peuvent être nécessaires, en fonction des exigences propres sur site de la mise en œuvre. Des ports supplémentaires peuvent être nécessaires, en fonction des exigences propres sur site de la mise en œuvre : http://technet.microsoft.com/en-us/library/dd772723(ws.10).aspxhttp://technet.microsoft.com/en-us/library/dd772723%28ws.10%29.aspx

Pour configurer NSS Samba :

  1. Modifiez le fichier de configuration Samba, /etc/samba/smb.conf, comme suit. Remplacez les variables, qui sont délimitées par des <crochets>, par vos valeurs et en omettant les crochets. La mise en majuscules est obligatoire aux emplacements indiqués.
    [global]
    workgroup = domain
    netbios name = <SA_APPLIANCE_HOSTNAME>
    password server = <ADSERVER.DOMAIN.COM>
    realm = <DOMAIN.COM>

    local master = no
    security = ads
    syslog only = yes
    log file = /var/log/samba/log.%m
    max log size = 5120
    idmap config * : range = 16777216-33554431
    template shell = /bin/bash
    winbind use default domain = true
    winbind offline logon = false
    winbind enum groups = yes
  2. Pour activer et démarrer le service de liaison de Windows, winbind, saisissez les commandes suivantes :
    chkconfig winbind on
    service winbind start
  3. Modifiez le fichier de configuration NSS, /etc/nsswitch.conf. Mettez à jour uniquement les 2 entrées ci-dessous et laissez le reste sur les valeurs par défaut :
    passwd:     files winbind
    group:      files winbind
  4. Pour associer le domaine, saisissez la commande suivante :
    net ads join -U <DomainAdminUser>
  5. Pour stocker le SID du contrôleur de domaine, saisissez la commande suivante :
    net rpc getsid -S <SERVER.DOMAIN.COM>
  6. Testez la fonctionnalité NSS comme décrit dans la section Tester la fonctionnalité NSS.  
  7. Lorsque vous avez confirmé que NSS fonctionne correctement à partir de la ligne de commande, pour redémarrer l'hôte pour que les modifications NSS prennent effet, saisissez la commande suivante.
    reboot

Pour dépanner NSS Samba :

Pour vérifier si NSS Winbind peut communiquer avec succès avec Active Directory :

  1. Saisissez la commande suivante :
    wbinfo -u pour renvoyer la liste des utilisateurs AD
    wbinfo -g pour renvoyer la liste de groupes AD
  2. Si aucune commande ne fonctionne, exécutez winbind dans la console en mode de débogage en saisissant les commandes suivantes :
    service winbind stop
    winbindd -S -F -d <optional debugleve 0-10>
  3. À partir d'une session ssh séparée, répétez l'étape 1 et vérifiez la sortie winbindd pour obtenir l'indication du problème.
    Augmentez le degré d'explicitation du débogage de winbindd le cas échéant.
  4. Effectuez les ajustements nécessaires pour /etc/samba/smb.conf.
  5. Dans la fenêtre de débogage winbindd de l’étape 2, arrêtez winbindd en saisissant CTRL-C
    Répétez les étapes 1 et 2 et continuez le dépannage jusqu'à ce que les commandes wbinfo réussissent.
  6. Après le succès des commandes wbinfo, utilisez les commandes getent de la section Test de la fonctionnalité NSS de ce guide pour tester NSS.
    getent passwd <pamUser>
    getent group <groupOfPamUser>
  7. Lorsque la commande getent réussit, arrêtez la ligne de commande winbindd en saisissant CTRL-C et saisissez la commande suivante pour démarrer le processus du service :
    service winbind start

Si wbinfo -g réussit depuis la ligne de commande, mais que la recherche du mappage de groupe externe ne présente aucun des groupes Active Directory :

  1. Ajoutez les lignes suivantes à /etc/samba/smb.conf :

allow trusted domains = no

  1. Saisissez service winbind restart.

Ceci termine la configuration de NSS Samba. Ensuite, passez à la section Tester la fonctionnalité NSS.

NSS LDAP

Remarque : Ces instructions exigent que tous les utilisateurs PAM et les objets des groupes NSS de Active Directory comportent la valeur de leurs attributs uidNumber et gidNumber sur des numéros UID et GID de style UNIX afin d'être utilisés par NSS LDAP. Les anciens schémas Active Directory peuvent ne pas avoir ces attributs par défaut. Les nouveaux schémas AD peuvent comporter ces attributs, mais ils ne peuvent pas être définis dans chaque objet. La configuration correcte de ces attributs n'entre pas dans le cadre du présent document. Contactez votre administrateur Active Directory pour que ces attributs soient définis pour les utilisateurs PAM et les groupes NSS.

Un utilisateur de liaison LDAP doit être créé dans Active Directory pour utiliser NSS. Cet utilisateur doit être configuré pour que son mot de passe n'expire pas. Étant donné que ces informations d'identification doivent être spécifiées pour le service NSS LDAP en clair, les autorisations de /etc/nslcd.conf doivent être laissées sur 600 (leur valeur par défaut) de sorte que le fichier ne puisse être lu par des utilisateurs du système autres que racine.

LDAP Communication Ports - TCP 389 or TCP 636

TCP 389 peut être utilisé pour à la fois le trafic déchiffré et dans la plupart des cas, le trafic chiffré, ce qui suffit souvent. La plupart des implémentations LDAP modernes prennent en charge la commande start_tls lors de la connexion du port 389, qui met à niveau la connexion d'un état déchiffré en passant à l'état chiffré. Dans cette instance, les URI LDAP commencent toujours avec ldap:// même en utilisant start_tls.

TCP 636 est utilisé uniquement dans les instances où le serveur LDAP ne prend pas en charge la commande start_tls.  Dans cette instance, les URI LDAP commencent par ldaps:// et la commande start_tls n'est pas utilisée.

Pour configurer le module NSS pour LDAP avec Active Directory :

  1. Obtenez le package nss-pam-ldapd à partir du référentiel SMCUPDATE ou à partir du référentiel des mises à jour du serveur Security Analytics si le serveur est synchronisé avec SMCUPDATE. Cela nécessite un compte Live configuré dans Security Analytics.
  2. Pour installer le package, procédez comme suit :
    1. Pour installer directement à partir de SMCUPDATE, saisissez la commande suivante :
      yum --enablerepo=sa install nss-pam-ldapd
    2. Pour installer à partir du référentiel de mises à jour Security Analytics, saisissez la commande suivante :
      yum --enablerepo=nwupdates install nss-pam-ldapd
  3. Modifiez /etc/nslcd.conf pour inclure les lignes ci-dessous, assurez-vous que les lignes existantes dans le fichier commencent d'abord par un caractère dièse # au début de la ligne :
    #voir la remarque dans la section des Ports de communication NSS LDAP pour obtenir des conseils sur l'utilisation de ldap:// ou ldaps://
    uri ldap://<ldapServerHost>/ 
    base dc=<yourDomain>,dc=<com>
    binddn <ldapBindUser@yourdomain.com>
    bindpw <bindPassword>
    bind_timelimit 30
    timelimit 30
    idle_timelimit 3600
    pagesize 1000
    referrals off
    filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
    map    passwd uid              sAMAccountName
    map    passwd homeDirectory    unixHomeDirectory
    map    passwd gecos            displayName
    filter shadow (&(objectClass=user)(!(objectClass=computer))(uidNumber=*)(unixHomeDirectory=*))
    map    shadow uid              sAMAccountName
    map    shadow shadowLastChange pwdLastSet
    filter group  (objectClass=group)
    map    group  uniqueMember     member
    uid nslcd
    gid ldap
  4. (Facultatif) Pour activer le transport sécurisé pour la communication LDAP avec vérification de certificat homologue (plus fiable), ajoutez ces lignes dans/etc/nslcd.conf :
    ssl start_tls
    tls_cacert /etc/openldap/certs/myca.pem


    myca.pem est un fichier qui contient un certificat x.509 au format dencodage PEM/Base64 pour l'autorité de certification racine (pas l'autorité de certification émettrice) de la chaîne de certificat qui a émis le certificat LDAP sécurisé des contrôleurs de domaine. Contactez votre administrateur Active Directory pour obtenir ce certificat d'autorité de certification racine.  Le certificat doit être au format PEM.

Remarque : Les contrôleurs de domaine Windows n'activent pas par défaut le transport LDAP sécurisé. Ils requièrent l'installation d'un certificat de serveur pour l'authentification serveur. L'obtention et l'installation de ce certificat en CC ne sont pas traités dans le cadre de ce document. Quelques indications à ce sujet sont disponibles à l'adresse https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

  1. (Facultatif) Pour activer le transport sécurisé pour la communication LDAP sans certificat homologue, ajoutez ces lignes dans /etc/nslcd.conf :
    ssl start_tls
    tls_reqcert never
  2. Modifiez le fichier de configuration de NSS /etc/nsswitch.conf. Mettez à jour uniquement les deux entrées ci-dessous et laissez le reste sur les valeurs par défaut :
    passwd:files ldap
    group:files ldap
  3. Pour activer et démarrer le service NSLCD, saisissez ces commandes :
    chkconfig nslcd on
    service nslcd start
  4. Testez la fonctionnalité NSS à l'aide des conseils de la section Tester la fonctionnalité NSS. Si les tests NSS échouent, dépannez NSS LDAP comme décrit dans Dépanner NSS LDAP.
  5. Lorsque vous avez confirmé que NSS fonctionne correctement à partir de la ligne de commande, redémarrez l'hôte pour que les modifications NSS prennent effet.
    reboot

Pour dépanner NSS LDAP :

  1. Pour dépanner NSS LDAP, arrêtez d'abord le service nslcd en saisissant la commande suivante :
    service nslcd stop
  2. Pour copier les informations de dépannage et d'état du service à la console, exécutez le service nslcd en mode débogage à partir de la ligne de commande.
    nslcd -d
  3. (Facultatif) Pour augmenter le degré d'explicitation du débogage, ajoutez un d supplémentaire plusieurs fois à la fin de nslcd -d, par exemple, saisissez la commande suivante :
    nslcd -ddd
  4. À partir d'une session ssh distincte, utilisez les commandes getent de la section Test de la fonctionnalité NSS de ce guide pour tester NSS. Surveillez la sortie de débogage à partir de nslcd pour obtenir les indications de l'endroit où l'échec se produit.  Augmentez le degré d'explicitation du débogage de nslcd le cas échéant.
    getent passwd <pamUser>
    getent group <groupOfPamUser>
  5. Effectuez les ajustements nécessaires dans /etc/nslcd.conf en fonction de la sortie de l'étape 2 ou 3.
  6. Dans la fenêtre de débogage nslcd de l'étape 2 ou 3, arrêtez nslcd avec CTRL-C.  Répétez l'étape 2 ou 3 et continuez le dépannage jusqu'à ce que les commandes getent réussissent.
  7. Lorsque getent réussit, arrêtez la ligne de commande nslcd et démarrez le processus du service :
    service nslcd start

Les problèmes courants peuvent comprendre :

  • Le certificat SSL de transport sécurisé LDAP qui n'est pas installé sur le serveur LDAP/AD.
  • Échec de vérification de certificat d’autorité de certification : commentez la ligne tls_cacert dans /etc/nslcd.conf et essayez tls_reqcert never.  Si elle réussit, vous savez quelle vérification du certificat est un échec.
    • Le certificat CA racine n'est pas au format PEM.
    • Utilisez le certificat de l'autorité de certification émettrice plutôt que le certificat de l'autorité de certification racine.
    • Le nom du certificat SSL du serveur LDAP ne correspond pas à son nom d'hôte.
  • Nom unique de base incorrect.
  • L'utilisateur ou le mot de passe de liaison LDAP n'est pas spécifié correctement.
  • En spécifiant de façon incorrecte ldaps:// au lieu de ldap:// dans la ligne uri de /etc/nslcd.conf. ldaps:// doit uniquement être utilisé avec LDAPS mais pas la commande start_tls.
  • Les utilisateurs et les groupes Active Directory ne disposent pas d'attributs uidNumber ou gidNumber définis.
  • Le pare-feu réseau bloque les communications.
  • Le nom d'hôte du serveur LDAP spécifié ne peut pas être résolu
    • Paramètres DNS incorrects dans /etc/resolv.conf.
    • Nom d’hôte incorrect spécifié à la ligne uri de /etc/nslcd.conf.

Ceci termine la configuration de NSS LDAP. Ensuite, passez à la section Tester la fonctionnalité NSS.

Tester la fonctionnalité NSS

Pour tester si NSS fonctionne avec l'un des services NSS précédents, utilisez les commandes suivantes :

getent passwd <pamUser>
getent group <groupOfPamUser>

La sortie doit être similaire à :

[root@~]# getent passwd myuser
myuser:*:10000:10000::/home/myuser:/bin/sh

[root@~]# getent group mygroup
mygroup:*:10000:myuser3

  • Si aucune commande ne produit de sortie, l'autorisation externe ne fonctionne pas correctement sur NSS. Reportez-vous aux conseils de dépannage de votre module NSS fournis dans ce document.
  • Si les commandes getent fonctionnent et que la réussite de l'authentification est confirmée dans /var/log/secure mais Security Analytics ne parvient toujours pas à autoriser les utilisateurs externes à se connecter :
    • Est-ce que le nom de groupe correct a été spécifié pour le groupe NSS dans le mappage de groupe externe SA ?  Reportez-vous aux sections ci-dessous Activer PAM et Créer des mappages de groupe.
    • Il se peut que la configuration NSS a changé et que Security Analytics n'a pas relevé le changement.  Un redémarrage de l’hôte Security Analytics poussera Security Analytics à récupérer les modifications de configuration de NSS.  Un redémarrage de jettysrv n'est pas suffisant.

Passez à la section suivante, Activer PAM dans le serveur Security Analytics.

Activer PAM dans le serveur Security Analytics

  1. Connectez-vous à Security Analytics et dans le menu Security Analytics, sélectionnez Administration > Services.
    La vue Administration - Sécurité s'ouvre sur l'onglet Utilisateurs.
  2. Cliquez sur l'onglet Paramètres.
  3. Dans Authentification externe, sélectionnez PAM et cliquez sur Appliquer.

PAM est activé et Active Directory est automatiquement désactivé. Les paramètres de configuration Active Directory sont stockés et masqués. Passez à la section finale, Créer des groupes de mappage dans le serveur Security Analytics.

Créer des mappages de groupes sur le serveur Security Analytics

  1. Dans la vue Sécurité, cliquez sur l'onglet Mappage de groupe externe.
  2. Mappez les noms des groupes externes aux rôles Security Analytics appropriées, comme décrit dans Étape 5. (Facultatif) Mapper des rôles d'utilisateur aux groupes externes.
    Le nom du groupe externe et le nom du rôle Security Analytics doivent correspondre.
    Par exemple, Analystes et Analystes mais pas Analystes et Analyste. 
You are here
Table of Contents > Configurer la sécurité du système > Étape 4. (Facultatif Configurer l'authentification externe > Configurer la fonctionnalité de connexion PAM

Attachments

    Outcomes