Thank you for the bug report. At the moment, I have two suggestions -- one is to try out 1.11.5 which we'll be releasing today, it contains a largish number of fixes. The second (and maybe more important) would be to use the AD id_provider. Since it looks like you're using POSIX attributes in AD, you can just use the id_provider=ad together with ldap_id_mapping=False

See https://fedorahosted.org/sssd/wiki/Configuring_sssd_with_ad_server (still a bit of work in progress)

Hey,

Thanks for the response. I switched id_provider from "ldap" to "ad" as you suggested and coupled that with ldap_id_mapping = False and then did "rm -f /var/lib/sss/db/cache_XXXXX.NET.ldb" then I did "service sssd restart".

It still fails to grab the groups. I can try 1.11.5 and see what happens, but it sounds like you're not convinced that will even help. Is there anything else you can think of that I can test or look at? Any additional information that will help?

I think I need logs at this point. please put debug_level=7 into the domain section, restart sssd and re-run the tests. Also please remove the cache before the test. Feel free to send the logs to me directly if you don't like attaching them to the ticket.

Hey,

I failed to properly check the version; looks like I'm running the Centos 6 default sssd packages, which appear to be 1.9.2 and I didn't change the forms default submission version. Let me upgrade and see if that helps resolve the issue.

Do you have a 1.11.5 rpm or repo link?

Thanks,
Alex

Replying to [comment:4 aaltman]:

Hey,

I failed to properly check the version; looks like I'm running the Centos 6 default sssd packages, which appear to be 1.9.2 and I didn't change the forms default submission version. Let me upgrade and see if that helps resolve the issue.

Do you have a 1.11.5 rpm or repo link?

Thanks,
Alex

Sorry for the late reply.

You can use this repo with the latest 1.11 code

http://copr-fe.cloud.fedoraproject.org/coprs/jhrozek/SSSD-1.11-RHEL6/

Don't be mistaken by the version, all the commits since 1.11.2 are present as patches to keep upgrade path clean between el6 and el7 before the official upgrade tool supports upgrades where el6 version is higher than el7.

Fields changed

owner: somebody => jhrozek
status: new => assigned

Hey,

Thanks for the response. We ended up porting:

https://fedorahosted.org/released/sssd/sssd-1.11.5.tar.gz

to Centos 6 and I have to carve out some time to put it into the test environment. I will update my findings when that's done.

Thanks,
Alex

Replying to [comment:7 aaltman]:

Hey,

Thanks for the response. We ended up porting:

https://fedorahosted.org/released/sssd/sssd-1.11.5.tar.gz

to Centos 6 and I have to carve out some time to put it into the test environment. I will update my findings when that's done.

Thanks,
Alex

Sure, that would work as well, but the repo I sent you is equivalent to 1.11.5 code-wise, just the nvr is different. Also, the packaging in that repo is already done :)

Hi, any luck testing the new code?

Kindly reopen if you can reproduce the problem with 1.11.x

resolution: => worksforme
status: assigned => closed

Hey just an update. Srry for the delay got held up on other projects.

So like I said we ported 1.11.5 and installed that which went fine. The config files were unchanged. I did have to issue "ln -s /usr/lib64/security/pam_sss.so /usr/lib64/security/pam_sss.so" because pam couldn't find the pam_sss.so.

Now I can't login at all. I don't know if you want to log that under a different bug file or this one..., but essentially we went from almost working to not working at all. Is there some kind of information I can provide you to assess?

Personally I'm just not having too much luck here. I do appreciate the help though.

First let's find out whether the login failure is due to a bug or a misconfiguration with either build or the config itself.

What do the logs say? I'd start with syslog and /var/log/secure.

Then, if all looks good there, what do the pam logs and the debug logs say?

If you remove or move the caches, can you run getent passwd user@domain ?

service sssd is running
service ntpd is running
service smb is running
net ads status returns positive --> it is a bit slow
hostname -d returns correct domain --> also a touch slow

issued "rm -f /var/lib/sss/db/cache_DOMAIN.COM.ldb"

getent passwd username@DOMAIN.COM returns nothing

/var/log/secure basically says:
pam_unix check pass; user unknown
pam_unix authentication failure
pam_succeed if: error retrieving info for user xxxxx
login FAILED LOGIN 1 FROM (null) FOR xxxxx, User not known to underlying authentication module

/var/log/sssd/sssd.log says:
sssd ldb asq; unable to register control with root dse
dbus server listed on unix:path=/var/lib/sss/pipes/private/sbus-monitor,guid=...
service_send_ping to DOMAIN.COM
ping successfull
ping nss
ping pam
service nss replied
service pam replied

/var/log/sssd/sssd_DOMAIN.COM.log says:
Wed apr 30 10:43:16 [sssd[be[DOMAIN.COM]]] [ad_account_info_complete] (0x0010): Bug: dp_error is ok on failed request ---> repeats this line
---------same thing as above until----> [id_callback] (0x0010): The Monitor returned an error [org.freedesktop.DBus.Error.NoReply]
EOF

Let me know what else to look at.

Thanks,
Alex

Thanks, it sounds like there is some issue in the domain lookups, but I think the error level you're currently using doesn't provide enough information. Can you put 'debug_level=7' into the domain and nss section, restart sssd, and run getent again?

Okay. I set debug to 7, restarted the service, and ran the getent command. It came up empty again. I also tried to login to see what /var/log/secure would show and it said the same thing as before with the Failed Login 1 from null etc. etc.

Confirmed services again, on domain, etc. looks good. It is possible maybe the port wasn't 100%. That's the only thing I can think of doing right now is switching to your repo.

Any other ideas?

Sorry for the late reply. The ticket fell off the radar a bit, because the status was closed, so I'll reopen it to keep the ticket visible.

Did you have a change to collect the debug logs? You might want to put debug_level=7 (or higher, up to 10 which is pretty verbose) to the [nss] and [domain] sections and then run the getent or id or login. The debug logs would show up at /var/log/sssd/

resolution: worksforme =>
status: closed => reopened

ping, any luck getting those logs?

Please reopen with the debug logs.

resolution: => worksforme
status: reopened => closed

Fields changed

mark: => 0
resolution: worksforme =>
sensitive: => 0
status: closed => reopened

Hello all, I've re-opened this ticket because I'm facing the same problem. In the joined file you'll find my conf and the logs (secure, sssd_domain and krb5_child)
Thanks for your help, I'm just one step to the end :-)

attachment
sssd_groupidnotfound.txt

Pavel agreed he'd take a look.

owner: jhrozek => pbrezina
status: reopened => new

Hi, I don't see any errors in the logs. Could you be more specific about the problem?

• what commands did you run to get those logs, what was the output and what output is expected?
• group membership
• is the dc you are connected to a global catalog?
• what sssd version do you use? Would you mind trying ad provider instead of ldap?

Thanks.

No response for 9 days, so I'm going to close this ticket as worksforme. Kindly reopen if you have the information requested in comment #22.

resolution: => worksforme
status: new => closed

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3351

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.