SAN MATEO (02/18/2000) - Novell Inc. this week pointed out a flaw in the way Microsoft Windows 2000's Active Directory (AD) handles security permissions for some objects. Microsoft quickly denied this bug existed, saying Novell had improperly configured its AD setup. I tested this in the InfoWorld Test Center and found that the bug exists, but only because Novell missed a security step.
On a freshly installed Windows 2000 Advanced Server machine, I set up AD using the defaults, and added an OU (Organizational Unit) named Payroll, and a user named Joe who is the payroll department's IT administrator.
To secure the Payroll OU so that Joe was the only administrator who could view and modify its objects, I followed the instructions on page 304 of the Windows 2000 Server Deployment Planning Guide for creating an OU to hide objects.
Logged in as Administrator, I went into the Active Directory Users and Computers utility. I right-clicked on my domain (infoworldtestcenter.com) and chose View and then Advanced Features. This allowed me to see the security tab in each object's properties box.
I opened the Security tab on the Payroll properties sheet and added Joe to the list. I gave him full control over the OU. Next, I unchecked the "Allow inheritable permissions from parent" box, removing security rights that would normally flow down from higher in the directory structure.
By removing the permissions of all users and groups except Joe, the Payroll OU should be secure from alterations by any other administrators in the domain.
Any objects put into Payroll will be hidden.
Because the Administrator has no rights to that object, the Payroll OU is now shown without an icon, and the type is listed as unknown. When I viewed the Payroll Security tab, the message "Unable to display security information" was shown. This is how things should be; the Administrator cannot view or modify the Payroll OU.
Now for the bug. Still logged on as Administrator, I pulled up the Users properties box. As a domain administrator, I was able to view the OU Security tab. I clicked OK and reopened the Payroll OU's properties. When I clicked to the Security tab, I could see (and modify) all security settings. Even though my user (Administrator) had no permissions for this object, I could add users and groups, remove Joe from the permissions list, and even turn inheritable permissions back on.
According to Novell, this is the major problem. However, it missed an important step. Joe needs to log in and take ownership of the Payroll OU from the Administrator. Once he has done this, the Administrator can no longer see and modify security information without first taking back OU ownership.
Taking ownership of an object will show up in a security audit. So, although the Administrator can override Joe's ownership, it cannot be done without raising a red flag. Microsoft should revise its deployment guide to include this step.
If an organization does not transfer OU ownership, this bug's impact could be big. Using proper procedures for securing objects will ensure audit trails for IT staffs' changes.
Kevin Railsback is the associate technical director at the InfoWorld Test Center.