Windows PowerShell: Automatyzowanie tworzenia i wyposażania użytkowników, część 2

Autor: Don Jones

Opublikowano: 23 listopada 2009

Zawartość strony

	Tworzenie użytkownika
	Brak Exchange?
	Opcje, opcje, opcje...
	Windows PowerShell - Pytania i odpowiedzi
	Dodatkowe materiały

W poprzednim odcinku zademonstrowałem podstawy skryptu automatyzującego tworzenie i wyposażanie kont użytkowników. Utworzyłem funkcję o nazwie ProvisionInputCSV, która ma na celu odczytanie informacji o użytkownikach z pliku CSV i zwrócenie ich w postaci obiektu typu hashtable. Wybrałem takie podejście, gdyż pozwala ono na tworzenie innych funkcji „importujących” – pobierających informacje z bazy danych, arkusza kalkulacyjnego lub dowolnych innych źródeł – i zapewnienie, że każda będzie zwracać identycznie wyglądający obiekt hashtable. Rzeczywista funkcja wyposażająca musi jedynie akceptować ten obiekt, który może zawierać takie elementy jak imię i nazwisko użytkownika, miasto, oddział przedsiębiorstwa i tak dalej.

W bieżącym odcinku zajmę się wykorzystaniem zawartości obiektu hashtable do utworzenia w Active Directory nowego konta użytkownika z włączoną obsługą poczty (albo użytkownika bez skrzynki pocztowej, jeśli nie korzystamy z Exchange Server 2007).

Bazowy szkielet funkcji wyposażającej wygląda następująco:

Function Provision {

  PROCESS {

  }

}

Ustaliłem już, że funkcja ta będzie odbierała obiekt hashtable przez potok, do którego dostęp zapewni specjalna zmienna $_ wewnątrz bloku PROCESS. Obiekt hashtable będzie używał kluczy odpowiadających atrybutom użytkownika, zaś wartości tych kluczy będą zawierały informacje o poszczególnych użytkownikach. Oto kilka przykładów:

• $_['sn'] = "Jones"
• $_['givenName'] = "Don"
• $_['samAccountName'] = "donj"

Konkretne dostępne atrybuty zależą od tego, co zostało przekazane do funkcji ProvisionInputCSV (lub innej funkcji importującej).

Należy pamiętać, że wyposażanie konta użytkownika zazwyczaj obejmuje kilka kroków, takich jak tworzenie konta, tworzenie folderu domowego i tak dalej. Mógłbym łatwo wstawić wszystkie te zadania do wnętrza funkcji Provision, ale takie działanie spowodowałoby, że stałaby się ona dość złożona – a większa komplikacja oznacza trudniejsze debugowanie i rozwiązywanie problemów. Zamiast tego użyję funkcji Provision jako swoistej głównej listy zadań, rozdzielając poszczególne czynności na odpowiadające im funkcje podrzędne. Na koniec funkcja Provision będzie wyglądać mniej więcej tak:

Function Provision {

  PROCESS {

    CreateUser $_

    CreateHomeFolder $_

    AddToGroups $_

    UpdateAttributes $_

  }

}

Każda z czterech podrzędnych funkcji obsługuje jedno z głównych zadań, które przedstawiłem w pierwszej części artykułu, przy czym do każdej przesyłany jest pełny zestaw informacji o użytkowniku zawarty w zmiennej $_. Tak więc – mówiąc najogólniej – skrypt jest już gotowy!

Tworzenie użytkownika

Żartowałem. Oczywiste jest, że muszę dopiero napisać kod prawdziwej funkcjonalności – treść owych czterech funkcji podrzędnych. W tej części skoncentruję się na funkcji CreateUser. Pierwsza iteracja tego kodu zakłada, że w danym środowisku używane jest rozwiązanie Exchange Server 2007 (przykro mi to powiedzieć, ale nie będzie to działało ze starszymi wersjami Exchange Server). Komputer, który zostanie użyty do wykonania skryptu, musi mieć zainstalowane narzędzia administracyjne Exchange Server i załadowaną przystawkę Exchange Server dla Windows PowerShell. W celu sprawdzenia tego warunku można użyć polecenia Get-PSSnapin. Jeśli przystawki nie ma na liście, należy użyć polecenia Get-PSSnapin -registered w celu upewnienia się, że nie jest zainstalowana. Następnie załadujemy przystawkę do powłoki, wykonując następujące polecenie:

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

Aby uniknąć konieczności wpisywania tego polecenia za każdym razem, można dołączyć je do skryptu zawierającego wszystkie funkcje wyposażania użytkowników albo dodać je do profilu Windows PowerShell, co spowoduje załadowanie przystawki przy każdym otwarciu powłoki. Tworzenie niestandardowych profili omówiłem w artykule opublikowanym w październiku 2008, „The Power of Profiles”.

Oto szkielet mojej funkcji:

Function CreateUser {

  Param($userinfo)

}

Zwróćmy uwagę na blok param, który informuje powłokę, jakich parametrów funkcja będzie oczekiwać. Przy wywołaniu tej funkcji przesłany do niej obiekt hashtable zostanie automatycznie umieszczony w zmiennej $userinfo.

Powyższe można również zapisać w następujący sposób:

Function CreateUser($userinfo) {

}

Składnia ta daje dokładnie ten sam efekt. Jednak powłoka wewnętrznie używa pierwszej wersji, zatem wolę stosować tę składnię. Ponadto uważam, że użycie bloku param zapewni lepszą czytelność funkcji, gdy trzeba będzie zajrzeć do niej kiedyś w przyszłości.

Wewnątrz funkcji muszę wykonać tylko jedno polecenie: New-Mailbox. Wbrew pozorom wykonuje ono znacznie więcej niż samo stworzenie nowej skrzynki pocztowej: tworzy również nowe konto użytkownika w Active Directory. Na początek musimy znać kilka informacji, takich jak nazwę bazy danych skrzynek pocztowych, w której utworzona skrzynka będzie przechowywana. Podstawowa składnia wygląda następująco (jest to w istocie jeden długi wiersz):

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

Jak widać, konieczne jest podanie hasła dla nowego użytkownika i ustalenie, w której jednostce organizacyjnej (OU) zostanie umieszczone tworzone konto (technicznie rzecz biorąc, użyty w tym przykładzie obiekt „Users” jest kontenerem, a nie OU, ale polecenie zaakceptuje obie wersje). Zakładając, że funkcja ProvisionInputCSV została zmodyfikowana tak, aby dostarczać wszystkich potrzebnych informacji, mogę oczekiwać, że zmienna $userinfo będzie zawierała następujące informacje (jako minimum):

• UPN (user principal name – nazwa główna użytkownika)
• OU (docelowa OU)
• MailDatabase
• givenName (imię)
• sn (nazwisko)
• samAccountName (którego użyjemy jako 'alias')

Łącznie daje to następującą funkcję:

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

}

(Ponownie polecenie jest pojedynczym wierszem, który został tu połamany w celu poprawy czytelności). W połączeniu z funkcjami Provision oraz ProvisionInputCSV funkcja ta pozwoli utworzyć nowe konta użytkowników z włączoną obsługą poczty.

Warto tu zwrócić uwagę na kilka interesujących rzeczy:

• Żaden element polecenia nie rozróżnia wielkości liter, choć Active Directory zachowuje ich wielkość w takich elementach jak nazwy.
• Parametry -name oraz -displayName są przekazywane jako wyrażenia. Zostały one ujęte w nawiasy (), aby zapewnić wyliczenie wartości tych wyrażeń przez powłokę i przekazanie wyniku jako parametru. Technika ta pozwala wykorzystać atrybuty givenName oraz sn do zbudowania pełnej nazwy (imienia i nazwiska).
• Wprowadziłem na stałe tymczasowe hasła, zamiast ichkreowania podczas wykonywania skryptu. Tworzenie haseł wymagałoby jakiegoś sposobu przekazania ich następnie użytkownikom, co samo w sobie może być skomplikowane, ale przede wszystkim wykracza poza ramy tego opracowania.
• Zmienna $true jest wbudowana w powłokę i reprezentuje logiczną wartość prawda (True) – przeciwieństwo fałszu (False).

 Do początku strony

Brak Exchange?

Windows PowerShell nie pomoże w tworzeniu użytkownika z włączoną obsługą poczty, jeśli nie używamy Exchange Server 2007. Nadal jednak można utworzyć podstawowe konto użytkownika w Active Directory. W tym celu potrzebne będą dodatkowe (bezpłatne) polecenia cmdlet obsługi Active Directory dla Windows PowerShell, które można pobrać z witryny www.quest.com/powershell. Należy zainstalować je na komputerze, który będzie wykonywał skrypt i dodać przystawkę do powłoki, wykonując poniższe polecenie:

Add-PSSnapin Quest.ActiveRoles.ADManagement

Należy zauważyć, że nazwa przystawki zawiera nazwę komercyjnego produktu firmy Quest (ActiveRoles Server), ale produkt ten nie jest wymagany do wykorzystania poleceń cmdlet w przystawce.

Użyjemy polecenia New-QADUser, umieszczając kod podobny do poniższego w funkcji 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

Zwróćmy uwagę, że wyjście z tego polecenia – obiekt zawierający nowo utworzone konto użytkownika – zostaje przekierowane do drugiego polecenia, uaktywniającego to konto. Należy się zastanowić, czy takie rozwiązanie jest właściwe w konkretnym środowisku.

Polecenie New-QADUser zawiera kilkanaście parametrów, których można użyć do ustalenia dodatkowych atrybutów Active Directory, ale w tym wypadku zdecydowałem się pozostawić je bez tych opcji, aby uzyskać równoległy odpowiednik wersji wykorzystującej Exchange Server. Wypełnieniem dodatkowych atrybutów zajmiemy się w ostatniej części skryptu.

 Do początku strony

Opcje, opcje, opcje...

Nawet jeśli używamy Exchange Server 2007, nadal możemy preferować użycie New-QADUser do tworzenia kont użytkowników. Postępowanie takie zapewnia większą elastyczność, gdyż polecenie to może obsłużyć każdy atrybut katalogu. Poza tym cmdlet New-QADUser zapewnia zgodność skryptu z każdym środowiskiem, bez względu na to, czy jest w nim używany Exchange Server 2007, czy też nie.

Przy korzystaniu Exchange Server 2007 można posłużyć się alternatywną składnią polecenia New-Mailbox w celu utworzenia skrzynki pocztowej i połączenia jej z dopiero co utworzonym kontem Active Directory. Można się przekonać, że Windows PowerShell zazwyczaj oferuje kilka sposobów osiągnięcia tego samego celu – właściwym podejściem zwykle jest to, które najlepiej działa w określonym środowisku i wymaga najmniej przygotowań i nauki.

W kolejnym odcinku rozbudujemy funkcję wyposażającą poprzez dołączenie tworzenia folderów domowych dla użytkowników i zastosowanie do tych folderów właściwych list kontroli dostępu (ACL). Budowanie ACL jest zadaniem szczególnie mozolnym i można się zdziwić, jak technika Windows PowerShell może uprościć jego realizację.

 Do początku strony

Windows PowerShell - Pytania i odpowiedzi

Pytanie: Nie widzę parametru computerName w składni wielu poleceń cmdlet. Czy Windows PowerShell może zostać użyty do zarządzania zdalnymi komputerami?

Odpowiedź: Windows PowerShell w wersji pierwszej ma ograniczone możliwości pracy zdalnej. Polecenie Get-WmiObject udostępnia, co można łatwo zauważyć, parametr -computerName, dzięki któremu można odczytać informacje z komputera zdalnego (lub kilku komputerów), tak jak poniżej:

Get-WmiObject Win32_Service –computerName

  "localhost","server2","server3"

Jednak jest to w zasadzie wszystko, co można powiedzieć o możliwościach zdalnego zarządzania w pierwszej wersji Windows PowerShell.

Tym niemniej, inne rozwiązania, takie jak Exchange Server czy Active Directory, są z natury rzeczy „zdalne” – inaczej mówiąc, komputer kliencki „wie”, że nie jest serwerem poczty ani kontrolerem domeny i będzie się kontaktował z odpowiednią maszyną w razie potrzeby. Zatem w rzeczywistości do pracy z tymi rozwiązaniami parametr -computerName nie jest potrzebny.

 Do początku strony

Dodatkowe materiały

• Obejrzyj wideo demonstrujące techniki prezentowane w artykule (j. ang.)

O autorze

Don Jones jest współzałożycielem firmy (i witryny) Concentrated Technology, zawierającej blogi na temat Windows PowerShell, SQL Server, App-V i inne.

Do początku strony