Nslcd: Difference between revisions

From SambaWiki
m (Added information since which version nslcd supports nested groups)
(Reworked HowTo and added Kerberos support for nslcd)
Line 1: Line 1:
= Advantages / Disadvantages =
= 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.''
''Because people may find that some of the disadvantages are advantages or vice versa in their environment, we won't classify here.''
Line 5: Line 5:
* Fast and easy to configure.
* Fast and easy to configure.


* Requires central storage of posix data (UID/GID, home directory, shell, etc.) in AD. Your domain have to be provisioned/upgraded with <tt>--use-rfc2307</tt> to store this data. Accounts/groups can be administrated e. g. via ADUC on Windows then.
* Requires central storage of posix data (UID/GID, home directory, shell, etc.) in AD. Your domain have to be provisioned/upgraded with <tt>--use-rfc2307</tt> to store this data.


* UIDs/GIDs are the same on every server.
* 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. A simple LDAP connection to the DC (389/tcp for LDAP or 646/tcp for LDAPs) is enough.
* Doesn't require the machine to be joined to the domain. Only a LDAP and Kerberos (if used) connection is used.


* Requires nslcd and pam_ldap to be installed on your system.
* Requires nslcd, Cyrus SASL GSSAPI and pam_ldap installed on your system.


* Resolving of nested groups is supported since nslcd 0.8.13 (<tt>nss_nested_groups yes</tt>).
* Resolving of nested groups is supported in nslcd 0.9.0 and later (<tt>nss_nested_groups yes</tt>).




Line 21: Line 21:
= Installation =
= Installation =


Most distributions already ship nslcd in their default installation. In RHEL6 the package is named <tt>nss-pam-ldapd</tt>.
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.


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, additionaly you require <tt>pam_ldap</tt>.
Line 31: Line 31:
= Configuring nslcd =
= Configuring nslcd =


== Method 1: Connecting to AD via Bind DN and password ==
The following basic example let nslcd retrieve it's information from AD through an separate account. nslcd is also capable to use Kerberos. This would not be part of this HowTo.


* Create a new user account in your AD, nslcd uses to bind via LDAP and retrieve it's information. Make sure, that you configure this account with the „password never expires“ option! Remember the DN (distinguished name) of the new user. The following example uses the DN „cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com“.
The following basic example of an <tt>nslcd.conf</tt> let the daemon retrieve it's information by binding via an AD account. Connections with this setup will be <u>unencrypted</u>, except you have setup [[Setup_LDAPS_on_a_DC|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 ([https://bugzilla.samba.org/show_bug.cgi?id=9788 Bug report #9788]), because of incorrect directory ACLs. As a workaround, simply add the following to your <tt>smb.conf</tt> on the DC, nslcd is connecting to and restart Samba:
* Currently not all required posix information could be retrieved via LDAP ([https://bugzilla.samba.org/show_bug.cgi?id=9788 Bug report #9788]), because of incorrect directory ACLs. As a workaround, simply add the following to your <tt>smb.conf</tt> on the DC, nslcd is connecting to and restart Samba:
Line 43: Line 45:
* Use the following content in your <tt>/etc/nslcd.conf</tt>:
* Use the following content in your <tt>/etc/nslcd.conf</tt>:


# User/group with which the daemon should run (must be a local account!)
#Mappings for Active Directory
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
pagesize 1000
referrals off
referrals off
# Filters (only required if your accounts doesn't have objectClass=posixAccount
# Passwd
# and your groups haven't objectClass=posixGroup. This objectClasses won't be added
filter passwd (&(objectClass=user)(!(objectClass=computer))(uidNumber=*))
# 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 uid sAMAccountName
map passwd homeDirectory unixHomeDirectory
map passwd homeDirectory unixHomeDirectory
map passwd gecos displayName
map passwd gecos displayName
map passwd gidNumber primaryGroupID
map passwd gidNumber primaryGroupID
# Groups
filter group (&(objectClass=group)(gidNumber=*))
map group uniqueMember member
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

* Start the nslcd daemon.

* Append <tt>ldap</tt> to the <tt>passwd</tt> and <tt>group</tt> entry of your <tt>/etc/nsswitch.conf</tt>, to let the system query LDAP for these databases.

passwd: files ldap
group: files ldap

* 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 <u>encrypted</u>.

* 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 [http://msdn.microsoft.com/en-us/library/windows/desktop/ms677949%28v=vs.85%29.aspx 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. <tt>k5start</tt> 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 <tt>nslcd.conf</tt>):

# 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 <tt>/etc/nslcd.conf</tt>:

# User/group with which the daemon should run (must be a local account!)
# User/group with which the daemon should run (must be a local account!)
uid nslcd
uid nslcd
gid ldap
gid ldap
# LDAP server settings
# LDAP/AD server settings
uri ldap://127.0.0.1:389/
uri ldap://127.0.0.1:389
base dc=SAMDOM,dc=example,dc=com
base dc=SAMDOM,dc=example,dc=com
# Some settings for AD
# Account in AD that is used from nslcd to bind to the directory
pagesize 1000
binddn cn=ldap-connect,cn=Users,dc=SAMDOM,dc=example,dc=com
referrals off
bindpw xxxxx
# 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


* Start the nslcd daemon.
* Start the nslcd daemon.


* Append <tt>ldap</tt> to the <tt>passwd</tt> and <tt>group</tt> entry of your <tt>/etc/nsswitch.conf</tt>, to let the system query LDAP for this this databases.
* Append <tt>ldap</tt> to the <tt>passwd</tt> and <tt>group</tt> entry of your <tt>/etc/nsswitch.conf</tt>, to let the system query LDAP for these databases.


passwd: files ldap
passwd: files ldap
group: files ldap
group: files ldap


* All accounts/groups are now available to the local system.
* All domain accounts/groups are now available to the local system.




Line 83: Line 154:
== Testing ==
== Testing ==


* Test 1: Retrieving accounts via <tt>getent</tt>. This should show local and domain accounts (which have the required posix attributes).
* Test 1: Retrieving accounts via <tt>getent</tt>. 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
# getent passwd
Line 90: Line 161:
demo1:*:10002:513:Demo User1:/home/demo1:/bin/false
demo1:*:10002:513:Demo User1:/home/demo1:/bin/false


* Test 2: Retrieving groups via <tt>getent</tt>. This should show local and domain groups (which have the required posix attributes).
* Test 2: Retrieving groups via <tt>getent</tt>. 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
# getent group
Line 108: Line 179:


= Configuring PAM (pam_ldap) =
= 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 <tt>pam_ldap</tt> to authenticate against AD via LDAP.
To authenticate local services (SSH, FTP, etc.) which uses PAM, you can setup <tt>pam_ldap</tt> to authenticate against AD via LDAP.

Revision as of 23:00, 28 August 2013

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.
  • Requires central storage of posix data (UID/GID, home directory, shell, etc.) in AD. Your domain have to be provisioned/upgraded with --use-rfc2307 to store this data.
  • 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 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.

If you want to authenticate local *nix services on your server against AD, additionaly you 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
  • Start the nslcd daemon.
  • 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
  • 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
  • Start the nslcd daemon.
  • 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
  • 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:513::/home/Administrator:/bin/bash
demo1:*:10002:513:Demo User1:/home/demo1:/bin/false
  • 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:*:10000:demo1
demo-group:*:10003: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
  • 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 ~]$