Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Voir tous les articles

Retrouvez les articles à la une

Active Directory : Réparer le Secure Channel

par | 10 Nov 2017 | , ,

Bonjour à tous,

Aujourd’hui nous allons aborder la problématique du Secure Channel (canal sécurisé) dans une infrastructure Active Directory.

Qu’est ce que le Secure Channel ?

Le Secure Channel ou Canal Sécurisé est un élément vital dans une infrastructure Active Directory. En effet, toute communication entre une station de travail et un contrôleur de domaine AD doit passer via un canal sécurisé.

Il est à noter que le canal sécurisé est également utilisé pour les communications entre deux contrôleurs de domaine.

Quand le canal sécurisé est cassé, toutes les opérations Active Directory liées au canal sont en échec (Tickets Kerberos, stratégies de groupes, …).

Quand le Secure Channel est cassé

Le signe le plus flagrant d’un problème de canal sécurisé entre un poste et un contrôleur de domaine est le message suivant au démarrage du poste : « The trust relationship between this workstation and the primary domain failed ».

La plupart du temps, ceci est du au fait que le mot de passe en usage pour établir le Secure Channel sur le poste concerné est différent du mot de passe du compte ordinateur stocké dans l’AD.

Réparer le Secure Channel

Habituellement, l’étape de réparation passe par les étapes suivantes :

  1. Sortie du poste du domaine pour un retour en Workgroup
  2. Réinitialisation du compte ordinateur correspondant dans l’Active Directory
  3. Réintégration du poste dans le domaine

L’ancienne méthode

Une méthode, plus propre, et qui vous épargnera un redémarrage consiste à réparer le canal sécurisé directement avec une invite de commande.

La commande à utiliser est netdom resetpwd /s:domaincontroller /ud:domain\User /pd:*

La nouvelle méthode

Avec l’avènement de Powershell, une nouvelle commande a fait son apparition : Test-ComputerSecureChannel.

Si la commande renvoie True, c’est que le Secure Channel est fonctionnel entre le poste et le contrôleur de domaine concerné.

Si elle renvoie False, c’est que le Secure Channel n’est plus fonctionnel entre le poste et le contrôleur de domaine concerné.

Il faut l’utiliser avec l’option Repair afin de réparer le Secure Channel.

Le retour de la commande, True ou False, indique le succès ou non de la réparation du Canal Sécurisé.

A noter qu’à partir de Powershell v4.0, l’option Credential permet de préciser les identifiants à utiliser pour réparer le canal sécurisé.

Version Windows 7 / Windows Server 2008 R2 :

Version Windows 8 / Windows Server 2012 R2 :

Azure–Présentation d’Azure ADDS

par | 27 Oct 2017 |

Présentation

Les services de domaine Azure Active Directory fournissent des services de domaine gérés tels que la jonction de domaine, la stratégie de groupe, le protocole LDAP, etc. Vous pouvez utiliser ces services sans avoir à déployer gérer et apporter des correctifs aux contrôleurs de domaine.

Microsoft à créé ce service pour faciliter aux entreprises la création d’un environnement full cloud dans Azure et de répondre aux différents besoins qui sont principalement le coût et la surcharge administrative.

image

Configuration

La particularité d’Azure ADDS est qu’on ne peux pas manager l’AD depuis son interface. Il faut obligatoirement passer par d’autres services, par exemple :

  • Pour la gestion des comptes il faut passer par le service Azure AD ou un AD On-Prémisse synchronisé.

image

  • Pour la gestion des GPO, des OU il faut passer par une VM du domaine et y installer les outils d’administrations.

image

Voici un schéma qui résume l’esprit d’Azure ADDS :

aadds-overview-onpremise

Information

Pour la création de VM Azure il est conseillé d’utiliser la série B. Cette série est une nouvelle offre qui a pour avantage d’être la plus basse car elle s’appuie sur un système de crédit. Elle est prévu en majorité pour des charges de travail ne sollicitant pas en permanences le processeur comme par exemple un serveur web ou un environnement de test. Ces machines sont disponibles dans les régions : US – West 2, US – East, Europe – West, et Asia Pacific – Southeast.

Pour plus d’information concernant la configuration d’Azure ADDS, Consulter le lien suivant : https://azure.microsoft.com/en-us/services/active-directory-ds/

SQL SSRS–Renouvellement de certificat

par | 16 Oct 2017 |

Contexte

Lors d’un renouvellement de certificat WEB sur une instance SSRS, le mapping du nouveau certificat échoue avec l’erreur suivante :

Microsoft.ReportingServices.WmiProvider.WMIProviderException: An SSL binding already exists for the specified IP address and port combination. The existing binding uses a different certificate from the current request. Only one certificate can be used for each IP address and port combination. To correct the problem, either use the same certificate as the existing binding, or remove the existing SSL binding and create a new binding using the certificate of the current request.

Explication

Le message d’erreur précise que la combinaison IP:Port est déjà mappée à un certificat existant (celui que l’on tente de renouveler).

La commande suivante permet de visualiser le binding existant :

netsh http show sslcert

image

On remarque que le certificat que l’on tente de renouveller est mappé à la combinaison IP:Port suivante : [::]:443

Résolution

A l’aide de la commande précédemment citée, récupérer la combinaison IP:Port utilisée par le certificat que l’on tente de renouveler, puis supprimer le mappage à l’aide de la commande suivante :

netsh http delete sslcert ipport=[::]:443

Derniers articles

Catégories

Archives

Auteurs/Autrices