• Article

Windows PowerShell Automatisation utilisateur mise en service, partie 2

Don Jones

Contenu

Création d'un utilisateur
Manquant Exchange ?
Options, Options, Options

Dans le précédent article de cette chronique, J'AI créé la base d'un utilisateur automatique mise en service de script. J'AI créé une fonction appelée ProvisionInputCSV, est conçu pour lire les informations utilisateur d'un fichier CSV et renvoyer ces informations dans la forme d'une table de hachage. J'a pris cette approche car elle autorisée me puis créer plusieurs autres fonctions « importer, importer à partir d'une base de données, importer d'une feuille de calcul, ou tout ce qui, et chaque retour un une table de hachage identiques de recherche. Ma fonction d'attribution de privilèges d'accès réelle simplement doit accepter cette table de hachage, qui peut contenir éléments pour un utilisateur prénom, dernière nom de ville, département et ainsi de suite.

Dans l'article de mois-ci ce, J'AI peuvent commencer à utiliser cette table de hachage pour créer un utilisateur de nouveau, avec boîte aux lettres dans Active Directory (ou un utilisateur non boîte aux lettres,) si vous utilisez Exchange Server 2007.

La structure de base de la fonction d'attribution de privilèges d'accès ressemble à ceci :

Function Provision {
  PROCESS {
  }
}

J'ai déjà établi que la fonction recevra une table de hachage dans le pipeline, il va accéder via la variable spéciale $ _ Dans le scriptblock de traitement. La table de hachage possèdent des clés qui correspondent aux attributs de l'utilisateur et les valeurs de ces touches contiennent les informations de chaque utilisateur. Voici quelques exemples :

  • $ _ ['sn'] = « Jones »
  • $ _ ['givenname'] = « Don »
  • $ _ ['samaccountname'] = "donj"

Les attributs exactes disponibles varient selon que vous avez placer dans votre fonction ProvisionInputCSV ou autre fonction d'importation.

N'oubliez pas que la mise en service utilisateur implique généralement de plusieurs étapes, comme la création d'un compte, créez un dossier et ainsi de suite. Il serait facile à coller toutes ces tâches dans ma fonction provision, mais cela rendrait la fonction assez complexe, et plus complexe signifie que plus difficile pour déboguer et résoudre les problèmes. Au lieu de cela, j'utiliserai la fonction de provision comme une sorte de liste de tâches maître, rupture chaque tâche hors dans sa propre fonction auxiliaire. Au final, la fonction de provision ressemblera à ceci :

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

Windows PowerShell Forum aux questions

q: je ne vois un paramètre –computerName sur très nombreuses cmdlets. Windows PowerShell peut être utilisé pour gérer les ordinateurs distants ?

une version de Windows PowerShell 1 est limitée des capacités d'accès distant. La cmdlet Get-WmiObject offre, comme vous pouvez ont découvert, un paramètre computerName afin que vous pouvez récupérer les informations à partir d'un ou plusieurs ordinateurs distants, comme suit :

Get-WmiObject Win32_Service –computerName
  "localhost","server2","server3"

Mais c'est sur la fonctionnalité de gestion à distance uniquement intégré que se trouve dans la première version de Windows PowerShell.

Toutefois, les autres technologies, telles que Exchange Server et Active Directory, sont transférée par nature « distance », c'est-à-dire que votre ordinateur client sait qu'il n'est pas un serveur de messagerie ou un contrôleur de domaine et est un contact en tant qu'approprié. Vous ne devez en fait un paramètre computerName pour les commandes qui fonctionnent avec ces technologies.

Chacune des quatre fonctions de filiales gère une des principales tâches que J'AI présentée dans la première partie de cette série et chaque cours est passé l'ensemble des informations utilisateur dans la variable $ _. Ainsi, il existe, mon script d'attribution de privilèges d'accès fait !

Création d'un utilisateur

Venez kidding. Évidemment J'AI toujours devez écrire la fonctionnalité réelle, qui se trouve dans les quatre fonctions secondaires. Dans cet article, je me concentrer sur la fonction CreateUser. La première itération de ce code suppose que vous disposez d'Exchange Server 2007 dans votre environnement. (Désolé, cela ne fonctionne pas pour les versions anciennes d'Exchange Server.) Quel que soit ordinateur que vous utilisez pour exécuter ce script doit avoir les outils de gestion Exchange Server installé et vous devrez peut-être assurez-vous que le composant logiciel enfichable Exchange Server pour Windows PowerShell est chargé. Pour vérifier, exécutez Get-PSSnapin et observez si elle est répertoriée. Si ce n'est pas le cas, exécutez Get-PSSnapin-enregistré pour vous assurer qu'il est installé. Ensuite, pour charger le composant logiciel enfichable dans l'interpréteur de commandes, exécutez ceci :

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin.

Si vous ne voulez plus de taper cette commande, vous pouvez l'ajouter au script qui contient toutes les fonctions d'attribution de privilèges d'accès ou pouvoir l'ajouter à votre profil Windows PowerShell à ce qu'il charge lorsque vous ouvrez l'interpréteur de commandes. (J'AI expliqué comment vous pouvez créer profils personnalisés dans l'article octobre 2008 de cet article » La puissance de profils."

Voici l'infrastructure de base pour ma fonction :

Function CreateUser {
  Param($userinfo)
}

Notez que j'ai inclus un bloc de param, qui indique l'interpréteur de commandes les paramètres que je suis attendu. Lorsque j'appelez cette fonction, la table de hachage que je transmets va être automatiquement stocké dans la variable d'userinfo $.

Voici une autre méthode pour écrire cela :

Function CreateUser($userinfo) {
}

Cette syntaxe a exactement le même effet. Toutefois, l'interpréteur de commandes n'utilise la première version interne afin que j'ont tendance à utiliser cette version me. Je pense l'utilisation du bloc param facilite la fonction de la lecture vers le bas la route.

Dans la fonction, je dois exécuter uniquement une seule commande : nouvelle boîte aux lettres. Ce fait ne plus que crée une nouvelle boîte aux lettres ; il crée également un nouvel utilisateur dans Active Directory. JE dois savoir quelques éléments d'information en amont, y compris la base de données boîte aux lettres souhaitée la boîte aux lettres à stocker. La syntaxe de base se présente comme suit (qui est réellement tout une longue et unique ligne de commande) :

New-Mailbox –UserPrincipalName don@concentratedtech.com 
  -alias DonJ 
  –database "Storage Group 1\Mailbox Database 1" 
  –name Don Jones 
  –organizationalUnit Users 
  –password $password 
  –FirstName Don 
  –LastName Jones 
  –DisplayName "Don Jones" 
  –ResetPasswordOnNextLogon $true

Vous pouvez voir que je dois proposer un mot de passe pour le nouvel utilisateur et de décider quel OU (unité organisationnelle) pour placer l'utilisateur dans. (Dans cet exemple, « utilisateurs » sont techniquement un conteneur, pas une unité D'ORGANISATION, mais la commande soit acceptera.) En supposant que ma fonction ProvisionInputCSV a été modifiée afin de produire tout ce dont J'AI besoin, pouvez prévu la variable userinfo $ contiennent les informations ­minimum suivantes :

  • UPN (nom utilisateur principal)
  • Unité D'ORGANISATION (OU de destination)
  • MailDatabase
  • givenName (Nom Prénom)
  • SN (Nom Prénom)
  • samAccountName (que je vais utiliser comme « alias »)

Qui me donne la fonction suivante :

Function CreateUser {
  Param($userinfo)

New-Mailbox –UserPrincipalName $userinfo['upn'] 
  -alias $userinfo['samAccountName'] 
  –database $userinfo['mailboxDatabase'] 
  –name ($userinfo['givenName'] + ' ' + $userinfo['sn']) 
  –organizationalUnit $userinfo['ou'] 
  –password 'P@ssw0rd!' –FirstName ($userinfo['givenName'] 
  –LastName $userinfo['sn']) 
  –DisplayName ($userinfo['givenName'] + ' ' + $userinfo['sn']) 
  –ResetPasswordOnNextLogon $true
}

(Là encore, la commande doit être une seule ligne, mais j'ai morcelés il ici pour rendre plus résumé.) Associé à mes fonctions provision et ProvisionInputCSV, cette fonction crée les nouveaux utilisateurs et rendre avec boîte aux lettres.

Quelques éléments intéressants sont important de noter ici :

  • Rien dans la commande respecte la casse, bien que Active Directory conserve le casse vous utiliser dans des éléments tels que des noms.
  • Je suis donnant-Paramètres de nom et - nom d'affichage une expression à une valeur. J'AI placer l'expression (entre parenthèses) pour vérifier l'interpréteur de commandes évalue l'expression et transmet les résultats au paramètre. Cette technique vous permet de m'utiliser les attributs de givenName et sn pour construire un nom complet.
  • J'ai codé en dur un mot de passe temporaire plutôt que d'un composant. Apporter des mots de passe nécessite un moyen de communiquer les mots de passe pour les utilisateurs, et c'est abordée dans cette discussion.
  • La variable $ true est intégrée à l'interpréteur de commandes et représente la valeur booléenne True (l'opposé de la valeur False).

Manquant Exchange ?

Windows PowerShell n'est pas aider à créer un utilisateur avec boîte aux lettres si vous utilisez Exchange Server 2007. Toutefois, vous pouvez toujours créer le compte d'utilisateur de base dans Active Directory. Pour ce faire, vous devez les cmdlets de Active Directory disponible pour Windows PowerShell, qui sont disponibles à www.quest.com/PowerShell. Ceux présents sur l'ordinateur sur lequel vous allez exécuter votre script et ajouter le composant logiciel enfichable à l'interpréteur de commandes en exécutant cette installation :

Add-PSSnapin Quest.ActiveRoles.ADManagement

Notez que le nom du composant logiciel enfichable inclut le nom d'un produit Quest commercial (ActiveRoles Server), mais inutile ce produit dans afin d'utiliser la cmdlet dans le composant logiciel enfichable.

Vous allez utiliser la commande New-QADUser, exécution à ce qui suit dans la fonction CreateUser :

New-QADUser –samAccountName $userinfo['samAccountName'] 
  –parentContainer $userinfo['OU'] 
  –FirstName $userinfo['givenName'] 
  –LastName $userinfo['sn'] 
  –Name ($userinfo['givenName'] + ' ' + $userinfo['sn']) 
  –UserPrincipalName $userinfo['UPN'] 
  –displayName ($userinfo['givenName'] + ' ' + $userinfo['sn']) 
  –userPassword "P@ssw0rd!" | Enable-QADUser

Notez que j'ai transmis la sortie de cette commande, qui se compose de l'utilisateur nouvellement créé, à une seconde commande qui permet au compte d'utilisateur. Vous pouvez décider si cette conception est adaptée à votre environnement.

La commande New-QADUser a des dizaines de paramètres que vous pouvez utiliser pour définir des attributs Active Directory, mais je suis laisser cette commande en tant que - est pour la rendre plus parallèle avec la version Exchange Server. Je vous remplissez des attributs supplémentaires dans la dernière partie de ce script.

Options, Options, Options

Même si vous exécutez Exchange Server 2007, il peut toujours préférable d'utilisant New-QADUser pour créer des comptes d'utilisateurs. Cela certainement offre plus de souplesse, que cette commande peut gérer n'importe quel attribut d'annuaire. Et New-QADUser va apporter votre script compatible avec n'importe quel environnement Exchange Server 2007 est en cours d'utilisation ou non.

Si vous possédez Exchange Server 2007, vous pouvez utiliser une syntaxe autre boîte aux lettres de nouvelle pour créer une boîte aux lettres et la lier au compte Active Directory juste créé. Vous trouverez que Windows PowerShell propose généralement plusieurs façons différentes pour faire quelque chose, l'approche de droite est généralement celui qui convient le mieux comportant le moins de formation impliqués.

Mois prochain, j'allons jeter un peu plus cette fonction d'attribution de privilèges d'accès en demandant à créer des dossiers personnel pour les utilisateurs et appliquer le droit Access listes de contrôle (ACL) à ces dossiers. Listes de contrôle d'accès sont particulièrement difficile à utiliser, et vous pouvez être surpris par la technique qui peut vous aider à obtenir le travail effectué plus facilement Windows PowerShell.

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