Active Directory information exposed to users?

Introduction

Most IT professionals I know deal with:

• Physical access

• Network access through firewalls

• Access to services on servers

• Access to applications

Much work is going into securing the areas mentioned above, but, what about the information stored in Active Directory? When using Windows Server 2008 domain controllers most people feel at ease by the security that is built within this great technology – and they should. However, you need to know that there might be sensitive information which ordinary users can actually access with the use of simple tools. Apart from this, you also need to check if you are allowing even more users to see this information with the backwards compatibility “feature” built into Active Directory since Windows Server 2000.

In this article I will cast some light on what information normal domain users can see in Active Directory and why this is available to users.

The security issue

In Active Directory there is a lot of information that, of course, includes the domain configuration, various account types, published printers and shared files. You could also have software that extends the schema and uses the directory to store configuration data. An example of this kind of software would be business accounting applications or security devices that use the directory as a configuration for the application and domain users. Therefore it is very important that you check what information your domain controllers and global catalog servers make available for the domain users – and perhaps anonymous users also.

A corporate network infrastructure should be as secure as possible. We get the security guys to setup firewalls and encryptions and restrict all access to the network, servers and applications which are reserved for the corporate users. Access is controlled by the user’s logon credentials or other types of authentication controls such as smart cards and biometrics (to make these credentials a little more secure please read the article series written by Derek Melber:  Windows Passwords: Making them secure).

Only authenticated users logged in at their computer should have access to domain resources for their particular job functions. The IT personnel make sure that the users get access to the correct file shares, printers, mailboxes and applications. It is possible that some “bad-guy” corporate user gets information stored in Active Directory that he could use in any way? Have you checked your own Active Directory as a standard domain user account? If you are responsible for domain security you need to know what information it is possible to see by default.

Checking the Directory

If I wanted to check this out, I would log in as a normal user (with the default domain settings) in my test environment. On my computer I would access the Microsoft TechNet SysInternals website and download/run the Active Directory Explorer from this website. In Figure 1 you can see that I would have to provide the program with my domain and credentials:

Figure 1: Active Directory Explorer logon box

Browsing my domain, I could check if anything looks interesting. In Figure 2 you may see some properties which could be interesting for a person looking for restricted information such as the password and audit policies. If you have good password policies, which also include lockout policies, then it is not that big a security issue.

Figure 2: Domain properties read by the normal domain user

If we move a bit down in Active Directory you could find the users. I here take a look at my administrator account in the domain. In Figure 3 you can see some details about this account, including the logon hours, group membership and when the password was changed.

Figure 3: Administrator account properties read by the normal domain user

We could make some cross-reference queries to look for domain administrators that have the “Password never expires” attribute set (a part of the userAccountControl attribute). Active Directory reporting and management software such as Javelina Software’s ADToolkit makes many reports for administrators and is very easy to use.

The directory information that is available is not only about the user and group objects, but also about the complete domain infrastructure as you see it in “Active Directory Sites and Services”.

Multiple security groups actually have read access to some or all properties.

• Authenticated Users

• Pre-Windows 2000 Compatible Access

The Pre-Windows 2000 security group can include other groups which I will discuss later in this article. The change and write permissions are quite well handled in Microsoft Active Directory, so please do not worry about this for now.

The reason

User accounts need access to most of the Active Directory with at least read permissions. Of course, you should plan a good password policy and implement an authentication procedure that fits your required security level in your corporation.

I know many of you do not run on a Windows 2000 Active Directory anymore, but you can still have a backwards compatibility configuration in your environment from an older upgrade. Microsoft made this “feature” for the operating systems before Windows 2000. These systems needed access to Active Directory and a security group was created to help these computers by giving users access to the directory. During the first Windows 2000 domain controller promotion (DCPROMO) the following window (Figure 4) is displayed.

Figure 4: Active Directory Installation Wizard for setting permissions

Notice the yellow exclamation mark?

When you select this compatibility option, the “Pre-Windows 2000 Compatibility Access” security group would be populated with the “Everyone” security group. In the Windows 2000 Active Directory, the “Pre-Windows 2000 Compatibility Access” security group was populated with the group “Everyone” which contained the anonymous users also.

Note:
The anonymous users were removed from the “Everyone” group in the Windows 2003 domain and later.

The Windows 2003 DCPROMO-command did change the “Pre-Windows 2000 Compatibility Access” group membership to include the anonymous users if the “Everyone” group was present already with the added the “Authenticated Users” also.

 I have made the following table to give you an overview of the default membership of the group in Figure 5.

Figure 5: “Pre-Windows 2000 Compatibility Access” security group membership

* “Yes” was answered in the DCPROMO wizard to enable “Permissions compatible with pre-Windows 2000”
** If Windows 2003 was upgraded from Windows 2000 the same answer as above applies

Let us say that you do not run on Windows 98 and Windows NT 4.0 in your environment, do you need this group? Well, some multifunction devices such as copy-machines with scanning and e-mail support use Active Directory to look up information, so you might have devices that use the “Pre-Windows 2000 Compatibility Access” group.

What can we do about it?

Much of the information that we can see in Active Directory is of course needed by the clients in your organization to function properly. Some details are relevant, some are not and some information should be kept confidential. Please check your own domain as a standard domain user and see if something is not following the security policy in your organization.

The “Pre-Windows 2000 Compatibility Access” security group

Firstly, you should make sure that you do not have any computers that use this group. That includes; Windows 98, Windows NT 4.0 and other devices that need access to Active Directory with the “full read” permission or null-sessions to the servers.

Next you need to remove the groups “Anynomous Logon”, “Everyone” and “Authenticated Users” from the “Pre-Windows 2000 Compatibility Access” group. You can use both the Active Directory Users and Computers and the command line to remove these.

Last thing is to check that everything is working as you expect.

I you find a device somewhere that needs this access and you cannot configure it for correct logon then of course you can add the group(s) that you removed, if your security plan allows this. Otherwise you remove that device from your installation (Please consult the Microsoft knowledgebase article mentioned in the links section of this article).

The “Authenticated Users” security group

I would not recommend implementing deny-rules for this because functionality in your environment may decrease and you might end up with an unsupported Active Directory. So, unless you know exactly what you need to deny, you should tighten the security by implementing e.g. better password policies and restrict users’ workstations.

Set a confidentiality flag in the schema attributes

For all objects besides the “Schema Base Objects” (Category 1 objects – those that have the bit 4 (Dec 14, Hex 10) set on the systemFlag attribute) you can actually mark an attribute as confidential. This filters the attribute in the searches to the directory so that only domain administrators can read the details. Setting the confidential-flag is done by adding 128 to the existing searchFlag on the attribute.

The requirement for this flag is that all domain controllers run Windows 2003 Server with Service Pack 1 (or later) regardless of the domain and forest functional level. The flag can be set with the ADSIEdit tool. Please read and follow the instructions in the Microsoft knowledgebase article mentioned in the Links section of this article.

Conclusion

In this article we found out some information that ordinary domain users can query for in a Microsoft Active Directory. Because of normal Windows domain behavior and backwards compatibility this can be more or less appropriate for your corporation. We have covered how we restrict read access to Active Directory to members of the “Pre-Windows 2000 Compatibility Access” security group as well as marking non-system-base as confidential.

Links

• Microsoft TechNet: Best Practice Guide for Securing Active Directory Installations
• Microsoft TechNet: SysInternals website and tools
• Microsoft Knowledgebase: How to Add Users to the Pre-Windows 2000 Compatible Access Group
• Microsoft Knowledgebase: Description of Dcpromo Permissions Choices
• Microsoft Knowledgebase: Everyone group does not include anonymous security identifiers
• Microsoft Knowledgebase: Distribution group membership is still visible after you hide the membership
• Microsoft Knowledgebase: How to mark an attribute as confidential in Windows Server 2003 SP1
• Javelina Software (Makers of ADToolkit):  http://www.javelinasoftware.com/