Good afternoon,
I've been playing around with sssd for a while not and it's been great but I've just run into a really weird problem. If I have a user specified in the 'simple_allow_users' configuration directive it works absolutely fine BUT I've got (at least) 2 groups that, for some reason, if the user is a member of these groups the account can't authenticate on my boxes. The groups that I'm having problems with are nothing to do with any simple_allow_groups - they're just normal AD security groups...
Can someone please point me in the right direction on this one or let me know how I can best find out why these groups are affecting sssd? I've been trawling logs but can't seem to find anything obvious.
Thanks, Allan
On (11/02/15 13:20), Mullan, Allan wrote:
Good afternoon,
I've been playing around with sssd for a while not and it's been great but I've just run into a really weird problem. If I have a user specified in the 'simple_allow_users' configuration directive it works absolutely fine BUT I've got (at least) 2 groups that, for some reason, if the user is a member of these groups the account can't authenticate on my boxes. The groups that I'm having problems with are nothing to do with any simple_allow_groups - they're just normal AD security groups...
Can someone please point me in the right direction on this one or let me know how I can best find out why these groups are affecting sssd? I've been trawling logs but can't seem to find anything obvious.
Which version of sssd do you use?
Which pam return code was returned?
I would suggest to start debugging with small debug level (0x00F0) and then you can increase to full debug level (0xFFF0)
If you have alredy log files with full debug level it is easy to filter the most critical with grep command.
grep -E "(0x00[1-9]0)" sssd_domain.log
LS
The logs show the following:
(Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_resolve_group_done] (0x0040): Refresh failed (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 1749812073 (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuseramm
The secure log is displaying the following:
Feb 11 13:38:40 uksn-test01 sshd[25114]: pam_sss(sshd:account): Access denied for user testuseramm: 4 (System error)
Hope this helps?
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Lukas Slebodnik Sent: 11 February 2015 13:26 To: End-user discussions about the System Security Services Daemon Subject: Re: [SSSD-users] sssd not authentication with user in random groups
On (11/02/15 13:20), Mullan, Allan wrote:
Good afternoon,
I've been playing around with sssd for a while not and it's been great but I've just run into a really weird problem. If I have a user specified in the 'simple_allow_users' configuration directive it works absolutely fine BUT I've got (at least) 2 groups that, for some reason, if the user is a member of these groups the account can't authenticate on my boxes. The groups that I'm having problems with are nothing to do with any simple_allow_groups - they're just normal AD security groups...
Can someone please point me in the right direction on this one or let me know how I can best find out why these groups are affecting sssd? I've been trawling logs but can't seem to find anything obvious.
Which version of sssd do you use?
Which pam return code was returned?
I would suggest to start debugging with small debug level (0x00F0) and then you can increase to full debug level (0xFFF0)
If you have alredy log files with full debug level it is easy to filter the most critical with grep command.
grep -E "(0x00[1-9]0)" sssd_domain.log
LS _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On (11/02/15 13:39), Mullan, Allan wrote:
The logs show the following:
(Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_resolve_group_done] (0x0040): Refresh failed (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 1749812073 (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuseramm
The secure log is displaying the following:
Feb 11 13:38:40 uksn-test01 sshd[25114]: pam_sss(sshd:account): Access denied for user testuseramm: 4 (System error)
^^^^^^^^^^^^^^^ It means unexpected error in sssd. It should not happen => it's a bug. Error code might be result of problem with resolving groups in log file.
We would need to see your sanitized configuration file and log file with higher debug level.
BTW: you did not mention version of sssd.
LS
On Wed, Feb 11, 2015 at 03:37:13PM +0100, Lukas Slebodnik wrote:
On (11/02/15 13:39), Mullan, Allan wrote:
The logs show the following:
(Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_resolve_group_done] (0x0040): Refresh failed (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 1749812073 (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuseramm
The secure log is displaying the following:
Feb 11 13:38:40 uksn-test01 sshd[25114]: pam_sss(sshd:account): Access denied for user testuseramm: 4 (System error)
^^^^^^^^^^^^^^^ It means unexpected error in sssd. It should not happen => it's a bug.Error code might be result of problem with resolving groups in log file.
We would need to see your sanitized configuration file and log file with higher debug level.
BTW: you did not mention version of sssd.
This is a known bug in the simple access provider: https://fedorahosted.org/sssd/ticket/2519
The fix for #2519 is a workaround around the issue which gets rid of the problem, but doesn't fix the root cause.
It would be nice to see what SID does the group with GID 1749812073 map to and see what is exactly the search that SSSD performs.
Hi Jakub,
Thanks for that. I'll have a look at the patch and see how I get on.
I can't figure out how the GID is retrieved (can't see either of the groups that were giving me grief refer to 1749812073) - if I can get some advice on where the GID is retrieved I can get the SID for you.
-----Original Message----- From: sssd-users-bounces@lists.fedorahosted.org [mailto:sssd-users-bounces@lists.fedorahosted.org] On Behalf Of Jakub Hrozek Sent: 11 February 2015 17:14 To: sssd-users@lists.fedorahosted.org Subject: Re: [SSSD-users] sssd not authentication with user in random groups
On Wed, Feb 11, 2015 at 03:37:13PM +0100, Lukas Slebodnik wrote:
On (11/02/15 13:39), Mullan, Allan wrote:
The logs show the following:
(Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_resolve_group_done] (0x0040): Refresh failed (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_check_get_groups_next] (0x0040): Could not resolve name of group with GID 1749812073 (Wed Feb 11 13:36:33 2015) [sssd[be[UK.CorpLAN.net]]] [simple_access_check_done] (0x0040): Could not collect groups of user testuseramm
The secure log is displaying the following:
Feb 11 13:38:40 uksn-test01 sshd[25114]: pam_sss(sshd:account): Access denied for user testuseramm: 4 (System error)
^^^^^^^^^^^^^^^ It means unexpected error in sssd. It should not happen => it's a bug.Error code might be result of problem with resolving groups in log file.
We would need to see your sanitized configuration file and log file with higher debug level.
BTW: you did not mention version of sssd.
This is a known bug in the simple access provider: https://fedorahosted.org/sssd/ticket/2519
The fix for #2519 is a workaround around the issue which gets rid of the problem, but doesn't fix the root cause.
It would be nice to see what SID does the group with GID 1749812073 map to and see what is exactly the search that SSSD performs. _______________________________________________ sssd-users mailing list sssd-users@lists.fedorahosted.org https://lists.fedorahosted.org/mailman/listinfo/sssd-users
On Thu, Feb 12, 2015 at 11:16:41AM +0000, Mullan, Allan wrote:
Hi Jakub,
Thanks for that. I'll have a look at the patch and see how I get on.
If you run SSSD on Fedora or RHEL, I guess we can build you a test package or point you to an RPM that is already fixed.
I can't figure out how the GID is retrieved (can't see either of the groups that were giving me grief refer to 1749812073) - if I can get some advice on where the GID is retrieved I can get the SID for you.
yum -y install ldb-tools ldbsearch /var/lib/sss/db/cache_$domain.ldb gidNumber=1749812073
should do the trick
On Wed, Feb 11, 2015 at 01:20:10PM +0000, Mullan, Allan wrote:
Good afternoon,
I've been playing around with sssd for a while not and it's been great but I've just run into a really weird problem. If I have a user specified in the 'simple_allow_users' configuration directive it works absolutely fine BUT I've got (at least) 2 groups that, for some reason, if the user is a member of these groups the account can't authenticate on my boxes. The groups that I'm having problems with are nothing to do with any simple_allow_groups - they're just normal AD security groups...
Can someone please point me in the right direction on this one or let me know how I can best find out why these groups are affecting sssd? I've been trawling logs but can't seem to find anything obvious.
Thanks, Allan
Did you verify it's actually the pam account phase that's kicking you out?
If yes, then increasing debug_level in the domain section is a good start.
Do the groups show up in the "id" output for the groups?
sssd-users@lists.fedorahosted.org
-
Jakub Hrozek -
Lukas Slebodnik -
Mullan, Allan