Thanks Bryan,
Yes, that's my point! I still feel that the issue is with the NAS vendors.
Adding the SSSD algorithm would be a small amount of effort and "just work" for
most of us working with Linux systems. As I mentioned before it seems that
multiple people say they've asked their NAS
For simple access control you can refer the man page "man sssd-simple" for
details on "simple_allow_groups".
For "memberOf" filter I think "memberOf" attribute needs to be enabled on
the openldap server, directory servers has it by default.(including AD)
Am Mon, May 09, 2022 at 01:54:00PM +0200 schrieb Bo Riis Toelberg Kristensen:
> Hi
>
> I'm trying to authenticate users based on group membership in our Google
> LDAP directory.
> I can authenticate just fine without the 'ldap_access_filter' but when I
> enable it they still authenticate even
Define 'large'?
In general many NAS, SAN and even Network vendors have issues with LDAP
trees and attributes any way.
So UID, GID and UPN (user@domain) and NT/Dom SID enumeration and mapping is
a secondary issue.
I.e., I spend a lot more time dealing with maintaining a 'light' 389/RHDS
or
Ed,
I'm a Linux engineer, reading and learning on this sssd mailing list. I
had just never seen a large company that used that algorithm that's all.
Spike
On Mon, May 9, 2022 at 2:21 AM wrote:
> Hey Spike,
>
> I'm curious, why is it you previously said that SSSD based ID mapping is
> only
Hi
I'm trying to authenticate users based on group membership in our Google
LDAP directory.
I can authenticate just fine without the 'ldap_access_filter' but when I
enable it they still authenticate even when the user is not a group member.
Additionally I don't see any check of the group
Hey Spike,
I'm curious, why is it you previously said that SSSD based ID mapping is only
used at small scale?
I understand that it's not using a single source of truth (the directory) to
provide UID and GID values, but the algorithm is so consistent. I ran a test
across all our systems in one
