How-To: Active Directory Workstation Logons (Part 2) – Enterprise Management with ADManager Plus

Category

SystemIdentity Services

Content Type

Vendors

Products

Versions

ADM-v8043

Related Technologies

Active Directory (AD)PowerShell Task Scheduler

AI Preview

Is this content worth your time? Use the quick preview to decide.

Welcome to the second part of our Active Directory Workstation Logons series.

In Part 1, we built the policy-based local sign-in mechanism and the workstation-side synchronization process. In this video, we take that design into a more centralized management model with ManageEngine ADManager Plus.

We cover single and bulk computer changes, on-demand policy synchronization, delegated technician access, reporting and auditing, and an offboarding workflow that removes a departing user’s workstation logon assignments while preserving unrelated entries. The goal is to show how the same custom solution can be managed more practically as the environment grows.

🔗 Helpful Links

There are no helpful links in this one.

Video Tutorial

Used Commands

Trigger workstation policy sync

<#
.SYNOPSIS
Triggers the Techaptic Workstation Access policy synchronization task on a remote Windows computer.

.DESCRIPTION
Queries the existing scheduled task before starting it, triggers a new remote run,
waits for the new run to finish, and validates the scheduled task Last Result.

The command is designed for Techaptic/ADManager Plus orchestration and preserves a
single final success message on the output stream. Errors are raised with throw so
the orchestration layer can detect a failed run.

.NOTES
Author : Techaptic
Scope : Remote workstation policy synchronization.
Task : Techaptic Workstation Access - Policy Sync
#>

param(
[Parameter(Mandatory = $true)]
[string]$ComputerName
)

# Variables
$TaskName = 'Techaptic Workstation Access - Policy Sync'

# Helper Functions
function Get-RemoteTaskInfo {
$raw = & "$env:SystemRootSystem32schtasks.exe" /Query /S $ComputerName /TN $TaskName /V /FO CSV 2>&1
if ($LASTEXITCODE -ne 0) {
throw "Could not query '$TaskName' on '$ComputerName': $($raw -join ' ')"
}

return ($raw | ConvertFrom-Csv | Select-Object -First 1)
}

# 1. Read the Current Task State
$before = Get-RemoteTaskInfo
$beforeLastRun = [string]$before.'Last Run Time'

# 2. Trigger the Remote Policy Sync
$runOutput = & "$env:SystemRootSystem32schtasks.exe" /Run /S $ComputerName /TN $TaskName 2>&1
if ($LASTEXITCODE -ne 0) {
throw "Run request failed on '$ComputerName': $($runOutput -join ' ')"
}

# 3. Wait for a New Completed Run
$deadline = (Get-Date).AddSeconds(30)
$after = $null

do {
Start-Sleep -Seconds 1
$after = Get-RemoteTaskInfo
$newRunDetected = ([string]$after.'Last Run Time' -ne $beforeLastRun)

if ($newRunDetected -and [string]$after.Status -ne 'Running') {
break
}
}
while ((Get-Date) -lt $deadline)

if (-not $newRunDetected) {
throw "The remote run request was accepted, but '$TaskName' did not record a new run on '$ComputerName'."
}

# 4. Validate the Scheduled Task Result
$lastResult = [string]$after.'Last Result'
if ($lastResult -notin @('0', '0x0', '0X0')) {
throw "'$TaskName' ran on '$ComputerName' but finished with Last Result '$lastResult'."
}

# 5. Return the Final Orchestration Result
Write-Output "SUCCESS: '$TaskName' completed on '$ComputerName'. Last Run Time=$($after.'Last Run Time'); Last Result=$lastResult"
exit 0

Offboarded user access cleanup

<#
.SYNOPSIS
Removes an offboarded user's Active Directory DN from Techaptic workstation access assignments.

.DESCRIPTION
Receives the user's sAMAccountName from ADManager Plus, resolves the user's exact
Active Directory distinguished name, finds computer objects whose
techapticLogonPrincipals attribute contains that DN, and removes only that matching
DN. Other users and groups on the attribute remain untouched.

The script writes an operational log under ProgramData and returns a single final
SUCCESS or FAILED message for the orchestration layer.

.NOTES
Author : Techaptic
Scope : Workstation access offboarding cleanup.
Argument : %ad.sAMAccountName%
Log : %ProgramData%TechapticLogsWorkstation-Offboarding-Cleanup.log
#>

$ErrorActionPreference = 'Stop'

# Variables
$UserName = if ($args.Count -ge 1) { [string]$args[0] } else { '' }
$UserName = $UserName.Trim().Trim('"').Trim("'")

$LogDir = Join-Path $env:ProgramData 'TechapticLogs'
$LogFile = Join-Path $LogDir 'Workstation-Offboarding-Cleanup.log'

New-Item -Path $LogDir -ItemType Directory -Force | Out-Null

# Helper Functions
function Write-TechapticLog {
param([string]$Message)
"$(Get-Date -Format s) $Message" | Add-Content -Path $LogFile
}

function Escape-LdapFilterValue {
param([Parameter(Mandatory = $true)][string]$Value)

$Value = $Value -replace '\', '5c'
$Value = $Value -replace '*', '2a'
$Value = $Value -replace '(', '28'
$Value = $Value -replace ')', '29'
$Value = $Value -replace ([char]0), '0'
return $Value
}

function Get-FirstPropertyValue {
param(
[Parameter(Mandatory = $true)]$Result,
[Parameter(Mandatory = $true)][string]$PropertyName
)

if (
$null -eq $Result.Properties[$PropertyName] -or
$Result.Properties[$PropertyName].Count -eq 0
) {
return $null
}

return [string]$Result.Properties[$PropertyName][0]
}

# Disposable DirectoryServices Objects
$computerResults = $null
$computerSearcher = $null
$userSearcher = $null
$directoryRoot = $null
$rootDse = $null

try {
# 1. Validate the ADManager Plus Argument
if ([string]::IsNullOrWhiteSpace($UserName)) {
throw 'No user name was supplied by ADManager Plus.'
}

# 2. Connect to the Active Directory Naming Context
Add-Type -AssemblyName System.DirectoryServices

$rootDse = New-Object System.DirectoryServices.DirectoryEntry('LDAP://RootDSE')
$defaultNamingContext = [string]$rootDse.Properties['defaultNamingContext'].Value

if ([string]::IsNullOrWhiteSpace($defaultNamingContext)) {
throw 'Could not determine the Active Directory default naming context.'
}

$directoryRoot = New-Object System.DirectoryServices.DirectoryEntry(
"LDAP://$defaultNamingContext"
)

# 3. Resolve the User's Exact Distinguished Name
$escapedUserName = Escape-LdapFilterValue -Value $UserName

$userSearcher = New-Object System.DirectoryServices.DirectorySearcher(
$directoryRoot
)

$userSearcher.Filter = (
"(&(objectCategory=person)(objectClass=user)" +
"(sAMAccountName=$escapedUserName))"
)

[void]$userSearcher.PropertiesToLoad.Add('distinguishedName')

$userResult = $userSearcher.FindOne()

if ($null -eq $userResult) {
throw "User '$UserName' was not found."
}

$userDn = Get-FirstPropertyValue `
-Result $userResult `
-PropertyName 'distinguishedname'

if ([string]::IsNullOrWhiteSpace($userDn)) {
throw "The distinguishedName of user '$UserName' could not be read."
}

# 4. Find Computers That Contain the User DN
$escapedUserDn = Escape-LdapFilterValue -Value $userDn

$computerSearcher = New-Object System.DirectoryServices.DirectorySearcher(
$directoryRoot
)

$computerSearcher.Filter = (
"(&(objectCategory=computer)" +
"(techapticLogonPrincipals=$escapedUserDn))"
)

[void]$computerSearcher.PropertiesToLoad.Add('name')

$computerResults = $computerSearcher.FindAll()
$affectedCount = 0

# 5. Remove Only the Matching DN from Each Computer
foreach ($result in $computerResults) {
$computer = $result.GetDirectoryEntry()

try {
$computer.RefreshCache(@(
'name',
'techapticLogonPrincipals'
))

$computerName = [string]$computer.Properties['name'].Value

$currentPrincipals = @(
$computer.Properties['techapticLogonPrincipals'] |
ForEach-Object { [string]$_ }
)

$updatedPrincipals = @(
$currentPrincipals |
Where-Object {
-not [string]::Equals(
$_,
$userDn,
[System.StringComparison]::OrdinalIgnoreCase
)
}
)

$principalProperty = $computer.Properties[
'techapticLogonPrincipals'
]

$principalProperty.Clear()

foreach ($principal in $updatedPrincipals) {
[void]$principalProperty.Add($principal)
}

$computer.CommitChanges()
$affectedCount++

Write-TechapticLog (
"SUCCESS Computer=[$computerName] RemovedUser=[$UserName] RemovedDN=[$userDn]"
)
}
finally {
$computer.Dispose()
}
}

# 6. Record and Return the Final Success Result
Write-TechapticLog (
"COMPLETE User=[$UserName] ComputersAffected=[$affectedCount]"
)

Write-Output (
"SUCCESS Removed '$UserName' from workstation principals on $affectedCount computer(s)."
)

exit 0
}
catch {
$message = $_.Exception.Message

Write-TechapticLog (
"FAILED User=[$UserName] Error=[$message]"
)

Write-Output "FAILED Workstation access cleanup: $message"
exit 1
}
finally {
# 7. Dispose DirectoryServices Objects
foreach ($item in @(
$computerResults,
$computerSearcher,
$userSearcher,
$directoryRoot,
$rootDse
)) {
if ($null -ne $item -and $item -is [System.IDisposable]) {
$item.Dispose()
}
}
}

Full Transcript

Click to see...

Why Enterprise Workstation Logon Management Matters

Hello everyone and welcome to Techaptic channel. Today we are going to look at how we can manage local sign-in on client computers in our Active Directory environment at an enterprise level. If you remember in the first of this series we went through the whole setup step by step. We had an admin console that managed the two custom attributes we created. One was Techaptic Logon Policy Enabledd which turns the policy on or off for a computer. The other was Techaptic Logon Principals which stores the information about who can sign in locally to that computer. We also said that this console alone wasn’t enough to manage the whole process. That’s why we had a scheduled task created on the computers by a startup script and set to run at certain times. When the computer could reach Active Directory, the task connected to the Domain Controller and read the attribute values, wrote the latest values to the local cache file, and updated the Allow log on locally setting. If the computer couldn’t reach Active Directory, it used the last values stored in the cache file instead. directory, it used the last values stored in the cache file instead. For a small environment, managing this from a single console can be more than enough. But in medium or large environments, a few limitations start to show up. First of all, configuring the policy on every computer one by one can take a lot of time. Once you have hundreds or thousands of computers, you naturally need a way to make these changes in bulk. You also need a way to find missing or incorrect settings after a rollout and fix them. The more computers you have, the more likely human errors become. So after the configuration is done, it is important to have a second or even a third way to check that everything was applied correctly. Some environments may also want only certain people to make these changes. In other words, specific technicians should be able to manage this without being able to change other Active Directory settings. That also makes auditing and tracking who changed what much more important. Finally, medium or large environments usually need automation as well, both to reduce human error and to help technicians use their time more efficiently. In this video, we are going to look at how ManageEngine ADManager Plus can help with these needs. In general, the product acts as a layer between technicians and Active Directory, and gives us tools for reporting, management, automation, and integrations.

ADManager Plus Preparation and Single-Computer Management

So let’s jump into the ADManager Plus interface and see how we configured it for this scenario. First, let’s quickly go over the basic settings we prepared. Under Directory and Application Settings, we configured an account that ADManager Plus can use for both reporting and management. Under the Administrative tab, we added the custom attributes we had already created in Active Directory and defined the syntax each one uses. We also configured them so they can be used in computer reports and computer modification tasks. With that out of the way, we can move on to the Management side. The Management tab is where we can make these kinds of changes. Under Computer Management, we can select Modify Single Computer, choose the computer we want, and update its settings. In this example, we will choose VID-CLIENT01. This section normally uses the system template, but for this video, we created a much more focused template that only shows the fields we actually need. So, for example, if we want to enable the policy on this computer, we can set Techaptic Logon Policy Enabled to True and update the computer. If we also want to define who can sign in to this computer, we need to enter the distinguished name values in the Techaptic Logon Principals attribute. We can get these values from the built-in reports under the Reports section, or from the Workstation Logon Access custom report we created earlier. In this example, I am going to copy the DN for Lab User 01. Once we do that, users other than the accounts we have defined and members of the local administrators group won’t be able to sign in to this computer. So what did we need for this to

On-Demand Policy Synchronization

take effect? Either the computer had to restart while it could communicate with Active Directory or the scheduled task would check AD every 30 minutes and pull down the latest values. With ADManager Plus, we added a third option using a script: on-demand synchronization. The automation section gives us some pretty flexible tools for this kind of work. Here you can see the automation we created for this. Let’s click edit and take a look at the settings. Our action here is a PowerShell script. To run it, we copied the PS1 file into the scripts folder under the product installation directory. and configured it to receive the DNS Hostname attribute, which is the computer’s FQDN, as a parameter. The script then connects to the target computers and triggers the scheduled task that was created earlier by the startup script. For this to work, the ADManager Plus Windows service needs to run under an account with the required permissions. Also, for this automation specifically, the RPC access required by Remote Scheduled Tasks Management has to be allowed through the firewall. Now let’s go back to the main automation page and click run now. It tells us the operation has been triggered. To check the status, let’s click OK and then click the icon next to it. Here we can see the previous runs for this automation. The latest ones are shown at the top and each one is stored with a request ID. Let’s open the most recent one. As you can see, there is quite a bit of information here. The script ran against three computer objects and all three completed successfully. In the message section, we can also see details such as the scheduled task being triggered and its last run status from our customized script. By the way, you can download these scripts from our website as well. Let’s connect to the computer and check whether the settings are active. We gave Lab User 01 access to this computer, so let’s try signing in with a different account. As you can see, we cannot sign in with this account.

Delegating Access to Technicians

Now let’s say we only want certain technicians to handle this management task and we don’t want them changing other Active Directory settings. ADManager Plus gives us flexible role-based delegation for this. Under delegation, we can add technicians and create roles. For this example, we created a role called Manage Logon Assignment. Let’s open it and check the details. This role includes access to the custom reports and the permissions needed to modify the computer objects. Let’s also look at its scope under the Technician section. As you can see, the LabSport01 technician only has access to the respective organizational unit, along with the specific templates and role we assigned. Now let’s sign in as that technician and see what the interface looks like. Because we are using the trial version of this product, we get a warning here. We will click continue. Because I restricted the role quite a bit there are basically only two tabs available and the report section is where the technician will do most of the work. So when we open it, we can see the users under the selected OU and their DN values, as well as the computers. If we click one of the computer records, we can see that the technician can only work with the custom attributes we allowed. So far so good, but there is another situation we need to think about. For individual inventory changes, a technician can handle these updates manually. But what if we want to roll this out across all of our computers? Maybe we have an inventory system, or maybe we keep this information in an Excel file. In that case we already know which computer is assigned to which users and we can also manage the additional support access through Active Directory groups. With hundreds or thousands of computers we obviously don’t want to do all of this one by one.

Bulk Workstation Updates with CSV

Under the Management section, ADManager Plus has bulk modification options for different object types. Since our policy is stored on computer objects, we can go to Computer Management and select Modify Bulk Computers. Here we can use a CSV file in the correct format to update the settings in bulk. Let’s look at an example. I already prepared the CSV file. I will select it from the Import section. Let’s click Browse, select the CSV file, and click OK. Before we save anything, we can see a list of the changes that are about to be applied. We are going to assign Lab User 1, Lab User 2, and Lab User 3 to their own computers, and we are also going to allow the Workstation Support group to sign in to all three computers. Let’s select all and click Update in AD. I’m only going to change the two custom attributes here, so I will clear the checkbox for the Name attribute and click OK. It says the operation completed successfully, so let’s test one of the computers. We will again use the automation so the computers pull down the latest settings. Then let’s try signing in to VID-CLIENT02 with an account other than Lab User 02. Lab User 01 isn’t a member of this support group, so we can use that account for this test. And as you can see, because the computer has received the updated policy, we cannot sign in with this account. Now we have seen how ADManager Plus can handle

Extending the Design to Employee Lifecycle Automation

this when a user’s assigned device or inventory changes. But what about onboarding a new employee or offboarding someone who is leaving the company? These events may not happen constantly, and the screens we just used could still handle them. But in real environments, the work we do for a user or a computer usually isn’t limited to just this one setting. For example, when a new employee starts, we create the account, add the user to the required groups, create a mailbox, and usually perform several other configuration steps as well. This is why it can be useful to include local sign-in management as part of the same automation process. For this video, we prepared a small example focused only on offboarding. But the same approach can also be adopted for onboarding by choosing the actions that make sense for your environment. Before we run the offboarding process, let’s take a quick look at the current policy state on the computers. We will open the Workstation Logon Access report again for this example. Let’s generate the report again to fetch the latest data. On the Computers tab, we can see the settings that we imported from the CSV file. Now let’s go to the Automation section and open the template under Orchestration Templates.

Building the Offboarding Orchestration

Let’s click Edit to take a look at it in detail. This type of template lets us run a series of actions in order and trigger that workflow from a specific management action. As you can see on the left, there are many different actions we can choose from, customize and then run in sequence as part of the workflow. The first step in our example workflow is a script. When a user leaves the company, this script searches the Techaptic Logon Principals attribute on Active Directory computer objects for that user’s DN and removes the DN wherever it finds it. This prevents old user entries from being left behind unnecessarily in the list of accounts that can sign in locally. At the same time, we don’t want to affect any other users or groups that were added for a reason, so the script leaves those entries alone. We are also running this script first because the user’s DN will change when we move the account to another OU. That’s why we do the cleanup before the move. In the sequence, the second step uses Remove Users from All Groups. This removes any access that was granted through those groups. The user’s default primary group, Domain Users, is kept while the other group memberships are removed. That’s worth keeping in mind. In the third step, we assign a random password to the user’s account. This means the former employee’s old password is no longer left in place, and a random password is set in place. From a security point of view, that’s the better option for this example. But if needed, you could also configure a fixed password instead. And in the final step, we move the former employee’s account to the Users OU under Former Employees. This keeps Active Directory employee accounts separate from accounts that belong to people who have left the company and helps keep the AD structure clean. Now we need to connect this workflow to a management action that can trigger it.

Event-Driven Automation and HR Integration

Let’s go back to the automation and this time open the Event-Driven Automation section. We created an automation called Workstation User Offboarding. Let’s click Edit and review the settings. Events here can be created for user or group objects. Since our workflow is about a user account, we select the user object. We then configure the automation to trigger when the user account is modified and narrow the condition so it only runs when the user account is disabled. So, when we disable a user through ADManager Plus, the Workstation User Offboarding orchestration template will be triggered and the actions inside it will run automatically in sequence. I think this is a realistic trigger for the workflow. Because when an employee leaves, one of the first things we usually do is disable the account. So, here we trigger the process manually and let the system handle the remaining steps. Of course, in many environments, onboarding, offboarding, and other employee lifecycle actions start in HR and are then passed on to IT. If the HR team uses an application for this, ADManager Plus can integrate with that application, check its records at regular intervals, and automatically apply the required actions in Active Directory when something changes. At that point, most of the IT team’s work can move toward reporting and auditing. We will cover this kind of integration and automation in a separate video later on.

Running and Verifying the Offboarding Workflow

We have gone through the configuration. Now let’s check whether the workflow actually works. For this task, we will use Lab User 03, who currently has local sign-in access on the third computer. Let’s look at the Active Directory first. The account is under the Techaptic Logon Access OU and it is currently enabled. If we check the group memberships, we can see Domain Users along with the VPN and File Server Access groups. We also saw earlier in the reports that local sign-in access was assigned to this account on VID-CLIENT03. Now let’s go back to ADManager Plus and disable the account so we can see what happens. Under Management, go to the User Management and then go to Enable/Disable Users. And let’s choose Disable and find the respective account. Click Search. Click the checkbox and click Apply. It says the account was successfully modified, and one event-driven automation matched and the event was successfully triggered. Let’s go to the audit report under delegation and first look at the results in the interface. The newest entry is shown on the top, so we will read the sequence from the bottom up. It says one event-driven automation matched and the event was successfully triggered. Then our script was triggered and the Lab User 03 account was successfully removed from the Techaptic Logon Principals attribute. Also, the account was removed from its group memberships. The password was changed and finally the account was moved from the OU we specified. Now let’s switch to the Domain Controller and verify these changes one by one. The user account was under Techaptic Logon Access. So let’s refresh the page. The account is no longer here and it has probably been moved to the Users OU under Former Employees. Let’s refresh this page as well. As you can see, our account is here and its status is disabled. Let’s check the group membership. As expected, only Domain Users remains and the other memberships have been removed. Finally, let’s check VID-CLIENT03, computer account where we had assigned accesses. The policy is still enabled but user account has been removed from the list and other entries are still there.

Summary and Extending the Model

In summary, you can use this same design in your own environment to manage and audit local sign-in more effectively and you can extend it with automation as needed. In this short video series, we focused only on local sign-in management but you can adapt the same approach for other user rights as well such as Log on as a service, Access this computer from the network, or Log on through Remote Desktop Services, along with the matching deny rights. And that brings us to the end of another video. See you in the next one. Take care.

Leave a comment on