Document Actions
9.4. Authentication against LDAP servers
In this section we will describe how ThinLinc can authenticate against an LDAP server, for example OpenLDAP, SunOne Directory Server or Novell NDS/eDirectory.
In order to authenticate against an LDAP server, a ThinLinc server uses two pieces of software:
pam_ldap is used to check the password of the user. This is done by first looking up the DN (Distinguished Name, the unique path leading from the top of the tree down to a specific object) of the user with a LDAP search, and then by trying to bind to that DN using the password supplied by the user. If this succeeds, authentication is successful. pam_ldap is a module in PAM, Pluggable Authentication Modules for Linux, the authentication system used in modern Linux distributions. It is also available for Solaris.
nss_ldap is used to provide information about the user after login. This is information such as the uidNumber, the gidNumber, the real name of the user, the home directory and the login shell. This data is all data that is normally accessed through the NSS (Name Service Switch) subsystem of libc. nss_ldap is a library for NSS and it provides the ability to ask the LDAP server for this information.
Optionally, the ThinLinc server can also use nscd which is a caching daemon for name services. This is higly recommended to increase LDAP query performance and decrease the load on the LDAP server(s).
In order for the authentication modules on Linux to work with your LDAP server it needs the fields in the posixAccount and posixGroup objectclasses. Therefore, the LDAP server needs to have these in its schema. Each user that should be able to login to the ThinLinc server must have the following attributes defined:
cn is the "Common Name" of the user. This means different things in different LDAP setups and implementations. The most common interpretation seems to be that it should represent the real name of the user, for example "John Smith". Some LDAP implementations, namely Novell eDirectory use it to represent the username ('user1' or similar').
uid is the login name of the user, for example 'user1'.
uidNumber is the user id number, for example 501.
gidNumber is the group number of the user's primary group, for example 20501.
homeDirectory is the path to the user's unix homedirectory, for example "/home/user1".
loginShell is the user's login shell, for example "/bin/bash".
The ThinLinc server must be able to read the attributes listed in the previous section from the LDAP server. Depending on your network infrastructure, it may not be wise to expose all the information to everyone on the network. Using the access control features of the LDAP server, it's possible to control who should be able to read the attributes. Creating a special user that has the right ACL (Access Control List) entries set and binding as that user when reading the attributes is one way of solving the problem. This user's DN is then added to the LDAP configuration file /etc/ldap.conf on the ThinLinc server.
ThinLinc contains a special tool for helping with this and other needed tasks when interoperating with a Novell eDirectory server. See Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ” for documentation on this.
Before configuring pam_ldap and nss_ldap, we will verify LDAP connectivity from the ThinLinc server to the LDAP server using the standard command line tool for doing LDAP searches - ldapsearch.
First we will check to see that a ordinary ldap search works as it should. This verifies network connectivity between the ThinLinc server and the LDAP server using the LDAP protocol (port 389 on the server). If SSL support is enabled on the server, LDAP connectivity against port 686 (LDAP over ssl) will also be tested. In order to test LDAP connectivity we need to know some parameters that will also be needed later when configuring LDAP lookups on the ThinLinc server. The parameters needed are:
Hostname of the LDAP server. This is the hostname or IP address of the LDAP server that contains data about users and groups. It is possible to configure pam_ldap and nss_ldap to use one of several LDAP servers if several LDAP servers are available with the same data (using replication to keep the data correct on all servers). In the example below we will use ldap.example.com as hostname.
Search base on the LDAP server. This is where in the tree structure the search should begin. In the example below we will use the DN ou=People,dc=example,dc=com . All accounts and groups that should be available for the ThinLinc server must reside below this point in the tree.
DN and password of special user created in Section 9.4.2.2, “ Creating a special user for reading attributes from the server ”. This is of course only needed if your setup demands this security. In the example below we will use the DN cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com
Execute the following command and give the password of the special user when asked for:
[root@test root] ldapsearch -x -D 'cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com' -H ldap://ldap.example.com -W -b ou=People,dc=example,dc=com objectclass=posixAccount
This command will first ask you for the password of the DN cn=tl-posixsearch,ou=thinlinc,dc=example,dc=com and then show all users that have the objectclass posixAccount. As mentioned earlier in Section 9.4.2.1, “ Object classes on the server ”, all accounts on the LDAP server that should be able to login to the ThinLinc server must have the posixAccount objectclass. Example output of the command for a system with only two users:
# nastrand, People, example, com dn: uid=nastrand,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: account objectClass: top objectClass: posixAccount host: * uid: nastrand uidNumber: 6004 gidNumber: 501 givenName: Nisse sn: Astrand cn: Nisse Astrand homeDirectory: /home/nastrand loginShell: /bin/bash2 mail: nisse@example.com gecos: Nisse Astrand # adam, People, example, com dn: uid=adam,ou=People,dc=example,dc=com objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: account objectClass: top objectClass: posixAccount host: * uid: adam uidNumber: 6005 gidNumber: 501 givenName: Adam sn: Doe cn: Adam Doe homeDirectory: /home/adam loginShell: /bin/bash2 gecos: Adam Doe
If the command fails with ldap_bind: Invalid credentials , the password of the special user is incorrect. If the error message instead is "ldap_bind: Confidentiality required", the server is configured not to allow bind operations without transport security (SSL). See Section 9.4.3.3, “ Verifying LDAP over SSL connectivity ” to verify SSL connectivity and redo the test above but with a ldaps:// URI. If not all needed attributes (cn, uid, uidNumber, gidNumber, homeDirectory and loginShell) are displayed, there is probably a problem with the Access Control Lists for the special user.
In order for authentication to work, the ThinLinc server must be able to bind to the server using the DN and password of each user that should be able to login. If for example there is a user named adam with the DN uid=adam,ou=People,dc=example,dc=com , you should be able to execute the following command:
[root@test root] ldapsearch -x -D uid=adam,ou=People,dc=example,dc=com' -W -H ldap://ldap.example.com -b ou=People,dc=example,dc=com uid=adam
The result of this should be a printout of the user's object in the LDAP database. If it fails with ldap_bind: Invalid credentials something went wrong. This could be a access control problem - the user might not be allowed to bind from this machine. However, the most common reason is that the password is wrong. If the bind instead fails with ldap_bind: Confidentiality required this means the server is configured not to allow binds without transport security which means you must either use SSL to connect to the LDAP server or configure the LDAP server to allow bind operations without SSL. The former is better than the latter from a security point of view, since if bind operations are performed without SSL, passwords are transmitted in cleartext over the network. Refer to Section 9.4.3.3, “ Verifying LDAP over SSL connectivity ” for a description of how to verify LDAP over SSL connectivity.
To test LDAP over SSL connectivity, execute the following command:
[root@test root] ldapsearch -x -D uid=adam,ou=People,dc=example,dc=com' -W -H ldaps://ldap.example.com -b ou=People,dc=example,dc=com uid=adam
Notice that compared to earlier examples we've changed the URI to the LDAP server to use ldaps:// instead of ldap://. In order for the SSL handshake to work properly, you need to provide the same hostname as the hostname set in the LDAP certificate. If not, the error message will be ldap_bind: Can't contact LDAP server . In this case, the LDAP certificate has a cn (CommonName) of "ldap.example.com". To find out which hostname the certificate is created for, you can use a web browser and point it to (in this example) https://ldap.example.com:636. Find the CN in the certificate info provided. Use the hostname in the CN when connecting. If the hostname does not exist, which is the case with for example some Novell eDirectory installations, add the non-existing hostname to /etc/hosts together with the correct IP address. This should allow you to use the hostname from the CN when connecting over SSL.
Note
If you instead get the error message: ldap_bind: Can't contact LDAP server (81): additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed , your ldapsearch was compiled with settings that instruct it to always try to verify the server's certificate. Adding TLS_REQCERT never to the ldap.conf used by ldapsearch (for Red Hat-derived Linuxes, this file is located in /etc/openldap) will solve this problem.
Another possible response to the command above is "Segmentation fault". If this happens on a Red Hat Linux 9, the problem probably has to do with a bug in OpenLDAP on Red Hat Linux 9 in combination with a SSL Certificate that has an alternateName attribute, something often found in the certificates built during installation of Novell eDirectory servers. This bug is listed as bug number 85728 in the Red Hat bug tracking system (http://bugzilla.redhat.com). Unofficial OpenLDAP RPMs that solve the problem are available at http://nabber00.hopto.org/projects/openldap/. Unfortunately, a rebuild of nss_ldap is also needed after installation of the updated OpenLDAP RPMs.
Note
If you're LDAP server is running Novell eDirectory, make sure you read Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ”.
If your operating system provides configuration tools for setting up authentication against LDAP, it is strongly recommended that you use them. On Linux distributions related to RedHat such as Fedora Core and Red Hat Enterprise Linux, there is a command named system-config-authentication that can be used for this purpose. In SUSE-related Linux distributions, configuration can be done in YaST under Network Clients.
If your operating system lacks tools for configuring PAM and NSS to use LDAP, you need to manually configure the system.
The documentation for pam_ldap and nss_ldap contains information on how to configure the modules. In short, you need to configure PAM to use pam_ldap for authentication, and NSS to use nss_ldap to fetch user and group information. The pam_ldap/nss_ldap configuration file, /etc/ldap.conf also needs to be modified for the modules to contact the right server, use the right searchbase, etc.
auth required /lib/security/pam_env.so auth sufficient /lib/security/pam_unix.so likeauth nullok auth sufficient /lib/security/pam_ldap.so use_first_pass auth required /lib/security/pam_deny.so account required /lib/security/pam_unix.so account [default=bad success=ok authinfo_unavail=ignore user_unknown=ignore service_err=ignore system_err=ignore] /lib/security/pam_ldap.so password required /lib/security/pam_cracklib.so retry=3 type= password sufficient /lib/security/pam_unix.so nullok use_authtok md5 shadow password sufficient /lib/security/pam_ldap.so use_authtok password required /lib/security/pam_deny.so session required /lib/security/pam_limits.so session required /lib/security/pam_unix.so session optional /lib/security/pam_ldap.so
The important lines in /etc/nsswitch.conf after running authconfig are the following two:
passwd: files ldap group: files ldap
They will instruct the name service switch library to first try to find passwd and group information in the local files on the system, and then ask the LDAP server. This will make sure accounts stored locally (such as "root" will always be available, regardless of trouble with the LDAP server.
The file /etc/ldap.conf is read by both pam_ldap and nss_ldap to find out which LDAP server to connect to and how to bind to it. Even though authconfig tries to setup this file, if you're configuring a Red Hat Linux machine, we recommend that you edit this file manually (after running authconfig, where relevant). The following parameters are relevant in our case:
Note
The ThinLinc Novell Configurator (TLNC) contains a function for generating a ldap.conf with the correct settings already present, when integrating with Novell eDirectory servers. See Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ” for documentation on this.
host is the hostname of the LDAP server. If you are using SSL, please note that this hostname must be exactly the hostname listed in the SSL certificate's cn attribute.
ssl can be either "on", "no" or "start_tls". If your server supports LDAP over SSL, set this to "on". If your server supports the STARTTLS negotiation on the normal LDAP port, set this to "start_tls". See also the tls_checkpeer and tls_cacertfile parameters.
base is the search base - the location in the tree where searches for users and groups will begin.
scope is the search scope that should be used when searching for users and groups. The most common value here is sub which makes pam_ldap and nss_ldap search through the whole tree, beginning with the searchbase specified in base . Other possible values are base and one .
binddn is used if your setup requires a special user to bind to the LDAP server in order to read all required attributes. If this parameter is not set, anonymous bind is used.
bindpw is the password of the special user given in binddn
tls_cacertfile is the full path to a CA (Certificate Authority) certificate in PEM format, used to verify the certificate of the server to prevent Man In the Middle Attacks. This is used only when SSL is enabled and in combination with the tls_checkpeer parameter.
Note
For instructions on how to acquire the file needed from eDirectory, see Section 9.4.5.2, “ Acquiring the SSL CA Certificate from eDirectory ”. For other LDAP servers, refer to the server documentation and your certificate source.
tls_checkpeer is either yes or no. If set to yes, pam_ldap and nss_ldap will try to verify the identity of the server using the CA certificate given in the tls_cacertfile parameter. This of course only applies to SSL connections. If the identity can't be verified, the connection is aborted and no data is fetched. Verifying the peer is important since it protects against Man in the Middle Attacks.
start_tls is either yes or no. This parameter is used for servers that can handle the STARTTLS protocol which means a connection is opened using the normal LDAP port. When needed (for example when binding), the connection is converted to a SSL connection using the STARTTLS protocol. This functionality exists for example in OpenLDAP. When setting this to on, a ldap:// URI should be provided, not a ldaps:// URI.
It's often best to try first with a cleartext connection and then switch to ldaps without verification of the peer. If that succeeds, try ldaps with verification of the peer which is the most secure alternative. Some examples of minimal /etc/ldap.conf follow.
# No SSL, bind anonymously, begin search at dc=example,dc=com # Search the whole tree. uri ldap://ldap.example.com base dc=example,dc=com scope sub
# Use SSL, bind anonymously, begin search at ou=People,dc=example,dc=com # Search the whole tree uri ldaps://ldap.example.com base dc=example,dc=com scope sub
# Use SSL, bind using the dn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com # The dn to bind as has password 'foobar' # Search the whole tree # Begin search at dc=example,dc=com uri ldaps://ldap.example.com base dc=example,dc=com binddn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com bindpw foobar scope sub
# Use SSL, bind using the dn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com # The dn to bind as has password 'foobar' # Search the whole tree # Begin search at dc=example,dc=com # Verify the server with the CA certificate found in /etc/ssl/LDAPCACert.pem ldaps://ldap.example.com base dc=example,dc=com binddn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com bindpw foobar scope sub tls_checkpeer yes tls_cacertfile /etc/ssl/LDAPCACert.pem
# Use STARTTLS, bind using the dn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com # The dn to bind as has password 'foobar' # Search the whole tree # Begin search at dc=example,dc=com # Verify the server with the CA certificate found in /etc/ssl/LDAPCACert.pem uri ldap://ldap.example.com base dc=example,dc=com binddn cn=tl-posixsearcher,ou=thinlinc,dc=example,dc=com bindpw foobar scope sub ssl start_tls tls_cacertfile /etc/ssl/LDAPCACert.pem
Beginning with ThinLinc 1.4.1, a tool called ThinLinc Novell Configurator (TLNC) helps in the task of configuring ThinLinc to interoperate with a Novell eDirectory server. By using this tool, most of the tasks needed to configure the eDirectory and ThinLinc servers are automated.
The Novell Configurator is available as a module in the tladm Webmin module as documented in Chapter 16, Administration of ThinLinc With the tladm Webmin Module .
The ThinLinc Novell Configurator takes care of the following tasks:
Verifying existence of the posixAccount and posixGroup objectclasses
Some older versions of eDirectory lacks the relevant LDAP schema needed for proper operation with a ThinLinc server. If they don't exist, they can most often be added by installing the Native File Access for Unix product from Novell.
Check for and remove incorrect attribute mappings
Some older versions of eDirectory, among them eDirectory on Netware 6.0, has incorrect attribute mappings, mapping the NDS attribute UID to uidNumber, and GID to gidNumber. If they exist, eDirectory will not function properly with a ThinLinc server.
Create user object needed for search operations
The ThinLinc servers need to run LDAP search operations, and to be able to access the relevant attributes, they will bind as a special user object with DN and password. The TLNC can create this user, if it doesn't exist.
Give relevant permissions to the search user object
The user object used for search operations need to have access to a number of attributes. The TLNC can modify the ACL (Access Control Lists) of the eDirectory server to allow the search user object to read the relevant attributes. TLNC will also create the file /opt/thinlinc/etc/ldap.conf.template that can be used as a template for the configuration file needed for pam_ldap and nss_ldap.
Create user object needed for tl-nds-posixuser/tl-nds-posixgroup
In most cases where ThinLinc is integrated with a eDirectory server, the tl-nds-posixuser and tl-nds-posixgroup tools are used to add attributes to existing user and group objects in the directory to make them usable in the ThinLinc environment. The TLNC can create the user object needed by the tools to access eDirectory. It will also write information about this user to the relevant configuration file.
See Section 9.4.5.4, “ Using eDirectory User and Group Objects with ThinLinc ” for detailed information on tl-nds-posixuser and tl-nds-posixgroup.
Give relevant permissions to user object used by tl-nds-posixuser/tl-nds-posixgroup
The user object needed by tl-nds-posixuser and tl-nds-posixgroup need to have read and write access to a number of attributes. The TLNC can modify the ACL (Access Control Lists) of the eDirectory server to allow the user object to read the relevant attributes.
Create a default group to be used for ThinLinc Users
All users of a ThinLinc server need to have a default posixGroup assigned to their user objects. This group can be created by TLNC.
Create indices needed for proper performance
For proper performance, a few indices on LDAP attributes are needed. The Novell Configurator can create the needed indices.
TLNC is normally used only a few times - at installation, and when new eDirectory servers are added to the network. It can be run at any time to verify that all settings are correct. It is recommended to run TLNC after each upgrade of ThinLinc, so new recommended settings in eDirectory can be applied. Also run TLNC when new eDirectory servers are added, to correctly configure attribute mappings and indices.
Note
Before running TLNC, make sure there are no distribution-specific notes (see Section 3.6, “ Platform Specific Notes ”)covering the use of LDAP as user and group database. This is especially important for users of SUSE distributions, as detailed in Section 3.6.9, “ All SUSE Linux variants, including SLES and SLED ”.
To run TLNC, point your web browser to your ThinLinc server, port 10000, as documented in Chapter 16, Administration of ThinLinc With the tladm Webmin Module . Look for the Novell Box with the text Novell Configurator and click on it. You have now entered the TLNC
Start by entering values into the fields provided by the web page you just entered.
The eDirectory Server Hostname should be the fully qualified hostname of one of your eDirectory servers. It doesn't matter which server you choose, TLNC will read out the list of LDAP servers from the first server, and configure all of them.
Activate the Connect using SSL checkbutton to communicate encrypted with the eDirectory server.
Note
You must use the fully qualified hostname, i.e., a hostname on the form server.example.com in the eDirectory Server Hostname field, or SSL connections will fail.
Normally, you don't have to enter anything into the Search base field, since most eDirectory sites have a structure that enables TLNC to work well when searching from "". For sites that have several LDAP trees below the root, this setting may be of need.
Enter the DN of the administrative user into the Novell Admin User DN field. The DN should be entered in LDAP-form, with comma signs between the different parts of the DN, not periods.
Finally, enter the password of the administrative user into the Password of Admin User field.
Now press the Start Configuration button. The Novell Configurator will now communicate with your eDirectory server to see what needs to be done. It will then present a page where the you can see the status of the integration between the ThinLinc cluster and eDirectory. Areas where action is needed are marked with red.
Inspect the data presented on the page. In the areas where action is needed, TLNC will have activated the checkbuttons for the action that needs to be taken. Verify that all checked actions are things you want, and then press the Execute selected actions button. The TLNC will now communicate further with your eDirectory server to execute the actions you selected.
When all actions are executed, the same page will show up again, with the integration status. Verify that all went well, and proceed with the actions needed after running TLNC.
After running TLNC, a few things need to to be done manually
After creating the search user needed by pam_ldap and nss_ldap in LDAP, TLNC writes the file /opt/thinlinc/etc/ldap.conf.template with information about the DN and password of the created user. The file resides on the filesystem of the server that hosts the Webmin that was used to run TLNC.
This file can serve as a good starting-point for the contents of the real configuration file for pam_ldap and nss_ldap. The recommended procedure is to configure LDAP authentication using your distribution's tools, as described in Section 9.4.4, “ Configuring a ThinLinc Server to use LDAP Lookups for Users and Groups ” and then replace the ldap.conf generated with the one generated by TLNC.
Some versions of eDirectory fail to create an index on the Object Class attribute via LDAP. The reason for this is unknown, but if TLNC indicates that this is the case, the index needs to be configured by hand. See Section D.2, “ Increasing performance by adding an index on some Attributes. ” for documentation on how to do this manually.
Also, some versions of eDirectory fail to create the default POSIX group tl-users via LDAP. Reason for this is also unknown, but if TLNC indicates that this i the case, create the default group by hand by creating a group object with cn=tl-users in eDirectory, and assign a gidNumber of 1000 to it.
When an index is created in eDirectory via LDAP, for example by TLNC, they are not immediately built and used. Instead, eDirectory waits for a process called LIMBER to run. There are several ways to make this happen:
Wait
LIMBER is automatically run every three hours, or when another server starts a connectivity check. When this happens, all indexes pending creation will be built.
Trigger a run via DSTRACE/ndstrace
On Netware, load DSTRACE, and then run SET DSTRACE=*L. This will trigger LIMBER to run immediately.
If the eDirectory server runs on Linux, for example on Open Enterprise Server, a LIMBER run can be triggered by running ndstrace. Within ndstrace, write set dstrace=*l and press enter. This will also trigger a LIMBER run.
Trigger a run via iManager
Enter iManager, Agent Configuration/Agent triggers, and trigger a LIMBER run.
After triggering the LIMBER on all eDirectory servers, run TLNC again to see if the status of the defined indices have changed to online.
Run tl-nds-posixuser and tl-nds-posixgroup as described in Section 9.4.5.4, “ Using eDirectory User and Group Objects with ThinLinc ” to complement your existing users and groups with values that allow them to be used with the ThinLinc server(s).
In order to use SSL with server verification, the public part of the CA Certificate used to sign the certificate used for SSL on the LDAP server in eDirectory must be extracted. This is done using the following procedure:
Find out what SSL Certificate object is used for the LDAP server in question using eDirectory. Find the LDAP Server object, choose properties and in the "SSL Configuration" tab, look up the name of the SSL Certificate object in use.
Find the Certificate Object, choose properties and in the "Certificates" tab, choose "Trusted Root Certificate". Press the "Export" button. If available, choose "File in base64 format", if not, choose "File in binary DER format".
Choose an appropriate filename and press the Export button. A file with the certificate will now be written to your harddisk.
If you managed to export the file in base64 format (which is the same thing as PEM), use the file as tls_cacertfile. If the export was done to DER format, execute the following command to convert it to PEM:
[root@test root] openssl x509 -inform der -in <filename.der> -outform pem -out <filename.pem>Use the resulting file as tls_cacertfile
If there by some reason is no way to enable transport security (SSL) for bind operations (where passwords are transmitted), eDirectory must be configured to allow cleartext bind operations. This is done in the LDAP Group object under the General tab.
When integrating a Linux server into a Novell Netware network with eDirectory as source for authentication information for the first time, the users in the eDirectory most probably doesn't have the neccesary objectclasses and attributes defined. The users must have the objectclass posixAccount and the attributes (from posixAccount) uidNumber, gidNumber, loginShell, uid, and homeDirectory defined. Groups must have the objectclass posixGroup, and a gidNumber defined. Manually assigning the required values is not practical for installations with more than a few users.
In ThinLinc, this problem is solved using two programs, tl-nds-posixuser and tl-nds-posixgroup that searches the directory for users that don't have posixAccount among their objectclasses, and for groups that don't have posixGroup among their objectclasses. When it finds such a user or group, the values required are automatically assigned. Optionally, tl-nds-posixuser can be used to assign filesystem permissions to home directories exported from Novell Netware servers in Independent mode (see Section 10.2, “ Accessing Novell Netware File Servers ”).
The idea is that tl-nds-posixuser and tl-nds-posixgroup are first run during deployment of the ThinLinc installation. At this occasion, all existing users and groups are assigned the posixAccount attributes. After deployment, tl-nds-posixuser and tl-nds-posixgroup are meant to be run from cron at regular intervals, for example every 15 minutes. This way, new users and groups added to the directory will be assigned the relevant attributes automatically. This means that new users will be able to log in to the ThinLinc servers without the administrator having to take any action, after a short delay determined by the interval between each tl-nds-posixuser invocation.
tl-nds-posixuser and tl-nds-posixgroup both need a set of configuration parameters to be able to perform their dutys. Some of the parameters are common to the two programs, others are command-specific. Parameters common to the two are stored under the /utils/tl-nds/ hiveconf folder. Parameters specific to tl-nds-posixuser are stored under the /utils/tl-nds/posixuser/ hiveconf folder, and parameters specific to tl-nds-posixgroup are stored under the /utils/tl-nds/posixgroup/ hiveconf folder.
It is a good idea to run the ThinLinc Novell Configurator as documented in Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ”. This creates the user object needed by tl-nds-posixuser and tl-nds-posixgroup, and writes down information about the server, user DN and password to /utils/tl-nds/.
All parameters specified in hiveconf can be overridden using command line parameters.
Table 9.1. Configuration Parameters Common to Both tl-nds-posixuser and tl-nds-posixgroup
| Hiveconf parameter path | Command line parameter | Explanation |
|---|---|---|
| /utils/tl-nds/ldapuri | --ldapuri | The LDAP URI to connect to. This may be either a ldap:// or ldaps://, the latter for LDAP over SSL. |
| /utils/tl-nds/binddn | --binddn | The DN of the object that should be used to bind to the eDirectory. This DN must have permissions to change some attributes of all relevant users in the directory. See below for information on the exact procedure for creating this object. |
| /utils/tl-nds/bindpw | --bindpw | The password of the binddn. As noted above, the big advantage of using a hive for storing this is that the hive can be protected so that only a specific user may see the contents of the specific part of the hive. This way, the password is not exposed to all users on the host running tl-nds-posixpath. |
| /utils/tl-nds/searchbase | --searchbase | The point in the tree from where searches should begin when trying to find users and groups without posixAccount/posixGroup attributes set. |
| --verbose | Print out what happens during execution. | |
| --simulate | Don't do anything, just simulate what would have been done. Only useful in combination with --verbose |
Table 9.2. Configuration Parameters Specific to tl-nds-posixuser
| Hiveconf parameter path | Command line parameter | Explanation |
|---|---|---|
| /utils/tl-nds/posixuser/cachefilename | --cachefilename | The file name of the filename where the last used uidNumber is stored. The default is /var/opt/thinlinc/utils/tl-nds/posixuser/cache, and generally, there's no reason to change this value. This file is locked by a running tl-nds-posixuser process to protect against duplicate uidNumber values in LDAP. |
| /utils/tl-nds/posixuser/excluded_dns | --exclude_dn | A list of entries in the LDAP tree to ignore. If setting this in hiveconf, use a space-separated list of DNs. If setting on the command line, give several --exclude-dn with one DN after each. This setting can be used if there are places in your LDAP tree where for example invalid users are stored. The DN itself and all its leaves will be ignored. |
| /utils/tl-nds/posixuser/ldapfilter | --ldapfilter | The LDAP filter (as defined in RFC2254) to be used for finding the users that should be modified. Default value is (&(objectclass=inetOrgPerson)(!(objectclass=posixAccount))). |
| /utils/tl-nds/posixuser/groupgid | --groupgid | The group that should be set as primary group for all users. This should be the group id (A number) of the group, not the name. |
| /utils/tl-nds/posixuser/loginshell | --loginshell | Login shell set on users (in the loginShell) attribute. The default is /bin/bash |
| /utils/tl-nds/posixuser/update_script | --update_script | This parameter points to a executable script that is run just before the the user object in eDirectory is updated. The script gets three parameters - the username, the uidNumber and the gidNumber. Example usage of this script is creation of home directories or permission changes on existing home direcotires. |
| /utils/tl-nds/posixuser/uidfield | --uidfield | This parameter can be used to decide what attribute of a user object in LDAP should be used as username. The default value is 'cn' which is OK for most eDirectory installations. |
Table 9.3. Configuration Parameters Specific to tl-nds-posixgroup
| Hiveconf parameter path | Command line parameter | Explanation |
|---|---|---|
| /utils/tl-nds/posixgroup/cachefilename | --cachefilename | The file name of the filename where the last used gidNumber is stored. The default is /var/opt/thinlinc/utils/tl-nds/posixgroup/cache, and generally, there's no reason to change this value. This file is locked by a running tl-nds-posixgroup process to protect against duplicate gidNumber values in LDAP. |
| /utils/tl-nds/posixgroup/excluded_dns | --exclude_dn | A list of entries in the LDAP tree to ignore. If setting this in hiveconf, use a space-separated list of DNs. If setting on the command line, give several --exclude-dn with one DN after each. This setting can be used if there are places in your LDAP tree where for example invalid groups are stored. The DN itself and all its leaves will be ignored. |
| /utils/tl-nds/posixgroup/ldapfilter | --ldapfilter | The LDAP filter (as defined in RFC2254) to be used for finding the groups that should be modified. Default value is (&(objectclass=groupOfNames)(!(objectclass=posixGroup))). |
In most environments, forcing the users to regularly change password is a good security measure. This section will describe how to do this with ThinLinc in an eDirectory environment.
By activating forced password changes in ThinLinc, a graphical window will popup during the login sequence if the password expire date is near, or if the password has expired. There is also support for the "grace logins" functionality of eDirectory. The functionality can be summarized as below:
At login, tl-nds-check-expired sends a query to the LDAP server defined in /etc/ldap.conf and asks for information about password expiration.
If the number of days until the password expires is less than warning_days (see below), tl-nds-check-expired pops up a window and warns the user that the password is about to expire, and asks if the password should be changed now, or not.
If the password has expired, and "grace logins" are enabled, tl-nds-check-expired will pop up a window and tell the user how many logins he/she has left before the account will be locked. The user will again be asked if he/she wants to change the password.
If the number of "grace logins" left is less than 3, the pop up window will inform the user that the current login attempt is the last login attempt before the account will be locked, and ask if the user wants to change password.
If the account is locked, the ThinLinc client will say that the username or password was invalid. No session will be created.
Before trying to use tl-nds-check-expired, make sure that tl-passwd works, since it's used by tl-nds-check-expired. Pay special attention to the note about pam_password in the part about the tl-passwd in Chapter 13, Commands on the ThinLinc Server to make sure it's set to a value appropriate for the eDirectory environment.
tl-nds-check-expired has one parameter, /utils/tl-nds-check-expired/warning_days, in the file tl-nds-check-expired.hconf located among the rest of the ThinLinc configuration files on the server. The warning_days parameter decides how many days before the password for a specific user expires that tl-nds-check-expired begins to warn about the expire date. If set to 0, it will not warn until the password actually has expired.
Start by verifying that the search DN created and configured either via the ThinLinc Novell Configurator (TLNC) (see Section 9.4.5.1, “ Configuring eDirectory and ThinLinc with TLNC ”) or via the procedure described in Section D.5, “ Creating a DN for search operations ” has access to the attributes passwordExpirationTime, loginGraceRemaining, and loginGraceLimit. Then create a symbolic link in /opt/thinlinc/etc/xstartup.d pointing at the tl-nds-check-expired command:
ln -s /opt/thinlinc/bin/tl-nds-check-expired /opt/thinlinc/etc/xstartup.d
Now continue by testing to login as a user with a password that will soon expire, or a password that has expired and has grace login attempts left.
IMPORTANT: Due to the internal structure of ThinLinc, each time a user logs in, three separate authentications is performed. This means that if "grace logins" is enabled, each time a user logs in after the password expiration time, three grace login attempts are consumed. The number of grace logins available should be adjusted to compensate for this. Grace login attempts are also consumed at session startup, if any NCP resources are mounted.
Also, if a user uses both ThinLinc and fat workstations, another problem might occur. If the user has logged in to fat workstations and ignored the prompt for password change so that the number of grace logins left is 1 or 2, the user will be locked out the next time he/she tries to login to ThinLinc, since the ThinLinc session will only be setup halfway before the server refuses to authenticate the user.
Further problems occur if the ThinLinc cluster is combined with Application Servers, for example Windows Terminal Servers, to provide access to Windows Applications from ThinLinc. If "grace logins" are enabled, each time the user starts an application on the Application server, one grace login attempt will be consumed. One way of limiting this problem is to check if the password is about to expire in the Netware login script. This can be done using the PASSWORD_EXPIRES or by using third-party software such as passXchk available here. If the password change popup shouldn't occur if the Windows Terminal Server session is used to execute a single program, the program tl-is-appsession can be used to determine if the session is an application session or not, in the login script.
In environments where ThinLinc users should be able to access software running on Windows Terminal Servers, with ThinLinc Single Sign-On support, some extra configuration is needed if the Windows Terminal Servers are configured to logon to a Novell network. The extra configuration is needed to make sure the user can automatically login without having to manually enter the context where his/her user object is located.
To solve this problem, the username is sent with context. For example, for a user with cn=user5 located in the ou ou=school1,o=organization, the username will be sent as cn=user5.ou=school1.o=organization over RDP.
For this to work, the Novell client installed on the Windows Terminal Server must be recent enough to support receiving usernames with context over RDP. Version 4.91 SP4 is known to work.
Activate login to Windows Terminal Servers with context by adding the script tl-set-novelluser.sh to /opt/thinlinc/etc/xstartup.d:
ln -s /opt/thinlinc/bin/tl-set-novelluser.sh /opt/thinlinc/etc/xstartup.d
This will set an environment variable at session startup. This environment variable is then detected by tl-run-rdesktop when run.
Note
Please note that for login to work, users must exist not only in eDirectory, but also in the Windows environment, for example via an AD domain or by using Zenworks dynamic local users feature. Setup of this is however outside the scope of this document.
To get the best performance and cause the least load on your LDAP servers, the servers running ThinLinc need to be correctly configured.
Don't use the compat nss module
The /etc/nsswitch.conf written when using Yast on SUSE Linux to configure the system to use LDAP as user and group database is not optimized for performance. The following lines are cause bad performance:
passwd: compat group: compat passwd_compat: ldap group_compat: ldap
They should be replaced with the following lines:
passwd: files ldap group: files ldap
The reason for this is that the compat NSS module does not know how to make optimized LDAP queries for finding out which groups a user is member of. This can be a real performance killer.
Change /etc/nsswitch.conf after running Yast to configure LDAP.
Change the reload-count in nscd
The Name Service Caching Daemon (nscd) should be used when running LDAP as user/group database backend, but the configuration shipped with most distributions should be slightly adjusted. Set the reload-count parameter to 0 instead of the default (typically 5). This will decrease the number of LDAP queries as cache values will not be automatically reloaded until they are actually needed.
If needed, turn off group enumeration in nss_ldap
Under some circumstances, there may be a continous stream of LDAP queries sent to the LDAP server. This may happen if all the following are true:
The LDAP server contains a large amount of large groups.
The groups are of the groupOfNames objectclass, with all members listed using the DN of each user in the member attribute.
Some program run on the ThinLinc servers enumerate all groups, and this program is run often.
In this case, turn off group enumeration in the nss_ldap module. Unfortunately, the nss_ldap module available at the time of writing (version 254) does not have this option, but it is supposed to appear in a future version. Contact Cendio for an unofficial and unsupported patch if this behaviour is a problem on your system.
The reason behind this behaviour is that the enumeration of groups is not cached by nscd, and for groupOfNames groups, nss_ldap needs to map the DN of each user to the uid of the same user, which is done using an LDAP query.
Don't use ldap for NSS services where they are not needed
In many cases, the /etc/nsswitch.conf generated by the tools in your distribution will contain lines like:
services: files ldap
If your LDAP server contains information only about users and groups, remove use of the LDAP nss module from the services where they are not needed. This will decrease the number of LDAP queries sent to the LDAP server, but in most cases, it's not a very significant change.