The second article in Marcin Policht’s ‘Accessing Active Directory via Active Server Pages’ series addresses authentication issues when accessing information stored in Active Directory via Web-based Active Server Pages scripts.
In the first article of this series, I presented a sample script embedded in an ASP page that accessed Windows 2000 Active Directory to extract a list of all Global Groups matching arbitrarily chosen criteria. This example was meant to illustrate several issues that arise when trying to incorporate ADSI VBScripts into a Web environment. The most critical one (and one that probably is the primary source of confusion when dealing with Web-based Active Directory management) is authentication. Every script running on a Windows system, whether executed interactively by a logged-on user, as a scheduled task, or as a server-based ASP script, needs to execute in a security context of a valid account. If this account happens to have sufficient permissions, the script has a chance of succeeding (providing everything else goes right); otherwise, it will fail, typically as the result of an “access denied” condition.
In order to ensure that the script executes with sufficient security privileges, I included username and password credentials in the script. This type of solution might be acceptable in some scenarios. For example, you can use NT integrated authentication to limit access to the Web site to domain users and set additional restrictions on the page level with NTFS permissions. But this does not change the fact that hard-coding user credentials is a discouraged practice, from both a programming and a security point of view.
You might wonder whether it would be possible to remove the credentials from the script and simply execute it after logging on with this username and password. The answer is, as usual, “it depends”.
Let’s first discuss the differences between running scripts interactively and via Web server-based pages, and then I’ll present several possibilities for addressing them.
If you follow the previously suggested idea and modify the script so it does not contain username and password, it will run in the security context of the account that executes it. This means, that if you log on using the same username and password and run the modified script, it will execute just as well as before. However, if you try to follow the same approach and modify the ASP Web page, the script will most likely fail with an “access denied” error message (I’ll explain in a moment the conditions that would allow it to run successfully). What exactly happens depends on the type of authentication set on the Web server. For the rest of this article, we will assume that IIS is using Integrated Windows authentication. I’ll cover other authentication options in a future article.
Integrated Windows Authentication causes the ASP page to execute in the security context of the user who connects to the Web server, which is essentially what we want. This should work with an ASP script just as well as with the interactive one. The reason it fails is the fact that this authentication mechanism applies only to the local system (i.e. the Web server) on which the script runs. The traditional Windows authentication mechanism (based on NTLM, which is used in this case) does not support so called “double hop” authentication. This means that if the user launches a process on a remote server (such as a Web server script), this process will run with the same security as the user. However, if this process tries to launch a new process on another remote server (in the case of our ADSI script, this “another” server is a Windows 2000 domain controller), user security context cannot be used. In the case of an IIS Web site configured with integrated (or anonymous) authentication, the process will use a special token with any network rights.
One way to ensure our modified ADSI Web script succeeds is to avoid the “double hop” and use of that special token. You can accomplish this by installing IIS on a domain controller or by running the script directly on the Web server itself. The first of these options is strongly discouraged from both a security and a performance point of view, while the second one is simply not realistic.
One viable option you can consider is using an authentication mechanism called delegation. Unfortunately, delegation is available only if you are using Windows 2000 Active Directory native mode domain with Windows 2000 Servers and Windows 2000/XP Professional clients (since delegation can only be used with Kerberos and is not available with NTLM). The benefit of delegation (besides the advantages inherent to Kerberos, such as increased security) is support for double-hop authentication. Delegation is a mechanism that works on a per account level, and you have to enable it for both computers and users accounts that participate in the authentication chain.
In order to take advantage of delegation (and therefore be able to successfully run our ADSI Web-based script), you will need to take the following steps:
- Determine the names of all users and the Web server which will be hosting the ASP Web page.
- Launch Active Directory Users and Computers for the domain where users and computer accounts are located.
- For each of the users’ accounts, bring up the account Properties dialog box, click on Account tab and select the “Account is trusted for delegation” checkbox.
- For the Web server computer account on the General tab, select “Trust this computer for delegation”.
- Ensure that you restart the computer and have the user re-logon to the domain.
Enabling Kerberos increases some security risks, so you might want to consider carefully whether you want to follow this path.
In the next article of the series I will discuss other solutions that are not limited to a Windows 2000 Active Directory domain and Kerberos-capable clients only.