9:33 a.m.
RHEL 6.4
sssd v1.11.6
Preface : I'm just recently absorbing sssd so I might be missing something here. I
assume that you can use the simple access provider with the ad id_provider.
In my domain section:
cache_credentials = true
id_provider = ad
auth_provider = ad
access_provider = simple
default_shell = /bin/bash
fallback_homedir = /home/%u
use_fully_qualified_names = false
ignore_group_members = true
And below I've tried a few things in the domain section:
simple_allow_users = bswift ---> this works!
simple_allow_groups = sjrb.lg.it.cfg.cdo --> this doesn't work :(
I'd really prefer to use the simple provider as it's just easier to configure. We
are using puppet as our config management tool so non-admins could submit pull requests
via git and they'd only have to know a simpler user API, and not understand SSSD or
LDAP queries.
Is this a deficiency in the version I'm using?
I found a post on this forum where setting "ldap_use_tokengroups = false" might
help, tried that.. didn't help.
debug_level = 7 gives me this log output (just the last few lines)
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists]
(0x0200): Allow users list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists]
(0x0200): Deny users list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_obtain_filter_lists]
(0x0200): Deny groups list is empty.
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_check_send] (0x0200): Simple
access check for bswift
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x1000):
Looking up groups for user bswift
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x0400):
User bswift is a member of 74 supplemental groups
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_check_get_groups_send] (0x0400):
All groups had name attribute
(Wed Nov 16 08:26:48 2016) [sssd[be[SJRB.AD]]] [simple_access_check_recv] (0x1000): Access
not granted
One thing that may be causing this is in AD under this group name, I see this:
"To enable access to this group for UNIX clients you will need to specify the NIS
domain this group belongs to." However the dropdown is empty (maybe access rights
as I'm not the domain admin).
Sometimes what you read on a windows box isn't the full truth.. maybe it is in this
case?
Any direction here would be appreciated.
Thanks!
11:13 a.m.
Update:
I had the Unix guy add a GID to the group. The group scope is set to
"Domain.local" and one of our "Unix Admins" said the group needed to
have it set to "universal". Which I have not yet done.
However, I am getting 60% success rate logging in.
If anyone has any advice on what I can grep from the log files that would help me find the
issue here, that would help.
running tcpdump shows that the AD server (i'm using DNS to resolve them) I connect
to, doesn't show consistency. IE: out of 4-5 IPs it's connecting to, some
IP's show both successful logins and failures. That to me, eliminates flaky AD
response - and maybe highlights a network issue.
Is there anything on the SSSD side I can inspect to see if the linux config itself might
be an issue?
2:22 a.m.
On Wed, Nov 16, 2016 at 05:13:17PM -0000, brettswift(a)gmail.com wrote:
Update:
I had the Unix guy add a GID to the group.
Whether this is needed depends on whether the setup uses POSIX
attributes (id mapping = false) or ID mapping. By default the ad
provider uses ID mapping.
The name of the group in the allow list must match the group as listed
in the "id" output.
The group scope is set to "Domain.local" and one of our
"Unix Admins" said the group needed to have it set to "universal".
Which I have not yet done.
This shouldn't be the case as long as the group comes from the joined
domain. Domain-local groups are only filtered out from results from
trusted domains.
However, I am getting 60% success rate logging in.
You're running a pretty old version and we had a bug with
ignore_group_members together with AD provider for some time. I would
suggest to upgrade for sure -- the 1.13 version in RHEL-6.8 is quite
stable.
If you can't can you at least temporarily disable ignore_group_members=false?
This old version had IIRC also some bugs when the (default) tokengroups
optimization was enabled. You might want to try disabling that, too for
a test if you can't upgrade.
>
> If anyone has any advice on what I can grep from the log files that would help me
find the issue here, that would help.
>
> running tcpdump shows that the AD server (i'm using DNS to resolve them) I
connect to, doesn't show consistency. IE: out of 4-5 IPs it's connecting to,
some IP's show both successful logins and failures. That to me, eliminates flaky AD
response - and maybe highlights a network issue.
>
> Is there anything on the SSSD side I can inspect to see if the linux config itself
might be an issue?
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
2711
days inactive
2718
days old
sssd-users@lists.fedorahosted.org
3 comments
2 participants
participants (2)
-
brettswift＠gmail.com -
Jakub Hrozek