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.
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”:
[QUOTE] 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.[/QUOTE]
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?
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?
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.)
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).
Ok, after much off-thread troubleshooting with the amazing folks on the TTP ListServ, we’ve got a working setup, which I will document here for others to benefit from:
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.
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
It is also my observation that sssd appears to be much more straightforward than the previous concepts, see also 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.
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):
