Posts

LAPS

Microsoft LAPS deployment and configuration guide

If you haven’t come across the term “LAPS” before, you might wonder what it is. The acronym stands for the “Local Administrator Password Solution.” The idea behind LAPS is that it allows for a piece of software to generate a password for the local administrator and then store that password in plain text in an Active Directory (AD) attribute.

Storing passwords in plain text may sound counter to all good security practices, but because LAPS using Active Directory permissions, those passwords can only be seen by users that have been given the rights to see them or those in a group with rights to see them.

The main use case here shows that you can freely give out the local admin password to someone who is travelling and might have problems logging in using cached account credentials. You can then have LAPS request a new password the next time they want to talk to an on-site AD over a VPN.

The tool is also useful for applications that have an auto login capability. The recently released Windows Admin Center is a great example of this:

LAPS

To set up LAPS, there are a few things you will need to do to get it working properly.

  1. Download the LAPS MSI file
  2. Schema change
  3. Install the LAPS Group Policy files
  4. Assign permissions to groups
  5. Install the LAPS DLL

Download LAPS

LAPS comes as an MSI file, which you’ll need to download and install onto a client machine, you can download it from Microsoft.

Schema change

LAPS needs to add two attributes to Active Directory, the administrator password and the expiration time. Changing the schema requires the LAPS PowerShell component to be installed. When done, launch PowerShell and run the commands:

Import-module AdmPwd.PS

Update-AdmPwdADSchema

You need to run these commands while logged in to the network as a schema admin.

Install the LAPS group policy files

The group policy needs to be installed onto your AD servers. The *.admx file goes into the “windows\policydefintions” folder and the *.adml file goes into “\windows\policydefinitions\[language]”

LAPS 02

Once installed, you should see a LAPS section in GPMC under Computer configuration -> Policies -> Administrative Templates -> LAPS

LAPS 03

The four options are as follows:

Password settings — This lets you set the complexity of the password and how often it is required to be changed.

Name of administrator account to manage — This is only required if you rename the administrator to something else. If you do not rename the local administrator, then leave it as “not configured.”

Do not allow password expiration time longer than required by policy — On some occasions (e.g. if the machine is remote), the device may not be on the network when the password expiration time is up. In those cases, LAPS will wait to change the password. If you set this to FALSE, then the password will be changed regardless of it can talk to AD or not.

Enable local password management — Turns on the group policy (GPO) and allows the computer to push the password into Active Directory.

The only option that needs to be altered from “not configured” is the “Enable local admin password management,” which enables the LAPS policy. Without this setting, you can deploy a LAPS GPO to a client machine and it will not work.

Assign permissions to groups

Now that the schema has been extended, the LAPS group policy needs to be configured and permissions need to be allocated. The way I do this is to setup an organizational until (OU), where computers will get the LAPS policy and a read-only group and a read/write group.

Because LAPS is a push process, (i.e. because the LAPS client on the computer is the one to set the password and push it to AD) the computer’s SELF object in AD needs to have permission to write to AD.

The PowerShell command to allow this to happen is:

Set-AdmPwdComputerSelfPermission -OrgUnit <name of the OU to delegate permissions>

To allow helpdesk admins to read LAPS set passwords, we need to allow a group to have that permission. I always setup a “LAPS Password Readers” group in AD, as it makes future administration easier. I do that with this line of PowerShell:

Set-AdmPwdReadPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

The last group I set up is a “LAPS Admins” group. This group can tell LAPS to reset a password the next time that computer connects to AD. This is also set by PowerShell and the command to set it is:

Set-AdmPwdResetPasswordPermission -OrgUnit <name of the OU to delegate permissions> -AllowedPrincipals <users or groups>

LAPS 04

Once the necessary permissions have been set up, you can move computers into the LAPS enabled OU and install the LAPS DLL onto those machines.

LAPS DLL

Now that the OU and permissions have been set up, the admpwd.dll file needs to be installed onto all the machines in the OU that have the LAPS GPO assigned to it. There are two ways of doing this. First, you can simply select the admpwd dll extension from the LAPS MSI file.

LAPS 05

 

Or, you can copy the DLL (admpwd.dll) to a location on the path, such as “%windir%\system32”, and then issue a regsvr32.exe AdmPwd.dll command. This process can also be included into a GPO start-up script or a golden image for future deployments.

Now that the DLL has been installed on the client, a gpupdate /force should allow the locally installed DLL to do its job and push the password into AD for future retrieval.

Retrieving passwords is straight forward. If the user in question has at least the LAPS read permission, they can use the LAPS GUI to retrieve the password.

The LAPS GUI can be installed by running the setup process and ensuring that “Fat Client UI” is selected. Once installed, it can be run just by launching the “LAPS UI.” Once launched, just enter the name of the computer you want the local admin password for and, if the permissions are set up correctly, you will see the password displayed.

LAPS 06

If you do not, check that that the GPO is being applied and that the permissions are set for the OU where the user account is configured.

Troubleshooting

Like anything, LAPS can cause a few quirks. The two most common quirks I see include when staff with permissions cannot view passwords and client machines do not update the password as required.

The first thing to check is that the admpwd.dll file is installed and registered. Then, check that the GPO is applying to the server that you’re trying to change the local admin password on with the command gpresult /r. I always like to give applications like LAPS their own GPO to make this sort of troubleshooting much easier.

Next, check that the GPO is actually turned on. One of the oddities of LAPS is that it is perfectly possible to set everything in the GPO and assign the GPO to an OU, but it will not do anything unless the “Enable Local password management” option is enabled.

If there are still problems, double check that the permissions that have been assigned. LAPS won’t error out, but the LAPS GUI will just show a blank for the password, which could mean that either the password has not been set or that the permissions have not been set correctly.

You can double check permissions using the extended attribute section of windows permissions. You can access this by launching Active Directory users and computers -> Browse to the computer object -> Properties -> Security -> Advanced

LAPS 07

Double click on the security principal:

LAPS 08

Scroll down and check that both Read ms-Mcs-AdmPwd and Write ms-Mcs-admpwd are ticked.

In summary, LAPS works very well and it is a great tool for deployment to servers, especially laptops and the like. It can be a little tricky to get working, but it is certainly worth the time investment.

Active Directory

Three Active Directory Automation Scripting Tips Using PowerShell

Active Directory is one of the most common products I see being automated. After all, it’s the perfect candidate. How many times do new users have to be created, group memberships changed, or new computers added? Employees are coming and going all the time, and the actions to perform these tasks are the same—every time.

Microsoft® has an Active Directory (AD) PowerShell module that allows anyone to manage AD objects and write scripts to tie various tasks together. However, with PowerShell expertise, we can create scripts that go past just finding users and groups. We can automate any task you can think of in AD.

Find All Effective Members of a Group

AD has a great feature that allows you to add groups to other groups. This cuts down on the number of repeated group assignments you have to make, and makes AD much cleaner. However, when navigating to a group in the AD Graphical User Interface (GUI), you can only see the members in that immediate group. You may see others, but you’ll have to look at the members of those groups over and over again.

It can become a pain when you want to see all of the affected user accounts, but we can solve that using a PowerShell code and a recursive function.

To find members of a group with PowerShell, use the Get-AdGroupMember cmdlet. This command returns all members in just that group. However, a property on each of those members is an AD attribute indicating if it’s a user, a group, etc. That way, we know what kind of object it is. Knowing this, we can build code to look at each of those members, check to see if they’re a group, and if so, run Get-AdGroupMember again. If not, we return the member.

We need to use a recursive function—a function that calls itself, forcing it to find user accounts nested deep inside of various groups. By using a recursive function like this, a user can be nested ten groups deep, and we’ll still find it.

An example of how this can be done is below. This function can be called via Get-NestedGroupMember -Group MyGroup.

function Get-NestedGroupMember {
[CmdletBinding()]
param (
[Parameter(Mandatory)]
[string]$Group
)

## Find all members in the group specified
$members = Get-ADGroupMember -Identity $Group
foreach ($member in $members) {
## If any member in that group is another group just call this function again
if ($member.objectClass -eq 'group') {
Get-NestedGroupMember -Group $member.Name
} else { ## otherwise, just output the non-group object (probably a user account)
$member.Name
}
}
}
Easily Find Inactive Group Policy Objects

The next tip is finding inactive Group Policy Objects (GPOs). Especially in large organizations, GPOs can get out of hand and run wild unless controlled. Sometimes there ends up being dozens of GPOs created that aren’t doing anything at all. Rather than picking these out one at a time via the GUI, we can build a simple script to find them all in one shot.

There are two ways to define an inactive GPO. This GPO could have all of its settings disabled, or it could not be linked to an organizational unit. We can create a script to find both of these types. First, we’ll pull all of the GPOs in the environment:

$allGpos = Get-Gpo -All

Once we have them all, we can then filter those GPOs by the ones that have all settings disabled:

$disabledGpos = $allGpos | Where-Object { $_.GpoStatus -eq 'AllSettingsDisabled' }
foreach ($oGpo in $disabledGpos) {
[pscustomobject]@{
Name = $oGpo.DisplayName
Status = 'Disabled'
}
}

Next, we can find all GPOs that aren’t linked to an organizational unit. This is a little trickier, but nothing we can’t handle using the code below:

## Create an empty array
$unlinkedGpos = @()
foreach ($oGpo in $allGpos) {
## Gather up all settings in the GPO
[xml]$oGpoReport = Get-GPOReport -Guid $oGpo.ID -ReportType xml;
## Only return the GPOs that don't have a LinksTo property meaning they aren't linked to an OU
if ('LinksTo' -notin $oGpoReport.GPO.PSObject.Properties.Name) {
[pscustomobject]@{
Name = $oGpo.DisplayName
Status = 'Unlinked'
}
}
}

This script will return a list of GPOs that look like this:

Name Status
---- ------
GPO1 Unlinked
GPO2 Disabled
GPO3 Disabled
Find How Long Ago a User Reset Their Password

For my last tip, let’s figure out how long ago a user’s password was set. More specifically, let’s write a small script that will allow us to find only those users that have had their password set within a configurable amount of days.

This small script uses the Get-AdUser command and filters the users returned using the Where-Object command. In this example, we’re looking at the passwordlastset attribute for each user that is greater than 30 days ago.

$daysOld = 30
$today = Get-Date
Get-AdUser -Filter { enabled -eq $true } -Properties passwordlastset | Where-Object 
{ $_.passwordlastset -gt $today.AddDays(-$daysOld) }
Summary

We’ve just skimmed the surface on what’s possible when automating with PowerShell and Active Directory. By leveraging Microsoft’s Active Directory module and stringing together commands with PowerShell, we’re able to come up with some interesting scripts.

 

Employee Onboarding

Automating Employee Onboarding in Active Directory

Employee onboarding is a task that is ripe for automation. Spend any time in the tech industry and you know that Active Directory (AD) helps improve workflow and operational services. In other words, it’s critical to an IT organization. When hired, every employee should be given an Active Directory user account, an email mailbox, access to various operating systems, a home folder with specific permissions available only to them, and so on.

However, AD is a big part of employee onboarding that many organizations are still doing manually. In many companies, the helpdesk is still manually opening Active Directory Users & Computers, creating a new user, and adding that user to a specific set of groups. This ultimately increases the risk of messing up that person’s other responsibilities within their account. Again, this is something automation can alleviate! And this is where Kennected comes in. Because staff onboarding is one of those tasks that’s performed hundreds of times and rarely changes, it’s a perfect candidate for automation even used for dbs check.

So, how do you go about automating onboarding in AD?

One of the easiest ways to automate AD tasks is with PowerShell – an automating management structure. By using a freely available PowerShell module, you can create scripts to do just about anything with AD.

For our purposes, we need to create a script to make a new user account for an employee and potentially add it to a few common groups. To do this, download a copy of Remote Server Administration Tools (RSAT) which will give you the Active Directory PowerShell module. Once you do this, ensure you’re on a company domain-joined computer and that you have the appropriate rights to create new users.

In the Active Directory PowerShell module, there is a command called “New-AdUser.” There are lots of ways to use this command but below is one of the most common ways. In this PowerShell code, we’ll generate a random password and then use it along with a first name, last name and username to create a new AD user.

Here’s an example of what this code looks like:


$password = [System.Web.Security.Membership]::GeneratePassword((Get-Random -Minimum 20 -Maximum 32), 3)

$secPw = ConvertTo-SecureString -String $password -AsPlainText -Force

$NewUserParameters = @{

GivenName = 'Adam'

Surname = 'Bertram'

Name = 'abertram'

Name = 'abertram'

}

New-AdUser @NewUserParameters

That’s it! No mouse clicking involved.

Once the above actions have been completed, we can move on to another useful AD onboarding command called “Add-AdGroupMember.” This will add the user that was just created to a few groups in a single line:

Add-AdGroupMember -Identity 'Accounting','Access to App1' -Members 'abertram'

One of the great things about automating employee onboarding with PowerShell is that once the code is built, it can be used for one – or even one hundred – employees with no extra effort.
For example, perhaps you have a ton of new employees you need provision for in AD. By using the “Import-CSV” command, you can read each row in that CSV file and run the code we just went over.

This example assumes you have a CSV with the columns “FirstName” and “LastName.”

Here it is exemplified below:


Import-Csv -Path C:\Employees.csv | foreach {

$password = [System.Web.Security.Membership]::GeneratePassword((Get-Random -Minimum 20 -Maximum 32), 3)

$secPw = ConvertTo-SecureString -String $password -AsPlainText -Force

$userName = '{0}{1}' -f $_.FirstName.Substring(0,1),$_.LastName

$NewUserParameters = @{

GivenName = $_.FirstName

Surname = $_.LastName

Name = $userName

AccountPassword = $secPw

}

New-AdUser @NewUserParameters

Add-AdGroupMember -Identity 'Accounting','Access to App1' -Members $userName

}

These are only a few of the many user onboarding tools available when you automate employee onboarding in Active Directory. If your organization has a predefined process with specific rules that must be followed, this could be just the beginning of a much larger employee onboarding process that can be 100% automated.

 

This article was provided by our service partner Connectwise.