Active directory is not the silver bullet for IAM best practices

Microsoft’s Active Directory (AD), the most dominant directory service for handling logins and other administrative functions on Windows networks has been a godsend for many IT administrators looking for a one-stop-shop to handle the Identity Access Management (IAM) functions within their organizations. And while AD works great for the core critical function of issuing the basic access to systems, it is often insufficient when it comes to truly securing the entire spectrum of user access including privileged access and edge cases such as contractors and vendors. This is why entire niche industries such as Identity Governance Administration (IGA), Privileged Access Management (PAM), and Vendor Privileged Access Management (VPAM) have sprung up to fill these holes. Here are some places where AD may not be the total solution for IAM and some suggestions on fixes, both free and paid: 

Not enough control over network access

AD is often used as de facto control over network access. And while AD can do this for most Windows hosts (assuming local administrators are disabled), it ends up not being a great control at all over raw network access. Many administrators look at it this way; if you can’t log onto the Windows workstation in front of you, you can't get on the network. This ignores the fact that the network plug is almost always unprotected from other machines, ones not joined to the domain. If you plug in, you are generally handed an IP address from the Windows DHCP server and can explore the network at will. Even if the DHCP server is locked down to only provide addresses to authenticated hosts, it is child’s play to sniff the traffic on the network and deduce the valid ranges to assign manually. Mobile access adds additional complexity unless you are using Mobile Device Management (MDM). First of all, you should definitely secure your DHCP servers so they are not handing out IPs willy nilly. Also, there are additional protections you can layer on, locking down ports via your network switches and routers, as well as flagging new port connections via IDS systems. 

Better control over administrator logins

This is an area where Microsoft has not kept up with evolving threats. They still have the generically named “administrator” account which every hacker in the world knows to focus brute force attacks on. And to make it worse, you can't set a lockout on this vital account. The reason, ostensibly, is to keep such attacks or even a fat-fingered admin from locking the whole system out, but it also means hackers can work away on it if it is exposed on any external RDP interface, which it usually is. Countermeasures are changing the name from “administrator” and not using the admin account for any functions except for “break glass in case of emergency” situations. Or, ideally using a credential vault or Privileged Access Management (PAM) which stores all such logins where they have to be checked out and logs all use, so it can be audited.

Lack of auditing features

Speaking of audit, another thing that AD lacks is audit capability in any serious way. Of course, you can set which events it logs and you can set it quite granularly. And you can view it through the Event Viewer function, but even at a relatively non-granular logging setting, AD will generate so many events per day, even per hour as to make this interface pretty unusable. You can export the file and do some sorting on event IDs to find things like excessive login failures but even that method falls down at any kind of scale. And that's assuming you have a Ph.D. in Windows ID numbers and know what to look for. Many companies end up adding additional systems or hiring outside companies to do this for them as it is a full-time job to monitor Windows AD events. There are many tools such as Splunk and even cloud-based solutions that bring scale to large logging outputs and other platforms that will specifically audit and separate your third-party vendors from your internal employees.

Special cases, such as vendors

Though these types of users are often a small percentage of the overall managed user base but can represent your largest risk. Studies show that over a third of all breaches come via a third party such as a vendor. The biggest issue with giving them logins from your internal Active Directory is that AD doesn't treat them any differently. There are no additional controls you can apply via AD to monitor them more closely by default. The other issue is that using AD to manage internal vendor users can quickly get out of hand if you have dozens or even hundreds of vendor users. When that happens, you either end up with a tangled mess in your directory structure or worse, end up issuing a single ID to be shared across their organization which is not only a huge breach risk but directly violates several major regulation frameworks. Finally, unlike internal users, you often don’t even know when that person has left the vendor company, until (and if) the vendor decides to notify you. What you really want when dealing with these specialty users is a system to act as a single source of truth for all their activity, so you can audit them separately and provide you with additional layers of controls such as MFA and credential vaulting. SecureLink Enterprise Access is an example of such a system. Active Directory is a great tool to use as the cornerstone of your IAM infrastructure. However, every building needs walls and a roof to make a full structure and you should do the same with your IAM controls; layering on multiple strategies for a strong defense in depth. Doing so will make sure there are no cracks in your IAM security.