PI Services

Le blog des collaborateurs de PI Services

Powershell / Active directory: Traduire le SID <=>l’utilisateur

 

CADRE:

Cet article vise un public débutant en powershell ne connaissant pas bien l’utilisation des classes objets avec powershell.

INTRODUCTION:

Dans cet article nous allons expliquer comment Traduire le SID lié à un utilisateur active directory ou local ou encore l’inverse.

Il faut savoir que Powershell est fondé sur la programmation objet.

Nous avons besoin d’installer aussi Net Framework 4.5, pour avoir les classes d’objets suivant sous powershell: 

1- System.Security.Principal.SecurityIdentifier (SID)

2- System.Security.Principal.NTAccount (compte NT)

SCRIPT:

Traduire le l’utilisateur en SID:

1-  Création de l’objet de la classe System.Security.Principal.NTAccount qui permet de représenter un utilisateur ou un groupe dans une variable $objUser .

$objUser = New-Object System.Security.Principal.NTAccount("administrator")

2-  Traduction de l’objet de la classe System.Security.Principal.NTAccount qui représente un utilisateur ou un groupe en classe System.Security.Principal.SecurityIdentifier qui représente le SID à savoir que .translate() après le $objUser est la méthode qui permet la traduction mais c’est la classe de l’objet contenue dans () sur lequel s’appuie la traduction (en quoi on veut le traduire) sans cela aucune traduction n’est possible .

$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])

2-  Traduction de l’objet étant effectué et mise dans une variable $strSID nous avons plus qu’à regarder la valeur de la variable en tapant .value après $strSID

$strSID .Value

affiche: S-1-5-21-29

Traduire le SID en Nom d’utilisateur:

Nous avons vu comment traduire l’utilisateur en SID l’inverse est tout simplement d’inverser les classes d’objets avec les noms des variables correspondant.

$objSID = New-Object System.Security.Principal.SecurityIdentifier("S-1-5-32-546")

$objUser = $objSID.Translate([System.Security.Principal.NTAccount])

$objUser.Value

affiche: BUILTIN\Invités

Powershell / Active Directory : Intégration de la photo des utilisateurs

Introduction

Cet article a pour but d'expliquer la gestion des photos dans l'annuaire Active Directory via une intégration par un script Powershell. En effet, le référentiel photo d'une entreprise ne respecte pas forcément les préconisations Microsoft. Grâce à un script, nous allons voir comment les respecter et peupler un annuaire Active Directory. La solution proposée permettra d'automatiser le processus en s'affranchissant d'outils tiers qui peuvent réaliser cette opération.

Solution

L'attribut AD permettant de renseigner la photo est thumbnailPhoto. Il y a plusieurs restrictions sur une image de profil :

  • la résolution est limitée à 96x96 pixels
  • la taille ne doit pas éxéder 100Kb

La valeur stockée dans l'attribut thumbnailPhoto est un tableau de bytes.

La solution proposée utilise des classes .Net issue de System.Drawing. Ainsi, on va pouvoir redéfinir la taille d'une image, la centrer et éventuellement définir la qualité si la photo est trop lourde. Afin d'être le plus portable possible, le script interroge Active Directory via ADSI pour réaliser la modification de l'attribut thumbnailPhoto.

NB : Depuis la V15 des produits d'infrastructure Microsoft et grâce au couple Exchange 2013/Lync 2013, il est possible de stocker des photos d'une résolution de 648*648 pixels directement dans la boîte aux lettres de l'utilisateur. Cette dernière est accédée directement via les Exchange Web Services par Lync. Une copie d'une résolution de 48x48 est toujours stockée dans l'attribut thumbnailPhoto.

Script

Le script permet de rendre conforme la photo d'un utilisateur et de la placer sur l'objet Active Directory dans l'attribut thumbnailPhoto. Pour chaque utilisateur, il est nécessaire de renseigner les paramètres suivants :

  • le samaccountname de l'utilisateur
  • le dossier contenant la photo
  • le nom du fichier photo
  • l'extension du fichier photo
Le script possède deux fonctions. Set-ADUserPhoto, requête l'annuaire Active Directory pour obtenir l'utilisateur via son SamAccountName. L'attribut thumbnailPhoto est ensuite mis à jour avec la valeur qui est retournée par la fonction Resize-Photo. Cette dernière retourne l'image sous la forme d'un tableau de bytes. Elle insère l'image d'origine dans une nouvelle image Bitmap possédant les limites de dimensions spécifiées (dans notre cas 96x96 pixels). Tout surplus sur les côtés est donc supprimé. L'image d'origine est positionnée de façon à se situer au centre. Enfin cette image est enregistrée en mémoire. Sa taille est évaluée. Si sa taille est supérieure au poids maximal choisi (ici 100Kb) alors on génère une nouvelle image en faisant varier la qualité (il s'agit d'un pourcentage que l'on décrémente de 5% à chaque essai).

Pour vérifier que l'opération s'est correctement exécutée, il suffit de vérifier dans la console Active Directory Users and Computers que l'utilisateur possède bien une valeur pour l'attribut thumbnailPhoto (via l'éditeur d'attribut). La photo peut ensuite être consultée via Outlook (pour les messageries Exchange) ou le client Lync. thumbnailPhoto

Ce script s'exécute utilisateur par utilisateur. Il est possible d'imaginer une logique de traitement "en masse".

Voici un script pour remplacer la région Main du script traitant l'intégralité des comptes utilisateurs Active Directory.
On suppose que toutes les photos sont stockées dans le même répertoire et portent comme nom de fichier le samaccountname de l'utilisateur. Bien entendu, cette partie reste adaptable en fonction des besoins. Il est par exemple possible de changer la racine de la recherche pour ne cibler qu'une unité d'organisation. Pour se faire, il faut remplacer $Root = [ADSI]'' par le distinguished name de l'unité d'organisation ciblée. Exemple :
A titre informatif, la fonction Resize-Photo peut être totalement décorrelée du processus de mis à jour de l'objet AD et être utilisée pour d'autre situation. Il est en effet possible de sauvegarder l'image générée dans un fichier plutôt qu'en mémoire en changeant un paramètre de la méthode Save :
Il faut remplacer la variable $Ms (représentant le buffer mémoire que l'on a instantié) par un chemin de fichier.

Hyper-V – Erreur “Logon failure : the user has not been granted the requested logon type at this computer” sous Windows Server 2012 R2

Contexte

Dans Hyper-V sous Windows Server 2012 R2 vous obtenez l’erreur “Logon failure : the user has not been granted the requested logon type at this computer” lorsque vous tentez d’éteindre ou allumer une VM.

2014-07-17_180510

Problématique

Cette erreur intervient même lorsque l’utilisateur fait partie du groupe “Hyper-V Administrators”.

L’erreur dans le journal d’évènements Windows (Applications and Services Logs / Microsoft / Windows / Hyper-V-VMMS / Admin) est la suivante :

Error 15500 : “VM” failed to start worker process: Logon failure:the user has not been granted the requested logon type at this computer. (0x80070569). (Virtual machine ID <GUID>)

2014-07-29_180732

Cette erreur est due à une GPO qui ôte un droit au compte d’Hyper-V.

Solution

Pour résoudre ce problème, il faut donc identifier et modifier la GPO qui change les droits en lui ajoutant NT Virtual Machine\Virtual Machines au droit Log on as a service ou exclure le serveur Hyper-V de la GPO.

Il existe également une solution à court terme qui permet de contourner le problème. Pour cela il faut redémarrer le service Hyper-V Virtual Machine Management depuis la console Services. Le redémarrage de ce service n’a pas d’impact sur les machines virtuelles (qu’elles soient allumées ou éteintes).

2014-07-17_180610

KEMP – Option GEO et Custom Location

Contexte

Ce billet fait suite à mon premier post sur l’option GEO des boitiers KEMP. Dans le billet précèdent j’expliquai comment faire pour contourner l’impossibilité de mettre des emplacements personnalisées sur les boitiers KEMP.

Hors depuis la version 7-1-20a, l’option GEO possède une nouvelle fonctionnalité : le Custom Location !

Mise en place

Avant la mise en place des custom location, il est intéressant de mettre à jour la base de données des localisations. Pour se faire connectez-vous au site https://support.kemptechnologies.com puis dans la partie Downloads et Other Downloads téléchargez la dernière version.

Connectez-vous à l’interface web du KEMP puis dans la partie Global Balancing, cliquez sur Miscellaneous Params. Dans Location Data Update cliquez sur Parcourir… sélectionnez le fichier d’update et cliquez sur Install Update.

2014-10-15_160414

2014-10-15_160452

Un message vous avertit une fois la mise à jour terminée.

2014-10-15_160506

Pour créer une Custom Location vous devez dans un premier temps indiquez une IP (ou un range d’IP). Pour cela dans la partie Global Balancing, allez dans IP Range Selection Criteria et ajoutez une IP en cliquant sur Add IP.

2014-10-15_160705

Indiquez l’IP (suivi du /32) ou un range d’IP (suivi de son masque sous la forme /XX) et cliquez sur Add Address.

2014-10-15_160738

Un message apparait pour valider l’ajout.

2014-10-15_160751

Cliquez ensuite sur Modify puis cochez la case Add Custom Location.

2014-10-15_1608132014-10-15_160832

Indiquez un nom à la localisation puis sélectionnez-la dans la liste déroulante.

2014-10-15_1608542014-10-15_161013

Cliquez sur <- Back pour valider et revenir à la page précédente.

2014-10-15_161042

Ce range d’IP appartient désormais à la localisation Siege – Noisy.

2014-10-15_161053

Il est désormais possible d’affecter cette localisation à une IP dans la partie Manage FQDNs.

2014-10-15_171016

Exchange 2013 CU6 – Problèmes lors de la coexistence avec Exchange 2007

Contexte

Lors d’une migration d’Exchange 2007 vers Exchange 2013 CU6 (dernière version en date) certains problèmes sont rencontrés lors de la coexistence entre les deux systèmes.

Problématique

Les problèmes rencontrés sont les suivants :

  • Problèmes de cohabitation sur le protocole ActiveSync
  • Bascule des bases de données Exchange de façon aléatoire

Ces deux problèmes sont résolus par deux hotfix que Microsoft délivre seulement sur demande au support :

Cependant le passage de ces correctifs peut engendrer deux nouveaux problèmes :

  • Impossibilité d’accéder à l’OWA
  • Impossibilité d’écrire un mail dans OWA

Solution

Pour résoudre ces problèmes il faut se connecter sur le serveur Exchange puis identifiez les deux dossiers suivants :

  • Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.31
  • Microsoft\Exchange Server\V15\ClientAccess\Owa\prem\15.0.995.29
    exchange

Le contenu des dossiers doit être identique. Sauvegardez le contenu du dossier 15.0.995.31 puis copiez les éléments du dossier 15.0.995.29 vers le dossier 15.0.995.31.

N.B : Le CU7 d’Exchange 2013, disponible très prochainement, devrait intégrer les deux correctifs (KB2997847 et KB2997203).

KEMP – Retour d’expérience de l’option GEO

Qu’est-ce que l’option GEO

L’option GEO des boitiers KEMP permet d'effectuer un équilibrage de charges multi-sites (sites internationaux). Cette option est conçue gérer un équilibrage de requêtes entre plusieurs datacenter en fonction de l’adresse IP publique du serveur DNS émetteur de la requête. Ainsi un utilisateur qui se trouve en France sera basculé vers les serveurs du site Français et un utilisateur qui se trouve aux Etats-Unis sera basculé sur les serveurs du site Américain.

L’option GEO fonctionne via le DNS. Les boitiers possédant l’option GEO deviennent des “serveurs DNS” autoritaire sur un FQDN (exemple : kemp.piservices.fr). Lorsqu’un utilisateur veux accéder à kemp.piservices.fr son serveur DNS le renverra vers un des boitiers GEO (au hasard, comme le veut le fonctionnement classique du DNS). Le boitier GEO récupère la position géographique du serveur DNS et lui indiquera le site le plus proche où se connecter.

GEOv2

Retour d’expérience

L’utilisation de l’option GEO peut également être utilisé dans un scénario LAN (en plus de son usage « traditionnel »). Dans ce cas les avantages sont :

  • La possibilité d’avoir un système de load balacing Actif / Actif (impossible à réaliser chez Kemp sans l’option GEO)
  • La possibilité d’équilibrer les requêtes provenant de certains sites distants sur un HLB en particulier avec fail-over vers un autre HLB (sous réserve que chaque site distant dispose de son propre DNS)
    La mise en place de cette option sur les boitiers KEMP est rapide. Tout d’abord l’ajout du FQDN.

geo_fqdn

Ensuite l’ajout des adresses IP correspondantes au FQDN avec le choix des localisations.

2014-09-15_102722

Enfin il est nécessaire de faire une délégation DNS sur le FQDN.

L’option GEO possède néanmoins une limite, il est en effet impossible de créer des localisations personnalisées (exemple : plusieurs villes d’un même pays). Il est tout du moins possible d’ajouter des adresses IP (des serveurs DNS) à des pays. Avec cette méthode il est alors possible d’affiner la localisation à des villes ou des sites plus rapproché géographiquement.