Dodawanie użytkowników z odpowiednimi parametrami przez PowerShell

Ostatnio przyszło mi postawić stronę internetową, która udostępnia interfejs do tego, aby dodać użytkownika do Active Directory, wrzucić do odpowiedniego (wcześniej ustalonego) kontenera OU, włączyć konto i uniemożliwić zmianę hasła użytkownikowi.

Skrypt, jaki to umożliwia (bazujący na cmdletach Quest):

Add-PSSnapin Quest.ActiveRoles.ADManagement

New-QADUser -name NAZWAUSERA -ParentContainer ‚CN=Users,DC=moja,DC=domena,DC=pl’ -samAccountName NAZWAUSERA -UserPrincipalName NAZWAUSERA -UserPassword ‚HASŁOUSERA’ | Enable-QADUser | Set-QADUser -PasswordNeverExpires $true -UserMustChangePassword $false | Add-QADPermission -Account SELF,Everyone -ExtendedRight "User-Change-Password" -Deny -ApplyTo ThisObjectOnly

Takie wpisy tworzą użytkownika NAZWAUSERA z hasłem HASŁOUSERA, włączają to konto oraz wyłączają możliwość zmiany hasła, ustawiając hasło na trwałe (niewygasające).

Do zmiany hasła użytkownik dostaje inny interfejs, gdzie wpisuje tylko swój login i nowe hasło. Skrypt “z tyłu”:

Add-PSSnapin Quest.ActiveRoles.ADManagement

Get-QADUser -sAMAccountName ‚NAZWAUSERA‚ | Set-QADUser -userPassword ‚HASŁOUSERA‚

W moim przypadku inny mechanizm chroni dostęp do tej witryny (wcześniej) – dla użytkownika pojawia się tylko miejsce na wpisanie nowego hasła.

 

Co, jeśli potrzeba zresetować hasła wszystkim w ramach danego OU? Zresetować – ustawić to samo dla wszystkich i wymusić zmianę przy najbliższym logowaniu albo tylko wymusić zmianę przy najbliższej okazji?

Wykorzystując cmdlety Quest:

Add-PSSnapin Quest.ActiveRoles.ADManagement

$OU = "DOMENA.COM/OUZmianyHasla"

get-QADUser -SearchRoot $OU | set-QADUser -userpassword "tYmcz4sow3Has!0"

ForEach-Object { get-QADUser -searchroot $OU | Set-QADUser -UserMustChangePassword $true}

Powyższe linie w PowerShell: aktywują cmdlety Quest, ustawiają zmienną OU, wszystkim użytkownikom z OU zmieniają hasło a następnie wymuszają zmianę hasła przy najbliższym logowaniu.

Jeśli z jakichś powodów musimy wymusić tylko zmianę haseł, z powyższego usuwamy linię trzecią.

 

Bez wykorzystania cmdletów Quest, za to w CMD a nie w powershell:

dsquery user OU=OUZmianyHasla,DC=DOMENA,DC=COM | dsmod user -pwd tYmcz4sow3Has!0 -mustchpwd yes

 

Na podstawie:

http://wss.pl/frmThread.aspx?tid=111070&pid=616149#616149

http://social.technet.microsoft.com/Forums/en/winserverpowershell/thread/c936873b-48ee-46d5-8c0d-8e73bbc5a01f

+ Własna walka (zakładanie i zmiana hasła pojedynczej osoby)

Błąd 8193 VSS po instalacji DHCP

Jeśli na Windows Server 2008 R2 zainstalujemy rolę serwera DHCP, czasem (na około 6 serwerów miałem/mam 2 takie przypadki), przy włączaniu komputera możemy otrzymywać błąd:

Volume Shadow Copy Service error: Unexpected error calling routine RegOpenKeyExW(-2147483646,SYSTEM\CurrentControlSet\Services\VSS\Diag,…).  hr = 0x80070005, Access is denied.

Co ciekawe, u mnie błąd ten pojawia się przy roli File Services:

Ponieważ nie lubię “czerwonych wykrzykników”, zacząłem szukać rozwiązania. Znalazłem krótką notkę o tym błędzie, przy czym sugeruje ona nadanie uprawnień dla klucza:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\VSS

Użytkownikowi, który jest wypisany w ramach błędu. A co, jeśli jest N/A?

Wtedy wystarczy dodać uprawnienia dla użytkownika NETWORK SERVICE:

Aby sprawdzić czy problem został rozwiązany, ukrywamy wszystkie wydarzenia:

a następnie z cmd z podwyższonymi uprawnieniami wykonujemy:

NET STOP WSEARCH

NET START WSEARCH:

Po tym zabiegu serwis zatrzymał się (EventID: 1013) i wstał (EventID: 1003) bez problemu:

Na podstawie: własne

http://www.jcarle.com/2009/09/06/fixing-the-volume-shadow-copy-service/

http://sharepointreporter.wordpress.com/2009/12/22/vss-error-in-windows-server-2008-r2-event-id-8193/#comment-58