Using Active Directory in Place of the Registry

The main topic of this book is security. From a strictly security perspective, there isn’t any better place to store sensitive settings than Active Directory. Storing settings on the local machine invites crackers to peek. For that matter, some users can’t wait to modify the registry so that Windows better suits some perceived need. In some cases, user preference doesn’t affect security, but, in other cases, it does. For example, you don’t want the user changing Windows so it no longer requires a password to deactivate the screen saver. Although you can secure registry settings, such as the security used for the Security Access Manager (SAM) settings, you can’t guarantee that the user won’t fiddle with the settings you miss. When information is stored in Active Directory, it remains safe because Windows itself protects the data store.

Developers do need to consider issues other than security. Although security is the focus of this book, it’s important to consider Active Directory outside of the security issues so you gain a fuller appreciation of this technology. With all of the functionality that Active Directory provides, it’s tempting to think that it will replace the registry. In some respects, Active Directory does replace the registry. You should consider using it wherever an application has global importance, more than one user will require access to a single set of settings, or the information is so critical that you want to ensure that it remains safe. However, placing all your data within Active Directory also presents some problems that you need to consider.

Tip

You don’t have to write a complete program to meet every ADSI programming requirement. Any environment that lets you access objects will work fine. For example, Microsoft produces a scripting tool that generates the code required to perform basic ADSI operations quickly. You can learn more about this tool at http://www.microsoft.com/downloads/details.aspx?familyid=39044e17-2490-487d-9a92-ce5dcd311228&displaylang=en.

Active Directory is a poor choice for local settings for applications that only matter to the user. For example, no one else is concerned with the user’s settings for a word processor. You gain nothing in the way of shared resource management or data security by storing these settings on the server. In fact, using Active Directory could mean a performance hit, in this case, because the application will need to access the server every time it needs to change a stored setting.

The performance hit for server access is relatively small for a LAN. However, consider the global nature of networks today. A user on the road is going to be out of communication for some time, which means Active Directory setting changes will languish on the local machine. In short, the registry is a better choice in many situations where the user data is noncritical, even though that data is more secure when stored in Active Directory.

A secondary performance consideration is one of managed versus unmanaged code and data. When you work with Active Directory, you’ll often need to work with unmanaged data and code. Active Directory applications require some access to the native COM components provided as part of the ADSI interface. Every time the application makes a transition between managed and unmanaged environments, the application suffers a performance penalty. In addition, unmanaged code requires special handling if you want to maintain a safe environment (read the “Extending the AppDomain to Unmanaged Code” section of Chapter 6 for details).

Using the registry is also easier than using Active Directory. The example applications in this chapter demonstrate that working with Active Directory is akin to working with a complex database. The registry is smaller and easier to understand. It’s less likely that you’ll experience major bugs when working with the registry because all of the registry manipulation functionality you need is contained within the .NET Framework. Because CLR performs extensive checks on managed code, you’ll find that it also catches more potential problems with your code.