Home | About PassGo | Press Center | Defender Token Self Registration and Active Directory Security

Defender Token Self Registration and Active Directory Security

The Defender Token Self Registration facility is a web-based service which guides the user through the steps required to assign a Defender authentication hardware token to their user ID, so that he may subsequently use the token to authenticate with the system. The facility creates an association between a token object and a user object in the Microsoft® Active Directory® to do this.

Since Defender 5 the token and user objects are held in Active Directory®, the web service must be capable of reading user objects, and writing user and token objects to and from Active Directory®. This association is essential to allow the service to function correctly but as with the implementation of any system, appropriate considerations should be made regarding its effect on overall system security. This information below describes the security-related considerations that the supervisors of a Defender implementation should address.

How does the facility communicate with Active Directory?

The Token Self Registration pages are written in ASP running on IIS. They retrieve and store data in Active Directory® by calling a distributed COM (DCOM) object installed on the web server machine which, in turn, uses standard Microsoft programming interfaces to communicate with Active Directory®, which uses LDAP as its underyling connection protocol.

 

 

 

 

 

 

 

 

 

How should the facility be configured?

• IIS should be configured to require integrated windows authentication. Users attempting to gain access to the web pages without having first authenticated will see a “Not Authorized” page.
• The web server should not be placed on an external network. Careful consideration should be given when placing the server on a DMZ, since this would require LDAP and NETBIOS channels to be opened in the firewall which may present an unacceptable risk.
• The Defender.exe DCOM object should run under the account of a user who has privileges to read user objects and write token objects. This account should not be given any further privileges that it does not need in order to fulfil the function of reading and writing these objects. Furthermore the DCOM object should allow only authenticated users to launch or access the DCOM object.
• The web server machine and IIS should be updated regularly with the latest patches.

How does the facility control and restrict access to Active Directory?

• The code which calls the DCOM object, which in turn accesses Active Directory, is written in ASP running on the server. This code is not visible from the browser and therefore cannot be exploited without compromising the web server in some way.
• Every user must log into the Active Directory domain in order to view the Token Self Registration pages. The service is not accessible to unauthenticated users, because Integrated Windows authentication under IIS requires this.
• Integrated Windows authentication allows the ASP pages to locate the user object in Active Directory for the logged-on user, so that the logged-on user cannot retrieve the user object for another user in Active Directory.
• Provided appropriate access controls are applied to the DCOM object, an attacker successfully compromising the web server still cannot launch the DCOM object unless they have managed to gain administrative rights on the web server machine or to compromise a weakly-protected domain user account.
• The DCOM object is only capable of retrieving certain basic user attributes, and writing a Defender token record. Having successfully negotiated all the barriers mentioned so far, an attacker gains little more than prestige, without having physical access to a Defender token as well as to the correct access node (i.e. to the correct source IP address).