Windows Security: Part 3
Active Directory (AD) is a set of Lightweight Directory Access Protocol (LDAP)-based directory services designed primarily to enable Windows users, applications and processes to be able to locate services and objects. Ever since AD was first introduced when Windows 2000 was released, Microsoft has highly touted its virtues almost incessantly. After all, not only does AD solve the problem of finding something in today’s too often gargantuan network environments, but it serves as a kind of backbone for security in Windows products, both servers and clients alike. AD offers Group Policy Objects (GPOs) that enables system and security administrators to choose security settings (e.g., password minimum length, Event Log settings, and much more), which if embodied within Domain GPOs apply across an entire Windows domain. AD also does much more—so much that I could write a 20-page blog posting that might possibly bore you to death, so I won’t.
Microsoft was correct in claiming that AD is a big step up from the way Windows security used to work (e.g., in Windows NT). At the same time, however, AD is no panacea from a security prospective because AD is so complex. Consider, for example, the way Group Policy works. AD consists of many hundreds of objects, each of which generally has multiple attributes or properties. Each of these objects and object attributes has permissions and ownerships. If any one of these is inappropriate (e.g., Authenticated Users are able to change an object or property), the potential for subversion of a critical AD function or possibly AD itself skyrockets. Fortunately, default installations of AD-capable versions of Windows operating systems have had good permissions and ownerships, but accidental mistakes in changing them to bad settings from a security perspective are a real possibility.
Another complication that AD causes is Group Policy confusion. GPOs can be linked at any of four levels: Organizational Units (OUs), Domains, Sites and Local. If there are different GPOs linked to different levels, rules determine which has precedence, i.e., which particular GPO will prevail. If different GPOs are linked to OUs, Domains, Sites and the local computer and if a Site-linked policy has the No Override setting enabled, then that Policy will prevail. On the other hand, if there is no Site-linked GPO but there is a Domain-linked GPO, that policy will prevail if it has the No Override setting enabled. When GPOs are linked to OUs as well as child and grandchild OUs, the policy linked to the GPO that is lowest in the OU hierarchy will prevail unless a policy linked to a higher-level OU has the No Override setting enabled. And within any of the four GPO levels, a Domain Administrator and Enterprise Administrator can select from multiple GPOs (if they exist) to determine which will have precedence. The craziness of all these rules has resulted in many an error or oversight that has resulted in negative consequences such as system administrators thinking that certain security settings were in place when they were in fact not. The confusion and frustration surrounding GPOs motivated Microsoft to develop and include several free tools such as the Resultant Set of Policy (RSOP) Tool that allows administrators to query for information from WXP, WS2003/8, Vista and Windows 7 systems to find what policies have been applied and the order in which the policies have been applied. Although these tools have helped many administrators, they constitute an extra “thing” that administrators have to learn how to use and run. Making GPO precedence rules much more straightforward would have been much better.
Finally, migrating users, groups and policies to a new domain is anything but easy. Reacting to the pain within its customer community, Microsoft again developed and distributed free tools such as the Active Direction Migration Tool (ADMT) to facilitate doing this task, but despite Microsoft’s good intentions, these tools go only so far in solving the problem. Commercial tools that do a better job are available, but why should someone have to buy and pay maintenance fees for a function that Unix and Linux administrators can do easily without any additional tool?
Please do not get me wrong—I like AD. The alternative, using Windows workgroups, is frightening. But AD still has a long way to go before it becomes what system and security administrators really need. Microsoft—I hope you are listening.