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

Publicités

 

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]