Enumerate users from external group from AD trust
by Bolke de Bruin
Hello,
I have sssd 1.13.00 working against FreeIPA 4.2 domain. This domain has a trust relationship with a active directory domain.
One of the systems we are using requires to enumerate all users in groups by (unfortunate) design (Apache Ranger). This is done by using
“getent group”. During this enumeration the full user list for a group that has a nested external member group* is not always returned so we thought to
add “getent group mygroup” in order to get more details. Unfortunately this does not seem to work consistently: sometimes this gives information sometimes it does not:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
[root@master centos]# id bolke(a)ad.local
UID=1796201107(bolke(a)ad.local) GID=1796201107(bolke(a)ad.local) groepen=1796201107(bolke(a)ad.local),1796200513(domain users@ad.local),1796201108(test(a)ad.local)
[root@master centos]# getent group ad_users
ad_users:*:1950000004:bolke@ad.local <mailto:bolke@ad.local>
If I clear the cache (sss_cache -E) the entry is gone again:
[root@master centos]# getent group ad_users
ad_users:*:1950000004:
My question is how do I get sssd to enumerate *all users* in a group consistently?
Thanks!
Bolke
* https://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/trust-g...
4 years
full_name_format and supplemental groups
by Orion Poplawski
Running IPA with an AD trust. Users are in AD. Trying to use
full_name_format = %1$s to strip the domain from user names. This appears to
break supplemental groups in strange ways.
On the IPA server:
Without full_name_format:
# id orion(a)ad.nwra.com
uid=470202603(orion(a)ad.nwra.com) gid=470202603(orion(a)ad.nwra.com)
groups=470202603(orion(a)ad.nwra.com),470200513(domain
users(a)ad.nwra.com),470204703(pirep rd users(a)ad.nwra.com),470204714(wireless
access@ad.nwra.com),470204715(nwra-users@ad.nwra.com),470204701(boulder(a)ad.nwra.com),470207608(heimdall
users(a)ad.nwra.com),470200512(domain admins(a)ad.nwra.com),470207124(andreas
admins(a)ad.nwra.com)
With:
# id orion(a)ad.nwra.com
uid=470202603(orion) gid=470202603(orion) groups=470202603(orion)
If I add:
default_domain_suffix = ad.nwra.com
# id orion
uid=470202603(orion) gid=470202603(orion)
groups=470202603(orion),470200512(domain admins),470207608(heimdall
users),470204714(wireless
access),470204715(nwra-users),470204701(boulder),470204703(pirep rd
users),470207124(andreas admins),470200513(domain users)
Which I guess makes some sense as you'd need to add the domain suffix back on
to find the groups.
But this appears to completely break IPA clients (with full_name_format = %1$s
and default_domain_suffix = ad.nwra.com):
# id orion(a)ad.nwra.com
id: orion(a)ad.nwra.com: no such user
# id orion
id: orion: no such user
>From looking at the server logs, it looks like only the IPA domain is searched
If I reset the server back to normal (drop full_name_format and
default_domain_suffix):
# id orion
uid=470202603(orion) gid=470202603(orion) groups=470202603(orion)
I don't get any supplemental groups. I see sssd errors like:
(Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_mod_group_member]
(0x0400): Error: 2 (No such file or directory)
(Mon Mar 30 15:20:52 2015) [sssd[be[nwra.com]]] [sysdb_update_members_ex]
(0x0020): Could not add member [orion] to group [name=domain
admins,cn=groups,cn=nwra.com,cn=sysdb]. Skipping.
Is t trying "cn=groups,cn=nwra.com,cn=sysdb" instead of
"cn=groups,cn=ad.nwra.com,cn=sysdb"
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
7 years, 1 month
netlink messages on Infiniband causing sssd to exit
by Ryan Novosielski
Over time, I’ve been having seemingly random sssd quits that I’ve not been able to figure out. Today, I finally traced it to fluctuations on my Infiniband fabric:
sssd.log
(Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16
(Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x1003 (broadcast,multicast,up)
(Tue Nov 3 13:17:59 2015) [sssd] [message_type] (0x0200): netlink Message type: 16
(Tue Nov 3 13:17:59 2015) [sssd] [link_msg_handler] (0x1000): netlink link message: iface idx 4 (ib0) flags 0x11043 (broadcast,multicast,up,running,lower)
This exactly corresponds to the time in /var/log/messages for the unexplained shutdown:
2015-11-03T13:17:59-05:00 node75 sssd[pam]: Shutting down
2015-11-03T13:17:59-05:00 node75 sssd[be[default]]: Shutting down
2015-11-03T13:17:59-05:00 node75 sssd[nss]: Shutting down
Here is sssd_default.log for good measure:
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x14133d0
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1414770/0x13fef90
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_ptask_destructor] (0x0400): Terminating periodic task [Cleanup of default]
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sdap_handle_release] (0x2000): Trace: sh[0x14bd850], connected[1], ops[(nil)], ldap[0x1424260], destructor_lock[0], release_memory[0]
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_connection_callback] (0x4000): Successfully removed connection callback.
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [sbus_remove_watch] (0x2000): 0x1415970/0x1416430
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The symlink points to [/var/lib/sss/pipes/private/sbus-dp_default.18702]
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): The path including our pid is [/var/lib/sss/pipes/private/sbus-dp_default.18702]
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [remove_socket_symlink] (0x4000): Removed the symlink
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed PAM client
(Tue Nov 3 13:17:59 2015) [sssd[be[default]]] [be_client_destructor] (0x0400): Removed NSS client
I can duplicate this by manually taking down the Infiniband link:
[root@node24 ~]# service sssd status
sssd (pid 9132) is running...
[root@node24 ~]# ifdown ib0
[root@node24 ~]# service sssd status
sssd dead but pid file exists
I have also noticed that sssd will not start on boot. As I know that Infiniband tends to flutter a little bit before the link comes up, I’m thinking this is probably the same cause.
Can anyone explain this behavior and tell me what I might do to prevent it?
--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | novosirj(a)rutgers.edu - 973/972.0922 (2x0922)
|| \\ Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
`'
7 years, 3 months
heads-up: new code to fetch sudo rules from an IPA server coming to Fedora and RHEL-6
by Jakub Hrozek
Hi,
the sssd's code that fetches sudo rules from the IPA server got an
overhaul recently. The search would no longer be performed against the
compat tree, but against IPA's native LDAP tree. This would have the
advantage that environments that don't use the slapi-nis' compat tree
for another reason (like old or non-Linux clients) would no longer
require slapi-nis to be running at all.
We'd like to get some tests for this new code! If you're running Fedora ,
you can just upgrade to the packages from Fedora's update testing. If
you're running RHEL-6.7 and would like to see what is cooking for 6.8,
you can try this repository:
https://copr.fedorainfracloud.org/coprs/jhrozek/SSSD-6.8-preview/
RHEL-7 wouldn't receive this code until 7.3, so we don't have test
packages for el7 yet..
7 years, 10 months
sssd + openldap + simple bind + tls + pam
by Marcelo Coelho
Hi all,
I've been struggling to setup a centralized authentication system for quite
some time. It is composed by:
- openldap 2.4.43, with TLS self-signed certs (root chain is ok):
ldaps://serv;
- pam 1.2.1; pambase 20150213;
- sssd 1.13.1;
- openssh 7.1.
Currently I'm trying to authenticate a LDAP user in the server that hosts
openldap.
ldapsearch -x shows me stuff correctly, with TLS working. If I try to
connect through the command-line, the logs show sssd getting stuff from
openldap with success. But, login fails:
<log>
login[xxxx]: pam_sss(login:auth): authentication success; logname=LOGIN
uid=0 euid=0 tty=/dev/tty1 ruser= rhost= user=user_a
login[xxxx]: FAILED LOGIN (1) on '/dev/tty1' FOR 'UNKNOWN', Authentication
failure
</log>
Also, id user_a fails, getent passwd user_a fails. Have no idea what may be
wrong (if sssd, ldap DB, whatever).
sssd.conf
[sssd]
config_file_version = 2
services = pam
domains = LDAP
debug_level = 4
[nss]
[pam]
debug_level = 5
[domain/LDAP]
debug_level = 4
id_provider = ldap
auth_provider = ldap
access_provider = ldap
cache_credentials = false
ldap_uri = ldaps://server
ldap_schema = rfc2307
ldap_search_base = dc=casa,dc=lan
ldap_id_use_start_tls = true
ldap_tls_cacert = /etc/openldap/ssl/cacert.pem
ldap_tls_cacertdir = /etc/openldap/ssl
ldap_tls_reqcert = demand
tls_reqcert = demand
ldap_user_search_base = ou=People,dc=casa,dc=lan
ldap_user_home_directory = homeDirectory
ldap_user_shell = loginShell
ldap_group_search_base = ou=Group,dc=casa,dc=lan
ldap_access_filter = memberOf=ou=People,dc=casa,dc=lan
# Leave this as password
ldap_default_authtok_type = password
system-auth
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
#auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so
account sufficient pam_localuser.so
#account sufficient pam_succeed_if.so uid < 500 quiet
#account [default=bad success=ok user_unknown=ignore]
pam_sss.so
#account [default=bad success=ok] pam_sss.so
account sufficient pam_sss.so
account required pam_permit.so
nsswitch.conf
passwd: compat sss
shadow: compat sss
group: compat sss
hosts: files dns
networks: files dns
services: db files
protocols: db files
rpc: db files
ethers: db files
netmasks: files
netgroup: files
bootparams: files
automount: files
aliases: files
Thanks in advance!
7 years, 10 months
translate trusted domain users to local users
by Bolke de Bruin
Hi,
In my setup (hello Hadoop!) I have the requirement to simplify user names from a trusted domain (Ad -> FreeIPA -> sssd)
so they don’t contain “@“. Furthermore, “id username” needs to return information.
Thus bolke(a)ad.local <mailto:bolke@ad.local> needs to become bolke (or bolke_ad_local). And “id -Gn bolke” needs
to return my group memberships.
I tried setting
auth_to_local = {
RULE:[1:$1@$0](^.*@AD.LOCAL$)s/@AD.LOCAL//
DEFAULT
}
in /etc/krb5.conf, but that does not seem to work. How do I go about this?
Thanks!
Bolke
7 years, 10 months
please do not remove enumeration from AD provider
by James Ralston
On Wed, May 6, 2015 at 4:27 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> You know, just this morning, I was thinking about enumeration. It
> doesn't work for IPA views at all for example. It doesn't work for
> trusted domains at all either (except for some limited support in AD
> trusted domains that is very untested)
>
> I wonder if we could just remove enumeration from IPA and AD back
> ends in some major release.
Please don't do this.
Enumeration is a very useful feature. It allows us to do things like
this:
$ getent passwd | grep -i lastname
The equivalent ldapsearch command is much more tedious:
$ ldapsearch -z 0 -E pr=2147483647/noprompt -o ldif-wrap=no -L -L -H
'ldap:///dc%3Dexample%2Cdc%3Dorg -Y GSSAPI -N -b "dc=example,dc=org"
"(&(objectClass=user)(cn=*lastname*))" dn cn sAMAccountName
More generically, enumeration is the way Unix/Linux has always worked.
Even getting users to change from:
grep -i lastname /etc/passwd
To this:
getent passwd | grep -i lastname
...has been a struggle.
We also have various services that (unfortuantely) pre-load the passwd
and group files at startup by enumerating them with getpwent_r() and
getgrent_r(), instead of using the get*nam_r() and get*id_r()
functions as-needed. These services break outright if enumeration is
disabled.
(Yes, these services are broken. Yes, they shouldn't do that. But our
ability to fix them is extremely limited at best, because we don't
control them.)
Finally, we have many systems that cannot be joined to Active
Directory (for policy reasons, not technical reasons). But we want to
use the same passwd/group entries on those systems as returned by sssd
on hosts that are joined to Active Directory. We do this by scraping
the output of "getent -s sss passwd" and "getent -s sss group" and
manually merging it into the local passwd and group files
(respectively) on these hosts.
> It's just a legacy feature, so those who need it can fall back to
> the LDAP provider..
But the LDAP provider doesn't support ID mapping; only the AD provider
does. And ID mapping is the main reason we use sssd.
I'm not asking you to make enumeration the default. It shouldn't be;
it should be something you only turn on if you need it, and you KNOW
you need it. But if you need it, you NEED it. Please don't take it
away.
7 years, 10 months
SSSD Client Auth on LDAP Server -both Client & Server CentOS6.7
by steven.murdoch＠cdk.com
Hi - I am new to SSSD and LDAP, and my first posting - so please bare with me.
# getent passwd only displays the local users - will not display the LDAP users and is driving me insane - ldapsearch seems to work
I am using SSSD with TLS to authenticate to LDAP Server
The CA.crt files were self signed certificates.
I used # cacertdir_rehash to create to create the sym-link to the CA.crt on both Client and Server
My LDAP Server hostname is 'ActDir-VM-Test'
My SSSD Client hostname is 'SSSD-VM-Test'
Here are my files:
Server - /etc/openldap/slapd.conf:
allow bind_v2
allow bind_anon_dn
pidfile /var/run/openldap/slapd.pid
argsfile /var/run/openldap/slapd.args
TLSCACertificatePath /etc/openldap/cacerts
TLSCACertificateFile /etc/openldap/cacerts/CA.crt
TLSCertificateFile /etc/openldap/cacerts/server.crt
TLSCertificateKeyFile /etc/openldap/cacerts/server.key
TLSCipherSuite HIGH:MEDIUM:+TLSv1
TLSVerifyClient never
access to dn.sub="dc=vmlab,dc=ari,dc=cdk,dc=hosting"
by anonymous read
by * read
access to dn.base=""
by anonymous none
by * read
database config
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
by * none
database monitor
access to *
by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
by dn.exact="cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting" read
by * none
access to * by users read
database bdb
suffix "dc=vmlab,dc=ari,dc=cdk,dc=hosting"
checkpoint 1024 15
rootdn "cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting"
rootpw p@ssw0rd
loglevel 256
sizelimit unlimited
#
Server - ldap.conf:
TIMELIMIT 120
ssl start_tls
URI ldap://ActDir-VM-Test:389/
BASE cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting
TLS_REQCERT allow
TLSCACertificatePath /etc/openldap/cacerts
TLSCACertificateFile /etc/openldap/cacerts/CA.crt
#
Server - /etc/sysconfig/ldap:
SLAPD_LDAP=yes
# Run slapd with -h "... ldapi:/// ..."
# yes/no, default: yes
SLAPD_LDAPI=no
# Run slapd with -h "... ldaps:/// ..."
# yes/no, default: no
SLAPD_LDAPS=no
#
Server - /etc/pam.d/password-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
#
Server: - /etc/pam.d/system-auth-ac
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3 type=
password sufficient pam_unix.so md5 shadow nullok try_first_pass use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid
session required pam_unix.so
session optional pam_sss.so
#
Server - /etc/nsswitch.conf
passwd: files sss
shadow: files sss
group: files sss
#
Client - /etc/sssd/sssd.conf:
[sssd]
services = nss, pam
config_file_version = 2
domains = vmlab
authconfig --enablesssd --enablesssdauth --enablelocauthorize --enableldap --enableldaptls --enableldapauth --ldapserver=ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389 --ldapbasedn=dc=vmlab,dc=ari,dc=cdk,dc=hosting --disablekrb5 --disablenis --enablerfc2307bis --enablemkhomedir --enablecachecreds --update
[domain/vmlab]
id_provider = ldap
auth_provider = ldap
# Timming
entry_cache_timeout = 600
ldap_network_timeout = 3
ldap_uri = ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389
ldap_user_search_base = dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting
ldap_tls_reqcert = demand
cache_credentials = True
ldap_tls_cacertdir = /etc/openldap/cacerts
ldap_access_filter = memberOf=CN=Manager,OU=Users,DC=ActDir-VM-Test,DC=vmlab,DC=ari,DC=cdk,DC=hosting
ldap_tls_cacert = /etc/openldap/cacerts/CA.crt
ldap_tls_reqcert = demand
ldap_default_bind_dn = cn=Manager,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
ldap_default_authtok_type = password
ldap_default_authtok = p@ssw0rd
enumerate = true
[nss]
filter_users = root, sshd, named, avahi, haldaemon, dbus, radiusd, news, nscd
filter_groups = root, sshd, named, avahi, haldaemon, dbus, radiusd, news, nscd
reconnection_retries = 3
entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
debug_level = 6
[pam]
reconnection_retries = 3
#
The enumerate = True will only be enabled during testing - if I ever get it working - then it will be removed.
Client - /etc/openldap/ldap.conf:
idle_timelimit 3600
TIMELIMIT 120
bind_timelimit 120
SASL_NOCANON on
TLSCACertificatePath /etc/openldap/cacerts
TLSCACertificateFile /etc/openldap/cacerts/CA.crt
#TLS_CACERTDIR /etc/openldap/cacerts
#TLS_CACERT /etc/openldap/cacerts/CA.crt
#TLS_CACERT /etc/openldap/cacerts/19913717.0
ssl start_tls
TLS_REQCERT allow
HOST ActDir-VM-Test.vmlab.ari.cdk.hosting
BASE dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting
URI ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting:389
TLS_CACERTDIR /etc/openldap/cacerts
ldap_default_bind_dn cn=Manager,dc=vmlab,dc=ari,dc=cdk,dc=hosting
ldap_default_authtok p@ssw0rd
BINDDN uid=Manager,ou=Users,dc=ActDir-VM-Test,dc=vmlab,dc=ari,dc=cdk,dc=hosting
#
Client - the PAM files password-auth-ac and the system-auth-ac files are the same as the Server:
Client - nsswitch.conf:
passwd: files sss
shadow: files sss
group: files sss
uid Manager
gid ldap
#base CN=vmlab,OU=Users,DC=vmlab,DC=ari,DC=cdk,DC=hosting
base DC=vmlab,DC=ari,DC=cdk,DC=hosting
uri ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting
#
Client - ldapsearch:
# ldapsearch -x -ZZ -H ldap://ActDir-VM-Test.vmlab.ari.cdk.hosting -b dc=vmlab,dc=ari,dc=cdk,dc=hosting objectclass=*
# extended LDIF
#
# LDAPv3
# base <dc=vmlab,dc=ari,dc=cdk,dc=hosting> with scope subtree
# filter: objectclass=*
# requesting: ALL
#
# vmlab.ari.cdk.hosting
dn: dc=vmlab,dc=ari,dc=cdk,dc=hosting
objectClass: dcObject
objectClass: organization
dc: vmlab
o: vmlab
# Users, vmlab.ari.cdk.hosting
dn: ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
objectClass: organizationalUnit
ou: Users
# Steve xxxxxxxxx, Users, vmlab.ari.cdk.hosting
dn: cn=Steve Murdoch,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Steve xxxxxxxx
sn: xxxxxxxx
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: sxxxxxxxx
# Bob Jones, Users, vmlab.ari.cdk.hosting
dn: cn=Bob Jones,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Bob Jones
sn: Jones
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: bjones
# Tom xxxxxxxx, Users, vmlab.ari.cdk.hosting
dn: cn=Tom xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Tom xxxxxxxx
sn: xxxxxxxx
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: txxxxxxxx
# Max xxxxxxxx, Users, vmlab.ari.cdk.hosting
dn: cn=Max xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Max xxxxxxxx
sn: xxxxxxxx
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: mxxxxxxxx
# Platform, Users, vmlab.ari.cdk.hosting
dn: cn=Platform,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Platform
objectClass: groupOfNames
member: cn=Bob Jones,cn=Steve xxxxxxxx,cn=Tom xxxxxxxx,cn=Max xxxxxxxx,ou=Users
,dc=vmlab,dc=ari,dc=cdk,dc=hosting
member: cn=Rod Stewart,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
member: cn=Steve xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
member: cn=Tom xxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
# mpitman, Users, vmlab.ari.cdk.hosting
dn: uid=mxxxxxxxx,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: Mike xxxxxxxx
sn: xxxxxxxx
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: mxxxxxx
# root, Users, vmlab.ari.cdk.hosting
dn: uid=root,ou=Users,dc=vmlab,dc=ari,dc=cdk,dc=hosting
cn: root
sn: root
objectClass: inetOrgPerson
userPassword:: cEBzc3cwcmQ=
uid: root
# search result
search: 3
result: 0 Success
# numResponses: 10
#
Any help much appreciated - thanks a lot.
7 years, 10 months
Re: disable ad backend group filtering? (was Re: Re: speeding up iterative enumeration?)
by James Ralston
On Wed, Jan 27, 2016 at 4:07 AM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Tue, Jan 26, 2016 at 05:50:06PM -0500, James Ralston wrote:
>
> > It's a long story, but what we are trying to do here is to take
> > regular snapshots of our AD users and groups, and sssd's
> > getpwnam()/getgrnam() mapping is the perfect way to do it. I
> > think I understand why distribution groups are filtered by default
> > (they're not security-enabled in AD, and can't be used in Windows
> > ACLs), but in this one particular case, we really do want to be
> > able to enumerate every single group.
>
> can you try setting:
> ldap_group_type = nosuchattr
> ?
>
> That should trick sssd into not seeing the group type at all and
> would avoid filtering I guess (not tested).
Unfortunately, this doesn't work: if sssd can't determine the group
type, it filters ALL groups, instead of filtering no groups.
Hmmm. If sssd can't determine the group type, wouldn't it be better
to filter no groups, instead of all groups? Because filtering all
groups is essentially the same thing as disabling group lookups
entirely. That doesn't seem like the best behavior to choose.
Then again, maybe a cleaner approach would be to add a
ldap_group_filtering option, and make the default value true (filter
groups that aren't security groups)? Tricking sssd by telling it to
look at the wrong field for the group type seems like a hack. :-(
7 years, 10 months
disable ad backend group filtering? (was Re: Re: speeding up iterative enumeration?)
by James Ralston
On Tue, Jan 26, 2016 at 3:03 PM, Jakub Hrozek <jhrozek(a)redhat.com> wrote:
> On Tue, Jan 26, 2016 at 02:19:42PM -0500, James Ralston wrote:
>
>> Here's the problem: unless the user/group objects already happen to be
>> in sssd's cache, enumerating the passwd/group entries in this way is
>> very slow: 3-5 entries per second, at best. For a larger AD domain,
>> the program can take 10-15 minutes to perform this iterative
>> enumeration, which is much longer than we'd prefer.
>>
>> Can anyone think of a way to make this iterative enumeration go
>> faster?
>
> Did you try mounting the cache to tmpfs to get rid of the cache writes?
>
> [...]
That's… a very clever idea.
From testing using tmpfs to back /var/lib/sss/db, the speed of lookups
increases by about an order of magnitude: about 44 lookups per second,
instead of 4-5 lookups per second. We have around 5,000 AD objects,
so the ~100 second wait would be tolerable.
A related question: is there any possibility of adding an option
to the ad backend to disable the filtering of distribution
groups (group type flag 0x8)?
It's a long story, but what we are trying to do here is to take
regular snapshots of our AD users and groups, and sssd's
getpwnam()/getgrnam() mapping is the perfect way to do it. I think I
understand why distribution groups are filtered by default (they're
not security-enabled in AD, and can't be used in Windows ACLs), but in
this one particular case, we really do want to be able to enumerate
every single group.
7 years, 10 months
