Active Directory is the defacto standard for computer and user authentication in basically all business environments. At its core, AD is simply a database of objects with properties. Microsoft has been so kind as to give us a plethora of built-in Windows tools to query and modify the database objects. With a little imagination and scripting knowledge, an IT Administrator can unlock AD’s hidden potential without having to purchase expensive 3rd party products.

Some time ago one of my clients with about 300 deployed computers called me in a panic. They had just gotten a virus alert for a computer named “ATLLAPTOP205”. This client needed to know who was logged into that computer. Normally that could be done by simply querying the computer directly, but the user had already powered off the computer and gone home. There was no way to query the computer to see the logged on user. The client said, “Can’t you just look at Active Directory to see who was the last person to logon to the computer?” By default, you cannot do this, but wouldn’t be great if you could! Since then, I’ve implemented the actions in this article for that client, and they have found it extremely useful as they currently do not maintain an inventory of their computers. I find that this is a common practice among rapidly growing companies.

With that in mind, this article will demonstrate one way of inventorying hardware and user information by writing the data to the computer object in AD. This way you can use Active Directory Users and Computers or PowerShell to find basic hardware and user information about a computer quickly. It could easily be extended to servers with some slight modifications. Additionally, the same process could be extended to collect more information from each computer (think members of the local Administrators group). Of course, a product such as SCCM would do all of this out of the box. If your company owns SCCM, you should leverage that instead of using this method. Feel free to contact Lockstep if you require assistance with SCCM or the steps described in this article.

The following hardware/user information will be added to AD computer objects by the end of this article:

• Last user to logon to a computer
• Last time the user logged on to that computer
• Hardware Manufacturer of the computer
• Hardware Model of the computer
• Serial Number of the computer

The basic tasks to be completed:

1. Add new custom computer attributes to the AD Schema
2. Add the PowerShell script that does the heavy lifting to a network share
3. Delegate permissions for computers to write to the new custom attributes
4. Create a GPO to schedule the write back to Active Directory from each computer

I recommend going through this exercise at least once in a lab environment. I used the built-in Hyper-V functionality of Windows 10 Pro and setup a Server 2016 RTM domain on my Surface Pro. This has been tested on Windows 7, 8, and 10 endpoints.

TASK 1 – Add Custom Computer Attributes to the Schema

Before modifying the Active Directory Schema, I recommend reading the articles below. Lockstep takes no responsibility if you incorrectly modify the Schema or if something about your environment causes your organization downtime or lost money due to this post. These tasks are low risk and are not difficult to accomplish, but it is the AD Schema. DO THIS IN A LAB FIRST!

Adding and Modifying Schema Objects
Issues Related to Modifying the Schema

Get the domain root OID using Microsoft’s VBS script

Ensure you are a member of Schema Admins and performing these tasks on a Domain Controller or a computer with RSAT tools installed.

1. Download and run the Microsoft Generate OID VBS script from https://gallery.technet.microsoft.com/scriptcenter/56b78004-40d0-41cf-b95e-6e795b2e8a06
   1. Save it to C:\Temp\OID.vbs
   2. Open the command prompt and run cscript oid.vbs so that you can copy/paste the root OID later
   3. Make note of the domain root OID. You will need it in the next section.

Create the custom computer attributes

First, decide what you will name your attributes. Remember that you can’t change this later, so give it some thought. The biggest tip I have is to prefix the attribute names so that all your custom attributes are in alphabetical order when you look them up in ADUC. I often use a 3-character company code to start my attribute names, but today I will use “Custom-“. The custom attributes we will create and their respective purpose are as follows:

Custom-LastLoggedOnUser – Last logged on user
Custom-LastLoggedOnUserDate – Last time the user logged on
Custom-HardwareVendor – Hardware Manufacturer
Custom-HardwareModel – Hardware Model
SerialNumber – This attribute is built into AD and doesn’t need created. We will use this built-in attribute for populating the serial number of each computer

1. Open Active Directory Schema
2. If you’ve never registered the Schema Management DLL, you will need to run this command from an elevated commnd prompt:
   1. Regsvr32 SchmMgmt.dll
3. WIN+R opens the Run dialogue. Open MMC.exe
4. CTRL+M opens Add or Remove Snap-ins
5. Choose Active Directory Schema and click Add
6. Click OK
7. Create the custom attributes:
   1. In the left pane, right-click Attributes
   2. Click Create Attribute and fill in the appropriate info. Screenshots of the custom attributes are below.

Common Name – Attribute name chosen in previous step
LDAP Display Name – Automatically fills, but I choose to keep it consistent with the common name
Unique X500 Object ID – This is the OID returned earlier appended with “.x.x”. Note the explanation and screenshot below.

• If this is the first custom attribute created in AD, you may be able to add “.1.1” to the end of the OID returned. Otherwise, start incrementing the number until you find one that works. (ie. “1.2”, “1.3”, etc). To gain a better understanding what this means, read the output of the OID.vbs script closely. This is a good time to start some documentation on any custom attributes you create.
• My Root OID (Yours will be different):
  • 1.2.840.113556.1.8000.2554.47914.3102.30763.18637.40847.646773.1410620
• The first X500 Object ID in my lab (Yours will be different):
  • 1.2.840.113556.1.8000.2554.47914.3102.30763.18637.40847.646773.1410620.1.1
• The second X500 Object ID (Yours will be different):
  • 1.2.840.113556.1.8000.2554.47914.3102.30763.18637.40847.646773.1410620.1.2

Description – Brief description of the attribute purpose.
Syntax – Choose Unicode String

New custom attributes

Attach the new attributes to the computer Class

1. In the left pane of the MMC, exand Classes
   1. Open the Properties of the Computer class
   2. Click the Attributes Tab
   3. Click Add
   4. Add each of the attributes just created to the computer class

1. Restart the Active Directory Domain Services service (You may consider doing this during non-business hours as this will cause authentication failures during the service restart.)
   1. After opening Active Directory Users and Computers, you should see that the new attributes now exist on computer objects

TASK 2 – Add the Included PowerShell Script to a Network Share

You will need to download the PowerShell script using the download link at the end of this article. After downloading, place it on a network share that Domain Computers can read. This can be on a standard file server or on a Domain Controller. I like to use the NETLOGON folder because it is shared with the correct permissions by default. Domain Computers needs to have read-only access to this script. On a side note, never give write/modify permissions on any scripts you use in your environment. This includes logon/logoff scripts or scripts used for reporting or installing applications. These become easy lateral movement attack vectors for an attacker that has compromised a single user or computer. One system or user compromise can lead to massive compromise.

1. Create a new folder under \\domain.com\NETLOGON entitled “Computer Info” and put the PowerShell script in this folder. After you download the script as a file, you will need to “Unblock File” first.
   1. If you choose to use the NETLOGON folder, you get some additional benefits.
      1. The script is synchronized to all domain controllers which means that it will not be removed as you decommission servers
      2. If your sites are setup with the correct IP ranges, the domain controller with the least cost will be used when running the script.
2. This is what the path looks like in my lab – \\shoe.local\NETLOGON\computer Info\Set-ComputerCustomAttributes.ps1

TASK 3 – Delegate Permissions in Active Directory

Be default computers on the domain do not have the permission to write to the attributes created in Task 1. We have to delegate the permissions for them to update the attributes on their own computer object only.

1. Open Active Directory Users and Computers
2. Right click on the appropriate OU in your domain hierarchy and click Delegate Control
   1. Click Add to delegate permissions
   2. User = SELF
   3. Next, choose the option Create a custom task to delegate and click Next
   4. Select Computer Objects 
   5. Next, check Property-specific and select Read  and Write for all the created attributes (Don’t forget the SerialNumber attribute):
      
   6. Next, validate the delegations you chose are correct and click Finish

TASK 4 – Create a GPO that Sets the Scheduled Task 

I’m going to assume that you know how to create GPO’s that create/update Scheduled Tasks, so I’m going to focus more on the Scheduled Task info. I recommend you test the GPO/Scheduled Task on a small subset of computers before scoping to all computers. When the GPO is ready for production, be sure to scope it to Domain Computers at the correct OU within the domain hierarchy.

Create your GPO similar to the following one:

Scheduled Task Info

• General Tab

Name: Set-ComputerCustomAttributes
Running As: NT Authority\SYSTEM
Check Run with highest privileges

• Triggers Tab

You can set one or multiple triggers to run the script. For testing and getting the data back into AD as soon as possible, set the following triggers. You may choose to dial it back a bit in production so that the script doesn’t run as often.

Trigger 1 – At log on of any user

Delaying the task for 30 minutes prevents this script from contending for resources with other startup/logon actions on older or slower systems

Trigger 2 – On idle

This trigger will allow the data to populate AD fast. You may choose to remove this trigger after the initial data population.

• Actions Tab:

Action: Start a Program
Program: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe
Arguments: -ExecutionPolicy bypass -file “\\\NETLOGON\Computer Info\Set-ComputerCustomAttributes.ps1”

• Conditions Tab: You may choose to allow this to run while a laptop is on battery power, but that is your call.
• Settings Tab:

These are the settings that I’ve chosen. You can adjust according to your environment as needed.

Allow task to be run on demand – Allows you to run the task from the Task Scheduler of a computer. This makes troubleshooting easier.
Run task as soon as possible after a scheduled start is missed – This is good for catching computers that are turned off every night or taken home with a user.
Stop the task if it runs longer than 1 hour – This script should run in under 30 seconds on most computers.
If the running task does not end when requested, force it to stop – This will force the PowerShell process to stop if the script hangs for some reason.

Test on a computer that is affected by the GPO policy scope

1. Perform a gpupdate /force on the target computer to apply the GPO and create the Scheduled Task
2. Logon to the target computer and run the Scheduled Task manually
3. If you have the $GenerateLog variable set to $true in the script, you will find the following log at C:\ADCustomAttributes.txt of the target computer
4. Look in Active Directory Users and Computers to verify that the custom attributes have been populated

Once you get it working as desired, be sure to remove your account from Schema Admins.

Getting the Data

The Active Directory Users and Computers Attribute Editor is handy for pulling the data for one computer. Using PowerShell allows you to gather the same data for all computers at once. The following command can be piped to Export-Csv to generate a report of hardware and user data for all computers:

Get-ADComputer -Filter * -Properties Custom-LastLoggedOnuser, Custom-LastLoggedonUserDate, Custom-HardwareVendor, Custom-HardwareModel, SerialNumber