Windows PowerShellAutomatisation utilisateur mise en service, 3ème partie

Don Jones

Contenu

L'environnement de modèles
Création du dossier
Attribution d'autorisations

Dans cette partie de Windows PowerShell, je suis prélèvement des là où J'AI laissé le mois dernier et continuer à créer un script que vous aide à attribuer de nouveaux utilisateurs dans un environnement Active Directory.Si vous n'avez pas à lire l'article précédent encore, je recommande de lire cette colonne avant de poursuivre ici.

À ce stade, je dispose d'un masque de mise en service fonction qui contient quatre fonctions sub.La fonction maître ressemble à ceci :

Function Provision {
  PROCESS {
    CreateUser $_
    CreateHomeFolder $_
    AddToGroups $_
    UpdateAttributes $_
  }
}

J'ai déjà créé des variantes de la fonction CreateUser. Dans cet article, je suis se concentre sur la fonction CreateHomeFolder. Je vais utiliser cette fonction pour créer des dossier personnel de l'utilisateur et appliquer les entrées de liste (ACL) contrôle d'accès approprié au.

Windows PowerShell Forum aux questions

Q : Windows PowerShell distinguer les guillemets simples des guillemets autour des chaînes de caractères ?

un Oui. Avec tout sauf une exception, single et doubles devis comportement identique. C'est-à-dire que ces deux commandes va affecter la chaîne « Microsoft » à la variable $ var :

$var = 'Microsoft'
$var = "Microsoft"

Toutefois, au sein des guillemets doubles uniquement, l'interpréteur de commandes recherche le caractère dollar ($). Si elle trouve qu'il, l'interpréteur de commandes suppose que les caractères suivant le signe dollar sont un nom de variable, et il remplacerez la variable avec valeur de cette variable :

$var1 = 'Windows'
$var2 = "Microsoft $var1"

Après l'exécution de ces deux commandes, $var2 contient « Microsoft Windows » ($var1 a été remplacé avec son contenu). Raisons, coller avec les guillemets simples, sauf si vous devez explicitement cette fonctionnalité de remplacement de la variable.

L'environnement de modèles

Comme toutes les fonctions enfants appelées par la fonction de provision, CreateHomeFolder accepte une table de hachage comme son entrée. Depuis la création d'un dossier personnel seulement réellement nécessite de connaître le nom de l'utilisateur d'ouverture de session, je peux utiliser la clé de table de hachage ['samaccountname']. J'AI utilisé cette clé dans article l'article du mois dernier, ainsi, étant donné que l'attribut samAccountName est requis lors de la création un nouveau compte d'utilisateur Active Directory.

Je dois également le dossier de base sera créé, et J'AI besoin ont accès réseau à cet emplacement. Dans cet exemple, je suppose que dossiers de base utilisateur sont tous stockés sur un spécifique serveur, basé sur le nom de l'utilisateur d'ouverture de session. Par exemple, tous les éléments commençant par A à D sont sur le serveur HomeFolders1, tandis que dossiers de E à H sont sur HomeFolders2. L'utilisation de cette structure, mon exemple doit fournir une structure qui vous pouvez développer sur le travail au sein de votre propre environnement. Pour cette discussion, je ne vais pas me à vous soucier des utilisateurs qui commencent par I à Z — le modèle sera évident et je souhaite conserver l'exemple simple et économiser l'espace.

Dans mon environnement exemple, chacun de ces serveurs possède un partage administratif appelé $ maisons, qui inclut tous les dossiers de base utilisateur. Et je suppose que les administrateurs disposez la possibilité de créer de nouveaux dossiers et que mon script est exécuté par un administrateur. Enfin, supposons que tous les serveurs impliqués sont dans le même domaine ou sont en cours d'approbation de domaines, afin que leur fait confiance le compte administrateur est utilisé pour exécuter le script.

Création du dossier

Création du dossier est relativement simple. Tout d'abord, je dois décider quel serveur je créer le dossier, comme suit :

Function CreateHomeFolder {
  Param($userinfo)
  $server1 = 'a','b','c','d'
  $server2 = 'e','f','g','h'
  Switch ($userinfo['samAccountName'].    substring(0,1).tolower()) {
    { $server1 –contains $_ } 
      { $homeserver = '\\homeserver1\'; break; }
    { $server2 –contains $_ } 
      { $homeserver = '\\homeserver2\'; break; }
  }
}

Ce donc qu'exactement il se passe ici ?

• Tout d'abord, je créer un tableau de lettres de chaque serveur de dossier de base prend en charge. Dans cet exemple, j'ai créé deux tableaux, $server1 et $server2 et affectés les lettres que j'ai décidé qu'ils sont ordinateur hôte. Cette approche facilite pour moi changer les affectations de lettre à l'avenir, ainsi que pour ajouter plusieurs serveurs si nécessaire.
• J'utilise ensuite l'instruction Switch pour évaluer une série de conditions possibles. J'évalue le premier caractère de samAccountName attribut l'utilisateur, après avoir converti le caractère en minuscule.
• Pour chaque serveur domestique je dispose, j'ajouter une condition à la construction de changement. La condition vérifie si la première lettre de samAccountName l'utilisateur (qui est contenue dans la variable spéciale $ _ à ce stade) existe dans le tableau de ce serveur de lettres. Le cas échéant, puis la variable homeserver $ indique le début d'un chemin d'accès UNC (Universal Naming Convention) pour ce serveur. Le mot clé « saut » empêche davantage conditions évalué une fois que j'ai trouvé le serveur correct. Notez que, comme écrit, cet exemple montre comment ne fonctionne pas pour les utilisateurs qui commencent par lettres I à Z — vous devez ajouter conditions pour cette plage de lettres.

Ensuite, j'ai simplement Windows PowerShell de créer le dossier, afin de la fonction se présente comme suit :

Function CreateHomeFolder {
  Param($userinfo)
  $server1 = 'a','b','c','d'
  $server2 = 'e','f','g','h'
  Switch ($userinfo['samAccountName'].
    substring(0,1).tolower()) {
    { $server1 –contains $_ } 
      { $homeserver = '\\homeserver1\'; break; }
    { $server2 –contains $_ } 
      { $homeserver = '\\homeserver2\'; break; }
  }
  Mkdir ($homeserver + '\$Homes\' + $userinfo['samAccountName'])
}

La commande MkDir, qui est en fait une fonction intégrée qui utilise le nouveau-Itemcmdlet, accepte les chemins d'accès UNC. Donc je suis combinaison le nom du serveur dossier personnel approprié avec le $ partagent des maisons d'administration et samAccountName de l'utilisateur. Si samAccountName l'utilisateur DonJ, MkDir engendre \\server1\$Homes\DonJ.

Attribution d'autorisations

Le nouveau dossier est, par défaut, les autorisations de son dossier parent hérite. Ainsi, pour cet exemple, je suis suppose que le dossier parent possède les autorisations de base appropriées que je souhaite s'affecter à tout nouveau dossier de base d'utilisateurs. Par exemple, cette autorisation pouvez affecter à un contrôle total sur le compte système intégré, ainsi que pour le groupe Admins du domaine ou le groupe d'administrateurs local, mais cette autorisation probablement pas comprennent les autres utilisateurs. Sorte suffit maintenant vous assurer que mon nouveau compte d'utilisateur dispose des autorisations pour le répertoire domicile, que J'AI créé simplement.

Maintenant, Veuillez ne pas récupérer mad, mais je dois que que ce n'est pas une tâche pour laquelle Windows PowerShell est actuellement adapté. Je sais, je suis désolé. Il est simplement que les autorisations de fichier Windows sont choses peu terrifically complexes. Vous disposez d'une liste de contrôle l'accès (ACL) qui contient les entrées de contrôle d'accès (ACE). Chaque ACE combine un indicateur verte/Refuser, autorisations such as en lecture ou écriture) et le GUID d'une entité de sécurité (telle qu'un utilisateur ou groupe). Il s'agit de nombreuses informations que doit travailler ensemble.

L'interpréteur de commandes offre cmdlet Get-ACL et Set-liste de contrôle d'accès, mais modification d'une liste de contrôle d'accès nécessite que vous obtenez la liste de contrôle d'accès, endommager autour des objets de Microsoft .NET Framework pour modifier la liste de contrôle d'accès et puis supprimer l'ACL sur le fichier ou le dossier modifié. C'est un peu trop bas niveau pour mon tastes. Je pourrait utiliser WMI (Windows Management Instrumentation), mais qui serait fonctionne très la même façon.

Heureusement, Microsoft a regroupé beaucoup de cette complexité dans un outil pratique et plus facile à utiliser appelé cacls.exe, je parie que vous connaissez, comme il a été autour jamais. Utilisation ne pas uniquement enregistrer me quelques efforts inutiles, mais également explique comment Windows PowerShell fonctionne parfaitement bien avec les outils de ligne de commande externes (Cacls, ping, ipconfig et ainsi de suite). Si vous connaissez déjà l'utilisation d'un de ces outils, Veuillez continuez d'utiliser il dans Windows PowerShell. Un des concepts plus importants avec Windows PowerShell est que vous ne devez relearn de toutes pièces.

(Au passage, je sais que cacls.exe est désapprouvé. Sa simplement une légèrement plus simple syntaxe est que le remplacement ICacls.exe, donc j'utilise. Vous pouvez modifier cette option pour utiliser ICacls.exe si vous le souhaitez.)

Prévoyez par le fichier d'aide de cacls.exe, je trouve que J'AI besoin d'une commande qui ressemble à ceci :

cacls \\server1\homes\DonJ /e /g DOMAIN\DonJ:R
cacls \\server1\homes\DonJ /e /g DOMAIN\DonJ:W

Cette s'attribuer les autorisations de lecture et écriture à notre nouvel utilisateur, sans remplacer les autres autorisations déjà sur le dossier.

Un problème, cependant, est que je souhaite utiliser des variables dans cette commande, plutôt que des valeurs statiques. Placer des variables d'environnement dans commandes externes peut être difficile parfois. Il existe un certain nombre de méthodes, mais celle que j'aime consiste à créer la chaîne de commande entière dans une variable d'environnement et à utiliser Cmd.exe pour exécuter cette chaîne. Il se présente comme suit :

$cacls1 = "cacls "+$homeserver+"$Homes\"
  +$userinfo['samAccountName']+" /E /G "
  +$user+":W"
$cacls2 = "cacls "+$homeserver+"$Homes\"
  +$userinfo['samAccountName']+" /E /G "
  +$user+":W"
cmd /c $cacls1
cmd /c $cacls2

D'accord, cela peut être pas la chose prettiest dans le monde, mais il obtient le travail effectué. Elle effectue également mon motive ulterior de démonstration outils de ligne de commande externes comment complexes peuvent être paramétrées à l'aide de variables d'environnement. J'AI peuvent déposer ces quatre lignes de code directement dans ma fonction après la commande MkDir et la fonction est terminée.

Tout j'avoir reste à faire consiste à ce stade à créer les deux dernières fonctions dans ma fonction provision maître : AddToGroups et UpdateAttributes. J'expliquerai comment procéder dans l'article suivant de la colonne de Windows PowerShell.

Don Jones est cofondateur de technologie concentrés ( ConcentratedTech.com), où il blogs hebdomadaires sur Windows PowerShell, SQL Server, Application-V et d'autres rubriques. Contacter par le biais de son site Web.