PI Services

Le blog des collaborateurs de PI Services

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 :

2008 R2 – Resynchroniser l’heure d’un domaine AD avec une source de temps externe

Pourquoi synchroniser l’heure ?

Au sein d’un domaine Active Directory, tous les postes de travail et serveurs membre synchronisent leur horloge auprès du contrôleur de domaine ayant le rôle d’émulateur PDC (Primary Domain Controller) que joue le rôle de serveur de temps pour le domaine.

Le bon fonctionnement de certains protocoles comme Kerbros v5, utilisé pour authentifier les utilisateurs au sein du domaine et assurer l’accès aux ressources partagées, est fortement dépendant de la synchronisation horaire entre les machines.

En effet, la RFC 4120 stipule que le décalage acceptable entre deux hôtes est de l’ordre de 5 minutes environ.

Each host on the network MUST have a clock which is "loosely synchronized" to the time of the other hosts; this synchronization is used to reduce the bookkeeping needs of application servers when they do replay detection.  The degree of "looseness" can be configured on a per-server basis, but it is typically on the order of 5 minutes.

C’est d’ailleurs cette valeur qui est positionnée par défaut depuis Windows 2000 sur le service Kerberos (cf. article KB837361 de la base de connaissance Microsoft).

Lorsque le décalage entre deux postes dépasse les 5 minutes, aucune authentification n’est possible via le protocole Kerberos. Ceci est particulièrement gênant lorsque la machine décalée correspond à un contrôleur de domaine ou à un serveur de fichiers.

Il convient donc de s’assurer que tous les postes et serveurs sont capables de joindre l’émulateur PDC et de mettre à jour leur horloge (lorsque cela n’est pas le cas, des erreurs W32Time sont générées par le service de temps Windows sur les postes de travail).

Il est également très important de synchroniser l’émulateur PDC avec une source de temps externe valide de manière à ce que l’heure propagée au sein du domaine soit la plus proche possible de l’heure exacte.

Or de trop nombreuses entreprises ne font pas attention à ce point qui n’est pourtant pas un détail car une juste synchronisation de l’horloge simplifie la vie des utilisateurs qui sont très friands de services Web où l’horodatage a une importance certaine (tweeter, myspace ou facebook pour ne pas les nommer).

D’un point de vue IT, la synchronisation de tous les équipements informatique (postes de travail, serveurs, mais aussi NAS, pare-feu et autres équipements réseau) auprès d’une seule et même source de temps permet de simplifier énormément les opérations de dépannage car les fichiers de logs sont alors parfaitement synchrones.

Quelle source de temps utiliser ?

Par défaut tout poste Windows est configuré pour synchroniser son horloge auprès du serveur “time.windows.com”.

De nombreux serveurs NTP “libres” sont accessibles en France et dans le monde (notamment les serveurs NTP des grandes universités françaises). De plus la plupart des FAI proposent à leurs clients un service de synchronisation de temps.

Il est néanmoins un projet qui se distingue de tous les autres par son ampleur : NTP Pool Project. Ce projet a pour objectif de proposer gratuitement un cluster de serveurs de temps gigantesque (1873 serveurs de temps à l’heure où j’écris ces lignes).

image

L’avantage de ce projet est qu’il propose également une configuration régionalisée par continent et par pays. Ainsi pour synchroniser votre PDC avec des serveurs de temps uniquement situés en France (env. 130 serveurs), il suffit de configurer le serveur pour pointer vers la liste de FQDN suivants :

  • 0.fr.pool.ntp.org
  • 1.fr.pool.ntp.org
  • 2.fr.pool.ntp.org
  • 3.fr.pool.ntp.org

Comment procéder ?

Pour reconfigurer l’horloge d’un poste sous Windows et notamment celle d’un émulateur PDC, les commandes suivantes peuvent être utilisées :

  • La commande net time fonctionne sur un contrôleur de domaine Windows 2000, 2003 et Windows 2008 (cette commande est maintenant obsolète avec Windows Server 2008 R2)
  • La commande w32tm doit impérativement être utilisée si le contrôleur de domaine exécute Windows Server 2008 R2

Avec la commande net time, voici la commande à saisir pour reconfigurer l’horloge du serveur de temps (PDC) vers le cluster “pool.ntp.org” français :

net time /setsntp:"0.fr.pool.ntp.org 1.fr.pool.ntp.org 2.fr.pool.ntp.org"

Pour vérifier la modification il est possible d’exécuter la commande net time /querysntp. Pour forcer la resynchronisation du PDC, il suffit de redémarrer le service de temps Windows (net stop w32time | net start w32time).

Sur un contrôleur de domaine Windows Server 2008 R2, la commande suivante doit être exécutée pour arriver au même résultat :

w32tm /config /update /manualpeerlist:"0.fr.pool.ntp.org,0x8 1.fr.pool.ntp.org,0x8 2.fr.pool.ntp.org,0x8 3.fr.pool.ntp.org,0x8" /syncfromflags:MANUAL

Cette commande doit être suivie des commandes suivantes pour que la configuration soit prise en compte et la resynchronisation initiée :

  • w32tm /config /update
  • w32tm /resync

Remarque : Il est également possible de le service de temps Windows pour forcer la resynchronisation (net stop w32time | net start w32time).

Les points à valider

Quelques points doivent être validés avant d’effectuer la modification sur l’émulateur PDC :

  • Le port du protocole NTP doit être ouvert depuis l’émulateur PDC vers Internet (il s’agit du port UDP 123)
  • Si le contrôleur de domaine est virtualisé, il convient de désactiver la synchronisation horaire entre la machine virtuelle et l’hôte physique (sinon l’heure synchronisée à travers le réseau sera toujours réécrite par celle de la machine hôte).

    Voici un exemple pour un contrôleur de domaine (émulateur PDC) virtualisé avec Hyper-V 2.0 (version d’Hyper-V intégrée à Windows Server 2008 R2) :

    image 

Comment mettre à jour les clients ?

En ce qui concerne les postes membres du domaine, aucune opération manuelle n’est nécessaire, le service de temps Windows étant capable d’effectuer les mises à jour automatiquement.

Pour les postes configurés en groupe de travail, il convient d’exécuter la commande suivante, puis de redémarrer le service de temps Windows :

w32tm /config /update /manualpeerlist:"ntp.ad.lan,0x8"
/syncfromflags:MANUAL,DOMHIER

Remarque : Il est conseillé de créer une entrée DNS de type CNAME (alias) pointant vers l’émulateur PDC (par exemple ntp.domainead.local). Cela permet de pouvoir reconfigurer très simplement tous les postes de travail hors domaine en cas de bascule du rôle FSMO.

Dans le scénario idéal, tous les équipements réseau (commutateurs, routeurs, pare-feu, imprimantes réseau, bornes WiFi, serveurs NAS…) doivent également pointer vers le FQDN ntp.domainead.local de manière à assurer un horodatage cohérent.

Pour aller plus loin…

Quelques liens utiles pour aller plus loin :