Preparing Active Directory
Prerequisites
- The Microsoft Windows 2000 or 2003 Server family operating system (including Active Directory) is installed on at least one domain controller in your network.
- The latest service pack is installed.
Service packs are required so that you can install the Adminpak for the Windows 2000 or Window 2003 server.
- The Adminpak for the Windows 2000 or Window 2003 server is installed.
If the Adminpak isn't installed, you can't extend the Active Directory schema.
Preparing to Extend the Active Directory Schema
If this is the first installation of SecureLogin on your server, you must extend the Microsoft Active Directory Schema before installing SecureLogin.
Management of the schema is restricted to a group of administrators called schema administrators. The Active Directory Schema snap-in allows schema administrators to manage the Active Directory schema by doing the following:
- Creating and modifying classes and attributes.
- Specifying which attributes are indexed and which attributes are to be catalogued in the global catalog.
WARNING: Extending the schema is a highly sensitive operation, with implications potentially throughout your network. Improper schema modifications can impair or disable Windows 2000 Server and possibly your entire network. Please seek the advice of a qualified systems administrator if you are uncertain about schema extension.
As a schema administrator, you won't perform schema management tasks frequently. Observe three safety precautions that control and limit schema modification:
- By default, all domain controllers permit Read access to the schema. A registry entry must be set on a domain controller to permit Write access to the schema on that domain controller.
- The schema object is protected by the Windows 2000 Security model. Therefore, administrators must be given explicit permissions or be members of the Schema Administrators group to make changes to the schema.
- Although Active Directory is based on a multi-master administration model, some operations support only a single master. One of these operations is schema management. Only one domain controller can write to the schema at any given time. This role is known as Schema Floating Single Master Operations (FSMO).
To manage the schema, you must be connected to the schema FSMO. By default, the schema snap-in is targeted to the schema FSMO role.
Extending the Active Directory Management Schema
You can transfer the schema FSMO from one server to another. However, if you have installed a single Windows 2000 domain controller in your network, this procedure is unnecessary. By default, that single domain controller handles the schema FSMO role.
Transferring the Schema FSMO
-
From the left pane of the Microsoft Management Console (MMC), right-click Active Directory Schema.
-
Click Change Domain Controller.
-
(Conditional) If the name in the Current DC field is not the target server, click Specify Name, type the name of the target domain controller, then click OK.
The following figure illustrates the Current DC field:
-
From the left pane, right-click Active Directory Schema, then click Operations Master > Change.
-
Click OK to confirm that you want to change the Operations Master.
-
When you receive the message that the Operations Master was successfully transferred, click OK.
Verifying the Domain Controller
-
From the left pane of the MMC console, right-click Active Directory Schema, then click Change Domain Controller.
The following figure illustrates Active Directory Schema in the directory structure:
-
Verify that the Current DC field lists the domain controller that you are currently working on, then click OK.
-
From the left panel, right-click Active Directory Schema, then select Operations Master.
-
Check The Schema May Be Modified on This Domain Controller check box, then click OK.
This check box sets a registry entry that permits schema updates. The server automatically detects the change to this registry. You don't have to restart the server to permit the schema to be updated.
The following figure illustrates this check box:
Extending the Active Directory Schema
To store information such as a user's credentials, application scripts, preferences and corporate configuration, you must extend the Active Directory schema to accommodate six object attributes.
-
Run adsschema.exe.
This file is available on your workstation after you run nsl351.exe from the CD or download image. Typically, this file is in the c:\securelogin\tools directory. However, if you unzipped to the Temp directory on a Windows 2000 workstation, you might need to unhide the Local Settings directory and then locate ndsschema.exe in the following path:
c:\Documents and Settings\Administrator\Local Settings\Temp\SecureLogin\Tools
When you run adsschema.exe on the server that is the FSMO master, adsschema.exe adds six attributes to the schema:
protocom-SSO-Auth-Data. This attribute is only for a User object. It is an octet-string type. It contains all user-specific authentication data, such as the passphrase.
protocom-SSO-Entries. This attribute is for User, Container, and Organizational Unit objects. It is an octet-string type. This attribute contains the following:
- All the user's login user IDs and passwords
- Specific preferences and application definitions at the User object
- Corporate application definitions and preferences at the Container and Organizational Unit objects
protocom-SSO-Entries-Checksum. This attribute optimizes the loading of data from Active Directory. Whenever data changes in the protocom-SSO-Entries attributes, the Checksum attribute is updated. When SecureLogin loads, it reads the checksum and compares it to the checksum in memory. If the checksums are different, SecureLogin reloads the Entries attribute from the directory.
protocom-SSO-Profile. This attribute contains the user's distinguished name.
protocom-SSO-Security-Prefs. This attribute stores data required for the Advanced Passphrase policies. This data includes Administrator-set Passphrase questions, Passphrase help information, and settings.
protocom-SSO-Security-Prefs-Checksum. This attribute functions with the protocom-SSO-Security-Prefs attribute much like the protocom-SSO-Entries-Checksum functions with the protocom-SSO-Entries attribute.
-
Reboot the computer.
If you need to verify that the schema has been extended, see Verifying the Active Directory Schema.
Assigning User Rights
You can assign SecureLogin schema attribute rights to user objects, containers, and organizational units. Assigning rights to containers and organizational units filters down to all associated user objects. Therefore, unless you have a specific requirement to do so, it is unnecessary to assign rights at the individual user object level.
To assign user rights:
-
If it is not already running, run adsschema.exe, found in the \securelogin\tools directory.
-
Click Assign User Rights, then click OK.
The Assign Rights to This Object dialog box appears.
In the above figure, rights are assigned to the User container.The User container definition is:cn=users, dc=www, dc=training2, dc=comTo assign rights to an organizational unit, for example Marketing, in thedomain www.company.com, the definition is:ou=marketing, dc=www, dc=company, dc=com
-
Click OK.
The Active Directory Schema dialog box reappears. Click OK to enter another context, or click Cancel.
If an error appears during an attempted login immediately after the install of SecureLogin on the Active Directory server, OK the message and wait for a few minutes before trying again. The reason for this error is because Active Directory takes time to synchronize. If the error continues, you might need to reboot the server.
Refreshing the Directory Schema
To do this,
-
From the left pane of the Microsoft Management Console (MMC), right-click Active Directory Schema.
-
Select the Reload the Schema option from the menu.
-
Select Exit from the Console menu to close the MMC.
In a multiple-server environment, schema updates will occur on server replication.
NOTE: Rights to objects can be assigned at any time after extending the schema. If you add organizational units, you need to rerun the adschema.exe tool and assign rights to the new OU to enable SecureLogin functionality.
Replicating Six Attributes
To enable other servers to have the protocom-SSO-Auth-Data, protocom-SSO-Entries, protocom-SSO-Entries-Checksum, protocom-SSO-Profile, protocom-SSO-Security-Prefs, and protocom-SSO-Security-Prefs-Checksum attributes, you must replicate the attributes.
-
In the MMC tool, navigate to the Attributes folder.
The following figure illustrates the Attributes folder:
-
Right-click the protocom-SSO-Auth-Data attribute, then click Properties.
The following figure illustrates the protocom-SSO-Auth-Data attribute:
-
Check the Replicate This Attribute to the Global Catalog check box, then click OK.
The following figure illustrates this check box:
-
Repeat this process for protocom-SSO-Entries, protocom-SSO-Entries-Checksum, protocom-SSO-Profiles, protocom-SSO-Security-Prefs, and protocom-SSO-Security-Prefs-Checksum attributes.
-
Shut down and restart the management console.
Active Directory doesn't incorporate the new attributes until the management console is restarted.