Skip past navigation linksSecure Global Desktop 4.40 Administration Guide > Users and Authentication > LDAP Users Cannot Log in to SGD

LDAP Users Cannot Log in to SGD

If you are using LDAP authentication and you find that LDAP users cannot log in to SGD, use the following checklist to identify the source of the problem. If this does not resolve the problem, use the following log filters:

Skip past command syntax or program codeserver/login/*:destination

The server/login/* filter allows you see what happens what LDAP users attempt to log in . The server/ldap/* filter allows you to see errors with connections to the LDAP directory.

Things to check Notes
Is LDAP authentication enabled? You cannot use an LDAP directory server with SGD unless the LDAP authentication is enabled.
Are the URLs of the LDAP directory servers correct? To be able to use LDAP authentication, each SGD server must be able to contact the LDAP directory servers at the specified URLs.

Check the URLs:

  • Does each URL refer to a valid LDAP directory server?
  • 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 SGD servers in the array contact the LDAP directory server at this URL? Can you telnet from the SGD server to the LDAP directory server?
  • If you have used a search root to restrict the start point of the search of the LDAP directory, 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 might also need to do some extra configuration to map names in the local repository to LDAP names correctly. For example, the LDAP directory has a c=country,o=org,ou=office structure and is configured to only allow searches under o=org,c=country. If the local repository has an o=org,ou=office structure, then SGD searches the LDAP directory using o=org and fails. You correct this as follows:

  1. Stop the SGD server.
  2. Run the following command:
    Skip past command syntax or program code$ tarantella config edit \ search_root
    where, for example, search_root is c=country.
  3. Use the SGD Administration Console or the command line to change the search root for the LDAP directory servers, for example ldap://server_URL/o=org,c=country.
  4. Start the SGD server.
  5. Repeat these steps on each SGD server in the array.
Is the LDAP directory server user name and password correct? Some LDAP directory servers support anonymous logins, so you do not need to supply a user name or password. Others, including Microsoft Active Directory, require the user name and password of a user that has sufficient privileges to search the LDAP directory.
If you are you using secure connections to the LDAP directory server, has this been configured correctly?


  • Does the URL of the LDAP directory server begin ldaps://?
  • Are SGD 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 SGD 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 SGD providing the right information for locating the user? When SGD searches an LDAP directory for a user it uses the following attributes:
  • cn
  • uid
  • mail
  • userPrincipalName
  • sAMAccountName

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

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

  1. Log in as superuser (root).
  2. Stop the SGD server.
  3. Use the following command:
    Skip past command syntax or program code# tarantella config edit \ attributes
    You can list more than one attribute. Each attribute must be separated by a space. The default attributes are cn, uid, mail, userPrincipalName, sAMAccountName.
  4. Start the SGD server.
  5. Repeat these steps on each SGD server in the array.
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.

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

Related Topics