The Sysadmins

Tips and tricks from the Sysadmins

Deploying Microsoft LAPS – Part 2

We recently covered preparing Active Directory and deploying the LAPS CSE/Client to the machines you wish to manage in part 1 of deploying Microsoft LAPS. Part 2 covers “Turning on” LAPS via Group Policy, the LAPS process and how it works once deployed.

Group Policy

On your LAPS management machine head to C:\Windows\PolicyDefinitions, there you will find AdmPwd.admx and AdmPwd.adml (under en-US). Copy these files into your Group Policy Central Store, if you do not have a Central Store (and do not which to create one) you can launch Group Policy Management Console directly from your management machine, or copy the ADMX/ADML to a Domain Controller where you will be editing the policy.

LAPS2-1

Create a new GPO and navigate to Computer configuration -> Policies -> Administrative Templates -> LAPS

LAPS2-2

Password Settings
This is where you’ll choose your password policy. The default is complex passwords, 14 chars and a password age of 30 days (machines will automatically change their password when this is met).

LAPSGPO-1


Name of administrator account to manage
In part 1 we deployed a custom local administrator account of LocalAdmin, this is the account I wish to manage. Leave this to not configured to manage the default Administrator account (-500).

LAPSGPO-2

Enable local admin password management
Enable this setting to turn LAPS on.

LAPSGPO-3

Do not allow password expiration time longer than required by policy
When you enable this setting, planned password expiration longer than password age dictated by “Password Settings” policy is NOT allowed. When such expiration is detected, password is changed immediately and password expiration is set according to policy.

LAPSGPO-4

Link the GPO to the OU with the computer objects you wish to manage with LAPS (and that you have deployed the LAPS client to).

The LAPS process

  1. Machine with LAPS CSE queries Group Policy and receives the LAPS policy settings defined above
  2. Machine queries ms-Mcs-AdmPwdExpirationTime, if not set, or expired it will generate a new password and set this locally and securely write this value to the mc-Mcs-AdmPwd attribute in Active Directory
  3. Password is now set locally, stored in Active Directory and is ready for use
  4. The LAPS CSE will query this value on each Group Policy update, when the ms-Mcs-AdmPwdExpirationTime is met, or the attribute is not set it will re-generate a new password
  5. If machine cannot contact Active Directory, no changes are made

Using LAPS

If you’ve followed all of the steps so far, the solution will now be fully deployed. There are various ways you can view the password set by LAPS. The most obvious choice, and probably what most people will default to using is the LAPS UI which is installed as part of the LAPS management tools.

1. LAPS UI – Simply run the UI, type the computer name and click search.

LAPS2-3

Note the Reset button. This allows you to manually manage when the password is re-generated for a given machine. If you want to expire the password immediately, click reset with the current date and time set. The next time the computer performs a gpupdate, it will check the ms-Mcs-AdmPwdExpirationTime attribute which will force it to re-generate a password (as it will have expired). You can also set it to a specific date and time if required.

2. Powershell – Get-AdmPwdPassword cmdlet

Import-Module AdmPwd.PS
Get-AdmPwdPassword Client01

LAPS2-4

3. Active Directory Users and Computer (DSA.MSC) – Make sure you have advanced features ticked from the view tab.

LAPS2-5

Note the expiry time is in NT system time, to convert to a readable format, use w32tm /ntte %ms-Mcs-AdmPwdExpirationTime%.

LAPS2-6

If you’re looking at a Local Administrator Password solution, currently using GPPs to deploy Local Administrator accounts or simply want to increase the security of your machines LAPS is absolutely something you should look to implement. I hope you’ve found these posts helpful, and good luck!

Microsoft Local Administrator Password Solution (LAPS) – Part 1

Deploying Microsoft LAPS – Part 1

What is LAPS?

A lot of organisations will use the same local administrator password across all machines, which is a bad idea for a number of reasons. At a basic level, if this password is learnt, it allows anyone to install software as an administrator – at a higher level it facilitates things such as pass the hash, mimikatz and general reconnaissance against your machines (usually with the goal of elevating to Domain Admin).

If you currently deploy your Local Administrator Account via Group Policy Preferences, this makes things even easier for an attacker to obtain the shared local administrator password. The CPASSWORD value is easily searchable against SYSVOL and Microsoft provide the 32-byte AES key which can be used to decrypt the CPASSWORD. Alan has a great post here why you should stop using Group Policy Preferences for deploying Local Administrators.

So what can we do?

LAPS – Local Administrator Password Solution! This is Microsoft’s solution to managing Local Administrator account passwords across an organisation. LAPS solution features include:

• Sets a unique randomly generated password PER machine
• Automatically change the Local Administrator Password every x days
• Stores Local Administrator Passwords as an attribute of the Computer Object in Active Directory
• Password is protected in AD by AD ACL, so granular security model can be easily implemented
• Password is protected during the transport via Kerberos encryption

Deployment Steps

  1. Installs LAPS onto management machine
  2. Extend Schema and prepare Active Directory
  3. Deploying LAPS client to those machines you wish to manage
  4. Configure Group Policy to enable and set the relevant policies

This post will cover steps 1, 2 and 3.

Management Machine

First off, we’re going to install the management portion of LAPS. Download LAPS here and next, next through the installation. On the custom setting page choose all of the management tools. The AdmPwd GPO Extension is required if the machine you’re installing the management portion on will also be managed by LAPS.

LAPS-1

Follow ‘Preparing Active Directory’ on the management machine.

Preparing Active Directory

1. Extending the Active Directory Schema

The Active Directory Schema needs to be extended to add two attributes to the computer class. These are ms-MCS-AdmPwd which stores the password in clear text, and ms-Mcs-AdmPwdExpirationTime which stores the password expiration time. You will need to be a member of the Schema Admins security group.

Import-module AdmPwd
Update-AdmPwdADSchema

LAPS-2

2. Adding Machine Rights

You need to delegate to right to allow the computer object to write to the ms-MCS-AdmPwd and ms-Mcs-AdmPwdExpirationTime attributes.

Set-AdmPwdComputerSelfPermission -OrgUnit "OU=SA Computers,DC=thesysadmins,DC=co,DC=uk”

This sets the following permissions against all computer objects within the OU specified, including all child objects.

LAPS-4

This is what the Set-AdmPwdComputerSelfPermission cmdlet does behind the scenes on the computer objects ACL:

LAPS-Self1

LAPS-Self2

3. Check ExtendedRights permissions on OU

To get information on the groups and users able to read the password (ms-MCS-AdmPwd) for a specific Organizational Unit (OU), run the following.

Find-AdmPwdExtendedRights -identity:"OU=SA Computers,DC=thesysadmins,DC=co,DC=uk" | Format-Table ExtendedRightHolders

LAPS-5

4. Remove ExtendedRights permission on OU

If you need to remove the permission to view the password (ms-MCS-AdmPwd) for a group or user, carry out the following.

  1. Open ADSIEdit
  2. Right Click on the OU that contains the computer accounts that you are installing this solution on and select Properties
  3. Click the Security tab
  4. Click Advanced
  5. Select the Group(s) or User(s) that you don’t want to be able to read the password and then click Edit
  6. Uncheck All extended rights

LAPS-10-2

5. Delegate a Security group the rights to view and reset LAPS

Here I’m delegating the Security Group ‘LAPS’ the right to view the LAPS Password and to have the ability to reset the password (more on that in part 2). I’ve re-run the ExtendedRights cmdlet, and you can now see that the LAPS group has been added.

Set-AdmPwdReadPasswordPermission -OrgUnit "OU=SA Computers,DC=thesysadmins,DC=co,DC=uk " -AllowedPrincipals "LAPS" 
Set-AdmPwdResetPasswordPermission -OrgUnit " OU=SA Computers,DC=thesysadmins,DC=co,DC=uk " -AllowedPrincipals "LAPS"

LAPS-6

This is what the Set-AdmPwdReadPasswordPermission and Set-AdmPwdResetPasswordPermission cmdlets are doing behind the scenes on the computer objects ACL:

LAPS-6.1

LAPS-6.2

Active Directory is now prepared!

Deploying LAPS

Continue reading

Deploying XenClient Enterprise Engine with SCCM

This post will explain how to automate the deployment of XenClient Enterprise Engine 5.5.5 using SCCM 2012 R2. There is very little information on how to achieve this, so hopefully this will help those looking for a solution. Thanks goes to a post made by Greg Roll early last year on the Citrix discussion forums which pointed me in the right direction. There were a few bits missing and lacking detail, which I will cover.

Preparing the files

Download the XenClient Windows Installer (xce-engine-setup-5.0.exe under additional software) and run it on a disposable Virtual Machine. When prompted, select the latest Engine ISO and continue

XenClient_SCCM_1

Select Resize Windows

XenClient_SCCM_2

Leave these options unticked

XenClient_SCCM_3

Next to start the installation and select no when prompted to reboot

XenClient_SCCM_4

There will be installation files dropped on the C drive – move these to your SCCM file share or the location you use for SCCM applications/packages

XenClient_SCCM_5

You will then need to move a few files around.

  1. Create a new folder called Engine and move the nxtop folder into it. Then move the nxtldr and nxtldr.mbr files from winboot to the root of the Engine folder. Rename them to grldr and grldr.mbr
  2. Download Grubinst and move grubinst.exe into the Engine folder
  3. Download psshutdown.exe and move psshutdown.exe into the Engine folder

You should end up with this:

XenClient_SCCM_6

Client.ini

You can achieve a fair amount of automation using the Client.ini file found in the boot folder. The following focuses on performing an auto installation into the XenClient Engine, ready for registration. The two variables you will want to pay specific attention to are assettag and name. In the example below I have used @baseboard-asset-tag@ which will pull the asset tag from the BIOS (tested with Dell laptops). Be aware that you cannot change the name of the owned computer once deployed and would need to redeploy the Engine to rename.

Example Client.ini
# Minimum parameters to perform an auto install are:
# name
# assettag
# encrypt
# keyboard
[GLOBAL]
action=install
assettag=@baseboard-asset-tag@
continue_on_no_space_for_recovery_partition=no
create_engine_recovery_partition=no =
encrypt=yes
kb=gb
Action = wipeinstall
lang=en
name=@baseboard-asset-tag@
require_mac_match=no
shrink_partitions_if_no_disk_space_is_found=yes

Other available DMI keywords:

@bios-vendor@ @bios-version@ @bios-release-date@ @system-manufacturer@ @system-product-name@ @system-version@ @system-serial-number@ @baseboard-manufacturer@ @baseboard-product-name@ @baseboard-version@ @baseboard-serial-number@ @baseboard-asset-tag@ @chassis-manufacturer@ @chassis-version@ @chassis-serial-number@ @chassis-asset-tag@ @processor-manufacturer@ @processor-version@

More information on editing the Client.ini file can be found here.

Continue reading

Unifi Wireless – 1. Installing the Controller

This mini-series will guide you through installing and configuring Ubiquiti’s Unifi Wireless solution using 802.1x, Windows NPS (radius) and Group Policy. This post will cover the installation of the Unifi Controller. The following posts will cover configuring the controller, NPS and deploying Wireless settings via Group Policy to your endpoints. I will add any relevant or helpful links at the bottom of each post.

The setup for this mini-series is as follows:

  • Server 2012 R2 member server hosting the Unifi Controller and Network Policy Server (NPS)
  • Windows 7/8.1/10 Clients
  • Unifi Controller 4.6.6

Unifi Controller Installation

From the Server 2012 R2 member server:

  1. Install the latest Java (8u51). Unifi recommend that if you are using an x64 operating system to install both x86 and x64 version of Java for the Unifi controller service to correctly start
  2. X64 Offline install (8U51): http://javadl.sun.com/webapps/download/AutoDL?BundleId=107944
  3. X86 Offline install (8u51): http://javadl.sun.com/webapps/download/AutoDL?BundleId=107943
  4. Install the latest Unifi Controller (4.6.6): http://dl.ubnt.com/unifi/4.6.6/UniFi-installer.exe.
  5. Accept the defaults, but untick “Start Unifi Controller after installation”

Unifi_1_1

The controller installs into “C:\Users\%username%\Ubiquiti Unifi” by default and there is no way to change this when installing, however moving it isn’t too difficult. Simply Copy the entire folder and move it to the required location e.g. C:\Ubiquiti Unifi.

Now that the installation has been moved, you will want to configure the Unifi Controller to run as a service. If this is not done, the Unifi Controller will need manually starting by a logged in user. When the user logs out, the controller software will close.

From an elevated command prompt run

java –jar "C:\Ubiquiti Unifi\lib\ace.jar” installsvc

Start the service with

net start “Unifi Controller"

Unifi_1_2

To access the controller browse to https://127.0.0.1:8843 to start the UniFi setup wizard.

Unifi_1_3

  • Choose you country and timezone
  • No devices discovered, next
  • Skip Wireless configuration for now
  • Set your username and password, next and finish

The controller has now been installed and initially configured.

Unifi_1_4

You can also uninstall the service for troubleshooting if need using

java –jar “C:\Ubiquiti Unifi\lib\ace.jar” uninstallsvc

Access Point Adoption

Last thing to do as part of the initial setup is to configure adoption for the access points. When you plug an access point in, you want them to automatically point at your Unifi Controller to receive their configuration and updates. This can be achieved a few ways, but layer 3 adoption via DNS is reliable and easy to configure.

Create a “unifi” A record that points to the server that you have installed the controller on. The Unifi AP will need to contact the controller via it’s FQDN.

Unifi_1_5

Links

Buy Unifi @ linitx.com
Buy Unifi @ 4gon.co.uk
Unifi Community Layer 3 Adoption Methods
Unifi Community Run Controller as Service
Unifi Community Java 8 Support Notes

Remote Desktop iOS 8.1.0 – Error 0x03000008

Issue

In a recent update to the iOS Remote Desktop client (8.1.0 and above) you receive the following error when connecting using a Remote Desktop Gateway: Can’t connect to the Remote Desktop Gateway. Contact your network administrator for assistance. (Error code: 0x03000008)

iPhone iPad Error 0x03000008

Confirmed on the Remote Desktop Services blog here.

Fix

1. Review the TerminalServices-Gateway operational event log on the Remote Desktop Gateway server and look for EventID 301 which states: The user “DOMAIN\user”, on client computer “1.2.3.4”, did not meet resource authorization policy requirements and was therefore not authorized to resource “172.17.50.10”. The following error occurred: “23002”.

RDS-IP-5

The resource IP should be one of your RDS servers, note healthy connections to the Gateway should (typically) specify the FQDN of the RDS server it is trying to connect to: The user “Domain\user”, on client computer “1.2.3.4”, met resource authorization policy requirements and was therefore authorized to connect to resource “RDS-NY-2.domain.co.uk“.

2. Open the RD Gateway Manager MMC on your Gateway server, go to Policies, Resource Authorization Policies (RAP) and review the policy you have configured for your company- note the locally stored computer group used.

iPhone iPad Error 0x03000008

3. Choose Manage locally stored computer groups from the right hand side, select the group used in the policy and select properties.

iPhone iPad Error 0x03000008

4. Add the IP for each of the RDS servers in the farm (keep hostname and FQDN if present).

iPhone iPad Error 0x03000008

Once this is complete it should resolve the issue. Review the TerminalServices-Gateway operational event log and you should now see: The user “DOMAIN\user”, on client computer “1.2.3.4”, met resource authorization policy requirements and was therefore authorized to connect to resource “172.17.50.10”.

This issue/bug/feature is still present in the Remote Desktop iOS application version 8.1.5 from 29th October.

Group Policy – GPResult Examples

GPResult is a command-line utility for determining the resultant set of policy for a given user and/or computer. In other words, it shows you what Group Policy Objects have been applied and their settings. This is typically one of the first tools I go to when troubleshooting Group Policy from a client once basic connectivity has been confirmed (e.g. Network/DNS). The tool itself is very simple to use and I will run through some common examples below.

List GPOs Applied with Summary Data

Gpresult /r

/r Displays RSOP summary data

This is pretty useful when you simply want to see what GPOs have applied and in what order. It will also display summary data, such as last time group policy was applied, which Domain Controller it was applied from, the site, security groups and if the slow link threshold has been activated. If you are unsure if a GPO has been applied, this is a quick way of checking.

Here we see that 4 GPOs have applied to the Computer settings portion.

GPresult /r

If you don’t want to view both Computer and Users settings in the output you can request one or the other with the /scope flag.

gpresult /r /scope:user
gpresult /r /scope:computer

The output reads fairly well from within the command prompt, but if you need to export the output you could use either of the following.

Gpresult /r > gpresult.txt Export output to a text file
Gpresult /r |clip Export output to Windows clipboard

I can’t see the Computer Settings?

If UAC is enabled, running GPResult without elevating the command prompt will only show you the user settings. If you want to see both user and computer settings, elevate the command prompt by either tapping the winkey+cmd then ctrl+shift+enter or right click on the command prompt and select run as administrator. If you elevate with an admin account different to the currently logged in user (common if the user does not have administrator rights), then you will receive an error message stating INFO: The user “domain\user” does not have RSOP data. This is because GPResult is using the elevated user’s context. To work around this, specify the standard user that you are troubleshooting.

gpresult /r /user:sa\edward.thomas

GPResult-5

Generate HTML Report

Gpresult /h report.html /f
Gpresult /h report.html /user:sa\edward.thomas /f

/h Saves the report in HTML format
/f Forces GPresult to overwrite the file name specified with /h
/user Specifies the user name for which the RSOP data is to be displayed

To get a more graphical view of what’s going on, you can generate a HTML report. This gives a detailed break down of each setting and the GPO from which it came. This view is particularly nice as you can show all and use ctrl+f to find a particular policy or setting.

GPResult /h html report

Run GPResult on Remote Computer

Gpresult /s server1 /r

/s Specifies the remote system to connect to

This allows you to run GPResult on a remote system, all of the above applies.

GPresult Remote Computer

The following GPOs were not applied because they were filtered out

Filtering Denied Security or Not Applied Empty

You may see this for a few reasons. The first that the policy is empty in which case you’ll see Filtering: Not Applied (Empty), this is fairly self explanatory. The second is Filtering: Denied (Security), which typically boils down to the “Apply Group Policy” permission on the GPO. You may also see Filtering: Denied (Unknown Reason) which is similar to (Security) in that the “Read” permissions has been denied.

To review the last two examples, launch the GPMC (Group Policy Management Console). Find the offending GPO, and select Delegation- from there you may see an additional group or a single user or machine that has been added.

GPO Delegation Permissions

Click on advanced and review the permissions against the object. In this case you can see that the Seven computer object has been denied Apply Group Policy resulting in the Filtering: Denied (Security) message.

Deny Apply Group Policy

If in doubt, select Advanced -> Effective Access and enter the required computer or user object. If you scroll down to around halfway you’ll see the Apply Group Policy permission with either a green tick of a red cross against it. If deny read has been granted every permission will have a red cross next to it.

Effective Access for GPO Permissions

I hope this gives you the basics behind GPResult and some good real world example to aid in your Group Policy troubleshooting.

Get Default Gateway from List of Remote Servers

Problem

Find the default gateway on a list of remote servers.

Solution

Create a textfile with a list of servers you would like to query, use a new line for each server. If you have an OU of servers you would like to query you could use the following to create a text file with all computer accounts within an OU (requires Active Directory Module for Windows PowerShell).

Get-ADComputer -LDAPFilter "(name=*)" -SearchBase "OU=Servers,DC=domain,DC=local" | Select -expand name | Out-File -Encoding utf8 "\\server\share\Servers.txt"

This would create a textfile with every computer account in the “Servers” OU on domain.local.

I tend to put a “dummy” line at the top of the text file as PSEXEC has issues with the first entry.

List of servers to obtain default gateway

Now use PSEXEC to execute the following, don’t forget to run the command prompt as administrator (using an account with the required permissions on the remote servers).

psexec @c:\Serverlist.txt ipconfig /all | findstr "Default Gateway Host" >> c:\Servergateways.txt

PSEXEC Command

…and here’s the final result.

Output text showing host name and default gateway

« Older posts