To install or upgrade SecureLogin in an LDAP directory environment, you must extend the LDAP schema with SecureLogin attributes. However, no change is required to Microsoft Active Directory (AD) schema.
You must manually assign read and write access to the new SecureLogin attributes. Due to a wide variety of LDAP-compliant directories, NetIQ does not provide a specific tool for assigning permissions to directory attributes.
If the LDAP directory and Microsoft AD are synchronized, SecureLogin can seamlessly pass a users’ AD’s credentials to LDAP so that users enter their login credentials only once.
Installing SecureLogin on the server requires extending the LDAP schema and assigning user rights to record data against these attributes.
Extending the directory schema adds the following six SecureLogin attributes:
Table 6-1 Attributes
|
Attribute To Be Mapped |
LDAP Mapping |
|---|---|
|
Prot:SSO Auth |
|
|
Prot:SSO Entry |
protocom-SSO-Entries |
|
Prot:SSO Entry Checksum |
protocom-SSO-Entries-Checksum |
|
Prot:SSO Profile |
protocom-SSO-Profile |
|
Prot:SSO Security Prefs |
protocom-SSO-Security-Prefs |
|
Prot:SSO Security Prefs Checksum |
protocom-SSO-Security-Prefs-Checksum |
NOTE:These mappings are case-sensitive. Extend the LDAP schema on all servers if you want them to act as failover servers.
If you intend to use Microsoft Group Policy (GPO) support, NetIQ recommends that you re-extend the SecureLogin directory schema extensions to include the new schema extensions for GPO support.
If the LDAP-compliant directory extension is deployed using the ldapschema.exe file copied from rather run from the SecureLogin installer package, then you need to copy the entire LDAP folder containing the LDAP schema files to your preferred location.
Log in to the server as administrator.
Run ldapschema.exe found in the \Securelogin\Tools\Schema\LDAP directory of the SecureLogin distribution package. The SecureLogin - Active Directory Schema dialog box is displayed.
or
Click Schema Extension Tools and click LDAP Compliant.
In the LDAP Server field, provide the IP address or the name of the LDAP server.
In the Admin User field, provide the distinguished name (DN) for the server administrator. For example, CN=admin
Provide the password and select the relevant directory mode (in this example, eDirectory), then click Update Schema. The certificate information is displayed.
Click Accept.
When the Schema Extension dialog box is displayed, click Close.
NOTE:LDAP schema extension is replicated to all servers in the LDAP Group, and not to all servers in the tree. Schema extensions are LDAP group specific and must be repeated for each LDAP group. By default, each NetWare server is in its own LDAP group, which means that by default LDAPSchema.exe must be run on every LDAP server.
You must assign permissions to objects in the directory to store data against the new SecureLogin attributes. Assign permissions to all objects that access SecureLogin Assigned User Rights.
The application does not start if you have not set permission to access SecureLogin schema attributes.
NOTE:LDAP implementations are varied. Therefore, SecureLogin does not provide a specific tool for each variation for assigning permissions.
The following permissions are recommended for successful implementation:
SecureLogin administrators are assigned read and write access to all SecureLogin attributes on all objects.
Users are assigned read and write access to all SecureLogin attributes on their user objects.
Users are assigned read access to the SecureLogin attributes on organizational units from which they need to read organizational policies or corporate settings.
All the functionality that is available in NMAS is also available in the LDAP Authentication client for SecureLogin. The LDAP client enables you to provide multilevel authentication (for example, a biometric device and a password).
When you use LDAP on eDirectory, the LDAP password can come from one of two places:
The eDirectory password
The NMAS Simple password
The eDirectory password takes precedence. The Simple Password exists if used in an eDirectory password does not exist.
If a user types a password that does not match the eDirectory password, LDAP attempts to match the simple password.