Boswell's Q&A

Under Script Control

How to give users more control with what they can see and edit in Exchange's Global Address list.

• By Bill Boswell
• 01/11/2005

Bill: I manage an Exchange 2003 system. My users would like to edit some of the information they see in the Global Address List property pages. I know about the Galmod32 tool that enables users to edit their own information, but this tool doesn't list many of the fields that my users want to edit. Also, we use the Employee Number field in Active Directory. I've added the Employee Number field to the GAL pages but I'm tired of using the ADSI Editor to add and modify the entry.

What I'm looking for is a GUI tool where non-IT personnel can edit some of the GAL information and where I can update fields that don't appear in Active Directory Users and Computers without resorting to ADSIEdit. Do you know of any tool or solution to this problem?
— Larry

Get Help from Bill Got a Windows or Exchange question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to Bill at mailto:[email protected]; the best questions get answered in this column. When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message but submit the requested information for verification purposes.)

Larry: If the user's update needs were limited to a few items, you might be able to get by with using the Windows Address Book. This often overlooked applet comes on every flavor of Windows. You can search Active Directory similar to the way you do lookups in the GAL. The difference is, if a user has permission to change an attribute, he or she can actually put in a new value from the Windows Address Book, whereas the GAL properties window displays values in read-only form.

As I'm sure you know if you've done a Google search, there are quite a few vendors who provide tools for accessing and updating Active Directory information. Some of these tools have special interfaces that are relatively simple to manage for users or department gurus. You might want to take a look at products such as Directory and Resource administrator from NetIQ www.netiq.com/products/dra and Hyena from SystemTools www.systemtools.com/hyena. (Send other suggestions to [email protected]).

But ... I took this question as an opportunity to demonstrate how a little work with scripts can help to resolve these kinds of issues. Not only does using a script avoid the cost of a third-party product, you gain flexibility because you can include attributes that are not displayed in ADUC or third-party interfaces and you can incorporate functionality that the packaged solution might not have.

Just as an aside, the inability to access all User and Computer fields in ADUC is a pet peeve. Microsoft should include a Custom tab in the Properties pages for User and Computer objects in ADUC and permit an administrator to select any attribute to include in this tab. Exchange System Manager has this functionality using Details Templates. That's how Larry added the Employee ID to the GAL properties. It shouldn't be that hard to add the same functionality to ADUC.

Anyway, back to the subject. I put together a sample Web page containing an ASP script that displays User attributes from Active Directory that you might want to let end users update. They won't actually be able to do an update until you give them Write access to the properties (more on that in a second). The script also gives an administrator the option of entering a user name and updating that user's information. The script name is UpdateUsers.asp, which you can download by clicking here; the script includes documentation. As usual, don't run this script in a production environment without thorough testing.

Figure 1 shows you what the page looks like. Users would not see the search field at the top of the page; they would only see their own values.

(Click image to view larger version.)

Assigning Write Permissions to Users
Whether you use this script or the Windows Address Book or a third-party product, if you want users to change Active Directory attributes, you have to give them permission to do so. This involves using the Delegation of Control Wizard in Active Directory Users and Computers. Try this on a test OU first:

1. Right-click the OU in ADUC and select Delegate Control from the flyout menu. This launches the wizard.
2. In the Users and Groups window, either type SELF or select SELF from the browse list. This is a placeholder that gets instantiated with the SID of the logged-on user. By delegating permissions to SELF, you're giving permission to update properties only on a user's personal User object.
3. In Tasks to Delegate, select the Create a Custom Task radio button.
4. In Active Directory Object Type, select the Only the Following Objects radio button and check User Objects.
   
   
   
5. In the Permissions window, leave the General option checked, scroll down the list, and check Read and Write Personal Information. This is called a "Property Set." It's essentially a shorthand way of assigning access to a list of properties rather than picking them one at a time from the list. If you're interested in the properties included in the Personal property set, search the Windows Server 2003 online help for "Property Set."
   

Once you complete the wizard, log on as an average user who resides in the test OU and use the Windows Address Book to find the user. If you open the Properties window, you'll find that several of the fields now permit you to make changes. The remainder stay dimmed, indicating that they're read-only.

Running the Script
Because the demo script comes inside an ASP page, you'll need to run it on a Web server that has IIS 5 (Windows 2000 or XP) or IIS 6 (Windows Server 2003):

1. Create a folder on the server called UserUpdates (or some other name that you like) and place the UpdateUsers.asp file in folder.
2. Use the IIS Manager console to create a virtual folder called UserUpdates and point it at the new folder.
3. Set the folder properties to allow ASP scripts to run.
4. In the Properties window of the new virtual folder in IIS Manager, set the Security settings to allow only Windows Integrated authentication. Uncheck Anonymous and Basic. This is important. Without this step, the script won't run. It uses thread impersonation to bind to Active Directory.

   Note: When connecting to the Web server in Internet Explorer, use the short name of the server. If you use the fully qualified DNS name (such as server.company.com) then you will get prompted for credentials then the script will fail to run. This is because IE assumes that any host name with a dot in it lies in the Internet zone and will not allow Windows Integrated authentication.

At this point, you can access the page from the console of the IIS server. If you want to access the page from a browser on another machine, you'll need to configure the server in Active Directory as "Trusted for Delegation." Without delegation, you'll get a run-time error because the script uses impersonation to bind to Active Directory. There are other workarounds, but this is precisely the reason delegation was included in Windows, so you might as well use the feature.

Note: Windows Server 2003 has the ability to constrain Kerberos delegation to a specific service. If this sounds like something you as readers might want to do, let me know and I'll cover it in a future Q&A.

If you can't get the script to run, contact me at [email protected] and I'll be happy to help you figure out the problem.