[RDS Windows Server 2016] Pensez à déployer vos Services/Serveurs RDS en mode « Core »

 

S’applique à : RDS Windows Server 2012, RDS Windows Server 2012 R2 et RDS Windows Server 2016

Introduction

Pour réduire la surface d’attaque sur certains rôles/serveurs RDS, il est fortement recommandé de les déployer sur une infrastructure Windows Server en mode « Core » plutôt qu’en mode « GUI ». Cela vous permet aussi de réduire vos efforts en terme de maintien et exploitabilité de la plateforme (moins d’Updates, moins de config post-déploiement…).

 

Services de rôles RDS pris en charge par Windows Server Core 2016

Le tableau ci-dessous, liste les différents services RDS pouvant être déployés/pris en charge sur un Windows Server 2012, 2012 R2 et 2016 en mode Core:

Service de rôle RDS	Supporté sur Server Core
RDCB
RDLS
RDSH
RDVH
RDWA
RDG

pris en charge

non pris en charge

 

En outre, Windows Server 2016 « Core » prend en charge tous les agents (graphiques) de Monitoring, Antivirus, Sauvegarde ou encore Sécurité (Encryption de Disk /Files). Vous pouvez donc continuer à inclure vos serveurs RDS en mode Core dans le périmètre de vos solutions d’infrastructures existantes, et ce sans aucun impact.

Pensez donc à privilégier l’utilisation du more « Core » pour vos serveurs Brokers (RDCB) et de Licences (RDLS).

Note importante : depuis Windows Server 2016, il n’est plus possible de Switcher entre les modes « GUI » et « Core ». Vous devez donc déployer vos serveurs RDS en mode Core « From Scratch ». Les serveurs RDS 2016 (existants) qui sont déjà en mode « Graphique » ne peuvent malheureusement être transformés en mode « Core » comme c’était le cas avec Windows Server 2012 et 2012 R2.

Gérer vos serveurs RDS Core à distance

Les serveurs RDS (RDCB et RDLS) exécutant Windows Server 2016 en mode Core peuvent être gérés à distance depuis n’importe quelle machine d’administration ayant les outils RSAT installés. Cela pourrait être une machine cliente (Windows 7, 8/8.1 ou encore Windows 10) ou un serveur d’administration (Windows Server 2008/2008, 2012 /2012 R2 ou encore 2016).

Depuis un Serveur d’Administration

Depuis Windows Server (2008 R2 ou ultérieur), lancez Windows PowerShell et saisissez la commande suivante :

Get-WindowsFeature RSATRDS* | FT –AutoSize

Les outils RSAT dédiés pour la gestion des services de rôles RDS sont retournés

L’outil (Snap-in) RSAT-RDS-Licensing-Diagnosis-UI correspondant à « Outils de diagnostic des licences des services Bureau à distance » vous permet de gérer et diagnostiquer les services de licence RDS à distance.

Quant à l’outil « Gestionnaire de Licence des Services Bureau à distance« , celui-ci vous permettra d’activer votre serveur de Licence RDS, installer, gérer et migrer vos CAL RDS.

Depuis une machine cliente d’Administration

Il est également possible de gérer votre déploiement RDS depuis une machine cliente (Windows 7 ou ultérieur) ayant les outils RSAT installés.

En effet, ces derniers incluent l’outil « Server Manager » qui vous permet de regrouper vos serveurs RDS de déploiement dans le même pool de serveurs et gérer ainsi votre déploiement depuis le volet « Services Bureau à distance ».

Vous trouverez ci-après les liens de téléchargements des outils RSAT pour les clients Win7 > Win10:

Outils RSAT pour Windows 10

Outils RSAT pour Windows 8.1

Outils RSAT pour Windows 7

 

A bientôt,

Publicité

[Tip of the Week] Obtenir la liste complète des Mises à jour Windows installées sur un serveur distant

Une question intéressante m’a été récemment posée par un de mes clients :

Comment obtenir la liste complètes des Updates Windows installées sur un Windows Server distant ?

Typiquement un serveur distant exécutant Windows Server 2008 R /2012 /2012 R2 ou encore 2016 en mode Core.

Je vous détaille à travers cet article la ligne de code qui vous permet de le faire.

HowTo : Obtenir la liste des Updates Windows d’un serveur distant 

La technique consiste simplement à utiliser une Cmd-Let nommée « Get-Hotfix » en spécifiant le hostname de votre serveur distant au niveau du paramètre -ComputerName.

Dans l’exemple suivant, nous allons obtenir la liste complètes des mises à jour Windows installées sur le serveur Core distant « LABRDS2016 » :

Get-HotFix -ComputerName LABRDS2016 | Select HotfixID, Description, InstalledOn | Sort-Object -Descending

les MàJ Windows installées sur ma machine distante sont affichées dans l’image suivante :

 

Liste des rôles et fonctionnalités supportés sous Windows Server Core 2016

Note : pour connaître la liste des rôles et fonctionnalités pris en charge sur Windows Server Core 2008 /2008 R2 /2012 /2012 R2, consultez cet article.

PI : visionnez cette vidéo pour en savoir plus sur la configuration initiale de Windows Server Core 2016

De nouveaux rôles et fonctionnalités sont désormais pris en charge sur Windows Server Core 2016.

Des fonctionnalités supplémentaires peuvent être ajoutées à partir des sources d’installation de Windows Server 2016 : à partir du fichier d’image Windows > fichier .WIM

Je vous détaillerai à travers cet article la liste complète des rôles et fonctionnalités pouvant être déployés sur un Server Core 2016.

Rappel sur le mode « Core », appelé aussi « Installation Minimale » 

Windows Server Core, appelé aussi « Installation Minimale de Windows Server », est un mode d’installation allégé et pourvu d’options d’installations et de configurations minimales.

Il ne s’agit pas d’une nouvelle version mais plutôt d’une simple option d’installation à sélectionner depuis l’’assistant d’installation lors du déploiement de Windows Server 2016.

La particularité du mode « Core » réside également dans l’absence de la couche graphique Windows (absence du Shell Graphique Windows).

Les principales interfaces de gestion et configuration d’un Server Core sont les outils en ligne de commande fournis par défaut avec cette option d’installation, citons :

Invite de commande : CMD.exe

Windows PowerShell : PowerShell.exe

Outil de configuration (natif) du Server Core : SConfig.exe

Il s’agit ici d’outils CLI qui vous permettent de gérer votre Windows Server Core de manière « Interactive ».

L’OS Server en mode « Core » peut également être géré à distance via des outils graphiques : utilisation des outils (snap-in) fournis avec les RSAT (Remote Server Administration Tools).

HowTo : lister les rôles et fonctionnalités disponibles sur Windows Server Core 2016

Ouvrez une Session Windows sur votre Server Core et saisissez la commande suivante pour lancer Windows PowerShell :

Start PowerShell

La console Windows PowerShell apparaît :

Saisissez Get-WindowsFeature depuis la console Windows PowerShell pour lister tous les rôles et fonctionnalités Windows :

PowerShell collecte alors les informations sur les rôles et fonctionnalités Windows et vous retourne le résultat comme montré dans l’image ci-dessus.

Comme vous pouvez le constater, la colonne « Install State » indique le statut du rôle, service de rôle ou fonctionnalité, on distingue 3 statuts :

Available : Le rôle, service de rôle ou fonctionnalité est disponible (ses binaires sont présents sur l’OS) et peut être ajouté /installé

Removed : Le rôle, service de rôle ou fonctionnalité est supprimé (ses binaires ne sont pas présents sur l’OS). Il faut donc ajouter /installer le rôle, service de rôle ou fonctionnalité à partir des sources d’installation de Windows Server 2012 R2 (depuis fichier .wim par exemple)

Installed  : Le rôle, service de rôle ou fonctionnalité est déjà installé (par défaut avec l’installation de Windows Server 2016).

Liste des rôles et fonctionnalités supprimés de Windows Server Core 2016

Saisissez la commande suivante pour lister les rôles et fonctionnalités dont les binaires sont supprimés par défaut du Server Core :

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

 

Liste des rôles et fonctionnalités disponibles (par défaut) sur Windows Server Core 2016

Saisissez la commande suivante pour lister les rôles et fonctionnalités qui peuvent être être installés sur un Server Core 2016:

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

Astuce : vous pouvez exporter le résultat retourné par la commande vers un fichier texte ou csv afin de trier les informations collectées et les exploiter par la suite. Pour ce faire, saisissez à la fin de la commande | Out-File C:\ListeRolesFonctionnalites.txt ou Export-CSV C:\ListeRolesFonctionnalites.csv

Liste des rôles et fonctionnalités installées (par défaut) avec Windows Server Core 2016

Saisissez la commande suivante pour lister les rôles et fonctionnalités qui sont (par défaut) installés avec Windows Server Core 2016:

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

Pour conclure:

17 rôle Windows peuvent désormais être installés et exécutés sur Windows Server Core 2016 :

Note importante : certains de services de rôles ne sont pas pris en charge sur un Server Core, il s’agit généralement des services de rôles nécessitant le « Shell Graphique ». E.g : service de rôle RD Session Host (Hôte de la session Bureau à distance) faisant parti du rôle parent « Services Bureau à distance ».

38 fonctionnalités Windows peuvent désormais être installées et exécutées sur Windows Server Core 2016 :

Azure Periodic Table – New Big Picture

Si vous souhaitez démarrer avec Microsoft Azure, commencez par comprendre tous les composants et services disponibles sur celui-ci.

Je vous propose de consulter la version cliquable d’Azure Periodic Table, disponible à cet URL.

Il s’agit d’une « Big Picture » cliquable qui vous détaille chaque service disponible sur Azure.

C’est un bon point de départ si vous souhaitez vous former sur MS Azure.

Préparer la migration de votre infrastructure AD vers Windows Server 2012 R2

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

 

Comprendre et utiliser le mode « Remote Credential Guard »

S’applique à : Windows 10 et Windows Server 2016

Remote Credential Guard, qu’est-ce que c’est ?

Le géant américain a lancé l’année dernière le « Credential Guard », une fonctionnalité de sécurité native dans Windows 10 Enterprise et Windows Server 2016. Credential Guard aide à empêcher le vol d’informations d’identification et permet de réduire l’efficacité des attaques Kerberos telles que Overpass-The-Hash et Pass-the-Ticket.

Récemment, avec la publication de la mise à jour « Anniversaire » Windows 10, Microsoft a annoncé la disponibilité du « Remote Credential Guard », une nouvelle fonctionnalité de sécurité qui vise elle aussi à protéger les informations d’identification sur les connexions Bureau à distance en générant des tickets de service nécessaires à partir de la machine source au lieu de copier les informations d’authentification (Haches et TGT) vers la machine cible.

Notez que Remote Credential Guard a été introduite sur Windows 10 version 1607.

Cette fonctionnalité peut être considérée comme le successeur /remplaçant du mode « Restricted Admin ».
En effet, les deux fonctionnalités s’activent et fonctionnent de la même manière, la seule différence réside dans le fait que le Remote Credential Guard ne limite pas l’accès aux autres ressources du réseau en redirigeant de nouveau toutes les demandes d’identifications vers la machine cliente du réseau.

Si vous voulez en savoir plus sur le mode « Restricted Admin », je vous invite à consulter cet article.

Enfin, un article détaillé sur le « Remote Credential Guard » a été rédigé et publié par CyberArk, je vous invite à consulter pour en savoir plus sur cette nouvelle fonctionnalité :
https://www.cyberark.com/blog/no-pass-hash-exploring-limitations-remote-credential-guard/

Prérequis

La fonctionnalité « Remote Credential Guard » est prise en charge par les OS suivants uniquement :

• OS Server : Windows Server 2016
• OS Client : Windows 10 (Entreprise)

Vous pouvez donc l’implémenter uniquement pour sécuriser des Connexions Bureau à distance établies depuis et vers les OS cités ci-dessus.

HowTo : Activer ou Désactiver le mode « Remote Credential Guard »

Le mode « Remote Credential Guard » est désactivé par défaut.

Il s’active de la même manière que le mode « Restricted Admin », il suffit donc de créer /ajouter la clé de Registre suivante sur vos machines cibles :

Chemin: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Lsa

Valeur DWORD (32-bits) : DisableRestrictedAdmin

Données de la valeur : 0

Note importante : Cette clé de Registre peut également être crée en exécutant la commande suivante (depuis CMD.exe lancée en tant qu’Admin) :

Reg.exe Add HKLM\SYSTEM\CurrentControlSet\Control\Lsa /V DisableRestrictedAdmin /D 0 /T REG_DWORD

Utiliser le mode « Remote Credential Guard »

Une fois activé, le mode « Remote Credential Guard » doit être forcé sur l’ensemble des machines du réseau (cibles) sur lesquelles vous vous connectez via Bureau à distance.

Cette configuration peut être effectuée 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é

Mode restreint : Requérir Credential Guard à distance

Le mode « Remote Credential Guard » ou « Credential Guard à distance » est représenté par un paramètre de l’outil MSTSC.exe et plus précisément le paramètre /remoteGuard, lancez MSTSC /? depuis l’invite de commande (CMD.exe) ou le Menu Démarrer et constatez la disponibilité du mode « /remoteGuard » :

Dans l’exemple suivant, nous allons établir une Connexion Bureau à distance en mode « remoteGuard » sur le serveur distant « LABRDS01 » :

---

Ceci est un extrait de l’eBook « RDS 2016 – Securisation et Hardening [2ème Edition] »