Windows 2000 Active Directory was released to manufacturing 18 years ago on December 15, 1999. It now has to register for the draft. Happy Birthday Active Directory!
You would think in that 18 years and the broad acceptance of Windows that every single software vendor and every application developer everywhere in the world would have been able to have figured out how to work with Active Directory. Sadly this is not true. Nearly every single week (sometimes day) I encounter applications from developers and vendors that write code to interact with AD but have absolutely no clue how to properly find domain controllers or properly use them once they find them. This results in a lot of applications that are far worse than they need to be if the developer/vendors would only spend a little time figuring out some basic items and properly coding to use the system. This isn’t just in house developers and small vendors, this includes very large vendors and sometimes even Microsoft itself. No… Just because Microsoft made Active Directory doesn’t mean that every group inside of Microsoft knows how to properly use it. I have helped many companies over the years with issues with how they use Active Directory, by far the company I have most helped is Microsoft themselves.
A big part of the issue are end user companies buying the products that allow vendors and developers to continue to write software that doesn’t work properly. Especially when a vendor labels something as Active Directory compatible or Active Directory integrated and yet the application is barely LDAP enabled and customers don’t look at them and say “This isn’t good enough.”[1]
I think every large company that writes code that works with Active Directory, especially if they are selling the products to other companies, should be hiring one or a few people who are very good with Active Directory, who understand it, understand the underlying components, how to use it, etc. The quality of AD integration that I have seen out of a variety of products could increase orders of magnitude if they did that. I was recently looking at a product from a random major well known Storage company and some folks in the company I work for by day were trying to get it to work with AD and were telling me “It has to be in an OU called XYZ and that OU has to be at the root of the domain and we have to be Domain Admins to do the work to join it”. Eventually we figured out that none of that was true but the documentation and defaults were so bad the folks doing the work (including the consultants from the vendor) all thought that was the case and could only get it to work by eating up a bunch of time on one of the smallest most critical support teams in the company. If random major well known Storage company wants to do stuff with AD they are big enough to hire some AD people that can help do what they want to with AD correctly. The defaults and the documentation should all be simple least privilege basic “how do you want us to fit into your structure” and not, “We don’t want to spend the time documenting and writing this so it is done the best way, just do what we want and we will allow you to continue to pay outrageous amounts of money for our products.”
So what are the low bars for an application to be properly Active Directory Integrated?
Finding Domain Controllers
Does your application have you configure a connection to Active Directory by specifying one or more domain controllers? I.E. Hard coding? While this is a nice option for an application to have to assist with troubleshooting, it should NOT be the primary and default method of configuration. This configuration setting is a very low bar for a vendor/developer to reach if they want to say they are Active Directory compatible/integrated. This also comes up in conversations when someone is asking for a load balancer or VIP (Virtual IP) to point at for AD/LDAP operations. If someone says they want or need a load balancer for accessing Active Directory for good redundancy that is a blood red screaming sign of improper AD compatibility / integration.
Generally speaking[2] there is no good valid reason for hard coding to specific domain controllers. It actually makes an application more likely to break and doesn’t leverage the built-in redundancy that is innate to the Active Directory design.
Admin and/or Operator and/or Local System Security Context
Does your application require you to be Domain Admin, or Administrator or be a member of one of the Operator groups or does it require to run as “local system” on a domain controller? Why? If you don’t know why, you better figure it out. Most likely it is due to lazy or uninformed developers/vendors. Any company that has a clue about AD Security isn’t just going to give someone any of that access just so they can add a device or run an application. If they are willing to do it or alternately willing to run some random application on your behalf then you need to start questioning the security and stability of your corporate Active Directory.
I want to call out Microsoft particularly over this one as they have historically completely and utterly sucked in this space. If you follow the MSFT documentation strictly for all of their products you will end up with a ton of people with no need to be Domain Admins with that level of access. This may be fine in a shop with 20 servers and 500 clients but when you have thousands of servers and hundreds of thousands of clients it makes no sense. If Microsoft did it correctly they would determine the actual minimal amount of permissions necessary to do anything for the various functions of their tools/programs and document that and then say but if you want… you can just use domain administrator. Microsoft has in very great part caused the “too many people have too much access in too many environments problem” that so many companies are regularly getting busted for in security audits (for good reason).
Applications and application support people should be able to function properly with AD Delegation; that is why there is AD Delegation. This is yet another very low bar to meet. No requirement to be in any specific group, especially Domain Admins or anything else that is built into the core OS. Applications should know exactly what access rights they need so when you need to deploy them you know exactly what needs to be granted so the application runs properly. If a developer/vendor cannot quickly and immediately tell you exactly what granular rights and delegation are needed you need to read that as a big blood red warning sign. Look for another product.
Application Must Run on a Domain Controller
Does your application have to run on a Domain Controller? Why? If you don’t know why, you better figure it out. Most likely it is due to lazy or uninformed developers/vendors. Sound familiar? I say that a lot because it happens a lot. Too often I see vendor products out there that they are charging thousands or even millions of dollars for that don’t even reach the quality bar that my free stuff hits. As a general rule Domain Controllers should be Domain Controllers, period. Don’t put other applications on DCs, they don’t belong there. Domain Controllers are or at least should be some of your most secure boxes on your network. That means the attack surface should be made as small as is absolutely possible. This means no additional software running on them. Every additional piece of code and every single port opened that an additional application is listening on is another piece of code and port that could have a potential vulnerability that someone could compromise. Again, even Microsoft is bad at this and saying this or that service should be run on domain controllers. When you see it just say no, tell them to fix it. I have done this many many times and if enough people say it strongly enough they correct the problem.
A quick side bar point here is also that there should be as few domains and domain controllers as possible to support your service. Every domain, every domain controller adds to the attack surface and offers an opportunity to make a mistake and or miss something that allows someone else to hurt you. There really needs to be very high bar amazing reasons to have multiple domains and especially multiple forests.
GC Knowledge
Does your application understand the concept and proper use of Global Catalogs? If not, the application is not AD Integrated. If the application understands and used Global Catalogs it will be specifically called out, you won’t have to plug in a Global Catalog server and port in the LDAP URL and hope it works.
Bind IDs
Does your application only allow full DNs for the bind ID instead of allowing the other allowed formats such as (not an inclusive list) the legacy Windows ID format (domain\user) or User Principal Name (user@domain.com)? If so, it is not AD integrated.
More to come on these topics.
joe
[1] Or for the less PC folks… “What the *&^$%* is this $#*#*?”
[2] There can be some possible reasons for hard coding in the case of applications that synchronize data to/from Active Directory.
