Neural failure… Abort, Retry, Fail?
I do this in my home test networks. It should NOT be done in a production system or even test systems where access to the server may be easy for many people.
Create a new GPO and link it where appropriate. Then edit the following:
Computer Configuration -> Policies -> Administrative Templates -> System -> Power Management -> Video and Display Settings -> Turn Off the Display (Plugged In)
Enable it and set “Seconds” to 0.
The default domain GPO is used to set the password policy in an Active Directory environment. However, according to MS only one GPO is allowed within a domain to be set when dealing with password policies. MS created Fine-Grained password policies to allow for additional password policy settings where required. This may be set via PowerShell commands or using the Active Directory Administrative Center (ADAC) tool.
A few cravats:
Fine-Grained password policies can be applied to user objects and global security groups. If you need to apply the Fine-Grained password policy against an OU, “shadow” groups are required to be applied to the OU. A shadow group can only be applied to one OU and if a user is moved between OU’s, the shadow group membership must also be changed.
There are several methods in which the new policy can be created, such as ADSI.exe, but this will only cover the more common methods of creation.
Create a New Fine-Grained Password Policy via GUI
Open Active Directory Administrate Center (ADAC) as admin:
Server Manager -> Tools -> Active Directory Administrate Center
Or open PowerShell as admin:
dsac.exe
In ADAC:
Manage -> Add Navigation Modes
In the “Add Navigation Modes window”:
System -> Password Settings Container -> click the double arrow button to add it to the navigation pane -> OK
Create a new password policy:
Select System-Password-Container -> New (under Tasks) -> Password Settings
Enter the appropriate password policy information. Note the name that you give it and set a precedence such as “1”. Under “Directly Applies To”, add the desired security group that the new policy will be applied against.
Fine-Grained Password Policies Using PowerShell
As always, see PowerShell Help for more detailed information than may be shown here. Open Powershell as admin.
To view all policies (or get a policy name):
Get-ADFineGrainedPasswordPolicy -Filter "*"
To view a single policy:
Get-ADFineGrainedPasswordPolicy -Identity "<policy name>"
To view all properties in a policy:
Get-ADFineGrainedPasswordPolicy -Identity "<policy name>" -Properties *
To view detailed properties information:
Get-ADFineGrainedPasswordPolicy -Identity "<policy name>" -Properties * | Get-Member
To view the group affected by the Fine-Grained Password Policy (can also be seen in the above commands):
Get-ADFineGrainedPasswordPolicySubject -Identity "<policy name>"
To Create a new policy:
New-ADFineGrainedPasswordPolicy "<policy name>" -ComplexityEnabled:$true -MaxPasswordAge:"90.00:00:00" -MinPasswordAge:"1.00:00:00" -MinPasswordLength:"12" -PasswordHistoryCount:"24" -Precedence:"1" -ReversibleEncryptionEnabled:$false -ProtectedFromAccidentalDeletion:$true
Apply a security group to a policy
Add-ADFineGrainedPasswordPolicySubject "<policy name>" -Subjects "<group name>"
Check the RSOP for the password policy for a user in the group:
Get-ADUserResultantPasswordPolicy "<user name>"
You can also edit and delete a policy using PowerShell. Look em up. In both PowerShell and ADAC the “Protect from accidental deletion” property must be changed before deletion can take place.
You should have access to a domain joined admin workstation and a domain controller.
Download the LAPS files from Microsoft onto the admin workstation. You can choose the architecture and documentation that you want to download.
Install all of the LAPS components onto the admin workstation.
NOTE: To see all of the module commandlets:
Get-Command -Module AdmPwd.ps
Extend the AD Schema. See the MS documentation if you have an RODC
On the admin workstation, open a PowerShell terminal as a user that has schema admin rights:
Import-Module AdmPwd.ps Update-AdmPwdADSchema
To verify LAPS was added to the AD schema, in a domain controller PowerShell terminal:
Get-ADObject 'CN=ms-Mcs-AdmPwd,CN=schema,CN=Configuration, DC=contoso,DC=com'
View Extended Right Holders in the target OU
Passwords are kept in plain text on the DC so permissions assigned to LAPS are critical. Only those who should have access to view and set the passwords should be allowed to view and change the passwords.
Get an early look at Extended Rights Holders on the OU’s where LAPS will be applied. On my clean lab machines, I only see “NT AUTHORITY\SYSTEM, CONTOSO\Domain Admins”. If any others show up, you should consider whether to remove them or leave them in place if they will be actually used in the LAPS configuration. See the MS document for further:
Find-AdmPwdExtendedRights -Identity "<OU NAME>" | Format-Table -or- Find-AdmPwdExtendedRights -Identity "<OU NAME>" | Format-List
Set the Extended Right Holders in the target OU
The following commands require the PowerShell module to be loaded:
Import-Module AdmPwd.ps
* Note also that the commands need to be run on each OU where LAPS is to be used.
Add SELF permissions to all computers in an OU to allow them to change their own local admin password:
Set-AdmPwdComputerSelfPermission -Identity "<OU NAME>"
For the next to commands, you will need to create the appropriate domain security groups as needed.
Add users/groups that will be allowed to read the LAPS passwords (this is a single command):
Set-AdmPwdReadPasswordPermission -Identity:"<OU NAME>" -AllowedPrincipals:"<domain\user or group>", "<domain\another user or group name>"
Add users/groups that will be allowed to reset the local admin passwords on the LAPS computers (also run the above command in addition to this one):
Set-AdmPwdResetPasswordPermission -Identity:"<OU NAME>" -AllowedPrincipals:"<domain\user or group>", "<domain\another user or group name>"
If you want to check that permissions were set, this command should show it:
Find-AdmPwdExtendedRights -Identity "<OU NAME>" | Format-List
Or check the object security permissions:
R-click the OU -> Properties -> Security tab -> Advanced -> Select the group name -> Edit
Under Properties (scroll down), these should be checked:
Read ms-Mcs-AdmPwdExpirationTime Write ms-Mcs-AdmPwdExpirationTime *Note - write depends on which Set-AdmPwd command you ran above.
Setup GPO for LAPS
The LAPS GPO files are installed on the admin workstation and need to be copied to the Active Directory server. They can be found under C:\Windows\PolicyDefinitions and C:\Windows\PolicyDefinitions\en-US (if using the US version of English).
Once the files have been copied to the AD server, create the following directories on the AD server if they do not already exist and copy the files.
The AdmPwd.admx file needs to be copied to:
C:\Windows\SYSVOL\contoso.com\Policies\PolicyDefinitions\
The AdmPwd.adml file needs to be copied to:
C:\Windows\SYSVOL\contoso.com\Policies\PolicyDefinitions\en-US\ en-US, (or what ever the appropriate language on the server is)
Open Group Policy Management and create a LAPS GPO object.
Edit the LAPS GPO for the appropriate settings for your domain:
Computer Configuration -> Administrative Templates -> LAPS
Link the GPO to the appropriate OU’s.
Install the client piece
The LAPS client can be installed using SCCM, Group Policy, scripting, or locally using a .msi or .dll file.
On my admin workstation, I can see that LAPS is already installed by viewing “Programs and Features”, or by looking for “C:\Program Files\LAPS\CSE\AdmPwd.dll”. This .dll file can be used to install the client on other computers if desired.
Adding additional OU’s after initial setup
If LAPS is already setup and you are adding new OU’s or computers:
-Set the permissions on the OU using PowerShell commands above. -Set up the admin user locally on each managed computer. -Set up a new GPO if needed. -Install the client.