Showing posts with label Group Policy. Show all posts
Showing posts with label Group Policy. Show all posts

Saturday, September 19, 2015

Deploy Local Administrator Password Solution (LAPS) for on-premises domain members

Local Administrator Password Solutions (LAPS) is a solution provided by Microsoft to manage the local administrator account on domain members which are included workstations and servers. LAPS extended Active Directory Schema to store each password of domain members into an Active Directory attribute, ms-Mcs-AdmPwd. By default, domain administrators can read this attribute to get the password of local administrator accounts but we can configure delegation to allow other groups or users to get it. Using LAPS to manage the password, it can change the password of local administrator account periodically because LAPS is needed to work with Group Policy.

LAPS tool requirement
  • Active Directory: Windows Server 2003 Service Pack 1 (SP1) or later
  • Managed domain members: Windows Server 2003 SP2 x86 or x64 later
  • Management tools requirement: .NET Framework 4.0, Windows PowerShell 2.0 or later, Group Policy Management Console, Active Directory Domain Services management tools

Lab environment
  • 1 x Domain Controller named DC01 is installed Windows Server 2012 R2
  • 1 x Windows Server 2012 R2 member server named MS01 to install LAPS
  • 2 x domain workstations are installed Windows 7 and 8.1 named W7 and W8.

Prerequisites
Download and save LAPS installation files on C:\Temp of MS01 from the following web site. Local Administrator Password Solution (LAPS)

Make sure the configuration account is a member of Schema Admins of your domain forest.
Install Group Policy Management Console and AD DS and AD LDS Tools on MS01.


Create a new OU named workstations and move W7 and W8 into this OU.
Create 2 domain user accounts R1 and R2 for testing.
Create a local user account named Nimda and add into local administrator group in Windows 7 and Windows 8.1

Lab
1. Log in MS01 as Domain Administrator.
2. Navigate to C:\Temp and then run LAPS.x64 to install LAPS with full installation.




3. Launch PowerShell as administrator.
4. Perform Import-Module AdmPwd.Ps to import the PowerShell module for LAPS.



5. Perform Update-AdmPwdSchema on PowerShell to extend Active Directory Schema.



ms-MCS-AdmExpirationTime and ms-Mcs-AdmPwd attributes have been added into you Active Directory Schema for computers.


6. Perform Find-AdmPwdExtendedRights -Identity Workstations to check current permission to read these attributes.


7. Perform Set-AdmPwdComputerSelfPermission -Identity Workstations to grant permissions for computer accounts which is under this OU to update the managed local administrator password and expiration date.


8. Perform Set-AdmPwdReadPasswordPermission -OrgUnit Workstations -AllowedPrincipals R1 to great domain user account, R1, to read these attribute.


9. Launch GPMC and the create a new GPO under Workstations OU on MS01.


Remark: The GPO for LAPS is required to create and configure by the Management PC because the GPO template is installed on it only.

10. Edit the GPO and then extend "Computer Configuration > Policies > Administrative Templates > LAPS".


11. Double click Password Settings and then select the following settings.

Password SettingsEnabled
Password Complexity: Large letters + small letters + number + specials
Password Length: 16
Password Age (Days): 30


12. Click OK.
13. Double click Name of administrator account to manage and then select the following settings.

Name of administrator account to manage: Enabled
Administrator account name: <local administrator account name of computers>


14. Click OK.
15. Double click Do not allow password expiration time longer than required by policy and Enable local admin password management, and then select Enable.


Test result
At this moment, W7 and W8 have been installed LAPS. I will install LAPS on W7 to verify the result.

Retrieve Password
1. On W7, log in as Domain Administrator.
2. Run LAPS installation tool with typical installation.


We can create a script to silent install LAPS tool by the following command.
msiexec /i LAPS.x64.msi or LAPS.x86 .msi /quiet

3. After installation, perform gpupdate /force to update the Group Policy.
4. Back to MS01, log in as R1.
5. Launch LAPS UI.
6. Under "ComputerName", enter W7 and then click Search.


The policy is applied to W7 and the password of Nimda on W7 is followed the GPO setting to generate it.

7. Under "ComputerName", enter W8 and then click Search.


The password of Nimda on W8 cannot be retrieved because LAPS hasn't been installed on W8.

8. On MS01, log in as R2.
9. Launch LAPS UI.
10. Under "ComputerName", enter W7 and then click Search.


R2 cannot retrieve the password of W7 because we didn't grant permission to R2.

Remark: We can perform Get-AdmPwdPassword -ComputerName <computername> to get the local administrator password by PowerShell.

Reset Password
1. On MS01, log in as R1.
2. Launch LAPS UI.
3. Under "ComputerName", enter W7 and then click Search.
4. Change "New expiration time" to next day and then click Set.


R1 got the message "Failed to request password reset" because we haven't granted permission to R1 to reset local administrator password of W7.

5. On MS01, log in as Domain Administrator.
6. Launch LAPS UI.
7. Under "ComputerName", enter W7 and then click Search.
8. Change "New expiration time" to next day and then click Set.


The local administrator password of W7 will be reset next day.

9. To grant R1 to reset local administrator password, we can perform Set-AdmPwdResetPasswordPermission -OrgUnit Workstations -AllowedPrincipals R1


Remark: We can perform Rest-AdmPwdPassword -ComputerName <computername> -WhenEffective <Date & Time> to reset the local administrator password by PowerShell.


More information:
Microsoft Security Advisory 3062591

Local Administrator Password Management Detailed Technical Specification

This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, January 5, 2015

Manage non-domain Hyper-V servers (Windows Server 2016 Technical Preview) by Hyper-V Manager

As one of my previous posts, I talked about Hyper-V Manager improvements in Windows Server Technical Preview (vNext). In Windows Server 2016 (Technical Preview), we can use "CredSSP" with NTLM authentication with different credentials to manage non-domain Windows Server 2016 (Technical Preview) with Hyper-V, Hyper-V Server Technical Preview or Windows 10 with Technical Preview. I'm going to try to manage Hyper-V servers in non-domain environment.

This lab is based on Windows Server 2016 (Technical Preview).

Lab environment
  • 1 server is installed Windows Server Technical Preview with Hyper-V management tools which is named vNext
  • 1 server is installed Hyper-V Server Technical Preview which is named HV05
  • Both servers with different local administrator password
Goal
Use the Hyper-V Manager of "vNext" to manage the Hyper-V Server, HV05.


High level steps
  • Enable "Remote Management" on HV05
  • Enable "WSManCredSSP" server role on HV05
  • Update the host file on vNext
  • Configure the local group policy on vNext
Steps
1. On HV05, log in as Administrator.
2. By default, "Remote Management" is disabled on Hyper-V Server Technical Preview.


We can enable "Remote Management" on sconfig of Hyper-V server or perform PowerShell cmdlet, Enable-PSRemoting to enable.


3. Perform "Enable-WSManCredSSP -Role Server -Force" on PowerShell console of HV05.


4. Go to vNext, log in as Administrator.
5. Add the host name, HV05, and IP address into Hosts" file as administrator.


6. Save and exit the file.
7. Launch "Local Group Policy Editor" by performing gpedit.msc on Start menu.
8. Navigate to "Computer Configuration > Administrative Templates > System > Credentials Delegation" and then modify "Allow delegating fresh credentials with NTLM-only server authentication".


9. Select "Enable" on on both policies and then click "Show".


10. Under "Value", enter "WSMAN/HV05".


Remark: To manage multi Hyper-V servers, we can insert "WSMAN/*" under "Value".

11. Click "OK" twice and close Local Group Policy Editor.
12. Launch "Hyper-V Manager", try to connect to "HV05" with "Connect as another user" option.


13. Click "Yes" to enable the delegation.


As a result, we can manage the Hyper-V hosts, HV05, with a different credential in non-domain environment.



In Windows Server Technical Preview, we cannot manage the previous versions of Hyper-V servers like Windows Server 2012 and R2 in non-domain environment.


There is a problem in down-level management in the Hyper-V manager of Windows Server Technical Preview.

This posting is provided “AS IS” with no warranties, and confers no rights!

Wednesday, August 6, 2014

Configuring an alternate source path for installing roles or features on Windows Server 2012 and R2

In Windows Server 2012 or R2 core fresh installation, the source files aren't copied to the Windows to reduce disk space and some features like .NET Framework 3.5 and Windows Deployment Services (WDS) also aren't copied to Windows. To install .NET Framework 3.5, you can follow "Installing Microsoft .NET Framework 3.5 in Windows Server 2012 or R2 by Windows Server installation disk" to install the feature. However, administrators need to insert the Windows Server installation disk on the server. In domain environment, administrators can copy the sources file to a file share to share it. After that, administrators configure and assign to servers which are installed Windows Server 2012 or R2 core. It's more efficiency.

In addition to core installation, servers with GUI installation were performed "Uninstall-WindowsFeature" with "-Remove" parameter. The binary files for installing roles or features are deleted.

Goal
  • Configuring a file share path on a file server to share source files
  • Configuring default alternate source path for all servers by Group Policy
Lab environment
  • 1 file server is installed Windows Server 2012 R2 named FS02 is joined test.tls1.lab
  • 1 domain controller is installed Windows Server 2012 R2 named DC01
  • 1 server core member server  is installed Windows Server 2012 R2 named SC01
Lab
For the demonstration, I will use Domain Administrator to log in all servers. In production environment, you should use another account with local administrator right to complete the steps.

Configuring folder permission
1. On FS02, log in as Domain Administrator.
2. Create a folder named "Sources" in C drive.



Remark: In production environment, you should configure the share folder on non-system drive.

3. Right-click "Sources", select "Properties".
4. Select "Sharing" tab then click "Advanced Sharing".



5. On "Advanced Sharing" window, check "Share this folder".
6. Click "Permissions".



7. On "Permissions for Sources" window, remove "Everyone" and then add "Domain Computers".
8. Check "Allow - Read".



9. Click "OK" twice.
10. Select "Security" tab then click "Advanced".



11. On "Advanced Security Settings for Sources" window, click "Disable inheritance".



12. On "Block Inheritance" window, click "Convert inherited permissions into explicit permissions on this object".



13. Click "Remove" to remove "Users" on this permission table.


14. Click "Add".
15. On "Permission Entry for Sources" window, click "Select a principal".



16. Enter "Domain Computers".
17. Make sure the permission "Allow - Read, List folder contents and Read & execute" and "Applies to - This folder, subfolders and files".



18. Click "OK".


We assigned the "Allow - Read" permission for Domain Computers to access the "Sources" folder. Domain Users don't need to access this folder.

19. Click "OK" twice.
20. Insert Windows Server installation DVD and then copy "Install.wim" to "C:\Sources".



Remark: In production environment, you may create other subfolders to store the other Windows Versions like Windows Server 2012.

Configuring an alternate source path Group Policy Object
1. On DC01, log in as Domain Administrator.
2. Launch "Group Policy Management Console".
3. Right-click "Default Domain Policy", select "Edit".



4. Navigate to "Computer Configuration > Administrative Templates > System".
5. On the right pane, double-click "Specify settings for optional component installation and component repair".



6. On "Specify settings for optional component installation and component repair" window, select "Enabled".
7. Next to "Alternate source file path", enter "WIM:\\FS02\Sources\install.wim:4".
8. Check "Never attempt to download payload from Windows Update".



We configured to get the source files from the file share and don't allow servers to get sources from Windows Update.

9. Click "OK".
10. Close "Group Policy Management Console".

Testing
Make sure the server is applied the latest GPO.

1. On SC01, log in as Domain Administrator.
2. Launch "PowerShell".
3. Perform "Install-WindowsFeature WDS -IncludeAllSubFeature -IncludeManagementTools" to install Windows Deployment Services on SC01.



As a result, SC01 get the source files from FS02 to install the roles or features.

Additional: Administrators can perform "Get-WindowsFeature | Where InstallState -eq Removed" to check which role or service is needed an alternate source path for installation.



Reference:
Install or Uninstall Roles, Role Services, or Features

This posting is provided “AS IS” with no warranties, and confers no rights!