Enabling LDAP user/group support (and authentication) in CentOS 6

4/5/2012

Again, nerdy stuff follows. Click away now if you were looking for pics of naked chicks or something.

Like a lot of people buying new hardware these days, we've recently started to look into migrating from CentOS 5 to CentOS 6. New hardware really is the only reason we're looking to migrate. The new hardware isn't supported by CentOS 5 kickstart and rolling your own updates into a new kickstart image can be a PITA. So why not upgrade to the new stuff? How hard can it be?

Kickstart and build stuff aside, the biggest problem we had with building some new CentOS 6 test boxes had to do with LDAP. You see, RedHat (and CentOS as a result) now supports 2 different providers for LDAP authentication. That's right, two. The bad thing is that it's 2 *new* providers. It's not the "new way" and the "old way." It's the "new way" and the "other new way." Those looking for seamless upgrades, keep wishing. Those who want to figure out how to do this easily, read on.

Basically, the old PADL NSS stuff is dead. They realized what a steaming pile of shit it was (memory leaks and all) and decided to scrap it. So they took a lot of the same stuff, renamed it, and pushed it out the door. I'll call this the "nslcd/openldap/legacy stuff." This is the closest method to "the old way" of doing things. But here's the catch, they fucked it all up. It's broken, convoluted, and not well documented. Worst, there's a lot of bad advice floating around the Internet in places like StackOverflow, ServerFault, ExpertsExchange, etc. Ignore it all. Just read this page. Ignore any piece of documentation that has you configuring nslcd.conf.

Fedora/RedHat realized how terrible PADL software is, so they wrote their own stuff; it's called SSSD. It's a terrible name, but overall it works pretty well. Use SSSD, don't use nslcd or anything that has pam_ldap or ldapd in the name. Just use SSSD. Update: This is the page that I used to learn about/configure sssd.

Here's the idiot's guide, super easy configuration:

yum install sssd
authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
Edit /etc/sssd/sssd.conf to look similar to this (I'm not going through each item -- RTFM instead):
[sssd]
config_file_version = 2
services = nss, pam
domains = default

[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd

[pam]

[domain/default]
ldap_tls_reqcert = never
auth_provider = ldap
ldap_schema = rfc2307bis
krb5_realm = EXAMPLE.COM
ldap_search_base = dc=domain,dc=com
ldap_group_member = uniquemember
id_provider = ldap
ldap_id_use_start_tls = False
chpass_provider = ldap
ldap_uri = ldaps://ldapserver1/,ldaps://ldapserver2/
ldap_chpass_uri = ldaps://your.ldapwrite.server/
krb5_kdcip = kerberos.example.com
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_access_filter = (&(object)(object))
Change the passwd, shadow, and group sections of /etc/nsswitch.conf to be "files sss". Do not use "files ldap". If you choose "files ldap", you'll tell the system to use the shitty PADL nslcd crap. Don't do that!
service sssd restart
After that, you should be able to type "id $user" and get something back from LDAP. You can make sure it's using the right LDAP servers by checking netstat (netstat -anp | grep sssd_be).
That's it. Don't mess with nslcd.conf. Don't install any nss-pam-ldapd packages or ldapd or anything. Just don't do it. Use the RedHat/Fedora stuff and tell PADL to kiss your ass.

Setting up autofs, sudo, etc to use LDAP is almost exactly like it was in CentOS 5. For example, you do want to add "ldap" to nsswitch.conf for autofs. My one recommendation would be to ditch the RH/CentOS sudo packages and install one of the RPMs from the sudo page. You'll be on the mainline versions *and* you'll avoid the stupid /etc/ldap.conf /etc/nslcd.conf crap that RedHat ran into in their version of sudo. In short, they updated the sudo package to look for configuration information in /etc/nslcd.conf, but the nslcd binary won't start if it sees directives it doesn't understand in its conf file. Basically, if you use the "old PADL LDAP nslcd" crappy way of LDAP auth, you can't use sudo. So don't use it. Stick with the basic SSSD stuff and get a sudo RPM from the sudo.ws page that looks for information in /etc/ldap.conf.

Oh and if you use nscd with sssd, be sure and set the passwd and group caches to "no". It's good to run nscd as a DNS host name cache, but its user and group caching conflicts with sssd's (which does its own).

Matt Bucknam

7/2/2012 05:56:02 am

Awesome write-up. Clear as a bell. Concise. Accurate. Saved me a ton of time.

diq link

7/2/2012 06:31:15 am

Matt, glad that it helped you out! That is the main reason why I post tech articles on here, to help out other ops people.

somecuriousOwl

7/2/2012 06:46:33 pm

Hi. I tried as it's written here. But get nothing. "id username" says that there is no such user.. but no errors.

7/2/2012 07:08:36 pm

it seems that sssd either not working or doesn't like my ldap server cause its logs also clean

7/3/2012 08:46:26 am

I'd double check your sssd.conf file and restart the sssd service. Also, the sssd config file shown here is from our use and needs to be customized to your environment. You can't just copy and paste the text. Our working example uses 389ds and the POSIX user/group schema from rfc2307bis.

7/3/2012 02:18:35 pm

Thank U) I've found the place where i'd made a mistake. It was ldap not ldaps in server url. Sorry for bothering U

7/4/2012 05:36:30 am

Glad you got it working! Keep in mind that ldap:// URI's mean that credentials are sent in the clear unless you enable StartTLS, too.

jt2ga56

7/18/2012 03:39:44 am

NSLCD and SSSD both work. I disagree with the author about sudo with nslcd. sudo will work fine with nslcd. It works fine with sssd also. There IS one reason to use nslcd over sssd, if it applies to you. If you have any applications that use the getent calls for user authentication, sssd will not work. Period. Red Hat decided that it knows better than any other software author, and dropped suooprt for getent shadow (from LDAP users) with sssd. A plus for sssd is that is supports credential caching, however this is only good is a user actually logged into the server while it was connected to LDAP, and we actually turn this caching setting off for security reasons. We are actually working with Red Hat to get some RADIUS support into sssd, and in a way that is not completely retarded.

Other than the author's bias against nss_ldap, anyone else have any reason to go with one other than the other? Both are actually pretty darn easy to get setup and working correctly. Neither have very good documentation.

7/18/2012 03:58:05 am

I believe that the author must be referring to using LDAP to specify sudo access. This was an issue with nslcd in late 2011, but it should have been in the updated nslcd before this article was written. Of course, this article doesn't actually mention using LDAP to control sudoers, and I don't believe the abive configuration will achieve that goal with sssd either.

Either way, I wanted to correct my previous statement about sudoers.

7/18/2012 04:08:50 am

sudo w/nslcd was broken when I wrote this post. At least it was in RH6.x at the time. Who knows if/when they took a fix from the 3rd party, but it wasn't working at the time and that's that.

The above configuration does work for authenticated sudo passwords via LDAP. The sudoers file is not controlled via LDAP in our case -- nor is it in any serious environment that I've worked at previously. The problem is that sudo processes the sudoers LDAP records in the order that they're received from the LDAP server. In case of more constraining records, the last record wins. Since some LDAP servers return records in an arbitrary order (AD and OpenLDAP do this -- 389DS always returns in order of creation), you can't really run any complex rulesets with sudoers from LDAP. The sudo guys mention this all over the place on sudo.ws and recommend against putting sudoers in LDAP for this reason.

sudoers file should be controlled via puppet, chef, or something else like that.

7/18/2012 04:17:36 am

Didn't know about the getent thing, but I don't think it applies to anything we're running since we haven't been bitten by it yet.

What are the security reasons for disabling LDAP credential caching? Microsoft has been doing this for over a decade without anyone saying it's a security hazard.

Also, I do have a bias against nss_ldap. One that's founded in fact, history, and battle scars. I've used that shitty software enough over 6 years to know I want nothing to do with it any more. nss_ldap on RH6 is *not* easy to get working. If it was, I wouldn't get over 200 pageviews/day to this blog entry.

Besides, I tend to bet with favorites. If Fedora/RH are throwing their hat into the ring, I'm going with them. Want to take odds on whether nslcd will be in RHEL7?

I'm not saying that sssd is a glorious piece of software development. It's not. It has bugs. I ran across one last week. In certain cases, su (with sssd enabled) will always return an exit code of 0, even if the process exited with something else. That said, it generally works. We're sticking with it (not that it really is any of your business).

Dan Paulus

8/2/2012 07:25:30 am

Spent the entire morning fighting nss, this post saved me from spending my afternoon doing the same.

Here is the link to the bug you guys were talking about: https://bugzilla.redhat.com/show_bug.cgi?id=760843. It is especially nice how the developer ignores every users suggestions and continues to make nss even more convoluted.

8/2/2012 08:56:10 am

Dan, glad I could help out! It really is amazing how convoluted they made things in RHEL 6 in regards to LDAP. It's also amazing how little they care about breaking their own distro's functionality...and not fixing it.

chris

8/19/2012 05:03:54 pm

There is one possible reason for using nslcd. I can use pam_filter to read the description attribute of a user in the ldap database. This can be used for machine based access control. Unless something like this is also possible with sssd (?).

8/20/2012 06:33:07 am

chris, check out the page I referenced in the blog post. It's http://docs.fedoraproject.org/en-US/Fedora/15/html/Deployment_Guide/chap-SSSD_User_Guide-Setting_Up_SSSD.html

Then check out section "8.2.3.2.3.2. The LDAP Access Provider"

It's what you're looking for.

8/20/2012 10:43:13 am

diq, you are right. With ldap_access_filter looking up values for the description attribute on the ldap server, machine based access control works "out of the box", so to speak. I now agree that sssd is the way to go. Thanks for the great post!

8/20/2012 03:02:21 pm

chris, glad it helped! RHEL/Fedora dropped the ball on properly documenting this. The amount of traffic to this post from search engines is pretty ridiculous... :/

Dan Lark

8/24/2012 12:28:45 am

Well this got me farther than anything I've found so far. Up to this point, I was unable to have it retrieve anything from LDAP. However, while I am able to get 'id $user' to work. I still cannot get it to work for authentication.

Micah Silverman link

8/24/2012 07:09:25 am

I am also having the same problem. Following the instructions in this post, I can confirm that it is using ldap with a command like: id.

However, I cannot login from the console or ssh as an ldap user.

9/2/2012 05:03:03 am

Be sure to check steps 2 and 4 again.

9/9/2012 11:28:00 pm

I did eventually get it going. Here's what I found:

1. SSSD absolutely needs either LDAPS or SASL logins configured and enabled for login to occur. The apparent logic is that it would compromise system security to allow passwords to be sent in the clear against LDAP. I kinda see the logic, but on a closed system, this might not be an issue.
2. It would appear that the 389 (Fedora) DS may trap authenticated bind attempts that do not use security. See above.
3. For getent to work properly, sssd.conf needs to have the following entry added: enumerate = true
Otherwise a command like "getent passwd" will only show entries from the local passwd file. Of note, querying something a specific user/group, ala "getent passwd username" will work as it makes an explicit lookup to LDAP.

I have now settled on FreeIPA, anyway. It takes care of a lot of heavy lifting and, for my use, is more of what I was looking for anyway.

YMMV

9/10/2012 07:36:11 am

Dan, yeah LDAPS, LDAP w/StartTLS, or SASL should always be used. I know it's frustrating because it's good to test without SSL at first to make sure you have everything setup right, then enable SSL last. The new RHEL/sssd stance makes it that much harder to get everything working.

Also, good find on the enumerate=true config option!

9/12/2012 04:29:02 am

One small caveat on the "enumerate" option. There is a known bug on this option. The problem is sssd_be will segfault with this option turned on and id_provider set to anything other than ldap (i.e. ipa, local, etc.). There is a fix present in the sssd source tree, but has not been implemented within the RHEL distribution. (I think this will likely be updated in 6.4, as this causes breakage in FreeIPA.) BTW, I have seen strange issues with enumerate in conjunction with sudo, sssd, and ldap. I suspect this bug is related, also.

I will also agree that sssd is a vast improvemnt over the kludgy PADL system. However, with such a major change, documentation, authconfig (and friends), etc. need to keep up - and it just ain't there. I would argue a poorly documented system is almost as bad as a system that is buggy.

Just my $0.02.

Philip

9/9/2012 10:42:54 pm

This worked very well for me. I fought with the CentOS 6.3 client for about 3 weeks and this got me going immediately. I am reluctant to de-install the distro sudo and download the sudo org rpms so I am going to struggle a little bit longer with the nlscd.conf. I have never run into an order problem with sudoers in ldap like someone suggested. I keep my sudoers rules pretty simple.

Micah silverman link

9/10/2012 12:15:53 am

The solution for me was to simply do this:

yum install nss-pam-ldap.x86_64
authconfig --enableldap --ldapserver="ldap://my.ldap.server/" --ldapbasedn="dc=my,dc=basedn" --disableldaptls --disableldapstarttls --updateall

I realize that this is the "old" way of doing things, but I am in an environment where the LDAP configuration is not in my control.

9/10/2012 07:37:19 am

Micah, you really should try to get either LDAPS or LDAP with StartTLS working. It's not the best idea to send credentials in the clear...

Artem

9/10/2012 01:56:46 am

You're a genius. Thanks man!

Chris

9/13/2012 04:50:42 am

Thanks for this. This helped out a lot. Everything I have been getting mixed signals about sssd on the internet... use it / don't use. Ually with no reason. Anyway, this write up helped me out a lot. Thanks for the enumerate option also. I wish Red Hat would document this precise. ;-)

Larry link

9/14/2012 03:39:46 am

After much struggle for a couple days, I finally stumbled on your site and worked like a charm. It cleared up quite a bit of the confusing information that is out there (outdated).

DanTMan63

6/4/2013 12:46:35 am

Did anyone ever answer this or did you find the answer?

msz59

9/29/2012 10:24:31 am

Sorry for slightly OT question but I run into this page googling for "LDAP authentication based on group" :)
I am using NIS in my LAN with one central server and many client machines (mainly CentOS 5/6) which allow users to login not only by user/passwd by also by netgroup membership. In NIS it is as simple as adding

+@netgroupname::::::
+@anothergroup::::::
+::::::/sbin/nologin

to /etc/passwd and "compat" to nsswitch.conf for passwd/group.
And, obviously, configuring netgroups on the NIS server.

Is anything like this possible with LDAP? If not, I would not consider switching.

Andrew

10/1/2012 12:51:43 am

I configured all as you wrote, and I able to write "id ldapuser" and get info from this command. Also I can from root switch to ldapuser by typing "su ldpauser" and act as ldapuser (it doesn't require password). But when I try to login as ldapuser from non-root user it require password, and when I type password I always get an error: "Incorrecr password" . Same error appears when I try to login using GUI. I think, probably when typing password it don't lookup LDAP. Where may be problem? Thanks.

10/22/2012 09:37:25 am

> .. Worst, there's a lot of bad advice floating around the Internet in places like StackOverflow, ServerFault, ...

Can you give us some links. Those sites are specifically setup so that incorrect/invalid information can be corrected or removed. Simply whining about it means that the pages stay broken. Next time please spend a couple minutes and make the Internet a better place.

10/22/2012 10:57:14 am

Chris, I normally try and be deferential when responding to obvious flame comments, but you sir, can shut the fuck up.

Yeah, I'm not taking a few making the Internet a better place by writing up this blog post? I could have easily just sat on this information or not taken the time to give back.

It's not my duty or obligation to correct bad information out there. Sure, those places have up/down voting systems, but there's no vetting of the people doing the up and down voting. Most of the people don't know what they're doing. Replies get buried down there. Even then, that's not the fucking point. The point is that I'm writing this blog to help people out and to use my company's product.

If you want to sit in your ivory tower and throw stones, be prepared for a few to be thrown back. It's not my job to improve another company's product. Do you yell at bloggers who write reviews outside of Yelp, too?

Aaron

10/27/2012 10:48:10 am

Awesome info! Thanks a ton for making the internet a better place, ;)! I was wondering if you could tell me what the authconfig line changes, as I am looking to automate this via puppet. I can manage the others as you list out the paths, thanks in advance!

10/29/2012 07:23:39 am

Aaron, glad you enjoyed it! For authconfig, we put all the right files in place with puppet (sssd.conf, nsswitch.conf). After that, we run "/usr/sbin/authconfig --enableldap --enableldapauth --enablelocauthorize --update"

Justin

6/10/2013 12:47:04 am

Aaron - I believe the only changes authconfig makes for this are the password-auth and system-auth files. New versions below.

/etc/pam.d/password-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so

/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 pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so

account required pam_unix.so
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so

password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so

session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so

jean

11/14/2012 03:09:43 am

1. yum install sssd -- works!
2. authconfig --enablesssd --enablesssdauth --enablelocauthorize --update
Starting sssd: [FAILED]
3. Edit /etc/sssd/sssd.conf -- no such file. it is empty at /etc/sssd.
please help.
Thanks!

Sum Yung Gai

4/4/2013 11:14:26 pm

I noticed that as well. You've got to write one, like the article shows. A little strange, given that Red Hat are trying to GUI-fy everything and make it easier for Microsoft sysadmins. Usually RH include an example config file, but it wasn't too hard to write one.

Chandan

11/16/2012 06:24:42 am

Thanks for the article it helped me a lot. However, still I have to manually create each user in the machine after creating it at the server. Is it way that once I create a user a the ldap server, rest things will get automatically created on the very first login of the use.

I specifieced that pam_mkhomedir module but its not helping.

Chandan link

11/21/2012 03:40:56 am

http://serverfault.com/questions/449614/ldap-389-auto-user-creation-at-the-client-machines

Todor

11/19/2012 11:24:42 pm

Thanks for the wonderful guide, it's the best one I have found.

Here are some tips and tricks, which may help other people:
In order for the PAM service to create your homedir upon login with the LDAP user, do the following:

1) edit /etc/pam.d/system-auth and before
session optional pam_keyinit.so revoke
add the following line
session required pam_mkhomedir.so umask=0022 skel=/etc/skel/
This will create the user homedir when you make "su - $user"
2) edit /etc/pam.d/sshd and add this line
session required pam_mkhomedir.so umask=0022 skel=/etc/skel/

at the end of the file. This will create the homedir when you log via SSH. Of course, sshd should be started with "UsePAM yes" option in sshd_config

Good luck!

diq

11/20/2012 09:14:08 am

Yeah I didn't really think about the homedir thing because we have all of our home directories mounted over NFS (via LDAP and automount).

11/20/2012 03:48:14 pm

Yes, NFS directories are about to be implemented in my case, but still not yet.

One more question: how do you manage the change of client passwords? In my case, I have Centos DS service and some servers, which are using it for LDAP user lookup. I was looking for a solution so the user to be able to change his password by himself when he wants and not writing me email "please change my password to XXX" I see some tips and tricks with NSS, but I want to avoid them and use the SSSD way, as you have written it.

11/21/2012 03:34:42 am

I believe that 389DS supports the pasword change exop, so you shouldn't have to do anything for sssd. The user should just change his password with the passwd command. In fact, I just changed mine. You're probably not running multi-master in 389DS so you should have config lines in sssd.conf like this:

chpass_provider = ldap
ldap_chpass_uri = ldaps://your.master.server/

11/21/2012 04:12:40 am

Yeah, I figured it out. Was trying to do it by the root user at first. Now I am looking into adding the list of co-workers with a script, something like http://linuxadministration.us/?p=140. Will try it tomorrow and let you know, if you are interested.

Regards,

bill

5/6/2013 09:32:30 am

As you said, the passwd works out of the box. However, local root user cannot use passwd to change an ldap user's password, with the following msgs:
/var/log/secure
pam_unix(passwd:chauthtok): user "moi" does not exist in /etc/passwd

/var/log/sssd/sssd_default.log
[sssd[be[LDAP]]] [sdap_pam_chpass_handler] (0x0100): Password reset by root is not supported.

Is this by design? How can we enable this? i.e. # passwd user

5/9/2013 02:01:53 am

bill, that's just not going to work. I'm sure it violates lots of security principles. For one, a local root user having the ability to change external user's passwords sounds like a terrible idea. If you need to reset LDAP passwords or change them, use a dedicated account in LDAP for that (or let users change their own).

mjr

7/23/2013 11:57:38 pm

Stephen Gallagher (one of the SSSD developers) wrote [1]:

"This is intentional behavior. SSSD is designed not to allow root on
the local system to change the passwords of the centrally-managed
users. The reason for this is that we would have to store credentials
for an LDAP administrator on the system somewhere in plaintext, which
would mean that a rogue admin or attacker could easily gain access to
an administrator account.

If you need to admin reset an LDAP user's password, it's much wiser to
use ldappasswd instead, because this will force you to present admin
credentials (of course, if you're storing the password in
/etc/openldap/ldap.conf, you're vulnerable to the same local attack
compromising your infrastructure)."

[1] https://lists.fedoraproject.org/pipermail/users/2013-July/438550.html

chandan

12/6/2012 09:48:16 am

You article is superb. It helped me to get sssd worked with password caching, but I am facing one strange issue. Getting the error "id: cannot find name for group ID" on login. The login is successful but everytime getting this error. Did a lot google but could not resolve the issue. I am using Centos 6.3 on server (389) and client.

[root@ldap02 ~]# ssh ttt@dsl
ttt@dsl's password:
Last login: Thu Dec 6 17:44:00 2012 from 10.2.3.69
id: cannot find name for group ID 6006
[ttt@dsl ~]$ id
uid=6006(ttt) gid=6006 groups=6006
[ttt@dsl ~]$

12/6/2012 07:36:18 pm

Have you checked /etc/nsswitch.conf? It should contain a line like this:

group: files sss

Also, the group should be presented in LDAP, try to look up for it:

ldapsearch -D "cn=Directory Manager" -LLLW -h LDAPSERVER -s sub -b "ou=Groups,dc=domain,dc=com" -S objectClass=posixgroup

12/7/2012 02:58:19 am

I think now I understand little bit. Thank you very much you guys, I have been struggling for this simple thing for so long as finally I got answer over here.

below article also helped me.

http://techhelplist.com/index.php/tech-tutorials/34-openldap/48-user-management-in-openldap

Here what I did. I created a separate Posix group (from 389 Admin console) and added the User with Posix account to this group. And now when I login it does not show the error any more. I now there is lot to learn for this complex ldap subject.

12/7/2012 01:04:13 am

Thanks for quick reply. Yes the nssswitch.conf is good. Also I do get output the ldapsearch you provided. http://pastebin.com/WPUd7TDU

Well none the users I have created belong to the ou=Groups. I have created every user in separate ou. Such as ou=Support Group, etc. So directory entry of the users are uid=ttt,ou=Support Group,dc=ma,dc=net. Please find the ldapsearch output for the same. http://pastebin.com/bEHrVGcw

Please suggest.

12/7/2012 01:56:48 am

I can not see any GID property of a group, are you sure there are any?

12/7/2012 02:09:23 am

Todor is right, you need to create these as POSIX groups with the appropriate objectClass for your LDAP server. That's the only way you will get GID and group membership to work.

12/7/2012 02:10:05 am

May be I have configure wrongly. But while creating user, I do specify Posix properties such as GID and UID.
uidNumber: 6004
gidNumber: 6004
So you mean these are not enough? Do I need to specify somewhere else too?

12/7/2012 02:22:19 am

Right, you've got half of the equation down. The other half is creating the groups that map to the correct GID. The POSIX user entry tells Linux what the UID and GID should be. The POSIX group entry tells Linux what the name of that GID is (and typically which users are groups but that depends on your LDAP implementation). You need the POSIX group objectClass with appropriate attributes to map back to the GID's you specified for your users. Hope this helps.

5/5/2013 07:35:21 am

Although I've setup a posixGroup and insert the user names in it (memberUid=user1) I'm still unable to resolve group names. The strange thing is that while my logs report that the search query is correct no result is returned. For instance the following returns netries=0:

conn=1163 op=9 SRCH base="dc=iit,dc=demokritos,dc=gr" scope=2 deref=0 filter="(&(gidNumber=2070)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))"

Using ldapsearch, this correctly returns a the group record.

Centos 6.4 and OpenLDAP

adfalafl link

1/25/2013 07:16:20 am

Yeah, a solution that worked for years fell on its face with CentOS 6.3. No amount wrangling of pam_ldap nss-pam-ldapd nss_ldap pam_crapdap would make this work. I throw sssd into the mix, still no joy but I get TLS errors in /var/log/messages:
"Could not start TLS encryption. TLS
error -8172:Peer's certificate issuer has been marked as not trusted by the user."
The key was to add "ldap_tls_reqcert = allow" to /etc/sssd/sssd.conf. This allows continuation in the event of my evil, bad, nasty, self-signed certificate.

thefold

1/28/2013 11:03:44 pm

Excellent guide! I'd got sssd setup on some RHEL workstations just fine but I was having some problems with a CentOS migration I'm carrying out. My problem was that I was still thinking LDAP/PAM had to be in the picture.

Needless to say after removing them, following your guide and then copying over a working configuration, all is now working!

shakour

1/29/2013 02:39:57 am

After I added the RHEL6.3 to the Ldap server as instructed above and automount a home from the sever (auto.home & auto.master configured), local users (such as admin) cannot access /home/admin?

Any idea?

linuxlife

2/14/2013 10:55:41 pm

Great work, keep it up.

aliaj00

2/19/2013 11:25:37 pm

thanks a lot. i also have the issue with the:
[root@###### openldap]# su ktimi
id: cannot find name for group ID 1004

i created the user with uid and gid on the posix account options when created the user.

how can i create the POSIX group objectClass to fix this issue.
Anyway does this id: cannot find name for group ID 1004 affect the user system or can be ignored????

thanks for the guide its the best one i found so far.

TIMI

3/21/2013 09:26:03 am

I had the same problem. You have to separately create posix group with Group ID and while creating the user you have to specify that UID. Best is read the Manager Entries section in the deployment guide of the RHDS documentation it has nice explanation with examples. If uid/gid is done properly then id <username> will return with all names and numbers without any error.

Dan

2/25/2013 12:50:28 pm

ldaps:// is deprecated in favor of Start TLS [RFC2830]

Rick

2/26/2013 08:20:24 pm

Thank you!! Worked flawlessy and finally, I can get rid of the tons of files of the old implementation that, frankly, just sucks, as you said!
Thumbs up for Red Hat and CentOS!!!!!

3/6/2013 07:51:10 pm

Diq, have you tried to use sudo without password for some users? I can not get rid of the password prompt:(

Thanks in advance.

3/7/2013 01:02:20 am

We use sudo -n frequently for certain tasks. Works just fine. That said, we do not store sudo values in LDAP. The users are in LDAP, but the sudo config is on disk. It's a bad idea to put sudo configs in LDAP (even with a DS like 389DS that always returns in order).

3/21/2013 03:01:29 am

I have installed 389 directory server on Centos 6 and sssd clients (thanks for your article). Now So far things look good, but one thing I don't understand, If I delete a user from a group, it takes almost 4-5 minutes to reflect the same on the clients (output of "id" command). I am wondering what could be the reason? (group add works immediately) Is there any timer/caching that could be changed. I tried restating sssd but that did not help either. For Linux user group I am using 389's static groups and adding users in a group by

dn: cn=mygroup,ou=Groups,dc=my,dc=net
changetype: modify
delete: uniqueMember
uniqueMember: uid=chandank,ou=People,dc=my,dc=net

am I doing anything that is not standard for Linux user/group management in LDAP?

3/21/2013 07:31:20 am

Answering my own question. That turn out to be controlled by the parameter "entry_cache_timeout" in sssd.conf file. Now after I set it to 5 (secocds) the changes are shown immediately as all cached entries are expired after 5 second and hence sssd will make fresh query to ldap for that.

3/21/2013 10:05:34 am

First and foremost - thank you for this! Taking a dive into LDAP and this is the most helpful thing i have found by far.

Having one issue that's got me stumped - I'm sure it's some sort of noobish mistake. Using 389ds and rhel 6.4 client, i have a user on 389ds and from the client i can "id" it, but cannot log into the client using it. I can "su" to it from root, but i i try su'ing from another user when i enter the password it returns "incorrect password" - i know it's right though!

3/21/2013 10:22:54 am

Justin, check steps 2-4 again. Also make sure you're using TLS or LDAP SSL. I don't think RHEL/CentOS 6 will let you login without a secure channel. You can use a self-signed cert if you want, just add 'ldap_tls_reqcert = never' to your sssd.conf.

justin

3/23/2013 07:08:47 am

Thank you very much! Worked like a charm after setting up SSL

Any suggested reading on CentOS LDAP authentication / best practices for a noob like me? Like you mentioned in your blog post, a lot of people out there seem to have different ideas as to what is the "right" way of doing things

Dexter

3/22/2013 12:58:58 am

This is a great post Diq. Thank you.

Johnny Wang link

3/24/2013 04:41:11 pm

Save me quite a lot time on this. It works on my case. Thx.
A quick question is:
With this setting, has it enabled any kind of encryption?
or we need to do some extra to enable StartTLS?

3/25/2013 04:34:39 am

Johnny, it depends on what you use for your ldap_uri values. My example setup uses LDAPS, so credentials are encrypted. If you use a LDAP URI there, you should check your value for ldap_tls_reqcert and make sure it's not "never".

toldav

4/11/2013 12:06:14 pm

I had been told that don't use /etc/openldap/ldap.conf on the client side if you are using SSSD only use sssd.conf can someone please explain what this two files are different from one to another. I'm using 389ds on rh.

4/11/2013 02:27:49 pm

well the /openldap files are used for openldap clients such as ldapsearch/modify etc and /etc/sssd/ files used for sssd. clients. So if you plan to use openldap-client packages then you must setup /etc/openldap files (hostname and cert files). usually the cert files are stored in single place and it is often /etc/openldap/cacert (for sssd and openldap clients as well). HTH

John

4/19/2013 12:01:37 am

Awesome post - clear concise and extremely helpful

Collins Richey

4/19/2013 06:58:29 am

We use ldap-only for id/auth. We don't use kerberos for anything. Is the krb5_kdclp in your example just required for completeness, or is actual kerberos required to do ldap authentication using sssd?

4/19/2013 07:41:01 am

No you don't need krb for sssd/ldap. However, if you are interested in that then use IPA otherwise managing LDAP+ KRB might be real pain.

4/20/2013 03:09:27 am

Collins, it's there just for completeness. You don't need it for LDAP. This isn't Windows. ;)

4/23/2013 12:59:25 am

It turns out that krb_kdcip is deprecated anyway. Now I'm having troubles getting authentication to work. In our previous configs without sssd (works flawlessly for rel 5 systems), we have the parameters

nss_base_passwd ou=People,dc=ourdc,dc=com
nss_base_shadow ou=People,dc=ourdc,dc=com
nss_base_group ou=Group,dc=ourdc,dc=com

After massive googling, I still can't find where/how to invoke this setup under sssd.

Also our type is rfc2307 rather than rfc2307bis

4/25/2013 02:54:25 am

Collins, make sure you're authenticating over LDAPS/StartTLS. RHEL/CentOS6 won't authenticate in the clear. That's a change over RHEL5.

darkfader link

4/22/2013 10:13:55 am

"sudo w/nslcd was broken when I wrote this post. At least it was in RH6.x at the time. Who knows if/when they took a fix from the 3rd party, but it wasn't working at the time and that's that." <<--- THAT! Many people don't realize that "fixed in git" means shit to the installed base because there's no little elves doing the QA for RHEL and patch rollout to your servers while you're sleeping.

4/25/2013 02:57:39 am

Yeah I'd stick with the sudo project's RPM's over RHEL's here. RHEL has become increasingly slow to patch broken functionality in things. Lately we've been rolling our own updates more and more. Honestly, we only run CentOS for server vendor firmware updates.

Jeremy Markel link

4/26/2013 07:38:28 am

Thanks for the info on this post. I used most of what you have here with some minor edits and got our RHEL6 servers authenticating quite nicely with our AD.
I found putting "debug_level = 9"into the sssd.conf was quite helpful for troubleshooting any issues that arose while getting this working.

4/30/2013 10:02:04 am

Great! As a former Windows admin, it's always good to see Linux interoperability.

Gerard

5/20/2013 10:24:28 am

Mate, this really helped me. Been battling with PAM LDAP for a long time. But sssd was so simple! Been using this simple formula. Really appreciate this.

I've just been from San Francisco on holiday. Nice place - like the sister city of Sydney Australia.

Thanks

Dannycorp

5/22/2013 12:52:50 am

This works flawlessly thank you.
I had been struggling with this for the last week trying to get my self signed certificate to work.

Thanks for this article.

Jarkko

6/12/2013 09:14:05 pm

Thank you very much for this article, I have successfully configured nearly all. I can login via ssh and from console as ldap user, but for some strange reason I can not get the graphical login to work? I use gdm and when I try to login it approves my login/password and tries to load the Desktop but it just returns back to login screen. /var/log/secure just stated that session was opened and on the next line session was closed. I can successfully login as a local user to Desktop and I can get the Desktop to work if I first login as ldap user via console and startx from there, no problem. Any help would be appriciated!

Amir Habibi link

6/17/2013 05:00:32 am

Great post. Up to the point and insightful. I was struggling with the point for a few hours before I hit your post and could configure my system in minutes. I also had special setup on the ldap server and these additional settings helped me to fix the issues:

ldap_default_bind_dn = <DN>
ldap_default_authtok_type = password
ldap_default_authtok = <DN Secrect>
ldap_user_shell = /bin/bash

Thanks again for sharing your experience.
Amir

SuperAdmin

6/19/2013 07:11:01 pm

Your R A Genius Man !!!

Faruk Okcu

6/23/2013 11:21:18 pm

Thanks for this precious info but it doesn't work for me. I want to auth users in zimbra ldap. (openldap). My client is a Centos 6.4. getent passwd lists only local file. nsswitch.conf and tls is configured. I can see sssd pings ldap server and receives a reply. It still remains a mystery If the query (id $user) is sent to ldap server or not, even with debug_level = 0xFFF0 Config files are as follows can sb give a hint where to start debugging?

# cat /etc/sssd/sssd.conf
[sssd]
config_file_version = 2
services = nss, pam
debug_level = 0xFFF0
enumerate = true
domains = mydomain
[nss]
filter_users = root,ldap,named,avahi,haldaemon,dbus,radiusd,news,nscd
[pam]
[domain/mydomain]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
ldap_id_use_start_tls = true
ldap_tls_reqcert = allow
ldap_uri = ldap://mail.mydomain.com
ldap_search_base = ou=people,dc=mydomain,dc=com
ldap_default_bind_dn = uid=zimbra,cn=admins,cn=zimbra
ldap_default_authtok_type = password
ldap_default_authtok = zimbraldappassword
ldap_user_object_class = zimbraAccount
ldap_access_filter = (&(objectclass=zimbraAccount))

Comments are closed.

Enabling LDAP user/group support (and authentication) in CentOS 6

Author

Archives

Categories