Le blog technique

Toutes les astuces #tech des collaborateurs de PI Services.

#openblogPI

Retrouvez les articles à la une

EXCHANGE 2010 – Gestion des groupes de distributions

Pour rappel sous Exchange 2010 il ne suffit pas de mettre un gestionnaire

pour lui permettre de gérer un groupe de distribution:

image

Il faut activer le rôle défini par le mécanisme RBAC.

Cochez “MyDistributiongroups”

image

On constate en lançant Outlook Web App que la création de groupe

n’est pas disponible avant l’activation du rôle:

image

Après activation, de nouveaux menus sont disponibles:

image

Chaque utilisateur peut donc créer un groupe

et supprimer un groupe dont il est le propriétaire !

Ce droit “excessif” peut ne pas répondre à la stratégie de la société.

Nous allons donc retirer ces droits de création et de suppression.

Recherchons le rôle “MyDistributionGroups”

image

Créer un rôle enfant de “MyDistributionGroups” en supprimant le droit de créer et de supprimer un groupe.

New-ManagementRole –Name ****OwnerDistributionGroups -Parent MyDistributionGroups

image

image

On remarque la présence de ce nouveau rôle dans la console “RBAC”:

image

Vérifions le rôles assignés sur “Default Role Assignment Policy”

image

MyDistributionGroups est présent.

Supression des droits New et Remove

Remove-ManagementRoleEntry ****OwnerDistributionGroups\New-DistributionGroup -Confirm:$false

Remove-ManagementRoleEntry ****OwnerDistributionGroups\Remove-DistributionGroup -Confirm:$false

Puis il faut associer le “Default Default RoleAssignment Policy” avec ce nouveau rôle :

New-ManagementRoleAssignment –Role ****OwnerDistributionGroups -Policy "Default Role Assignment Policy"

image

L’opération n’est pas finie car le rôle parent est toujours assigné donc actif.

Supprimons ce lien:

Remove-ManagementRoleAssignment “MyDistributionGroups-Default Assignment Policy”

image

Vérifions

image

Ce qui donne dans la console RBAC cette configuration:

image

Et pour l’utilisateur final:

image

Les droits de création et de suppression ne sont plus disponible.

Windows échoue à se connecter à l’imprimante

Symptômes :

Lors du rapatriement des pilotes un bug se produit et l’assistant s’interrompt (imprimante réseau couleur).

« Windows cannot connect to the printer. Operation failed with error 0x0000007e ».

imageimage

                            image

Ce problème survient lorsque qu’on tente d’ajouter une imprimante couleur sur un poste client Windows 7 rattaché à un serveur d’impression Windows 2003 ou Windows 2008.

Deux solutions de contournements fonctionnent car le problème est connu par Microsoft mais sans correctif pour le moment.

· Le premier s’opère sur le poste client, et consiste à installer l’imprimante en utilisant le port LPT2, puis d’utiliser une commande de redirection

                             clip_image002

· Le deuxième consiste à modifier une clé de registre sur le serveur d’impression. Puis de se connecter à l’imprimante.

Regedit> HKLM\System\CurrentControlSet\Control\Print\Printers\printername\CopyFiles en renommant le répertoire CopyFiles par xCopyFiles. Ce répertoire n’existe que pour une imprimante couleur.

clip_image003

Les deux solutions fonctionnent instantanément. Mais il est beaucoup plus rapide de modifier le répertoire défaillant directement dans la base de registre pour toutes les imprimantes concernées.

Manipulation des droits NTFS via Powershell

Il existe un module nommé NTFSSECURITY permettant une manipulation simplifié des droits NTFS sur des dossiers et/ou fichiers.

Ce module peut être trouvé sur la galerie Technet http://gallery.technet.microsoft.com/scriptcenter/1abd77a5-9c0b-4a2b-acef-90dbb2b84e85/file/48905/1/NTFSSecurity%201.3.zip

 

Une fois téléchargé, mettez le dossier du module NTFSSecurity ici C:\Windows\System32\WindowsPowerShell\v1.0\Modules

Maintenant, nous allons charger le module dans powershell

image

Une fois celui-ci chargé, de nouvelles cmdlets sont désormais disponible.

image                                   

Récupération du SID d’un utilisateur dans une variable.

Nous allons définir dans une variable $SamMember le nom de l’utilisateur que nous voulons récupérer.

Ensuite nous allons utiliser l’object System.Security.principal.NtAccount(« domaine »,utilisateur) qui va nous permettre de récupérer notre utilisateur dans un domaine spécifié.

image

image

Maintenant, récupérons le SID de notre utilisateur grâce à une méthode de notre variable $account.

image

Nous avons ainsi récupéré dans notre variable $accountsid le SID de notre utilisateur spécifié dans la variable $SamMember.

 

Modification du propriétaire d’un répertoire.

Avec le chargement du module NTFSSecurity, une cmdlet get-owner est apparue nous permettant de connaitre simplement le propriétaire d’un élément (fichier ou répertoire).

Exemple :

image

Nous allons maintenant changer le propriétaire de ce répertoire avec l’utilisateur contenu dans notre variable $accountsid

image

Voyons maintenant le résultat :

image

 

Le propriétaire à bien été changé.

 

Modification des ACE du répertoire.

Nous allons maintenant modifier les ACE du répertoire de façon à ne laisser que l’utilisateur de notre variable $accountsid en FullControl et aucune autre ACE.

Rajout de l’ACE :

image

Suppression des autres ACE :

image

(Ce lien permet de connaitre les SID connu dans les OS Windows http://support.microsoft.com/kb/243330)

 

Si on consulte maintenant nos ACE, on peut remarquer que notre ajout d’ACE s’est bien passé mais que la suppression des autres ACE ne s’est pas déroulée correctement.

 

image

Cela est normal, car ses ACE sont hérité du répertoire parent. Il faut donc pour cela retirer l’héritage.

clip_image001[4]

Et maintenant si on essaie de nouveau de supprimer nos ACE on peut remarquer que celle-ci ont bien disparu.

 

image

Il est maintenant facile d’imaginer la création d’un script pouvant réappliquer correctement des droits sur une toute une arborescence de répertoires profils en récupérant par exemple le nom du répertoire profil et en réaffectant celui-ci dans une boucle pour notre variable $account.

 

image

 

clip_image005

Ainsi, l’utilisateur authentifié en user2, ne pourra accéder qu’à son répertoire profil.