Configuration de la connexion Active Directory locale pour LDAPS - Gladinet

Si les contrôleurs de domaine Active Directory locaux possèdent des certificats de serveur qui prennent en charge les connexions LDAP sur SSL (LDAPS), il est préférable de configurer CentreStack pour qu’il communique avec les contrôleurs de domaine en utilisant LDAPS plutôt que LDAP, car la communication LDAPS est chiffrée, alors que LDAP est en texte clair et susceptible d’être intercepté.

Certificats de serveur

Les contrôleurs de domaine Active Directory locaux doivent avoir des certificats qui prennent en charge la communication LDAPS. Les exigences sont documentées dans cet article de support Microsoft : https://support.microsoft.com/en-us/help/321051/how-to-enable-ldap-over-ssl-with-a-third-party-certification-authority

Le port TCP 636 de LDAPS

Le serveur web CentreStack doit être autorisé à accéder aux contrôleurs de domaine sur TCP 636, le port LDAPS. Le port LDAP est TCP 389.

Configuration

Dans le tableau de bord du locataire CentreStack, cliquez sur l’icône de la clé à molette dans la section Local Active Directory :
Cliquez sur le bouton Modifier, puis activez l’option Activer l’intégration Active Directory.
Dans la zone de texte Adresse du contrôleur de domaine ou du serveur LDAP, saisissez ensuite le nom de domaine DNS du domaine AD suivi de « :636 », dans cet exemple : t2.hadroncloud.com:636, puis indiquez un nom d’utilisateur et un mot de passe. NOTE : Un administrateur de domaine n’est pas nécessaire car tous les utilisateurs ont généralement un accès en lecture au répertoire :
Cliquez sur l’onglet Paramètres avancés puis activez l’option Activer LDAPS pour l’accès sécurisé :
Cliquez sur Appliquer en haut de l’écran. Le système se liera à Active Directory en utilisant la nouvelle configuration. Il ne devrait y avoir aucune erreur signalée.
De retour dans le tableau de bord du locataire, cliquez sur Ajouter un nouvel utilisateur.
Cliquez sur le domaine AD :
Les objets du domaine devraient être énumérés prouvant que la connexion fonctionne :

Vérifier les certificats sur les contrôleurs de domaine

Exécuter le snap-in de certificats mmc.exe contre l’ordinateur local sur les contrôleurs de domaine. Dans un environnement utilisant une autorité de certification Microsoft pour l’infrastructure à clé publique (PKI), vous devriez un certificat de serveur avec ces propriétés:

Sonder TCP 636 sur le ou les contrôleurs de domaine

Utiliser l’outil de Microsoft SysInternals, psping.exe, pour vérifier que le serveur CentreStack peut accéder à TCP 636 sur les contrôleurs de domaine. Une fois PsPing téléchargé et extrait, lancez une invite de commande et exécutez une commande similaire à celle-ci :

psping <domain_controller_fqdn>:636

Par exemple :

psping T2BRADDC01.t2.hadroncloud.com:636

Les résultats devraient ressembler à ceci:

TCP connect to 10.0.0.20:636:
5 iterations (warmup 1) ping test:
Connecting to 10.0.0.20:636 (warmup): from 10.0.0.29:57741: 0.37ms
Connecting to 10.0.0.20:636: from 10.0.0.29:57742: 0.43ms
Connecting to 10.0.0.20:636: from 10.0.0.29:57743: 0.25ms
Connecting to 10.0.0.20:636: from 10.0.0.29:57744: 0.50ms
Connecting to 10.0.0.20:636: from 10.0.0.29:57745: 0.40ms
TCP connect statistics for 10.0.0.20:636:
Sent = 4, Received = 4, Lost = 0 (0% loss),
Minimum = 0.25ms, Maximum = 0.50ms, Average = 0.39ms

Si vous voyez des résultats autres que ceux ci-dessus, il y a de fortes chances qu’un pare-feu bloque le TCP 636 vers le ou les contrôleurs de domaine.

Test avec ldp.exe

Sur le serveur CentreStack, exécutez cette commande dans une session PowerShell élevée :

Install-WindowsFeature RSAT-ADDS-Tools

Cela va installer l’outil ldp.exe et d’autres outils de gestion Active Directory sur le serveur CentreStack.

Lancer ldp.exe

Dans le menu Connexion, cliquez sur Connecter….

Dans la zone de texte Server, spécifiez le nom de domaine DNS
Dans la zone de texte Port, utilisez 626
Activer l’option SSL :

Une fois que le bouton OK est cliqué dans la boîte de dialogue Connecter, les résultats de la connexion seront affichés dans ldp.exe:

Si cette erreur est affichée par ldp.exe, cela signifie généralement qu’il y a un problème de certificat:

Auquel cas, cela peut être consigné dans le journal des événements du système:

Log Name: System
Source: Schannel
Date: 12/10/2019 3:06:48 PM
Event ID: 36882
Task Category: None
Level: Error
Keywords: 
User: TXBRCSTK02\JeffR
Computer: TXBRCSTK02
Description:
The certificate received from the remote server was issued by an untrusted certificate authority. Because of this, none of the data contained in the certificate can be validated. The TLS connection request has failed. The attached data contains the server certificate.

Le « untrusted certificate authority » signifie généralement que l’autorité de certification (CA) qui a émis le certificat n’est pas digne de confiance par le serveur CentreStack. C’est très typique si l’AC est une AC privée interne et que CentreStack n’est pas joint à un domaine (c’est-à-dire un ordinateur de groupe de travail dans le réseau périphérique).

Dans CentreStack, ce problème s’affichera avec ce symptôme:

L’erreur est : La configuration ne peut pas être vérifiée:La configuration ne peut pas être vérifiée:Erreur inconnue (0x80005000)

Ceci entraînera également l’enregistrement par Schannel du même ID d’événement : 36882.

Pour que CentreStack fasse confiance au certificat de l’AC, vous devrez généralement l’importer dans le nœud Autorités de certification racine de confiance dans le snap-in de certificat de mmc.exe, comme indiqué ici :

Informations supplémentaires

En supposant que ldp.exe soit capable d’établir la connexion LDAPS, vous pouvez également l’utiliser pour vérifier que la liaison peut être effectuée à l’aide des informations d’identification utilisées pour la configuration AD de CentreStack :

Dans le menu Connexion, cliquez sur Lier: