AD Archive

0

Comparaison de GPOs via SCM

Recensement et par pur hasard nous sommes tombés sur une feature de SCM (Security Compliance Manager) permettant de comparer deux GPOs  (dans notre cas il s’agissait de comparer une GPO XenApp de Prod avec son pendant en Qualification)

En effet il est possible de comparer facilement deux GPOs via SCM , la seule contrainte est le fait qu’il faille backuper au préalable les GPOs à comparer.
L’installation de SCM est une suite de Next, Next, Next (juste besoin d’un base SQL, cependant sqlexpress est fourni dans le package).

SCM est disponible ici (en 3.0).

Première étape : sauvegarder les deux GPOs qui seront comparées.

SCM_01Cliquez sur GPO Backup (folder)

SCM_02Choisissez la GPO à comparer

SCM_03Cliquez sur Ok

SCM_04Cliquez sur OK

SCM_05La première GPO à comparer apparaît dans la Custom Baselines
Répéter les opérations d’import pour la seconde GPO à comparer

SCM_07Sélectionnez une des GPO importée (dans Custom BAselines-GPO Import) puis cliquez sur Compare/Merge (dans Baseline)

 SCM_08Sélectionnez la deuxième GPO à comparer
Cliquez sur le bouton OK

SCM_09Enjoy 😉

Un point négatif est que SCM ne fonctionne pas avec les GPP et bug avec des settings de type wirelless, nous sommes en train de voir avec MS si une évolution/Correction est prévue.

D’autres outils permettant de comparer deux GPos (liste non exaustive 😉 ) : 
GPO Compare,
AGPM
GPOADmin (Quest)

0

Vérifiez si un utilisateur fait bien parti d’un groupe de publication

Dans une infra AD un peu « cossu », il peut arriver que le groupe de publication contienne des groupes imbriqués dans d’autres groupes imbriqués etc.. etc… 🙂 ……….et tout ça dans une profondeur assez « intéressante » (une trentaine d’imbriquation dans notre cas).

Quand les collègues doivent vérifier rapidement si un utilisateur fait bien partie d’un groupe de publication ça peut devenir un peu… laborieux.

En PowerShell c’est simple et rapide :

Get-ADGroupMember -Identity "YourGroup" -Server "YourDC" -recursive | % {if ($_.name -eq "YourUser") {write-host "User found"}}

Au passage si vous souhaitez en savoir plus sur les limitations Active Directory c’est par ici.

2

Poster Cmdlets Active Directory

Si comme nos collègues de ldap389 vous êtes fan des cmdlets Active Directory, alors le poster ci-dessous (le billet original sur le blog Technet est ici) devrait faire votre bonheur 🙂 .

0

Nouveau blog AD : LDAP389

Un nouveau blog Français (les articles sont aussi traduits en anglais) traitant de l’AD vient de voir le jour : LDAP389.

 

 

Nous lui souhaitons longue vie et vous recommandons ce blog de qualité.

Léo t’en a mis du temps à le faire ce blog 😉 .

0

Forcer le domaine par GPO

Par défaut en GPO nous ne pouvons pas forcer un nom de domaine.

Il peut arriver qu’un admin se connecte en mode console et en local (ou un autre domaine) sur un serveur et qu’il oublie qu’il était en mode console.

L’incidence est que vos users tomberont sur la gina.dll, pour peu que dans leurs crédentials ne soient pas forcés avec le nom de domaine.

La clé permettant de forcer un domaine : « DefaultDomainName » se  trouve dans « HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon ».

Bien que cela puise être scripté, ,le mieux est de mettre ce paramètre en GPO.

Vous trouverez en pièce jointe à ce billet, un adm permettant de forcer votre domaine sur vos serveurs.

Tags: , , ,