Articles Tagués ‘Windows Server 2012 R2’

 

Introduction à l’outil CLI « APPCMD.exe »

AppCmd.exe est un Outil en ligne de commande (CLI) fourni avec le rôle Windows Server « IIS ».

C’est un outil d’administration très puissant qui vous permet (entre autres) de :

Créer, configurer et gérer des Sites IIS

Créer, configurer et gérer des Applis et Pools d’Applications IIS

Créer, configurer et gérer des Virtual Directories (Répertoire virtuels IIS)

Démarrer, arrête et recycler les Pools d’application

Afficher/Visualiser des informations sur les Worker Process

…Etc

Pour finir, AppCmd.exe vous permet non seulement de réaliser toutes les tâches d’administration classiques que vous pouvez effectuer depuis l’outil graphique IIS Manager (InetMgr.exe) mais aussi d’industrialiser /d’automatiser à l’aide de scripts Bat(ch) toute tâche d’administration /configuration fastidieuse et répétitive.

 

Définir le chemin par défaut d’AppCmd.exe

Les Best Practices IIS consistent à définir (forcer) le chemin by default de l’outil AppCmd.exe au niveau de la %var% d’environnement %PATH%, cette opération vous faciltera l’utilisation de l’outil car vous pourrez l’appeler depuis n’importe quel CMD Folder et vous n’aurez donc plus à faire du CD (Change Directory) à chaque fois que vous souhaitez appeler /lancer AppCmd.exe

Pour ce faire, la commande ci-dessous est à exécuter sur tous les serveurs IIS Server faisant parti de votre infrastructure système MS (Windows Server 2008 et ultérieur).

SETX PATH « %PATH%;%WINDIR%\System32\inetsrv » /M

Saisissez ensuite la commande suivante pour vérifier que la valeur de la variable %PATH% a bien été Updatée :

Echo %PATH%

Vous pouvez également vérifier le contenu de la variable %PATH% depuis les propriétés systèmes du serveur IIS > Variables d’environnement

Et voilà le tour est joué :).

Stay Connected, plusieurs HowTo IIS sont en cours de préparation.

N’hésitez pas à vous abonner à mon Blog pour rester informé de toute nouvelle publication ^^

See you soon.

#HK

 

Hello GPO Guys,

Une « Trick » sur les GPOs qui peut vous être utile si vous faites régulièrement des audits GPOs.

J’ai récemment audité une infrastructure système « Windows Server 2012 R2 /2016 » assez complexe avec un peu plus de 1000 GPOs implémentées.

La phase /Step 1 de mon audit GPO était de lister et supprimer (après validati/on du client) toutes les GPOs vides, le but étant de réduire rapidement le nombre de GPOs de domaine « inutiles » (MAIS qui sont quand même répliquées dans tous les sens, lors de la réplica AD ^-^).

Alors comment ça marche ?

Lancez PowerShell ISE depuis un D(omain) C(ontroller) ou une machine d’administration ayant les outils RSAT ADDS installés et Copiez /Collez le bloc de code PS suivant :


$GPOVides = Get-GPO -All
foreach ($item in $GPOVides)
{
if ($item.Computer.DSVersion -eq 0 -and $item.User.DSVersion -eq 0)
{
write-host $item.DisplayName est vide !
}
}


Dans l’exemple suivant, le script me retourne les GPOs listées ci-dessous :

Notez que ce script PS est disponible en téléchargement gratuit sur la Gallery TechNet.

Téléchargez-le ici.

A bientôt

HK T___T

Une astuce AD qui peut vous être utile lors de vos audit Active Directory 🙂

Comment lister tous les comptes d’Ordinateurs Active Directory qui sont « Désactivés » ?

La réponse est simple, lancez Windows PowerShell (en tant qu’Admin) depuis un DC (Writable) du domaine ou serveur d’administration ayant les outils RSAT AD DS d’installés, et exécutez la commande suivante :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Ft -AutoSize

Vous pouvez trier (par Date) le résultat retourné par la commande en rajoutant un « Pipe » Sort-Object -Descending, la commande devient donc :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Sort-Object -Descending | FT -AutoSize

Enfin, le résultat (liste complète des Comptes Ordinateurs AD Désactivés) peut être exporté vers un fichier TXT ou CSV, et ce via l’utilisation d’un Pipe suivi de la Cmd-Let Export-CSV Chemin_d’Export, la commande finale est donc :

Get-ADComputer -Filter {(name -like « * ») -and (enabled -eq $FALSE)} -Properties * | Select Name, LastLogonDate | Sort-Object -Descending | Export-CSV C:\Liste_CompteOrdiAD_Desactives.csv

Hello RDS Guys,

Je viens de créer un partage « OneDrive » dans lequel j’ai ajouté tous les scripts (développés par mes soins) liés au rôle RDS et au protocole RDP.

Ils sont accessibles en free download, à l’URL suivante :

https://1drv.ms/f/s!Agu0mgqr6F71pUWk4wK4fwu6H5_Q

Enjoy !

HK

Si vous cherchez un moyen pour lister tous les comptes utilisateurs AD « Désactivés », eh bien, The « Best & Easiest » way est l’utilisation de la Cmd-Let « Search-ADAccount », fournie avec le module PowerShell « ActiveDirectory »

Comment ça marche ?
  • Lancez Windows PowerShell (en tant qu’Administrateur) depuis un DC (Domain Controller) ou un serveur d’administration ayant les outils RSAT AD DS installés, et saisissez ensuite la commande suivante :
    • Search-ADAccount -AccountDisabled

That’s all :).

Connaitre son environnement

Lors de la migration d’un environnement Active Directory vous risquez de rencontrer des difficultés avec les éléments qui dépendent de votre annuaire. Citons par exemple Microsoft Exchange dont les services sont très dépendants du catalogue global. Ces difficultés sont liées en général à des oublis lors de la mise à niveau, surtout dans de grandes entreprises, où la personne en charge de la migration, n’a pas forcément conscience de l’ensemble des applicatifs s’appuyant sur l’AD. Afin de préparer au mieux votre déploiement, il est recommandé de réaliser un inventaire de votre environnement et des services qui en dépendent.

Documentez les éléments suivants :

  • Liste des domaines avec le niveau fonctionnel, les approbations de domaine ou de forêt.
  • Liste des contrôleurs de domaine avec les rôles (Serveur de fichiers et d’impression, DNS, DHCP, KMS,…) et les applications installées.
  • Lister les serveurs qui disposent du catalogue global, des rôles FSMO, serveurs tête de pont pour la réplication inter-sites.
  • Liste des serveurs DNS, liste des zones DNS, redirecteurs, redirecteurs conditionnels et zone de Stub.
  • Liste des sites, sous réseau et lien de site (performances, plage de disponibilités).
  • Liste des équipements qui utilisent l’annuaire LDAP (serveur Proxy Web avec authentification, serveur Radius, solution VPN, copieurs multifonctions).
  • Liste des applications utilisant l’authentification Active Directory ou exécutant des requêtes LDAP (inspecter les applications qui utilisent le compte et le mot de passe Windows comme information de connexion).

Il est recommandé d’utiliser les services DNS sur vos contrôleurs de domaine. Il est préférable d’utiliser des zones DNS intégrés à Active Directory et acceptant les mises à jour sécurisées. Les zones intégrées Active Directory bénéficient de la réplication multi-maître AD et sont donc toutes accessibles en écriture. Il n’est pas obligatoire que tous vos contrôleurs de domaines soient serveur DNS. Dans un environnement Multi-Site, si vous prévoyez d’installer un contrôleur de domaine afin de garantir la disponibilité du service, il est primordial d’assurer également la résolution de nom sur ce site. Dans une forêt Active Directory il existe une zone DNS propre à la forêt « _mstsc » et une zone pour chaque domaine de la forêt. Il est recommandé de répliquer la zone de la forêt sur tous les DCs de la forêt et la zone du domaine sur tous les DCs du domaine. Les problèmes DNS sont à l’origine de beaucoup de problèmes Active Directory.

Note importante : les applications suivantes sont fortement liées à l’AD (liste non exhaustive)

* Exchange Server

* Lync /Skype for Business

* System Center

* Services de synchronisation de profil SharePoint

Pour vous aider à préparer votre déploiement, vous pouvez utiliser les informations suivantes.
Vous pouvez consulter la liste des domaines de votre forêt depuis la console « Domaines et Approbations Active Directory» accessible via l’outil « Domain.msc ». Dans notre laboratoire la forêt comporte un domaine unique.

Vous pouvez utiliser la commande PowerShell suivante pour lister tous les domaines de la forêt :

Get-ADForest | Select Domains

Déterminer les catalogues globaux pour chaque domaine, depuis la console « Utilisateurs et Ordinateurs Active Directory », sur l’unité d’organisation « Domain Controllers » :

La commande PowerShell suivante permet de lister les DCs qui sont catalogues globaux :

Get-ADForest | Select GlobalCatalogs

Pour le niveau fonctionnel des domaines et de la forêt, utilisez la console « Domaines et approbations Active Directory ». Il suffit de faire un clic droit sur le nom du domaine ou sur « Domaines et approbations Active Directory », puis sélectionnez « Augmenter le niveau fonctionnel du domaine/de la forêt ».

Pour déterminer le niveau fonctionnel de la forêt avec PowerShell, utilisez la commande :
Get-ADForest | select Forestmode

Pour le niveau fonctionnel du domaine, utilisez la commande :
Get-ADDomain | select Domainmode

Vous trouverez la liste des zones DNS hébergées sur un contrôleur de domaine à partir de la console DNS (sauf si vos DCs ne font pas office de DNS Server).

Vous pouvez vérifier si la zone est intégrée à Active Directory dans les propriétés de la zone. Sur l’image ci-dessous, vous pourrez déterminer les paramètres de réplications de la zone. La flèche indique les options de mise à jour de la zone.

Si la zone DNS hébergée sur votre DC n’est pas intégrée à l’annuaire Active Directory, vous pouvez modifier le paramètre depuis cette page. Le changement en zone intégrée à l’AD n’impacte pas la production.

Vous trouverez également le détail des relations d’approbations en ouvrant les propriétés du domaine en question, sur la page « Approbations ».

Pour lister les rôles installés sur un serveur, utilisez la commande PowerShell suivante :

Import-Module ServerManager

Get-WindowsFeature | Where-Object {$_.Installed -eq « Installed »}

La console « Sites et Services Active Directory », vous permettra de faire le point sur la partie Sites, Réseaux et Lien de sites.

Pour déterminer si un contrôleur de domaines a été défini comme serveur tête de pont pour la réplication intersites, ouvrez les propriétés du serveur. Dans la page « Général », vous pourrez vérifier si le DC en question est serveur tête de pont.


Cet article est un extrait de l’eBook (Step-by-step guide) : Migrer son infrastructure Active Directory vers Windows Server 2012 et 2012 R2

 

 

S’applique à : Windows Vista > Windows 10 | Windows Server 2008 > Windows Server 2016

Par défaut, une machine Windows (Client ou Server) sur laquelle les connexions Bureau à distance ont été activées /autorisées, écoute sur le port 3389 (TCP), ce dernier correspond au protocole RDP (Remote Desktop Protocole).

Pour le constater, ouvrez une Session (locale) sur une machine (Physique ou Virtuelle) ayant le RDP activé, lancez l’invite de commande (CMD.exe) en tant qu’Administrateur et saisissez NetStat -a, enfin notez l’existence du port d’écoute 3389

1

 

Protocole RDP : Vulnérabilité 

L’utilisation du port par défaut (3389 :: TCP) présente plusieurs vulnérabilités au sein d’un S.I et offre aux Hackers la possibilité d’effectuer plusieurs types d’attaques, notamment :

  • Attaque par Brute-Force
  • Attaque par DoS (Denial of Service)

En effet, tous les hackers qui s’en prennent aux connexions RDP s’appuient sur le port 3389 pour provoquer un DoS ou brute-forcer une machine Windows.

A l’aide de n’importe quel Network Sniffer, un Hacker peut capturer les RDP Data et facilement localiser la(es) machine(s) écoutant sur le port TCP 3389.

Prenons l’exemple de la vulnérabilité MS12-020, celle-ci a été détectée dans le protocole RDP et permettant un déni de service, et ce via l’utilisation du port 3389.

Comme le montre la vidéo ci-après, à l’aide d’un simple outil de Hacking (MSF « MetaSploit Framework » fourni avec KALI Linux), vous pouvez provoquer un DoS, et rendre (en quelques secondes…) un serveur RDSH (Remote Desktop Session Host) ou une Machine d’Administration écoutant sur le port 3389 indisponible :

 

Recommendations

Il est fortement recommandé de changer le port RDP par défaut [TCP : 3389] et en définir un autre « Personnalisé ».

Vous pouvez utiliser un numéro de port situé entre 1025 et 65535

Dans l’exemple suivant, le port 9933 sera configuré.

 

HowTo : Changer le port RDP par défaut

Le port RDP par défaut peut être changé via :

Le Registre (BDR : Base De Registre)

Lancez l’outil RegEdit.exe (depuis le menu Démarré /Exécuté ou Welcome Screen)

Naviguez jusqu’au : HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp

Localisez et éditez la clé DWORD « PortNumber »

Définissez un nouveau port (Base > Décimale)

2

 

GPO (Group Policy Objects)

Créez une nouvelle GPO ou éditez une GPO existante, naviguez ensuite jusqu’au : Configuration Ordinateur | Préférences | Paramètres Windows

Faites un clic-droit sur « Registre » et sélectionnez « Elements Registre »

Remplissez les champs comme suit :

3

Liez votre GPO aux OUs contenant les objets AD « Ordinateurs » correspondant à vos serveurs RDSH ou Poste d’Admin.

Enfin, lancez un GpUpdate.exe depuis un serveur sur lequel la GPO a été linkée et enjoy the change :).

 

Script PowerShell

5

Un script PowerShell a été développé (par mes soins :)) et uploadé sur la Gallery TechNet > Scripts Center.

Il vous permet de changer le numéro de port RDP par défaut en deux clics, il suffit de l’exécuter, renseigner le nouveau numéro de port RDP et valider le changement en cliquant sur la touche « Entrée » du clavier.

6

Ce script est téléchargeable ici.

 

L’outil « RDP Port Configurator »

Je work actuellement sur outil GUI que j’ai nommé « RDP Port Configurator » basé sur le script PowerShell décrit ci-dessus.

Il sera disponible en téléchargement gratuit sur BecomeITExpert.com, so Keep in touch :).

L’outil RDP Port Configurator ressemble à l’image ci-après :

7

 

Note importante 

Downtime

Tout d’abord, il faut noter que le changement de port RDP par défaut nécessite un redémarrage de votre machine. S’il s’agit d’un changement sur une ou plusieurs machines de production, pensez à planifier ce changement et surtout le downtime qui aura lieu lors du reboot de la machine.

Nouvelle syntaxe de connexion RDP

Quand vous utilisez un port autre que le 3389 pour les connexions Bureau à distance, vous devez le spécifier après l’adresse (IP ou Hostname) de l’ordinateur distant, dans notre cas la connexion bureau à distance se fait sur Nom_Serveur_RDS:9933

4

 

Extrait de l’eBook [RDS 2012 R2 – Sécurisation et Hardening : Guide du Consultant]

 

S’applique à : Windows Server 2008 /2008 R2, 2012 /2012 R2 et 2016 | Windows Seven, Windows 8/8.1 et Windows 10

La « Tip of the Week » est un HowTo pour afficher la date du dernier redémarrage de Windows (Server & Client).

Ayant travaillé sur plusieurs projets d’Audit Infrastructure (Windows Server, P2T, Active Directory…) ces dernières années, j’ai pu constater que la plupart des serveurs Windows Server présentant des problèmes de stabilités et/ou dysfonctionnement n’ont aucun « redémarrage périodique » de planifié. Si nécessaire, ces serveurs sont donc redémarrés manuellement.

Redémarrer une machine Windows consiste à faire deux clics de souris ou saisir 2 mots depuis le Menu « Démarrer », mais quand il s’agit d’un serveur de production, l’opération devient plus compliquée : négocier, planifier le redémarrage du serveur, astreinte possible, intervention post-redémarrage possible (si effets de bord post-reboot) …

C’est la raison pour laquelle, le redémarrage d’un serveur Windows Server est souvent une tâche oubliée par les IT Admin /Ing de prod allergiques à ce type d’opération et ne voulant pas prendre le risque, résultat : lors de plusieurs audits réalisés chez différents clients (Banques, Assurances, Grand groupes de l’industrie …), j’ai souvent constaté que :

Plusieurs serveurs (quelques dizaines voire des centaines) n’ont pas été redémarrés depuis plusieurs mois voire plusieurs années (côté Banques & Assurances)

Les serveurs « en attente de redémarrage » présentent toujours des problèmes de stabilité au niveau de certains Services /Fonctionnalités Windows /Couches Applicatives spécifiques

Les serveurs qui n’ont pas été redémarrés hébergent pour la plupart des services /applications critiques (Standards & Métiers)

De plus, un Serveur Windows Server en attente de redémarrage (suite à l’installation de mises à jour Windows par exemple) peut bloquer plusieurs actions telle que l’ajout de nouvelles fonctionnalités /Services /Rôles /Apps, bloque l’utilisation de certaines fonctions /options et ce au niveau de plusieurs Snap-ins, il peut également bloquer (dans certains cas) l’accès distant à différents services …

Vous aurez compris, connaître la date du dernier redémarrage d’un serveur est une information précieuse qui peut vous aider à cerner un ou plusieurs problèmes présents celui-ci.

Ci-après, les différentes techniques vous permettant d’afficher la date du dernier reboot de Windows Server et Client.

Vous pouvez connaître la date du dernier redémarrage d’un Windows (Server & Client) via l’utilisation de différents outils /méthodes, à savoir :

Outil WMIC.exe

Windows PowerShell

Outil SystemInfo.exe

Script PowerShell

 

Via l’outil « WMIC.exe »

Utilisez la commande suivante : WMIC OS Get LastBootUpTime

1

Via Windows PowerShell

Utilisez la commande suivante : Get-CimInstance -ClassName Win32_OperatingSystem | Select CSName, LastBootUpTime
2

Via l’outil « SystemInfo.exe »

Utilisez la commande suivante : SystemInfo | Find /i « Heure de démarrage du Système »

Note : pour les OS en EN utilisez plutôt la commande suivante : SystemInfo | Find /i « System Boot Time »

3

Via Script (PS)

Un script PowerShell a été uploadé par « Gary L Jackson« , sur  la TechNet Gallery et disponible en téléchargement ici.

 

J’espère que cette astuce pourra vous être utile J

A bientôt.

ScriptGuyPic

S’applique à : RDS Windows Server 2012 R2, RDS Windows Server 2016, Windows 8(.1), Windows 10

SniffPassword

Microsoft a apporté plusieurs améliorations en matière de sécurité au couple d’OS {Windows Server 2012 R2 & Windows 8.1} pour les protéger contre les attaques PtH (Pass-the-Hash). Les mots de passes des comptes utilisateurs ainsi que leur Hashes sont généralement stockés sur le Disque et la Mémoire du Poste de travail /Serveur, si votre machine est compromise, vos informations d’identification peuvent être réutilisées par un Hacker pour accéder à d’autres systèmes /plateformes /services critiques sans que vous soyez au courant.

Introduit avec Windows Server 2012 R2, la fonctionnalité « Restricted Admin Mode » ou « Mode d’Administration Restreinte » a été conçu pour protéger les comptes Administrateurs (locaux et du domaine) contre ce type d’attaque en s’assurant que les informations d’identification saisies lors d’une connexion Bureau à distance ne soient mémorisées et stockées dans la mémoire de la machine distante, qui peut potentiellement être compromise.

Quelques scénarios typiques

Equipe Help Desk utilisant un compte « Administrateur » pour effectuer du support N1/N2 à distance (via RDP) sur les machines des utilisateurs du réseau

Equipe IT Admins utilisant un compte « Administrateur du Domaine » pour effectuer du support N3 à distance (via RDP) sur des serveurs Membres.

Processus d’ouverture de Session RDP

Lorsque vous établissez une Connexion Bureau à distance sur une machine distante, vous êtes invités à vous authentifiez : Apparition de la fameuse boite de dialogue « Sécurité de Windows« :

LogOnWindows

L’authentification se fait dans un premier temps avec le service local RDP via le Process « Remote Interactive Logon ». Dans ce contexte, le mot « Interactive » signifie que l’utilisateur saisi « physiquement » son nom d’utilisateur et son mot de passe associé.

Le Service RDP tente ensuite d’ouvrir une Session Réseau sur la machine distante pour vérifier si l’utilisateur est autorisé à s’y connecter/accéder ou pas. Lors de cette phase, aucune information d’identification n’est requise. En effet, le ticket Kerberos ou Hash NTLM ayant été créés lors de l’ouverture de session initiale peuvent être utilisés pour l’authentification via réseau.

Une fois authentifié par le service RDP de la machine distante, les informations d’identification de l’utilisateur sont envoyées à travers un canal sécurisé vers la machine distante, l’ouverture de session « Interactive » a lieu ce qui permet à l’utilisateur distant de voir et accéder au Bureau à distance.

Prérequis

La fonctionnalité « Restricted Admin Mode » est supportée uniquement par les OS suivants :

OS Server : Windows Server 2012 R2 et Windows Server 2016

OS Client : Windows 8.1 et Windows 10

Donc avant de lancez une Connexion Bureau à distance en mode « Restricted Admin », assurez-vous que celle-ci est établie depuis et vers un des OS cités ci-dessus.

Dois-je utiliser le mode « Restricted Admin » ?

Si vous souhaitez restreindre les accès Bureau à distance sur des machines pouvant présentées un problème (machine présentant des problèmes de stabilité, potentiellement compromise, infectées par des virus…), vous pouvez envisager l’activation du mode « RestrictedAdmin », car comme expliqué ci-haut, vous pouvez être sûre que vos infos d’identifications ne peuvent être réutilisées par un programme malveillant ou un Hacker pour s’introduire sur d’autres machines du réseau jugées « critiques » comme les DC, BDD, Filers …

Cependant, certaines « Best Practices » de l’éditeur soulignent une préférence pour le « Hardening d’OS » incluant la mise en place de stratégies de sécurité pour renforcer la sécurité des comptes Administrateurs (locaux et du domaine), comme par exemple :

Le compte « Administrateur du Domaine » doit uniquement être utilisé pour s’authentifier sur les DCs pour gérer et administrer l’infrastructure AD et JAMAIS pour administrer les serveurs membres, les machines des utilisateurs du réseau …

Chaque machine du réseau doit avoir un compte « Administrateur » et mot de passe unique pour les besoins de gestion, d’administration et support

Comment utiliser le mode « Restricted Admin » ?

Le mode « Restricted Admin » est représenté par un paramètre de l’outil MSTSC.exe (Application Cliente : Connexion Bureau à distance).

Cette fonctionnalité correspond au paramètre /RestrictedAdmin, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarré et constatez la disponibilité du mode « /RestrictedAdmin »:

MSTSCPI

Activer ou Désactiver le mode « Restricted Admin » 

Le Mode « Restricted Admin » est désactivé par défaut.

Pour activer cette fonctionnalité, une nouvelle clé doit être créée au niveau du BDR (Base de Registre), voir les paramètres suivants:

Chemin : HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Vous pouvez également activer cette fonctionnalité d’une manière centralisée sur un ensemble de serveurs /postes de travail via GPO, et ce via l’utilisation du paramètre de Stratégie de groupe suivant :

Chemin : Configuration Ordinateur | Stratégies | Modèles d’administration | Système | Délégation d’informations d’identification

Paramètre : Limiter la délégation d’informations d’identification à des serveurs distants

Valeur du paramètre : Activé

Une fois activé, si vous établissez une Connexion Bureau à distance (en mode Normal sans le paramètre /RestrictedAdmin) sur un serveur distant, le message suivant apparaît:

RestrictedAdminIssue

Maintenant, essayez de vous connecter à votre machine distante via l’utilisation de la commande : MSTSC /RestrictedAdmin

Note : Cette commande peut être lancée depuis le Menu Démarrée ou l’Invite de commande (CMD.exe)

Comme illustré dans l’image ci-après, la connexion Bureau à distance avec le mode « RestrictedAdmin » renforcé permet l’ouverture de la Session Bureau à distance :

AccèsBàD_OK

Limitations du mode « Restricted Admin »

Comme expliqué précédemment, quand le mode « Restricted Admin » est activé, l’utilisateur authentifié sur la machine distante n’a pas la possibilité de se connecter sur d’autres machines ni ressources du réseaux,
En effet, la délégation étant restreinte, les connections vers les autres machines s’effectuent via le compte d’ordinateur local.

Vous risquez (par exemple) de ne pas pouvoir vous connecter à un lecteur réseau depuis une Session Bureau à distance.

Dans l’exemple suivant, une Connexion Bureau à distance (en mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a échouée (pas de délégation d’informations d’identification):

SrvPool_N.OK

Cette fois ci, une Connexion Bureau à distance (en mode normal : sans le Mode Restricted Admin) a été ouverte sur le DC. Le Gestionnaire de Serveur du DC a été lancé et une tentative de Connexion sur le serveur distant RDS01 a réussie (délégation d’informations d’identification ):

SrvPool_OK

Hello everyone,

Aujourd’hui, nous allons parler des GPO (Group Policy Objects), et plus précisément d’une nouvelle fonctionnalité introduite aux Stratégies de Groupe sous Windows Server 2012 R2 et Windows 8.1 : Group Policy Caching

Group Policy Caching ?! Qu’est-ce que c’est ?

Quand une machine du réseau exécutant « Windows 8.1 » ou « Windows Server 2012 R2 » récupère des paramètres de Stratégies Groupes depuis un DC (Domain Controller), les valeurs de ces paramètres de stratégies de groupes sont stockées localement sur la machine où l’utilisateur AD s’est authentifié, et ce dans l’emplacement suivant :

C:\Users\<UserName>\AppData\Local\GroupPolicy\DataStore\0\SysVol\<domain name>\Policies

Chaque GPO récupérée est représentée par un dossier portant son IDentifiant Unique (GUIDGlobally Unique IDentifier)

1

Le principe du « Policy Caching » consiste à lire /charger le contenu le plus récent des paramètres de stratégies de groupe téléchargé et stocké localement depuis l’emplacement (local) indiqué précédemment au lieu de contacter un DC à chaque Logon.
Ceci réduit le temps requis pour chaque actualisation du moteur de stratégie de groupe local et chargement des paramètre GP depuis le réseau (depuis un DC du réseau).

Notez que le « Group Policy Caching » est une fonctionnalité activée par défaut sur les OS Windows Server 2012 R2 et Windows 8.1

Si toutefois vous voulez contrôler l’activation /désactivation de cette fonctionnalité, cela peut être fait via l’arborescence suivante :

OS en FR :

Configuration Ordinateur > Modèles d’administration > Système > Stratégies de groupe > « Configurer la mise en cache des stratégies de groupe »

OS en EN :

Computer Configuration > Administrative Templetes > System > Group Policy > « Configure Group Policy Caching »