PI Services

Le blog des collaborateurs de PI Services

Azure AD Connect – Relancer les synchronisations après la suppression d’un domaine Active Directory enfant

Contexte

La synchronisation entre l’Active Directory et Office 365 est un sujet extrêmement sensible dans un environnement de production. Une mauvaise configuration peut entrainer la suppression de nombreux objets dans le cloud (comptes, groupes…).

Le domaine enfant de mon domaine Active Directory a été décoché dans la configuration de mon connecteur dans la console Synchronization Service Manager.

2018-01-10_1613512

Figure 1 – Propriétés du connecteur

Lorsque l’on coche à nouveau le domaine enfant et que l’on relance une synchronisation, le domaine enfant n’est pas resynchronisé.

Solution

Lors de la suppression du domaine enfant, les étapes de synchronisation associées sont supprimées.

On remarque en allant dans Configure Run Profiles… sur le connecteur qu’il n’y a qu’une seule étape qui correspond au domaine parent.

2018-01-12_1111362

Figure 2 – Profil du connecteur pour le Full Import avec une seule étape (domaine parent)

Il est donc nécessaire de recréer les étapes pour le domaine enfant. Pour cela il est recommandé de lancer l’outil de configuration d’Azure AD Connect.

Une fois l’outil de configuration terminée, les étapes pour le domaine enfant sont de nouveaux en place.

2018-01-12_1142582

Figure 3 – Profil du connecteur pour le Full Import avec deux étapes (domaine parent et domaine enfant)

Il est ensuite nécessaire de relancer dans l’ordre :

  • Full Import – Connecteur Active Directory
  • Full Synchronisation – Connecteur Active Directory
  • Export – Connecteur Active Directory
  • Delta Import – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Delta Synchronisation – Connecteur Office 365 (domaine.onmicrosoft.com)
  • Export – Connecteur Office 365 (domaine.onmicrosoft.com)

Powershell / Active Directory : Intégration de la photo des utilisateurs

Introduction

Cet article a pour but d'expliquer la gestion des photos dans l'annuaire Active Directory via une intégration par un script Powershell. En effet, le référentiel photo d'une entreprise ne respecte pas forcément les préconisations Microsoft. Grâce à un script, nous allons voir comment les respecter et peupler un annuaire Active Directory. La solution proposée permettra d'automatiser le processus en s'affranchissant d'outils tiers qui peuvent réaliser cette opération.

Solution

L'attribut AD permettant de renseigner la photo est thumbnailPhoto. Il y a plusieurs restrictions sur une image de profil :

  • la résolution est limitée à 96x96 pixels
  • la taille ne doit pas éxéder 100Kb

La valeur stockée dans l'attribut thumbnailPhoto est un tableau de bytes.

La solution proposée utilise des classes .Net issue de System.Drawing. Ainsi, on va pouvoir redéfinir la taille d'une image, la centrer et éventuellement définir la qualité si la photo est trop lourde. Afin d'être le plus portable possible, le script interroge Active Directory via ADSI pour réaliser la modification de l'attribut thumbnailPhoto.

NB : Depuis la V15 des produits d'infrastructure Microsoft et grâce au couple Exchange 2013/Lync 2013, il est possible de stocker des photos d'une résolution de 648*648 pixels directement dans la boîte aux lettres de l'utilisateur. Cette dernière est accédée directement via les Exchange Web Services par Lync. Une copie d'une résolution de 48x48 est toujours stockée dans l'attribut thumbnailPhoto.

Script

Le script permet de rendre conforme la photo d'un utilisateur et de la placer sur l'objet Active Directory dans l'attribut thumbnailPhoto. Pour chaque utilisateur, il est nécessaire de renseigner les paramètres suivants :

  • le samaccountname de l'utilisateur
  • le dossier contenant la photo
  • le nom du fichier photo
  • l'extension du fichier photo
Le script possède deux fonctions. Set-ADUserPhoto, requête l'annuaire Active Directory pour obtenir l'utilisateur via son SamAccountName. L'attribut thumbnailPhoto est ensuite mis à jour avec la valeur qui est retournée par la fonction Resize-Photo. Cette dernière retourne l'image sous la forme d'un tableau de bytes. Elle insère l'image d'origine dans une nouvelle image Bitmap possédant les limites de dimensions spécifiées (dans notre cas 96x96 pixels). Tout surplus sur les côtés est donc supprimé. L'image d'origine est positionnée de façon à se situer au centre. Enfin cette image est enregistrée en mémoire. Sa taille est évaluée. Si sa taille est supérieure au poids maximal choisi (ici 100Kb) alors on génère une nouvelle image en faisant varier la qualité (il s'agit d'un pourcentage que l'on décrémente de 5% à chaque essai).

Pour vérifier que l'opération s'est correctement exécutée, il suffit de vérifier dans la console Active Directory Users and Computers que l'utilisateur possède bien une valeur pour l'attribut thumbnailPhoto (via l'éditeur d'attribut). La photo peut ensuite être consultée via Outlook (pour les messageries Exchange) ou le client Lync. thumbnailPhoto

Ce script s'exécute utilisateur par utilisateur. Il est possible d'imaginer une logique de traitement "en masse".

Voici un script pour remplacer la région Main du script traitant l'intégralité des comptes utilisateurs Active Directory.
On suppose que toutes les photos sont stockées dans le même répertoire et portent comme nom de fichier le samaccountname de l'utilisateur. Bien entendu, cette partie reste adaptable en fonction des besoins. Il est par exemple possible de changer la racine de la recherche pour ne cibler qu'une unité d'organisation. Pour se faire, il faut remplacer $Root = [ADSI]'' par le distinguished name de l'unité d'organisation ciblée. Exemple :
A titre informatif, la fonction Resize-Photo peut être totalement décorrelée du processus de mis à jour de l'objet AD et être utilisée pour d'autre situation. Il est en effet possible de sauvegarder l'image générée dans un fichier plutôt qu'en mémoire en changeant un paramètre de la méthode Save :
Il faut remplacer la variable $Ms (représentant le buffer mémoire que l'on a instantié) par un chemin de fichier.

Windows Server 2012 R2 – Ajout d’un poste au domaine avec un RODC en DMZ

Contexte

L’intégration d’un poste à un domaine Active Directory nécessite un contrôleur de domaine “writable”. Dans le cas où les postes se trouvent avec le RODC dans un site local et que les DC sont dans un site central (via un MPLS sans filtrage réseau par exmple) l’intégration au domaine fonctionne normalement.

Mais dans le cas où le RODC est dans une DMZ (ou un réseau isolé) qui bloque les flux AD depuis le poste vers le DC “writable” il est alors impossible d’ajouter le poste de façon classique au domaine.

Solution

L’ajout du poste à travers le RODC se fait en quatre étapes.

1ère étape :

Il est tout d’abord nécessaire de créer le compte ordinateur sur un DC en lui spécifiant un mot de passe. Pour cela utiliser la commande PowerShell suivante :

1: New-ADComputer -Name <Nom du poste> -AccountPassword (Read-Host -AsSecureString "Password?") -SAMAccountName <Nom du poste> -Enabled $true

2014-01-17_103759

2ème étape :

Ensuite il faut ajouter le poste dans un groupe qui est autorisé à répliquer les mots de passe avec le RODC (par défaut le groupe Allow RODC Password Replication Group).

2014-01-17_103835

3ème étape :

Sur le compte ordinateur du RODC, Propriétés et dans l’onglet Password Replication Policy, cliquer sur Advanced... Ensuite cliquer sur Prepopulate Passwords… et ajouter le compte ordinateur du poste.

2014-03-14_111138 2014-01-17_104040

Il faut maintenant attendre que la réplication se fasse entre le DC et le RODC.

4ème étape :

Il faut maintenant lancer le script disponible à cette adresse http://technet.microsoft.com/fr-fr/library/dd728035(v=ws.10).aspx en indiquant les paramètres suivant :

1: joinscript.vbs /domain <nom du domaine > user <utilisateur> password <mot de passe> /dc <FQDN du RODC> /readonly /machinepassword <mot de passe du compte ordinateur> 

Une fois le script terminé, il faut redémarrer le poste. Au redémarrage il sera intégré au domaine.

Windows Server 2012 R2 – Plantage d’un DC lors d’une modification d’objet AD

Contexte

Lors de la modification d’un objet dans l’Active Directory (exemple : modification sur l’objet KRBTGT lors de l’installation d’un RODC), le Domain Controller redémarre automatiquement de manière inopinée et non planifiée avec ce message d’erreur :

2014-01-03_102252

A la suite du redémarre, les erreurs suivantes se trouvent dans l’Event Viewer :

Application – Wininit – Error 1015 : A critical system process, C:\Windows\system32\lsass.exe, failed with the status code c00000005. The machine must now be restarted.

2014-01-03_102418

Application – Application Error – Error 1000 : Faulting application name: lsass.exe

2014-01-03_102354

Cause

L’erreur est due à un paramètre de l’Audit object access. Ce problème est vraisemblablement un bug de Windows Server 2012 R2.

Solution

Pour résoudre ce problème, il faut désactiver (ou a minima de ne pas inspecter) la journalisation des accès aux objets dans le Local Security Group ou dans une GPO.

Ce paramètre se trouve dans Computer Configuration, Policies, Windows Settings, Security Settings, Local policies, Audit Policy.

2014-01-03_102510

Active Directory Replication Status Tool

Pour vérifier la santé de l’Active Directory on utilise habituellement un outil

en ligne de commande tel que  REPADMIN.

Microsoft met à disposition un outil graphique, Active Directory Replication Status Tool.

Cet outil s’installe sur plusieurs version d’OS Windows (prérequis .Net Framework 4.0).

Après installation de l’outil, lancez la console.

image

Cliquez sur Refresh Replication Status

Ce type de résultat est retourné:

image

Dans ce cas il n’y a pas d’erreur.

En fonction des erreurs liées au “Tombstone LifeTime”, les informations prendront une couleur diffèrente.

Pour rappel le “Tombstone LifeTime” est de 180 jours depuis Windows 2003 SP1.

On peut modifier les colonnes à afficher par un clique droit dans l’une des colonnes :

image

Le rapport peut être exporté:

image

N’hésitez pas à installer cet outil que vous pourrez télécharger depuis ce lien:

http://www.microsoft.com/en-us/download/details.aspx?id=30005.

Exchange2010 – Erreur lors de l’installation du rôle Hub Transport

Symptôme

Lors d’un déploiement d’Exchange Server 2010 SP2 avec RU4v2 (rollup stocké dans le sous-dossier Updates des sources Exchange), j’ai rencontré l’erreur suivante durant l’installation du rôle Hub :

Service “MSExchange Transport” failed to reach status “Running” on this server.

image

Voici le détail de l’erreur dans le journal Application :

Event ID : 1002
Source : MSExchangeSetup
Task Category : Microsoft Exchange Setup
Level : Error
Error :
The following error was generated when "$error.Clear(); if ($RoleStartTransportService) { start-SetupService -ServiceName MSExchangeTransport }" was run: "Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.".
Service 'MSExchangeTransport' failed to start. Check the event log for possible reasons for the service start failure.

 

Cette erreur à l’installation peut être considéré comme un “classique” d’Exchange 2010 lorsqu’une mauvaise configuration IPv6 est positionnée sur le serveur (cf. ce billet réalisé peu après la sortie d’Exchange 2010 : http://blog.piservices.fr/post/Exchange2010-Erreur-lors-de-linstallation-du-role-de-transport-Hub.aspx).

Néanmoins dans ce cas précis l’erreur n’était pas liée à la configuration IPv6 (interface réseau et clé de registre DisableComponents correctement configurés).

Après investigation l’erreur d’installation s’accompagnait de plusieurs évènements autour du service AD Topology dont le suivant :

Event ID: 2080
Source: MSExchange ADAccess
Task Category:
Topology
Level:
Information
Error:
Process MSEXCHANGEADTOPOLOGYSERVICE.EXE (PID=2386). Exchange Active Directory Provider has discovered the following servers with the following characteristics:
(Server name | Roles | Enabled | Reachability | Synchronized | GC capable | PDC | SACL right | Critical Data | Netlogon | OS Version)
In-site:
dc01.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc02.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc03.domain.lan CDG 1 7 7 1 0 0 1 7 1
Out-of-site:
dc05.domain.lan CDG 1 7 7 1 0 0 1 7 1
dc06.domain.lan CDG 1 7 7 1 0 0 1 7 1

Explication

Après investigation il s’avère que le problème d’installation est dû à un droit manquant sur la stratégie de groupe Default Domain Controllers Policy  pour le groupe Exchange Servers.

Pour rappel le groupe Exchange Servers est créé lors de la phase de préparation de l’annuaire Active Directory pour Exchange 2010 (ou Exchange 2007) et plus exactement via la commande setup.com /PrepareAD.

Lors de la phase de préparation des domaines via la commande setup.com /PrepareDomain la GPO Default Domain Controllers Policy de chaque domaine est modifiée de manière à donner le droit Manage auditing et security log au groupe Exchange Servers.

Dans le cas rencontré ici ce droit était manquant (d’où la présence d’un zéro dans la colonne SACL right lors de la détection des contrôleurs de domaine par le service de détection de la topologie Active Directory).

Résolution

Pour résoudre le problème rencontré la stratégie de groupe GPO Default Domain Controllers Policy est éditée via la console Group Policy Management Editor. Le droit manquant est situé dans l’emplacement suivant :

Computer Configuration / Policies / Windows Settings / Security Settings / Local Policies / user Rights Assignments

image

Il faut modifier le paramètre Manage auditing and security log et y ajouter le groupe nommé “Domaine racine \ Exchange Servers”.

image

Une fois la modification de stratégie de groupe prise en compte (comptez quelques minutes), l’instalation du rôle Hub Transport peut être relancée et cette fois-ci se déroule sans encombres.

Pour aller plus loin, vous pouvez consulter les articles suivants :

http://blogs.technet.com/b/richardroddy/archive/2010/06/16/msexchange-adaccess-dsaccess-errors-and-the-manage-auditing-and-security-right.aspx

http://jasonshave.blogspot.fr/2010/04/dscenosuitablecdc-error-with-exchange.html

http://blog.mattsampson.net/index.php/exchange-hogging-dc-s-and?blog=1

Lync2010 - Déploiement de Lync Server 2010 dans une forêt distante (retour d’expérience)

Introduction

Dans le cadre d’un POC (proof of concept) ou bien tout simplement dans le cadre d’un rapprochement entre deux sociétés (fusion / acquisition), il peut être nécessaire de déployer Lync Server 2010 dans une forêt distante.

S’il s’agit d’un POC, l’intérêt de monter une forêt dédiée à Lync 2010 est généralement de ne pas impacter l’environnement de production (Lync nécessitant une extension du schéma Active Directory) et donc de permettre un retrait / une désinstallation facile de Lync dans l’hypothèse où le produit ne serait pas retenu à l’issue de la phase de test.

S’il s’agit d’une fusion entre deux sociétés ou tout simplement d’une société disposant de plusieurs forêts (reliées entre elles par le biais de relations d’approbation) on déploie généralement Lync dans une seule forêt (la forêt “principale” ou bien la forêt de ressources le cas échéant) pour éviter de multiplier les serveurs.

Quel que soit le cas de figure, à un moment donné l’administrateur se retrouve contraint de donner un accès à des serveurs Lync dans une forêt B sur ses utilisateurs de la forêt A.

Ce billet a pour but de lister l’ensemble des contraintes et actions à prendre en compte dans un tel scénario.

Points à prendre en compte

Les points à prendre en considération (par rapport à un déploiement de Lync en environnement mono-forêt et mono-domaine) sont les suivants :

  • Une relation d’approbation (de type inter forêt) doit exister entre les deux forêts
  • Les comptes utilisateurs de la forêt A doivent être provisionnés dans la forêt B par le biais d’un outil tél qu’ADMT (si la population est réduite) ou bien via un outil de synchronisation de compte tel que FIM (si l’environnement est de plus grande taille)
  • L’outil de provisionnement des comptes doit migrer l'attribut SID du compte source dans l’attribut SIDHistory des comptes cible. Il est conseillé de désactiver les comptes présents dans la forêt cible pour des raisons de sécurité (de la même manière que pour une boîte aux lettres Exchange 2010 de type “linked”)
  • Un script doit ensuite être développé pour copier le SID source dans l’attribut msRTCSIP-OriginatorSid du compte utilisateur
  • Les certificats utilisés sur les serveurs frontaux et Edge Lync 2010 devront être émis par une infrastructure PKI reconnue comme de confiance par les clients des deux forêts

L’intégration du composant Lync au Webmail Exchange 2010 est possible quelle que soit la forêt dans laquelle est déployée Exchange. Si la messagerie Exchange 2010 est déployée dans une forêt distincte de celle de Lync alors les adresses SIP devront être ajoutées manuellement (ou pas script) sur les boîtes aux lettres.

N.B. : Le déploiement de Lync 2010 dans une forêt distante n’a pas d’impact particulier sur le déploiement des services de Mobilité Lync 2010.

SCOM – Active Directory Bind Monitor et GPO

 

Une alerte courante est issue du moniteur “Active Directory Bind Monitor” du management pack AD:

The processing of Group Policy failed. Windows could not authenticate to the Active Directory service on a domain controller. (LDAP Bind function call failed). Look in the details tab for error code and description.

En ouvrant les propriétés de l’alerte (double-clic) et l’onglet Alert Context, on peut voir dans l’exemple ci-dessous le compte incréminé, dans le champ User:

image

l’execution d’une GPO a échoué pour ce compte.

Independement de la solution proposé dans la description de l’alerte, une premiere piste consiste a verifier si le compte en question n’a pas une session restée ouverte sur la machine (ceci meme si le compte est désactivé dans Active Directory). Si c’est le cas, fermez cette session, reseter le moniteur dans SCOM (il s’agit d’un moniteur de type “Manual Reset”), et verifiez par la suite que le problème ne se reproduit pas.

Exchange2010 – Préparation de l’annuaire pour Exchange Server 2010 SP2

La préparation de l’annuaire Active Directory pour le déploiement du service pack 2 d’Exchange Server 2010 est tout à fait classique.

Mise à jour du schéma Active Directory

Dans un premier il faut déployer les extensions de schéma Echange Server 2010 SP2 à l’aide de la commande setup.com /PrepareSchema.

Remarque : Cette opération effectue des modifications sur la partition de schéma de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Schema Admins”.

image

Les extensions de schéma du service pack 2 intègrent de nouvelles classes et de nouveaux attributs. Parmi ces nouveaux attributs il y a notamment 5 nouveaux attributs nommés extensionCustomAttribute1 à extensionCustomAttribute5. Ces attributs supplémentaires peuvent être utilisés pour stocker des propriétés supplémentaires sur les objets destinataires (boîtes aux lettres, groupes, contacts…). Ils sont utilisables avec les commandes PowerShell suivantes :

Ainsi que le document de référence sur les extensions de schéma Exchange Server (document mis à jour suite à la sortie du SP2) :

http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5401

Pour vérifier que le schéma a bien été mis à jour il suffit de vérifier la valeur de l’attribut rangeUpper sur la classe ms-Exch-Schema-Version-Pt à l’aide d’un outil comme ADSIEdit (ou via une requête de type dsquery par exemple).

Suite à la mise à jour du schéma, la valeur de l’attribut rangeUpper passe de 14728 (version Exchange 2010 SP1) à 14732 (version Exchange 2010 avec SP2).

image

Mise à jour de l’organisation Exchange

L’étape suivante consiste à mettre à jour l’organisation Exchange 2010 à l’aide de la commande setup.com /PrepareAd (dans cet exemple l’organisation se nomme PIServices).

Remarque : Cette opération effectue des modifications sur la partition de configuration de l’annuaire Active Directory et par conséquent nécessite l’utilisation d’un compte membre du groupe “Enterprise Admins”.

Pour valider la propagation des modifications apportées à la partition de configuration sur les différents contrôleurs de domaine le plus simple consiste à affichez les propriétés de l’organisation Exchange via ADSIEdit.

L’attribut objectVersion de l’organisation passe de 13214 (Exchange 2010 SP1) à 14247 (Exchange 2010 SP2).

image image

Mise à jour des domaines

Il faut enfin mettre à jour chaque domaine de la forêt Active Directory à l’aide de la commande setup.com /PrepareDomain.

Remarque : Cette opération effectue des modifications sur la partition de domaine du domaine concerné et par conséquent nécessite l’utilisation d’un compte membre du groupe “Domain Admins” dans le domaine concerné.

Suite à l’application du service pack 2 d’Exchange 2010 la valeur de l’attribut objectVersion sur l’objet CN=Microsoft Exchange System Objects présent à la racine du domaine passe à 13040 (cette valeur est identique à celle du SP1 d’Exchange 2010).

image

Déploiement du service pack 2 sur l’ensemble des serveurs

Une fois l’annuaire préparé et les modifications propagées sur l’ensemble des contrôleurs de domaine il est conseillé de mettre à jour les serveurs Exchange 2010 dans l’ordre suivant :

  • Serveurs CAS
  • Serveurs HUB
  • Serveurs Mailbox
  • Serveurs UM

Remarque : les serveurs Edge étant situés en workgroup ils peuvent être patchés en parallèle.

    Si la haute disponibilité est déployée sur l’environnement il faudra bien sur déployer le package successivement sur chaque nœud en pensant bien à isoler le nœud en train d’être patché (mode “drain” sur les serveurs CAS et/ou HUB en load balancing matériel ou NLB, mode maintenance sur un nœud appartenant à un DAG).

    Le déploiement du patch sur un serveur nécessite que les outils d’administration Exchange 2010 (console MMC et Powershell) soient fermés. De plus les services tiers accédant aux services Exchange (agent de sauvegarde, agent antivirus dédié à Exchange…) doivent également être arrêtés.

    Si certains services ou outils bloquent le déploiement du Service Pack alors une fenêtre équivalent à celle-ci s’affichera à l’issue de test des prérequis.

image

Attention, pas retour d’expérience, le service pack 2 peut mettre jusqu’à 1h, voir 1h30 pour se déployer sur certaines configurations.

2008 R2 - Utilisation des comptes de services gérés

Parmi les nouveautés de Windows Server 2008 R2 et au niveau du composant Active Directory on trouve les comptes de services gérés (Managed Service Accounts).

Plusieurs applications SQL Server et IIS reposent sur des services qui doivent parfois être démarrés avec des comptes de domaines pour des besoins spécifiques. L’administration de ces comptes, de leurs mots de passe ainsi que des SPN peut s’avérer complexe et peut affecter la disponibilité de l’application.

L’utilisation des comptes de services gérés réduit la charge administrative quant à la gestion des mots de passe et des SPN (nom principal de service) tout en assurant la disponibilité de ces applications et réduisant les risques lié à la modification des mots de passe.

Pré-requis

Pour pouvoir utiliser les comptes de services gérés :

- Les ordinateurs hébergeant les applications à configurer doivent être équipés de Windows Server 2008 R2 ou Windows 7,

- Les domaines dont le niveau fonctionnel est Windows Server 2008 R2 supportent nativement la gestion automatique des mots de passe et des SPN,  

- Si le domaine n’est pas au niveau fonctionnel Windows Server 2008 R2 mais que le schéma Active Directory a été mis à jour au niveau Windows Server 2008 R2 les comptes de services gérés peuvent être utilisés, la gestion automatique des mots de passes de ces comptes sera possible mais pas la gestion automatique des SPN

- Pour utiliser les comptes de services gérés dans des domaines Windows Server 2008, Windows Server 2003 ou des domaines mixtes il faut tout d’abord procéder aux actions suivantes :

           1- Exécuter adprep /forestprep au niveau de la forêt AD

           2- Exécuter adprep /domainprep dans chaque domaine où on souhaite utiliser le comptes de services gérés

           3- Avoir un contrôleur de domaine Windows Server 2008 R2 ou Windows Server 2008 avec Active Directory Management Gateway Service ou Windows Server 2003 avec Active Directory Gateway Service, Active Directory Management Gateway Service permet l’utilisation des commandes PowerShell nécessaires à la gestion des comptes de services gérés

- Pour utiliser les commandes PowerShell nécessaires à l’administration des comptes de services gérés au niveau des ordinateurs clients sur lesquels les applications doivent être configurées on doit avoir installé le Framework .NETainsi que le module Active Directory pour Windows PowerShell

Installation des pré-requis sur Windows Server 2008 R2

  1. Démarrer la console Server Manager

image

  1. Sélectionner Features puis cliquer sur Add Features   

image 

  1. Sélectionner  .NET Framework 3.5.1 Features

image 

  1. Sélectionner  Active Directory module for Windows PowerShell sous Remote Server Administration Tools |  Role Administraion Tools | AD DS and AD LDS Tools

image 

  1. Cliquer sur Next

image 

  1. Cliquer sur Install

image 

  1. Redémarrer le serveur si nécessaire

 

Installation des pré-requis sur Windows 7

  1. Télécharger Remote Server Administration Tools for WIndows 7
  2. Installer la mise à jour
  3. Ajouter les fonctionnalités .NET Framework 3.5.1 et le module Active Directory module for Windows PowerShell
  4. Redémarrer l’ordinateur

 

Création et configuration d’un compte de service géré

  • Ouvrir une invite PowerShell  Active Directory

image 

  • Créer le compte de services en exécutant la commande suivante :
    New-AdServiceAccount <Nom Du Compte>  -AccountPassword (ConvertTo-SecureString –AsPlainText “<mot de passe>” –Force) –Enabled $true –Path “CN=Managed Service Accounts,DC=<Domain Name>,DC=COM”

image 

  • Associer le compte de service à l’ordinateur client en exécutant la commande suivante :
    Add-ADComputerServiceAccount –Identity <Nom Ordinateur> –ServiceAccount <Nom du compte>

image 

  • Installer le compte de service sur l’ordinateur client (cette commande soit être exécutée sur le poste qui utilisera le compte de service géré)
    Install-ADServiceAccount –Identity <Nom du compte>

image 

  • Vérifier que le compte de service à été bien affecté au compte de la machine au niveau Active Directory en explorant les propriétés de l’objet ordinateur en question avec ADSI Edit et en cherchant l’attribut msDS-HostServiceAccount   

 image

Utilisation du compte de service

Nous allons maintenant utiliser un compte de service géré pour démarrer le services SQL Server Reporting Services au niveau d’un serveur Windows Server 2008 R2.

  • Double cliquer sur le service SQL Server Reporting Services au niveau de la console Services 

 image

  • Au niveau de l’onglet Log On cocher This account et cliquer sur Browse afin de localiser le compte de service, ou taper le nom du compte au format <Nom du Domaine>\<Nom du compte>$ , laisser le mot de passe vide et cliquer sur Apply puis sur Ok     
    Attention : si vous tapez le nom du compte à la main il faut ajouter un $ à la fin. 
    image  
  • Démarrer ou redémarrer le service

image 

  • Vérifier que le service a bien démarré malgré la fait que le mot de passe n’a pas été saisi !

Pour plus de détails, vous pouvez consulter les articles suivants :