Sur un contrôleur de domaine, la gestion des comptes et groupes locaux est très spécifique puisque cette machine est… Un contrôleur de domaine !

Lorsque vous lancez l’utilitaire de gestion des comptes et groupes locaux sur une machine lambda, la console s’exécute et vous permet de manipuler les utilisateurs et groupe locaux. Sur un contrôleur de domaine vous aurez la désagréable surprise d’obtenir le message suivant :
Lire la suite

L’implémentation d’un serveur DHCP Microsoft en environnement Active Directory nécessite l’autorisation de ce dernier. Le mécanisme d’autorisation des serveurs DHCP se base sur un jeu de classes Active Directory et apporte des fonctionnalités telles que :

• l’implémentation d’une liste d’adresses IP disponibles pour tous les ordinateurs que vous autorisez à fonctionner comme serveurs DHCP sur votre réseau ;


• la détection des serveurs DHCP non autorisés avec verrouillage de leur démarrage ou de leur exécution sur votre réseau.

Il est dans certains cas nécessaire d’implémenter un serveur DHCP de test sans pouvoir (ou vouloir) autoriser celui-ci. Vous rencontrerez ce cas si vous implémentez un serveur DHCP de test sans avoir les autorisations Active Directory nécessaires. Dans ce cas, votre serveur DHCP non autorisé ne délivrera aucun bail à vos clients.

Afin de passer outre cette interdiction, une méthode relativement simple existe : Bypasser la vérification d’autorisation au démarrage du serveur.

La solution : Une clé registre !

Créez la clé suivante :
Path : HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\DHCPServer\Parameters
Name: DisableRogueDetection
Type: REG_DWORD
Data: 0×1

Redémarrez ensuite le serveur (redémarrer le service ne suffit pas), et le tour est joué !

L’Offline Domain Join est un nouveau processus d’ajout de machine (Windows 7 ou Server 2008 R2 ) à un domaine Active Directory et ce, sans contact avec le contrôleur de domaine.

L’implémentation de l’Offline Domaine Join passe par un nouvel outil nommé « DJoin.exe ». Cet outil permet de provisionner un compte ordinateur au sein d’un Domaine Active Directory Domain Services.

Retrouvez ci-dessous les explications nécessaires à l’implémentation de cette nouvelle fonctionnalité !

Quels prérequis ?

Djoin.exe peut être exécute uniquement sur des machines Windows 7 ou Windows Server 2008 R2.

Par cela, comprenez que l’ordinateur que vous souhaitez ajouter au domaine doit être une machine Windows 7 ou Windows Server 2008 R2 et que la machine qui vous permettra de provisionner la nouvelle machine devra exécuter Windows 7 ou Windows Server 2008 R2.

Par défaut, Djoin.exe cible le « premier » contrôleur de domaine exécutant Windows Server 2008 R2. Sinon, l’attribut /downlevel permettra de cibler un contrôleur de domaine exécutant une version antérieure dans le cas ou votre site ne serait pas pourvu de DC 2008 R2.

Notez également qu’afin d’exécuter cette commande, vous devez être membre du groupe des administrateurs du domaine ou avoir les droits requis à l’ajout de machines au domaine.

Offline Domain Join, le processus.

Commencez par générer les métadonnées du compte ordinateur à ajouter (depuis n’importe quel poste W7 ou WS2008 R2 membre du domaine). Les métadonnées seront générées sous la forme d’un fichier texte que vous spécifierez en tant qu’attribut de la commande DJoin.

La commande à exécuter est sous la forme suivante :

djoin /provision /domain domain to be joined /machine name of the destination computer /savefile MetaData.txt

Une fois cette commande exécutée et les métadonnées générée, exécutez, sur l’ordinateur à joindre au domaine, la commande suivante en passant en parametres le fichier txt généré par la commande précédente :

djoin /requestODJ /loadfile MetaData.txt /windowspath %SystemRoot% /localos

Au redémarrage de la machine, celle-ci sera jointe au domaine.

Le fichier de métadonnées pourra également être « inclus » dans le fichier Unattend.xml utilisé lors de l’installation de votre système d’exploitation Windows7.

Détails sur la syntaxe d’utilisation de Djoin.exe :

djoin /provision /domain  /machine  /savefile  [/machineou ] [/dcname ] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob]
djoin /requestodj /loadfile  /windowspath  /localos

à vous de jouer !

Les fichiers ADM, sont des templates d’administration appliqués aux GPOs et permettant d’ajouter une série de paramètres à celles-ci.

Concrètement, une GPO est basée sur plusieurs fichiers ADM, ces fichiers ADM permettent un mapping entre (généralement) des clés registre et des items dans la console de Gestion des Stratégies de Groupe Active Directory.

Il est possible d’ajouter des items à cette console au travers de fichiers ADM personnalisés, cette solution permet dans l’exemple ci dessous de pouvoir configurer les mises a jour automatiques d’Adobe Reader 10.

Dans le cas du fichier ADM ci-dessous:

• On crée un “conteneur” : “Pierre Salvy ADM” contenant le conteneur : “Adobe Reader 10“, contenant le conteneur “Updates”
• le conteneur “Updates” contient quant à lui une entrée “AutoUpdates Config“
• l’entrée “AutoUpdates Config” permet la configuration de la clé registre : bUpdater située sous “SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockdown“

CLASS MACHINE
CATEGORY "Pierre Salvy ADM"
   CATEGORY "Adobe Reader 10"
      CATEGORY "Updates"
	POLICY "AutoUpdates Config"
	   KEYNAME "SOFTWARE\Policies\Adobe\Acrobat Reader\10.0\FeatureLockdown"
           EXPLAIN !!DescbUpdater
	   PART "AutoUpdate State" DROPDOWNLIST REQUIRED
	      VALUENAME "bUpdater"
	      ITEMLIST
	         NAME "Disabled" VALUE NUMERIC 0
	         NAME "Enabled" VALUE NUMERIC 1
	      END ITEMLIST
	   END PART
	 END POLICY
	END CATEGORY
      END CATEGORY
END CATEGORY

[strings]
DescbUpdater="Enable or Disable Adobe Reader AutoUpdates"

Une fois le fichier ADM chargé de la façon suivante :

La console d’édition des stratégies de groupes contiendra une nouvelle entrée :

la clé registre ciblée aura donc la valeur affectée après application :

Nous avons donc ici modifié une clé registre au moyen d’une GPO.

Vous l’aurez compris; rien de bien compliqué d’après cet exemple ! (en dehors des fautes de syntaxe et de frappe !)

Dans certains cas, vous êtes contraint de rendre vos utilisateurs administrateurs de leurs postes de travail (compatibilité applicative, gestion des postes portables « hors réseau interne » , …), l’implémenter, c’est bien, mais correctement et de façon sécurisée, c’est mieux !

Plusieurs solutions s’offrent à vous, notamment la plus simple : créer un groupe d’utilisateurs, et l’intégrer par GPO au groupe Administrateur de chaque poste de travail grâce aux « Restricted Groups ».

Seconde solution ! Utiliser le compte NT « Interactif » et l’intégrer par GPO au groupe Administrateur de chaque poste de travail grâce aux « Restricted Groups ». En filtrant l’application de cette GPO (comme décrit dans cet article), vous pourrez gérer l’attribution des droits d’administration très finement.

Ce compte générique correspond utilisateurs interactifs, comprenez ceux qui ont une session ouverte, par opposition aux utilisateurs distants (RDP, …).

Donc concrètement, tout utilisateur connecté physiquement sur la machine en deviendra administrateur, sans que les autres utilisateurs (qui subiraient le même sort s’ils étaient connectés physiquement) ne puissent accéder aux partages administratifs, et autres configurations de la machine.

Créez une Stratégie de groupe (GPO) puis rendez-vous sous : Configuration Ordinateur \ Paramètres Windows \ Paramètres de sécurité \ Groupes restreints.

Ajoutez l’utilisateur « BuiltIn\INTERACTIVE» au groupe « Builtin\Administrators », et le tour est joué !
Vous obtiendrez donc sur les postes, le groupe administrateur avec cette entrée en plus des entrées « standard » :

La stratégie résultante sur le poste (GPRESULT ou RSOP) contiendra alors :

Vous l’avez certainement lu dans un de mes précédent article (comment ça non ? tout est ici), Windows 8 introduit un nouveau format de package applicatif, le AppX !

J’abordais également dans un précédent article le fonctionnement d’AppLocker sous Windows 7.

Sous Windows 8, AppX et AppLocker sont implémentés et configurables ! Et aux fonctionnalités actuelles d’Applocker s’ajoutent la possibilité d’appliquer de nouvelles règles spécifiques aux packages AppX !

Vous pourrez donc par GPO (lorsque les consoles Windows 8 seront disponibles) ou via GPEDIT vous pouvez donc apercevoir un Item supplémentaire : AppX.

Ensuite, lorsque vous choisirez de créer une nouvelle règle (tel qu’expliqué dans cet article) portant sur un package AppX, vous aurez la possibilité de sélectionner un package AppX :

Vivement l’arrivée de Windows Server « 8 » et des consoles associées pour pouvoir profiter pleinement de toutes ces nouvelles fonctionnalités !

En ces temps où les déploiements de Windows 7 tournent à plein régime, il est souvent necessaire de dédier certaines GPO à la configuration de ces postes sans impacter le reste du parc XP, serveur 2003 et 2008,… (Attention : Windows 2000 ne supporte pas les filtres WMI)

Pour cela l’implémentation de filtres WMI nous simplifiera la tâche !

Petite explication :

• Au travers de la console de Gestion des Stratégies de Groupes (GPMC.MSC) effectuez un clic droit sur “Filtres WMI” puis “Nouveau“
  
  
  


• Créez ensuite votre filtre WMI de la façon suivante :
  
  
  Requête : Select * from Win32_OperatingSystem where Version like “6.1%”
• Une fois le filtre créé, il suffit de s’en servir ! pour cela, créez votre GPO et selectionnez le filtre WMI créé.
  
  
  

La GPO ainsi filtrée ne sera appliquée que sur les postes Windows 7 .

Il est courant d’avoir besoin de récupérer divers paramètres d’objets présents dans une Unité d’Organisation Active Directory.

La fonction ci-joint vous permettra de lister les objets Ordinateurs d’une OU en affichant le nom du poste, la date de création, de dernier login, le système d’exploitation et la version du service pack installé.

Cette fonction est très simple a utiliser, déclarez l’objet “ObjOutputFile” dans votre script, passez un Objet active directory (computer ou OU) grâce a la commande “GetObject” et la fonction se chargera du reste !

Nous le savons, en VBS, tout est possible (ou presque) !
Les actions autour d’active Directory sont relativement simples via Visual Basic Script, en voici un exemple qui pourrait s’avérer fort utile.

Cette fonction est utilisable pour déplacer un objet d’une OU vers une autre. Les deux attributs de cette focntions sont des chemins LDAP au format LDAP://OU=OuCible,DC=MonDomaine,DC=Local”

Active Directory connait actuellement une sacrée révolution avec l’arrivée des Cmd-lets Powershell. En effet depuis l’arrivée de Windows Serveur 2008 R2, Microsoft propose maintenant d’administrer Active Directory en Powershell !

Une révolution pour nous tous, fini les scripts VBS et autres Batchs, maintenant nous utiliserons Powershell.

Cependant et vous vous en doutez, la transition se fera en douceur, car malgré diverses bibliothèques de composants powershell tierces existantes depuis quelques mois sur le marché, powershell est encore (trop ?) peu rependu.

En attendant l’arrivée de ces outils powershell, je vous propose ci-dessous un petit script “A l’ancienne” (donc en Visual Basic Script …) permettant de lister les utilisateurs actifs ayant un attribut placé à une valeur donnée. Dans l’exemple nous listons les utilisateurs Active Directory actif ayant l’attribut “msExchHideFromAddressListsList” actif. Ce script documenté est très facilement adaptable à tout types d’attributs, il n’est pas parfait mais pourra très certainement servir de base à vos développements (je sais … le script ce n’est pas du développement…)

Pour faire court, je vous invite à télécharger ce script au format zip ! ICI