Difference between revisions of "Nslcd"

(Added link to 'Using RFC2307 on a Samba DC' documentation.)
m (Installation)
Line 21: Line 21:
 
= Installation =
 
= Installation =
  
Most distributions ship nss-pam-ldapd, which contains nslcd, in their default installation. If you intent do use Kerberos, you additionally require to install Cyrus SASL with GSSAPI support. Depending on the version of nlscd you use, not all required Kerberos features may be supported. See the manpage of nslcd.conf for the supported options.
+
Most distributions ship nss-pam-ldapd, which contains nslcd, in their default installation. If you intend to use Kerberos, you are additionally required to install Cyrus SASL with GSSAPI support. Depending on the version of nlscd you use, not all required Kerberos features may be supported. See the manpage of nslcd.conf for the supported options.
 
 
If you want to authenticate local *nix services on your server against AD, additionaly you require <tt>pam_ldap</tt>.
 
 
 
 
 
 
 
  
 +
If you want to authenticate local *nix services on your server against AD, you additionally require <tt>pam_ldap</tt>.
  
 
= Configuring nslcd =
 
= Configuring nslcd =

Revision as of 16:31, 19 November 2014

Advantages and disadvantages of nslcd

Because people may find that some of the disadvantages are advantages or vice versa in their environment, we won't classify here.

  • Fast and easy to configure.
  • UIDs/GIDs are the same on every server, because of the central storage inside the directory.
  • Doesn't require the machine to be joined to the domain. Only a LDAP and Kerberos (if used) connection is used.
  • Requires nslcd, Cyrus SASL GSSAPI and pam_ldap installed on your system.
  • Resolving of nested groups is supported in nslcd 0.9.0 and later (nss_nested_groups yes).



Installation

Most distributions ship nss-pam-ldapd, which contains nslcd, in their default installation. If you intend to use Kerberos, you are additionally required to install Cyrus SASL with GSSAPI support. Depending on the version of nlscd you use, not all required Kerberos features may be supported. See the manpage of nslcd.conf for the supported options.

If you want to authenticate local *nix services on your server against AD, you additionally require pam_ldap.

Configuring nslcd

Method 1: Connecting to AD via Bind DN and password

The following basic example of an nslcd.conf let the daemon retrieve it's information by binding via an AD account. Connections with this setup will be unencrypted, except you have setup LDAP over SSL on your DC and change the following example nslcd.conf accordingly!

  • Create a new user account in your AD, nslcd will use to bind via LDAP and retrieve it's information. Make sure, that you configure this account with the „Password never expires“ option! It's recommented also to set „User cannot change password“. Remember the DN (distinguished name) of the new account. The following example uses the DN „cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com“.
  • Currently not all required posix information could be retrieved via LDAP (Bug report #9788), because of incorrect directory ACLs. As a workaround, simply add the following to your smb.conf on the DC, nslcd is connecting to and restart Samba:
[global]
...
acl:search = no
  • Use the following content in your /etc/nslcd.conf:
# User/group with which the daemon should run (must be a local account!)
uid nslcd
gid ldap

# LDAP/AD server settings
uri ldap://127.0.0.1:389
base dc=SAMDOM,dc=example,dc=com

# Some settings for AD
pagesize 1000
referrals off

# Filters (only required if your accounts doesn't have objectClass=posixAccount
# and your groups haven't objectClass=posixGroup. This objectClasses won't be added
# by ADUC. So they won't be there automatically!)
filter  passwd  (objectClass=user)
filter  group   (objectClass=group)

# Attribut mappings (depending on your nslcd version, some might not be
# necessary or can cause errors and can/must be removed)
map     passwd  uid                sAMAccountName
map     passwd  homeDirectory      unixHomeDirectory
map     passwd  gecos              displayName
map     passwd  gidNumber          primaryGroupID
map     group   uniqueMember       member

# LDAP bind (Account in AD that is used from nslcd to bind to the directory)
binddn cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com
bindpw xxxxx
  • Append ldap to the passwd and group entry of your /etc/nsswitch.conf, to let the system query LDAP for these databases.
passwd:     files ldap
group:      files ldap
  • Start the nslcd daemon.
  • All domain accounts/groups are now available to the local system.


Method 2: Connecting to AD via Kerberos

The following basic example of an nslcd.conf let nslcd retrieve it's information by using Kerberos. The connection will be encrypted.

  • Create a new user account in your AD. Make sure, that you configure this account with the „Password never expires“ option! It's recommented also to set „User cannot change password“. If the machine is joined to the domain, you can skip this step and use the machine account instead, if you want. The following example uses the domain account „ldap-connect“.
  • Add a SPN (service principal name) to the account you've created. On your Samba host this can be done by the following command (replace „dc1.samdom.example.com“ with the name of the host you'll run nslcd on):
# samba-tool spn add nslcd/dc1.samdom.example.com ldap-connect
  • Extract the keytab for this account and make sure, it is readable only for the user nslcd runs under:
# samba-tool domain exportkeytab /etc/krb5.nslcd.keytab --principal=ldap-connect
# chown nslcd:root /etc/krb5.nslcd.keytab 
# chmod 600 /etc/krb5.nslcd.keytab
  • As Kerberos tickets have to be renewed before they expire, you have to take care of this job. k5start is a usefull tool for that. The following command starts k5start in background mode. The above created keytab is used and the owner of the the cache file will be the local account, nslcd uses to run (parameter „uid“ in nslcd.conf):
# k5start -f /etc/krb5.nslcd.keytab -U -o nslcd -K 360 -b -k /tmp/nslcd.tkt
Remember to start k5start on system startup. Otherwise the ticket won't be renewed after reboot!
  • Use the following content in your /etc/nslcd.conf:
# User/group with which the daemon should run (must be a local account!)
uid nslcd
gid ldap

# LDAP/AD server settings
uri ldap://127.0.0.1:389
base dc=SAMDOM,dc=example,dc=com

# Some settings for AD
pagesize 1000
referrals off

# Filters (only required if your accounts doesn't have objectClass=posixAccount
# and your groups haven't objectClass=posixGroup. This objectClasses won't be added
# by ADUC. So they won't be there automatically!)
filter  passwd  (objectClass=user)
filter  group   (objectClass=group)

# Attribut mappings (depending on your nslcd version, some might not be
# necessary or can cause errors and can/must be removed)
map     passwd  uid                sAMAccountName
map     passwd  homeDirectory      unixHomeDirectory
map     passwd  gecos              displayName
map     passwd  gidNumber          primaryGroupID
map     group   uniqueMember       member

# Kerberos
sasl_mech GSSAPI
sasl_realm SAMDOM.EXAMPLE.COM
krb5_ccname /tmp/nslcd.tkt
  • Append ldap to the passwd and group entry of your /etc/nsswitch.conf, to let the system query LDAP for these databases.
passwd:     files ldap
group:      files ldap
  • Start the nslcd daemon.
  • All domain accounts/groups are now available to the local system.


Testing

  • Test 1: Retrieving accounts via getent. This should show local and domain accounts with posix attributes. Please check that all fields contain the values set in AD (UID, primaryGroup, homeDirectory, shell).
# getent passwd
...
Administrator:*:10000:10513:Administrator:/home/Administrator:/bin/bash
demo1:*:10008:10513:demo1:/home/demo1:/bin/bash
  • Test 2: Retrieving groups via getent. This should show local and domain groups with posix attributes. Please check that the output contains all fields set in AD (GID, members).
# getent group
...
Domain Users:*:10513:
demo-group:*:10015:demo1
  • Test 3: Change owner/group of of a file to a domain user/group:
# touch /tmp/testfile
# chown Administrator:"Domain Users" /tmp/testfile
# ls -l /tmp/testfile 
-rw-r--r-- 1   Administrator   Domain Users   0   26. Aug 22:35 /tmp/testfile



Configuring PAM (pam_ldap)

Method 1: Connecting to AD via Bind DN and password

To authenticate local services (SSH, FTP, etc.) which uses PAM, you can setup pam_ldap to authenticate against AD via LDAP.

  • Edit /etc/pam_ldap.conf:
base dc=SAMDOM,dc=example,dc=com
binddn cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com
bindpw xxxxx
bind_policy soft
pam_login_attribute sAMAccountName
uri ldap://127.0.0.1:389:389/
ssl no
  • If your distribution is shipped with a tool for doing changes on PAM configurations, you should use them, instead of editing manually. E. g. SLES provides pam-config and Debian pam-auth-update for that.
  • Edit your PAM configuration file(s) corresponding to the services you want to hook up. The following is an example for a PAM configuration, that can be used e. g. for ssh (/etc/pam.d/sshd). But be carefull: Change take effect immediately!
#%PAM-1.0M-1.0
auth     required      pam_nologin.so
auth     sufficient    pam_ldap.so
auth     required      pam_unix.so      use_first_pass # set_secrpc

account  required      pam_unix.so

password required      pam_pwcheck.so
password required      pam_ldap.so      use_authtok
password required      pam_unix.so      use_first_pass use_authtok

session  required      pam_unix.so
session  required      pam_limits.so
session  required      pam_env.so


Testing

  • Test 1: Try accessing a service or log into a service, you have configured to use pam_ldap. Example for ssh:
# ssh demo1@DC1
demo1@dc1's password: 
Last login: Mon Aug 26 22:59:40 2013 from pc01.samdom.example.com
[demo1@DC1 ~]$