Nslcd: Difference between revisions
Mmuehlfeld (talk | contribs) m (Mmuehlfeld moved page Local user management and authentication/nslcd to Nslcd: Rename page for better wiki struture) |
Mmuehlfeld (talk | contribs) m (Fix link) |
||
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. See [[ |
* Requires central storage of posix data (UID/GID, home directory, shell, etc.) in AD. See [[Administer_Unix_Attributes_in_Active_Directory_via_RFC2307|Administer Unix Attributes in Active Directory]]. |
||
* UIDs/GIDs are the same on every server, because of the central storage inside the directory. |
* UIDs/GIDs are the same on every server, because of the central storage inside the directory. |
Revision as of 21:01, 25 August 2015
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. See Administer Unix Attributes in Active Directory.
- 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 ~]$