Secure Global Desktop Administration Guide > Users and authentication > LDAP users can't log in to Secure Global Desktop

LDAP users can't log in to Secure Global Desktop

If you are using the LDAP login authority to authenticate users and you find that LDAP users are not able to log in to Secure Global Desktop, use the following checklist to identify the source of the problem.

You may also find it helpful to turn on extra logging in Array Manager. Select the Array properties panel and add a server/login/* and a server/ldap/* filter in the Log Filter box.

Things to checkNotes
Is the LDAP login authority enabled?You cannot use an LDAP directory server with Secure Global Desktop unless the LDAP login authority is enabled.

Use the Secure Global Desktop Login properties in Array Manager (or use the tarantella config edit --login-ldap 1 command) to enable the LDAP login authority.

Are the URLs of the LDAP directory servers correct?To be able to use the LDAP login authority, each Secure Global Desktop server must be able to contact the LDAP directory servers at the specified URLs.

Use the Secure Global Desktop Login properties in Array Manager (or use the tarantella config view --login-ldap-url command) to check the URLs of the LDAP directory servers. Check:

  • Does each URL refer to a valid LDAP directory server?
  • Is each URL separated by a semicolon?
  • Does the URL use the fully qualified name of the LDAP directory server?
  • If the LDAP directory server listens on a non-standard port, is the port number the LDAP directory server listens on included in the URL?
  • Can all Secure Global Desktop servers in the array contact the LDAP directory server at this URL? Can you telnet from the Secure Global Desktop server to the LDAP directory server?
  • If you have used a search root to restrict the start point of the search of the LDAP database, check that the search root is correct.
  • Do the log files indicate that the connection to the LDAP directory server is timing out? Try increasing the LDAP timeouts.

For Sun™ ONE (formerly Netscape or iPlanet) Directory Server, you may also need to do some extra configuration to map ENS names to LDAP names correctly. For example, the LDAP directory server has a c=country,o=org,ou=office structure and is configured to only allow searches under o=org,c=country. If ENS has an o=org,ou=office structure, then Secure Global Desktop will attempt to search the LDAP database using o=org which will fail. To correct this:

  1. Use the tarantella stop command to stop the Secure Global Desktop server.
  2. Run the following command:

    tarantella config edit --com.sco.tta.server.login.ens.LdapProfileCandidateAuthority.properties-ensMapping search_root

    where, for example, search_root is c=country.
  3. Use the Secure Global Desktop Login properties in Array Manager (or use the tarantella config edit --login-ldap-url command) to change the search root for the LDAP server, for example ldap://server_URL/o=org,c=country.
  4. Use the tarantella start command to start the Secure Global Desktop server.
  5. Repeat these steps on each member of the array.
Is the LDAP directory server username and password correct?Some LDAP directory servers support anonymous logins, so you don't need to supply a username or password. Others, including Microsoft Active Directory, require the username and password of a user that has sufficient privileges to search the LDAP database.

Use the Secure Global Desktop Login properties in Array Manager (or use the tarantella passcache list --ldap username command to check the username and password.

If you are you using secure connections to the LDAP directory server, has this been configured correctly?

Check:

  • Does the URL of the LDAP directory server begin ldaps://?
  • Is the Sun Secure Global Desktop Security Pack installed on every server in the array?
  • Are Secure Global Desktop security services running?

    Use the tarantella status command to check.
  • Has the root certificate for each LDAP directory server been imported into the cacerts keystore on each Secure Global Desktop server?
  • If you are using Microsoft Active Directory, does each Secure Global Desktop server have a valid client certificate?

See Securing connections to LDAP directory servers for details.

Is Secure Global Desktop providing the right information for locating the user?When Secure Global Desktop searches an LDAP database for a user it uses the following attributes:
  • their full name (common name or cn);
  • their uid;
  • their e-mail address; or
  • their SAM account name.

If these attributes are not sufficient for identifying users, you can add extra attributes:

  1. Use the tarantella stop command to stop the Secure Global Desktop server.
  2. Run the following command:

    tarantella config edit --searchldapla.properties-searchAttributes-append attributes

    You can list more than one attribute. Each attribute must be separated by a space. The default attributes are cn uid mail sAMAccountName.
  3. Use the tarantella start command to start the Secure Global Desktop server.
  4. Repeat these steps on each member of the array.

Note These steps require caution as any mistakes can result in all users being unable to log in.

Have recent LDAP configuration changes taken effect?After making changes to your LDAP database, it is advisable to wait for a period of time for the changes to take effect.

Secure Global Desktop caches the data it collects from an LDAP directory server. If you find that Secure Global Desktop is not detecting changes, you can manually flush the cached data with the tarantella cache command.

Related topics