PDA

View Full Version : SLES 12 Configuring LDAP user authentication



smily_03
03-Dec-2015, 18:33
Kinda frustrated because this used to be so easy in SLE11...

Out of curiosity, how do I make it so that we can log into our new SLE12 box with our LDAP accounts?

So far, I've got this, from various posts on the forums, but it's not working...

https://forums.suse.com/showthread.php?5793-SLE-12-and-LDAP-Authentication
https://forums.suse.com/showthread.php?5698-SLES12-SSSD-Port-status-of-port-636-for-server-bomaster
https://forums.suse.com/showthread.php?6462-SLE-12-Ldap-Authentication-to-clustered-LDAP-Server&highlight=sssd+ldap
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Deployment_Guide/SSSD-Troubleshooting.html#idp17015328



edit /etc/nsswitch.conf, set:
passwd: compat sss
group: compat sss


edit /etc/sssd/sssd.conf, contents:
[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_user_object_class = posixAccount
debug_level = 20
access_provider = ldap
ldap_uri = ldap://ourldapserver.millikin.edu
ldap_search_base = ou=tech,o=mu
create_homedir = true

ldap_tls_cacert = /etc/sssd/certs/rootcert.pem
ldap_tls_cacertdir = /etc/sssd/certs
ldap_id_use_start_tls = true

execute the following from root's command line:
pam-config --add --mkhomedir


I've also tried it with an ldap server URL of ldaps://ourserver.millikin.edu:636, but it didn't make a difference. I also don't see any references to LDAP connections when I run "netstat -aln | grep tcp"

The thing that's making this more difficult is that nothing's getting logged to /var/log/sssd, no matter what value I put in the debug_level parameter. There aren't even any files that get created in there. I also tried using ndstrace on the box that this points to (eDirectory on an OES2 box) and it's not reporting any attempts from this host. Also, /var/log/messages says:

2015-12-03T11:18:59.407125-06:00 muwacmaster sshd[1296]: Invalid user myusername from 172.20.9.87
2015-12-03T11:18:59.411807-06:00 muwacmaster sshd[1296]: input_userauth_request: invalid user myusername [preauth]
2015-12-03T11:18:59.414338-06:00 muwacmaster sshd[1296]: Postponed keyboard-interactive for invalid user myusername from 172.20.9.87 port 54501 ssh2 [preauth]
2015-12-03T11:19:01.528568-06:00 muwacmaster sshd[1298]: pam_unix(sshd:auth): check pass; user unknown
2015-12-03T11:19:01.529166-06:00 muwacmaster sshd[1298]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=mypc.it.millikin.edu

so it's like SSSD isn't even functioning?

When I view the user auth section in YaST it indicates that SSSD is configured though.

What am I doing wrong?

jmozdzen
03-Dec-2015, 18:51
Hi smily_03,

I see you configured the access_provider = ldap, but no ldap_access_filter. I'm not even sure that you actually wanted to set that ;)

My guess is that sssd is bailing out because of the missing filter. My recommendation is to comment out the access_provider line and re-test. Care about filtering when you can log in at all ;)

From "man sssd-ldap":


ldap_access_filter (string)
If using access_provider = ldap and ldap_access_order = filter (default), this option is mandatory. It specifies an LDAP search filter criteria that must be met for the user to be granted access on this host. If
access_provider = ldap, ldap_access_order = filter and this option is not set, it will result in all users being denied access. Use access_provider = permit to change this default behavior.

Regards,
Jens

smily_03
03-Dec-2015, 20:33
Cool, thanks for posting back Jens :)

So far, no luck :/
I tried commenting out that line, setting the value to "permit", and setting the value to "ldap" while adding the line

ldap_access_filter = objectClass=specialPerson

(where specialPerson is a placeholder for one of our custom ldap classes that's assigned to "people" on campus)

(Also, I rebooted the box in between each of the changes just to be safe.)

It's still not logging anything (or creating a log file) in /var/log/sssd either though, and I don't see anything in .../messages about sssd either?

jmozdzen
04-Dec-2015, 17:19
Hi smily_03,

> It's still not logging anything (or creating a log file) in /var/log/sssd either though, and I don't see anything in .../messages about sssd either?

what does "ps alx|grep sssd" report about the running sssd processes?

If sssd is actually running, I'd like to ask you to give the following minimal LDAP section a try:


[domain/LDAP]
id_provider = ldap
auth_provider = ldap
;access_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldap://ourldapserver.millikin.edu
ldap_tls_reqcert = allow
cache_credentials = False
enumerate = True
debug_level=0x07ff


Regards,
Jens

smily_03
04-Dec-2015, 19:51
Hmm, looks like it's not even running:

# ps alx | grep sssd
0 0 17897 17867 20 0 10492 928 pipe_w S+ pts/0 0:00 grep --color=auto sssd

Out of curiosity, what do I need to do to try to get it started?

smily_03
04-Dec-2015, 19:55
Nevermind, "service sssd start" worked.

smily_03
04-Dec-2015, 20:16
Ok, after some testing and tweaking, I got this to link up now. But, I'm still not able to log in.

Here's the last of our sssd log; there's a lot of random stuff in there, so I'm not sure what's a "this is failing because" message versus a general message?

http://susepaste.org/3a5e6d96

jmozdzen
07-Dec-2015, 14:26
Hi smily_03,

while looking at the current version of the configuration may have been helpful, digging through the logging messages leaves the impression that sssd is unable to handle group memberships.

Have you adjusted your sssd LDAP configuration to match the way your information is stored in your LDAP tree?

Regards,
Jens

smily_03
07-Dec-2015, 17:23
It would make sense I guess; if it's expecting to find group membership data, it won't be able to because we don't allow that on anonymous binds. Out of curiosity, is there a way to find out what attributes are required for a successful authentication? I haven't been able to find it in the manpage or my Googling. I'm fine with creating a special bind user for this to use to get the non-public attrs that it's needing, but I would rather create it with what it needs, rather than giving it access to everything. I can see lists of what it's looking for in the logs, but don't know what's all required, since we don't have all of those attributes in our schema.

And out of curiosity, is there a doc on the SuSE site anywhere on how to do this? It seems like something should either be straightforward, or well-documented, which it seems neither is the case unfortunately, at least from my searches and experiences thus far. I'm more than happy to write up my experiences after it's all said and done if there's some place that I can do so, since I'm guessing that others are going to have similar frustrations. I understand that the functionality has changed since they moved from a generic LDAP client authentication to SSSD, but with how much more complex this is now than it used to be, it almost feels like a functionality regression. (Not grumpy with you, and definitely appreciate your help; just kind of irritated that something that used to take 2 minutes to set up has wasted a couple of days of my time.)



Here's our current config in sssd.conf:


[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_groups = root
filter_users = root

[pam]

[domain/LDAP]
id_provider = ldap
auth_provider = ldap
access_provider = ldap
ldap_access_filter = muRole=adminRole
ldap_schema = rfc2307bis
ldap_user_object_class = millikinPerson
debug_level = 20
ldap_uri = ldaps://ldap.millikin.edu:636

ldap_search_base = ou=tech,o=mu
create_homedir = true

ldap_tls_cacert = /etc/sssd/certs/rootcert.pem
ldap_tls_cacertdir = /etc/sssd/certs
ldap_id_use_start_tls = true


and the latest logs from trying to log in today: http://susepaste.org/2e76313c

hangarbait
12-Dec-2015, 17:16
The SSSD is a bit of a new concept and once you get your head around it the complexity reduces. The lack of documentation doesn't help, so point conceded there.

Using it against eDirectory has its own nuances (primarily due to attribute names) that the SSSD can handle, but before we go there possibly reducing the configuration down to it's simplest form without access control and go from there. Ensure your proxy user has the required object rights. Use the eDir admin user to test if you are having a proxy user rights issue (never in production ovbiously).

Try:

[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_users = root
filter_groups = root

[pam]

[domain/LDAP]

id_provider = ldap
auth_provider = ldap

enumerate = False
cache_credentials = True
case_sensitive = False

ldap_default_bind_dn = <proxy_user_ldap_dn>
ldap_default_authtok_type = password
ldap_default_authtok = <proxy_user_password>

ldap_schema = rfc2307bis
ldap_user_name = cn
lldap_uri = ldaps://ldap.millikin.edu
ldap_search_base = ou=tech,o=mu

ldap_tls_cacert = /etc/sssd/certs/rootcert.pem
ldap_tls_cacertdir = /etc/sssd/certs
ldap_id_use_start_tls = true

debug_level = 7

See if you can login using this configuration and then we can look towards access control and home directories.


-- lawrence

smily_03
16-Dec-2015, 17:11
Ok, after much off-thread troubleshooting with the amazing folks on the TTP ListServ (https://thettp.org/), we've got a working setup, which I will document here for others to benefit from:


edit /etc/nsswitch.conf, set:
passwd: compat sss
group: compat sss

edit /etc/sssd/sssd.conf, contents:


[sssd]
config_file_version = 2
services = nss, pam
domains = LDAP

[nss]
filter_users = root
filter_groups = root

[pam]

[domain/LDAP]

id_provider = ldap
auth_provider = ldap

enumerate = False
cache_credentials = True
case_sensitive = False

ldap_schema = rfc2307bis
ldap_user_name = cn
ldap_uri = ldaps://ldap.millikin.edu
ldap_search_base = ou=base_ou,o=mu

ldap_id_use_start_tls = True

#debug_level = 7

ldap_tls_cacert = /etc/path/to/certs/rootcert.pem
ldap_tls_cacertdir = /etc/path/to/certs

ldap_default_bind_dn = cn=bind_user,ou=base_ou,o=mu
ldap_default_authtok_type = password
ldap_default_authtok = bind_user_password

ldap_user_member_of = groupMembership
ldap_group_name = cn


execute the following from root's command line:
pam-config --add --mkhomedir
pam-config --add --sss
service nscd stop
chkconfig nscd off

Need to also copy the certificate details for the root cert into that rootcert.pem file mentioned in the config. In our case this included the root cert and two intermediate certificates.

jmozdzen
16-Dec-2015, 17:18
Hi smily_03,

cool - both that you got it up&running and that you provide the according details here as well! Thank you for that!

Best regards,
Jens

smily_03
16-Dec-2015, 17:31
No problem! :D

I always hate those threads where I'm like - that's the EXACT same problem as I'm having, and you read through all the posts, and.....it just ends without their solution :/ So I always try to post my solutions afterwards :)

swadm
17-Dec-2015, 14:51
It is also my observation that sssd appears to be much more straightforward than the previous concepts, see also Embracing SSSD in Linux (http://geekdom.wesmo.com/2014/05/16/embracing-sssd-in-linux/).

It will probably still take a few years to really hit the road, but SLES(12) people have made a good decision to propagate it in favour of the nss_ldap / nscd combination.

When debug_level is set, the log files give fairly detailed and helpful information of what is going on, or ... why not.

Cheers, Thomas

hangarbait
17-Jun-2016, 03:36
To continue the solution to the access control by group membership:

The LDAP ID and AUTH providers are being used against eDirectory so a little bit of schema mapping is required first (as indicated in the previous post):

ldap_schema = rfc2307bis
ldap_user_name = cn
ldap_user_member_of = groupMembership
ldap_group_name = cn

Then to perform access control by group membership:

access_provider = ldap
ldap_access_filter = groupMembership=cn=<GROUP_CN_NAME>,ou=LDAP,ou=SVS,o=DVC

The context is an example, obviously.

I hope it helps,


-- lawrence