Installing SecureLogin on an Active Directory Server

The following information assumes that you have installed the Microsoft* Windows 2000 Server family operating systems (including Active Directory) on at least one domain controller in your network.

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.

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.

Adding Administrative Tools for Active Directory

The following procedures assume that you are logged in as an administrator with the required permissions to manage the schema.

1. Click Start > Settings > Control Panel > Add/Remove Programs.

2. Click Windows 2000 Administration Tools > Change, then click Next.

3. Click Install All Administrative Tools, then click Next.

4. After components and files are installed, click Finish, then click Close.

Starting the Active Directory Schema Snap-In

The Active Directory Schema snap-in is a Microsoft Management Console (MMC) tool. Because schema management is not frequently performed, there is no saved Schema console or Administrative Tool on the Administrative Tools menu. You must manually load the Schema Manager into MMC.

Run the following procedure on the domain controller that contains the schema.

1. Click Start > Run.

2. In the Open box, type MMC and then click OK.

3. From the Console drop-down list, click Add/Remove Snap-In > Add.

4. Click Active Directory Schema > Add.

5. Click Active Directory Users and Computers > Add.

6. Click Close, then click OK.

7. Save the MMC containing the schema snap-in.

   1. From the Console drop-down list, click Save As.

   2. Type a name for the saved console (for example, Schema.msc).

   3. Click Save.

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 to Another Domain Controller

To transfer the schema FSMO to another domain controller:

1. From the left pane of the MMC console, right-click Active Directory Schema.

   The following graphic illustrates Active Directory Schema in the directory structure:

2. Click Change Domain Controller.

3. (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:

   
   

4. From the left pane, right-click Active Directory Schema, click Operations Master, then click Change.

5. Click OK to confirm that you want to change the Operations Master.

6. When you receive the message that the Operations Master was successfully transferred, click OK.

Verifying the Domain Controller

To verify that you have selected the correct domain controller:

1. From the left pane of the MMC console, right-click Active Directory Schema and then click Change Domain Controller.

   The following figure illustrates Active Directory Schema in the directory structure:

   
   

2. Verify that the Current DC field lists the domain controller that you are currently working on and then click OK.

3. From the left panel, right-click Active Directory Schema and then select Operations Master.

4. Check the Schema May Be Modified on This Domain Controller check box and 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 three new object attributes.

1. Run adsschema.exe.

   This file is on the Novell SecureLogin CD in the \securelogin\tools directory.

   When you run adsschema.exe on the server that is the FSMO master, adschema.exe adds three attributes to the schema:

   • ProtAuthMethods

     This attribute is only for a User object. It is an octet-string type.

   • 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 userIDs and passwords
     • Specific preferences and application definitions at the User object
     • Corporate application definitions and preferences at the Container and Organizational Unit objects

2. Verify that the schema has been extended.

   1. Close and restart MMC.

      After extending the schema, you must close and restart MMC before you can verify that the schema has been extended

   2. In the MMC tool, navigate to the Attributes folder.

      The following figure illustrates the Attributes folder:

      
      

   3. Identify the three attributes.

      Ensure that ProtAuthMethods, protocom-SSO-Auth-Data, and protocom-SSO-Entries appear in the ADS list of attributes. The following figure illustrates these attributes that have extended the schema:

      
      

Replicating Three Attributes

To enable other servers to have the ProtAuthMethods, protocom-SSO-Auth-Data, and protocom-SSO-Entries attributes, you must replicate the attributes.

1. In the MMC tool, navigate to the Attributes folder.

   The following figure illustrates the Attributes folder:

   
   

2. Right-click the ProtAuthMethods attribute, then click Properties.

   The following figure illustrates the ProtAuthMethods attribute:

   
   

3. Check the Replicate This Attribute to the Global Catalog check box, then click OK.

   The following figure illustrates this check box:

   
   

4. Repeat this process for the protocom-SSO-Auth-Data and protocom-SSO-Entries attributes.

5. Shut down and restart the management console.

   Active Directory does not incorporate the new attributes until the management console is restarted.

Assigning Rights to User Objects

To use SecureLogin, users must have Read and Write rights to the ProtAuthMethods, protocom-SSO-Auth-Data, and protocom-SSO-Entries attributes on their User object. These rights enable users to add configuration data (for example, a passphrase) and create logins.

Default rights are set when SecureLogin is installed and the schema is extended for the first time.

If you don't assign rights to SELF, users are unable to read or write SecureLogin attributes.

To assign rights:

1. Bring up the MMC snap-in.

   1. Click Console, then click Open.

   2. Select the profile name that you saved in Step 7.

   3. Click Open.

2. Click Active Directory Users and Computers and then click the domain name (for example, inet.nsrd.lab.vmp.com) > Users.

3. Right-click a container, click Delegate Control, then click Next.

   For example, you can select the Users container. Active Directory automatically creates this predefined container. On the other hand, you can select a container that you have created (for example, RDlab).

   This step is necessary for every container that you want rights to apply to.

   If Container objects (for example, OU objects) contain users in subcontainers, you must set up the same rights as the ones assigned to Active Directory's built-in Users container.

   If branches exist in your Active Directory tree, ensure proper rights by assigning rights for each branch or by assigning rights globally at the Root.

   The following figure illustrates the Selected Users and Groups list box:

   
   

4. Click Add, then select SELF.

5. Click Add, then click OK.

6. (Conditional) Click Create a Custom Task to Delegate, then click Next.

   If you selected the predefined Users container, skip this step. The following screen won't appear. However, if you selected a container that you created (for example, RDlab), the following screen appears.

   
   

7. In the Active Directory Object Type window, click Only the Following Objects in the Folder, check the User Objects check box, then click Next.

   The following figure illustrates this option:

   
   

8. Set permissions on new schema attributes.

   1. Under Show These Permissions, check the General and Property-Specific check boxes.

   2. In the Permissions list box, check the Read and Write check boxes for the ProtAuthMethods, protocom-SSO-Auth-Data, and protocom-SSO-Entries attributes.

   The following figure illustrates these check boxes:

   
   

9. Click Next, then click Finish.

Assigning User Rights to an Organizational Unit

In addition to setting rights for User objects, you must set rights so that users can read corporate objects (for example, corporate scripts and serverPolicyOverride objects). Users can then inherit and use objects that you set up specifically for target users.

To accomplish this, you set Read and Write permissions for the prot-SSO-Entries attribute.

Settings and corporate scripts.

1. Bring up the MMC snap-in.

   1. Select Console, then click Open.

   2. Select the profile name that you saved in Step 7.

   3. Click Open.

2. Select Active Directory Users and Computers, select the domain name (for example, inet.nsrd.lab.vmp.com), and then click Users.

3. Right-click the container that you want to apply rights to, select Delegate Control, then click Next.

   For example, you can select the Users container. Active Directory automatically creates this predefined container. On the other hand, you can select a container that you have created (for example, RDlab).

   If Container objects (for example, OU objects) contain users in subcontainers, you must set up the same rights as the ones assigned to Active Directory's built-in Users container.

   If branches exist in your Active Directory tree, ensure proper rights by assigning rights for each branch or by assigning rights globally at the Root.

   The following figure illustrates the Selected Users and Groups list box:

   
   

4. (Conditional) Select Create a Custom Task to Delegate, then click Next.

   If you selected the predefined Users container, skip this step. The following screen won't appear. However, if you selected a container that you created (for example, RDlab), the following screen appears.

   
   

5. In the Active Directory Object Type window, select This Folder, Existing Objects in This Folder, and Creation of New Objects in This Folder, then click Next.

   
   

6. Set rights (permissions) on new schema attributes.

   1. Under Show These Permissions, check the General and Property-Specific check boxes, click Next, then click Finish.

   2. In the Permissions list box, check the Read and Write check boxes for the protocom-SSO-Entries attribute.

   The following figure illustrates these check boxes:

   
   

7. Click Next, then click Finish.

Setting the Default Domain Policy

At the domain level, make sure that the Default Domain policy allows all authenticated users to have Read rights to All Properties.

1. Expand Active Directory Users and Computers, right-click the domain name, then select Properties.

2. Select the Group Policy tab, click Properties, then select the Security tab.

3. Click Advanced.

4. Select Authentication Users Special, then click View/Edit.

5. Under the Allow column, check the Read All Properties check box.

   The following figure illustrates this check box:

   
   

6. Click OK.