This article presents a guide to Active Directory for IT Asset Managers – what it is, what it’s used for, and how you can use it to improve ITAM data quality and reduce audit risk.
Active Directory (AD) is the “address book” for virtually all corporate IT networks. It contains user accounts, computer accounts, corporate hierarchies, policies, and groups. It is both the reference library for information about a particular computer network or group of networks and also the primary tool for their management.
Pretty much everything to do with managing IT! At the most basic level it stores a record of a user’s membership of a Windows domain. Username, email address, password, group membership, last logon date, first logon date, last password change date and much more. It does the same for each computer that’s joined to the domain. It contains policy settings for managing those computers and users, and it contains groups used for everything from email distribution lists to controlling access to applications. It’s the golden record of truth about your IT estate. Well, at least, that’s the theory – but as anyone who has looked at the contents of an Active Directory will find it’s often out of date and poorly maintained. More on that later.
Usually, AD is maintained by IT Operations – most often your Windows Server or Network teams. These Domain Administrators hold the “keys to the kingdom” and tend to protect them vigorously. It’s very easy to do widespread damage if you don’t know what you’re doing when it comes to managing AD and so such “admin” roles are highly restricted. I’ve seen first-hand the damage caused by a misconfiguration in AD, which resulted in two weeks of widespread disruption to the business I was working for. Following the NotPetya attack in 2018 Maersk dispatched an engineer to a branch office in Ghana which contained the sole surviving pre-attack copy of their entire AD – and therefore the blueprint for their entire IT estate. Without that copy they would have been unable to recover anything of their pre-attack IT infrastructure.
Usually, it won’t contain non-Windows computers, servers, and users. Management of these entities – often Apple Mac and *nix devices (Linux, Unix etc.) – is limited, as is information about them. It also is unlikely to contain information regarding cloud services unless it has been integrated with your cloud provider.
Active Directory is a Discovery and Inventory source for ITAM. If you don’t have a dedicated ITAM tool it is likely to be the definitive source of truth for the estate you’re trying to manage.
An out-of-date Active Directory is a source of financial, data, and license audit risk.
Typically, during a license audit, auditors will ask for user and computer counts from your Active Directory. They may also ask for evidence of group membership, particularly for well-established audit risk scenarios such as VDI, Citrix, and non-production use. If your AD is not well maintained, it’s likely that users that have left and computers that are no longer in use are still listed. Whilst you can argue that AD isn’t a true reflection of consumption of licenses it can still be used as evidence in an audit. For example, it may provide evidence of unlicensed use that’s been remediated prior to the audit.
Financial risk arises from AD often being used to control access to applications. If groups aren’t kept up to date you are effectively assigning a license to a user who no longer requires it. This is particularly the case when groups are used to manage access to VDI, Citrix, or non-production environments.
Failure to maintain AD groups and user accounts also presents a data risk. If you don’t remove users when they leave or remove access to data they no longer require because they’ve moved departments or changed roles, then you’re at risk of breaching data processing and privacy laws.
There are also positives to IT Asset Managers paying attention to Active Directory. The biggest is that it enables you to reconcile and verify data gathered by your ITAM tools. For example, if your ITAM tool discovers 4500 active devices but AD reports 5000 with active logins you know you’ve got an agent deployment or other discovery problem. This also applies to user accounts.
Furthermore, if group membership is accurate it becomes possible to track and secure access to non-production environments, or VDI & Citrix environments. This is incredibly useful for proving under audit conditions that only authorised dev/test users have accessed those environments.
As noted above, Active Directory is often poorly maintained. Old accounts aren’t deleted, groups aren’t tidied up, and computer accounts aren’t removed when they’re no longer needed. Your AD admins are often too busy with day-to-day tasks to give a “spring clean” of AD the attention and effort that is needed. In my experience they need to be pushed to do clean-ups, with regulatory requirements such as Privileged Access Reviews for SOX being a catalyst. Because AD is so powerful, and the consequences of doing something wrong so catastrophic, there is also a reluctance to carry out widespread changes. Domain Controllers, the beating heart of AD, are labelled with virtual and sometimes actual “Do Not Touch!!” labels.
Before we go any further it’s important to note that ITAM teams are not the Data Owner for Active Directory. The quality and availability of that data is the responsibility of the owners of AD. You are not on the hook for it, but you are a stakeholder and that does mean we have the opportunity to help and encourage the owners of AD to clean up their directory. How do we do that? A good starting point is to use free tools to estimate the scale of any problems.
At its heart, AD is an LDAP directory. LDAP (Lightweight Directory Access Protocol) is an open IETF Standard that’s been widely adopted for maintaining and providing access to directory information. The beauty of this is that data stored in AD is easily accessible via a variety of tools and can also be integrated easily with other applications. Many ITAM tools provide the option for importing AD information as a source of discovery and inventory information.
If you want to dig deeper you can do so and, importantly, you don’t need any special credentials or access privileges. The entire directory is open and readable to anyone with a user account. Readable means readable – meaning that unless you’re for some reason a user with elevated privileges – all you can do is read and report on data, you can’t modify anything. This is important and should immediately head off any concerns your AD domain admins may have about giving you access. With a read-only account you simply can’t do any damage.
Our recommended tool for querying AD directories and domains is Softerra LDAP Browser (free) although there are many others available.
The first step is to find your Domain Controller. This is the computer that logged you on when you entered your username and password on your Windows machine. To do this;
Once you have the logon server hostname (e.g. DC01.acmecorp.com) you can configure your LDAP browser tool to connect to it.
That’s it – your profile is configured and now you can browse the directory structure using the folder tree on the left-hand side of the screen. AD is highly configurable but out of the box you should find Users, Computers, and Groups hierarchies – these are the ones you’ll query most as an ITAM manager.
For a beginners guide to using Softerra LDAP Browser to query directory information see https://www.ldapadministrator.com/resources/english/help/la20201/index.php
You are primarily concerned with Users, Computers, and Groups. By querying these objects you can find out:
For our purposes the AD attribute LastLogonDate is sufficient to determine this. The primary use of this attribute is to identify stale accounts – if a user hasn’t logged on for 90 days, are they still an active user? Have they left the company? Or perhaps they’re furloughed or on parental leave? We can certainly use this to identify users who can potentially be removed, which in turn will free up licenses and subscriptions. It’s worthwhile running this check at least monthly, and certainly in the run up to any renewals using a user-based metric.
This provides the same information for computers rather than users. Useful for identifying which computers may be dormant or off the network. If you have an ITAM tool you can use this report to identify licenses that can be harvested and reassigned. For HAM processes this date is useful for pinpointing whether a device has been consigned to a cupboard or someone’s desk drawer.
This is dependent on how your Windows team have configured Active Directory. Best practice is to use groups in AD to control access to network resources, servers, and applications. If your Windows team are doing this you can identify users listed as having access to a particular application and compare that with their last login time to see if a license can be reassigned or harvested. Similarly, you can check which users are accessing non-production environments, and potentially exclude software installations from compliance calculations, if the license agreement has different rules for non-production usage.
When I was exploring the usefulness of AD for ITAM I homed in on two things – finding the last logon/used date of Users and Computers and identifying potential discovery blind spots of my ITAM tool’s agents. I found the quickest way to generate reports was to use other free utilities – the two I used most frequently were AD Info from CJWDev and the command-line utility OldCmp from JoeWare.
These are both powerful reporting utilities. Of the two, AD Info is the easiest to use with a graphical interface, but OldCmp is very fast and ideal for getting data to use in other reports – for example importing into a spreadsheet. Both are freeware utilities from the “old school” – no warranty, no support, use with discretion – but remember, as long as your user account only has read-only access to AD you can’t do any damage.
To wrap up this article I’m going to share the two commands you can use in OldCmp to generate a complete dump of user and computer info from an AD domain in a CSV file, which can then be used for further analysis in Excel:
First, download OldCmp from JoeWare and place it in an easily accessible directory (e.g. C:\oldcmp)
Open a command prompt and enter the following commands according to whether you want to get a users or computers report.
Users: oldcmp -report -users -format csv -age 0
Computers: oldcmp -report -format csv -age 0
This is particularly useful for identifying computers/users which are active but not yet discovered by your ITAM tool.
For the above commands, if you wish to only retrieve a list of users/computers that haven’t been used for 90 days just drop the “-age 0” from the end of the command.
There’s a comprehensive list of commands in OldCmp available here – useful things like identifying disabled users and computers and so on.
The reason I used OldCmp for reporting is that it generates two additional report fields from AD:
pwage – how old in days the password is (i.e. when was it last changed)
lltsage – Last Login Timestamp Age – how long ago the last successful logon for that user or computer was.
This parsing of otherwise complex AD fields (pwdLastSet & LastLogonTimestamp) means you can easily build, for example, Excel pivot tables showing which users and accounts are potentially stale and should be inactivated/disabled/deleted.
PowerShell is Microsoft’s comprehensive utility for managing a Windows estate. It’s incredibly powerful, quite often you need to have special permissions to run it, and as such I’ve considered it to be out of scope for this article. My view is that the above utilities are safer for a non-administrator to go digging around in AD data.
Active Directory is a valuable source of information for your ITAM team. You can use it reduce costs and manage risks. By running your own reports, you can get a sense of the scale of completeness of your ITAM tool, and also how tidy your AD is. You can use this information to shine a light on the blind spots your ITAM tool isn’t seeing, and to engage with your AD administrators on improving the quality of data in AD. A closing note on this: your AD admins are busy, anything you can do to help them will be appreciated, but make sure you approach them in the right way. As with any stakeholder engagement the right way is dependent on your organisational culture. Get it right and you’ll cut costs, reduce risks, and have built a strong relationship with a key stakeholder. Remember, though, that they are the Data Owner for AD and ultimately it’s their responsibility to ensure that their data is accurate and complete.