In this section we will describe how ThinLinc can authenticate against a LDAP server, for example OpenLDAP, SunOne Directory Server or Novell NDS/eDirectory.
LDAP, an abbreviation for Lightweight Directory Access Protocol sprung out of the need for a directory system that could run on top of TCP/IP. The word Lightweight stands for not X.500-based, referring to the X.500 directory standard by the international telecommunications union (ITU). The problem with X.500 is that is was designed to run on top of the OSI suite of network protocols, which never became any success. There are also other problems with X.500, most of it relating to an overly complex specification, making implementation hard.
LDAP can be used for all kinds of data that fits in a hierarchical data model (that is, a tree of data). During the last few years, LDAP has increased in popularity and native LDAP support is now available in a wide range of applications. Examples of this is mail clients that use it for address book lookups, mail servers looking up mail routing information, and operating systems looking up usernames and other account-related data. The strength of LDAP is that a lot of the data needed for daily operation at a company, a school or some other kind of institution can be kept in one place - the LDAP database, and accessed by different kinds of applications. This makes it much easier to keep the data consistent and up to date.
In order to authenticate to 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 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.
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 GNU 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 can be used to increase performance if the LDAP server becomes a bottleneck.
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 ACLs 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.
Before configuring mod_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 mod_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.3.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=unixsearch,ou=Special Users,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=unixsearch,ou=Special Users,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=unixsearch,ou=Special Users,dc=example,dc=com and then show all users that have the objectclass posixAccount. As mentioned earlier in Section 9.4.3.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: [email protected] 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.4.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 users 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.4.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 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.
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 happends 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.
As mentioned earlier we use the pam_ldap module in the Pluggable Authentication Module system for password authentication, and the nss_ldap module for access to other data such as real name, uid, gid, homedirectory and shell. Both modules are contained in the nss_ldap package in Red Hat Linux.
Red Hat Linux provides a program for configuring how to do authentication. Execute the command authconfig and answer the questions. The result is that the files /etc/pam.d/system-auth, a /etc/ldap.conf and a /etc/nsswitch.conf are adapted for use with LDAP. An example /etc/pam.d/system-auth:
#%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. 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.
On other distributions, the authconfig command is not available. Either use your distributions tool to do the same thing, or edit the PAM configuration files by hand. See Section 9.1.1, “ Configuration files for PAM ” for information on what files should be edited. Don't forget to edit /etc/nsswitch.conf as well.
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:
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 certificates 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 mod_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.
For instructions on how to acquire the file needed from eDirectory, see Section 9.4.6.4, “ 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), a 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 follows.
# No SSL, bind anonymously, begin search at dc=example,dc=com # Search the whole tree. host ldap.example.com ssl no base dc=example,dc=com scope sub
# Use SSL, bind anonymously, begin search at ou=People,dc=example,dc=com # Search the whole tree host ldap.example.com ssl on base dc=example,dc=com scope sub
# Use SSL, bind using the dn cn=unixsearch,ou=Special Users,dc=example,dc=com # The dn to bind as has password 'foobar' # Search the whole tree # Begin search at dc=example,dc=com host ldap.example.com ssl on base dc=example,dc=com binddn cn=unixsearch,ou=Special Users,dc=example,dc=com bindpw foobar scope sub
# Use SSL, bind using the dn cn=unixsearch,ou=Special Users,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 host ldap.example.com ssl on base dc=example,dc=com binddn cn=unixsearch,ou=Special Users,dc=example,dc=com bindpw foobar scope sub tls_checkpeer yes tls_cacertfile /etc/ssl/LDAPCACert.pem
# Use STARTTLS, bind using the dn cn=unixsearch,ou=Special Users,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 host ldap.example.com base dc=example,dc=com binddn cn=unixsearch,ou=Special Users,dc=example,dc=com bindpw foobar scope sub ssl start_tls tls_cacertfile /etc/ssl/LDAPCACert.pem
In order for pam_ldap and nss_ldap to work, the NDS must have schema extensions for posixAccount and posixGroup. This means the user objects will have the following attributes:
The extensions will be added to NDS if Novell Native File Access for Unix is installed. During installation of this the command schinst is run to extend the schemas with posixAccount and posixGroup. You may have to run schinst manually later, for example after applying a Novell service pack. If Novell Native File Access for Unix is not available for your Novell platform (it's available for Netware 6.0 and above), extending the schema by hand should work although this is an untested configuration.
In a standard eDirectory installation, there is no index on the Object Class attribute, nor on the uidNumber or gidNumber attributes. Since pam_ldap and nss_ldap use LDAP queries that include the objectclass, uidNumber and gidNumber attributes, performance can often be increased by adding an index for these specific attributes. This has to be done on all servers that bear data needed for authentication.
We will give an example on how to add an index on "Object Class":
Find the server object for the server where the index is to be added. That is, find the Netware server object, not the LDAP server object.
Select properties, and choose the index tab.
Press the Add button, set Index Name to "objectclass". Choose "Object Class" in the list of Attributes.
The list of Attributes has a peculiar sorting order. All attributes that has names that start with a capital are ordered before the ones that doesn't.
Set the Rule to "Value".
Press OK.
Press Apply. That will create the index, a background process that may take a few minutes on a very large directory.
Repeat the procedures above for all servers that have replicas with the relevant information.
Repeat the steps above for the uidNumber and gidNumber attributes, adjusting parameters as needed.
After extending the schema, two attribute mappings must be removed for proper operations. If they are not removed, neither uidNumber nor gidNumber will work as needed.
Attribute mappings are used to map LDAP attribute names to NDS attribute names as a compatibility feature of Novell NDS. Since NDS has been around for a longer time than the LDAP specification, a lot of software exists that use the NDS names of object classes and attributes.
In order for LDAP authentication to work, the mapping from uidNumber to UID as well as the one from gidNumber to GID must be removed.
To remove the mappings you right click on the LDAP group entry at root level of your tree and select . Under the Attribute map tab can you find uidNumber and gidNumber , delete them.
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 Novells name for what the rest of the world calls 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.
In most environments, it's not a good idea to setup eDirectory so that anyone can read the attributes needed by LDAP Authentication (uid, uidNumber, gidNumber, homeDirectory and loginShell). Depending on the network setup, the information may be more or less sensitive. To prevent this, a special user is created in the database, and all search operations from the ThinLinc servers are made after binding as this user. This way, the amount of information that can be extracted by an anonymous user is limited. However, all users on the ThinLinc servers can read the password of this user, so the protection is limited. The user must have access to the mentioned attributes. In this section, we will describe how to create this user and setup the access control.
Begin by creating a user in eDirectory at an appropriate place in the tree. This user is a so-called application DN, so if your tree already has a place for similar users, place the user there. In our example, the DN of the user will be cn=unixsearch,ou=Special Users,o=example. This DN will be used as binddn in /etc/ldap.conf on the ThinLinc server.
Set a password for the user using the normal procedure (choose properties on the object, set the password under the Restrictions tab). Do not use a password that is used for anything else. This password will be used as bindpw in /etc/ldap.conf on the ThinLinc server and will be readable by all users on the ThinLinc server.
Now add the user just created as a trustee on a appropriate object in the tree. This object should be above all users that should be able to login to the ThinLinc server(s). For example, if all users reside under ou=People,o=example, add the user as a trustee on the ou=People,o=example object. Adding the trustee is done using the following procedure:
Right-click the object where the trustee should be added. Select "Trustees of this object..."
Press "Add Trustee..." in the dialog that appears and select the user we just created (cn=unixsearch,ou=Special Users,o=example in our example).
Select the user just added and press "Assigned Rights". For each of the attributes CN, gidNumber, homeDirectory, loginShell, uidNumber, Member, and uniqueID do:
Press the "Add Property..." button.
Locate the attribute in question and select it. You will have to press the "Show all properties" checkbox to see all required attributes. Also note that the sorting order in the dialog is a bit peculiar - attributes that begin with small case are sorted after all attributes that begin with uppercase. The easiest way to find attributes is probably to type their name, since the dialog then will find them for you.
After selecting the attribute, return to the "Rights assigned to" dialog box by pressing OK, and check the "inheritable" checkbox for the newly added attribute.
Repeat the procedure for [Entry Rights] which is not a normal LDAP attribute but a special keyword. Without browse rights on entries, the user will not be able to see any objects at all which is the first step in reading the information in them.
If tl-nds-mountpath (described in Section 11.2.3.3.2.2, “ Homedirectories spread among several servers and/or mountpoints ” is to be used, read access must also be enabled for the ndsHomeDirectory attribute.
Close all dialogs by pressing "OK". Your unixsearch user should now be able to search the directory and retrieve all relevant attributes. Test this by executing the following command:
[root@test root]
ldapsearch -x -D \
cn=unixsearch,ou=Special Users,o=example' -W -H \
ldaps://ldap.example.com -b \
ou=People,o=exampleThe output should contain CN, gidNumber, homeDirectory, loginShell, uidNumber, and uid. Also, if you add this users dn and password to /etc/ldap.conf on the ldap server, all users should be present in the output of getent passwd.
An alternative way of assigning the ACLs required is to add the following LDIF to the toplevel object (ou=People,o=example in our example) using ldapmodify or a similar tool:
ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#CN ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#UID ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#gidNumber ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#homeDirectory ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#loginShell ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#uidNumber ACL: 3#subtree#cn=unixsearch,ou=Special Users,o=example#member ACL: 1#subtree#cn=unixsearch,ou=Special Users,o=example#[Entry Rights]
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. Manually assigning the required values is not practical for installations with more than a few users.
In ThinLinc, this problem is solved using a program called tl-nds-posixuser that searches the directory for users that don't have posixAccount among their objectclasses. When it finds such an user, 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 11.2, “ Accessing Novell Netware File Servers ”).
The thought is that tl-nds-posixuser is first run during deployment of the ThinLinc installation. At this occasion, all existing users are assigned the posixAccount attributes. After deployment, tl-nds-posixuser is meant to be run from cron at regular intervals, for example every 15 minutes. This way, new users added to the directory will get posixAccount attributes and will be able to login to the ThinLinc servers after an initial delay determined by the interval between each tl-nds-posixuser invocation.
tl-nds-posixuser needs a few configuration parameters in order to run. The configuration parameters can either be stored in hiveconf under /tools/tl-nds-posixuser or be given as command line parameters. The former is convenient for automated invocations from cron and is also a matter of security - it's not a good idea to use command line arguments to provide passwords, since command line arguments are visible to all users. A list of the available parameters follow:
Table 9.1. Configuration parameters for tl-nds-posixuser
| Hiveconf parameter path | Command line parameter | Explanation |
|---|---|---|
| /utils/tl-nds-posixuser/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-posixuser/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-posixuser/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-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/searchbase | --searchbase | The point in the tree from where searches should begin when trying to find users without posixAccount attributes set. |
| /utils/tl-nds-posixuser/exclude_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/chown_homedir | --chown_homedir | If set to true in hiveconf or simply given as an argument on the command line, tl-nds-posixuser will set permissions on the home directories of each user that it sets posixAccount attributes for. Note that tl-nds-posixuser must run as root in order for this to work, something that is not neccesary otherwise. |
| /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 NDS installations. |
| --verbose | Print out what happends during execution. | |
| --simulate | Don't do anything, just simulate what would have been done. Only useful in combination with --verbose |
In order to function properly, tl-nds-posixuser needs to bind to eDirectory as a user that has appropriate permissions. Specifically, the user needs to write the attributes uidNumber, gidNumber, loginShell, uniqueID, and homeDirectory. Since an objectclass is also added, the user also needs write access to the objectclass attribute. It must also be able to read the cn attribute, and needs browse permissions on [Entry Rights] in order to find the users at all.
Follow the instructions in Section 9.4.6.6, “ Creating a DN for search operations ” but use another username. On the container that is above all users, set "write" permission on uidNumber, gidNumber, loginShell, uniqueID, objectclass and homeDirectory. Set read permission on the cn attribute and browse on [Entry Rights]. The raw ACL list for this looks like follows (given a DN of cn=posixaccount_updater,ou=Special Users,o=example):
ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#objectClass ACL: 1#subtree#cn=posixaccount_updater,ou=Special Users,o=example#[Entry Rights] ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#loginShell ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#uidNumber ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#gidNumber ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#homeDirectory ACL: 7#subtree#cn=posixaccount_updater,ou=Special Users,o=example#uid ACL: 3#subtree#cn=posixaccount_updater,ou=Special Users,o=example#cn
For installations not running eDirectory with its administration tool ConsoleOne, there are a few options for administrating a LDAP directory. We'll briefly describe some of them here.
The most basic tools available are ldapsearch, ldapmodify and friends from the openldap-clients package. These are lowlevel tools that present information in textform. They are suitable for advanced users and for scripting and batch processing of large datasets.
gq is a graphical LDAP editor. It's not primarily a user management tool but instead just an LDAP editor with a graphical frontend, allowing searching and browsing in a LDAP directory. You can also edit and add objects, but it's mostly useful for small corrections.
Directory Administrator is a user and group management tool available from http://diradmin.open-it.org/. It provides an easy interface to user administration. Further, we will write DA instead of Directory Administrator. DA currently only handles flat organization of users, but according to project roadmap it will handle hierarchical directory setups in the future.
After installation you need to configure DA with connection settings for your directory. DA handles multiple Connection profiles, which is a named setting. An example profile has the following values:
Profile name : example
Server address : ldap.example.com
Search root : dc=example,dc=com
DN/User ID : cn=admin,dc=example,dc=com
Password : **********
This tells DA that it should connect to the host ldap.example.com , as the user cn=admin,dc=example,dc=com (a user named Manager, organized directly under the tree root dc=example,dc=com ), with a password. The search root tells DA which part of the tree to search under. You should set this to the node under which you store users to prevent DA to search your whole tree. When the above is configured you can press the button for a sanity check.
Now you should be able to press the button in the main window. When pressed, DA will try to connect to your LDAP server. If connection is successful (no error message), then the and buttons should be enabled. Before adding any users you should add at least one group since you need to enter a group when adding a user.
To add a group you press the button to launch the New group wizard. After the initial (and somewhat annoying) welcome message you will get a Group information form. Here you enter the LDAP organizational unit to which the user should be added. This can for example be ou=users,dc=example,dc=com , depending on your LDAP tree organization. Enter a group name in the Group name field. If you already have users, you can add them to the list at the bottom of the form. Press and you're finished.
To add a user you press the button to launch the New user wizard. After the initial welcome message you will get an Essential information form. Here you enter the LDAP organizational unit to which the user should be added, as you did when you added a group. You should also enter Given name, Last name and if you want another than the generated, change the UNIX user ID. On the next page you enter and confirm the password. If you don't mark the Grant access to all computers you need to fill in a list of computer names that the user should be able to connect to. The Extended information page is optional and self explanatory. Enter an e-mail address at the E-mail information page if needed. On the UNIX account information you enter select which group the user should have as primary group. Check that the calculated home directory is correct and that the Login shell is correct. On the Samba account information page you get more fields if you check the This user participates in a Samba domain checkbox. If checked you can enter information related to SMB/CIFS. The Security policies form gives you the possibility to set password lifetime and force password changes. This is the last form, after you press and your user should show up in the main window.
To edit an existing user or group you simply double-click on its icon. A tabbed dialog will be displayed with the same forms as during the creation steps.
For most sites that plan to introduce a LDAP directory as the central storage of information, some custom programming is needed for some tasks, such as automating imports of data from other sources. LDAP modules exists for a variety of programming languages, including C, C++, Python, Perl and PHP.