sssd performance on large domains
by zfnoctis＠gmail.com
Hi,
I'm wondering if there are any plans to improve sssd performance on large active directory domains (100k+ users, 40k+ groups), or if there are settings I am not aware of that can greatly improve performance, specifically for workstation use cases.
Currently if I do not set "ignore_group_members = True" in sssd.conf, logins can take upwards of 6 minutes and "sssd_be" will max the CPU for up to 20 minutes after logon, which makes it a non-starter. The reason I want to allow group members to be seen is that I want certain domain groups to be able to perform elevated actions using polkit. If I ignore group members, polkit reports that the group is empty and so no one can elevate in the graphical environment.
Ultimately this means that Linux workstations are at a severe disadvantage since they cannot be bound to the domain and have the normal set of access features users and IT expect from macOS or Windows.
Distributions used: Ubuntu 16.04 (sssd 1.13.4-1ubuntu1.1), Ubuntu 16.10 (sssd 1.13.4-3) and Fedora 24 (sssd-1.13.4-3.fc24). All exhibit the same problems.
I've also tried "ldap_group_nesting_level = 1" without seeing any noticeable improvement with respect to performance. Putting the database on /tmp isn't viable as these are workstations that will reboot semi-frequently, and I don't believe this is an I/O bound performance issue anyways.
Thanks for your time.
1 year, 8 months
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...
3 years, 10 months
SSSD strangeness
by simonc99＠hotmail.com
Hi All
We've got SSSD 1.13.0 installed as part of a Centos 7.2.1511 installation.
We've used realmd to join the host concerned to our 2008R2 AD system. This went really well, and consequently we've been using SSSD to provide login services and kerberos integration for our fairly large hadoop system.
The authconfig that's implicitly run as part of realmd produces the following sssd.conf:
[sssd]
domains = <joined domain>
config_file_version = 2
services = nss, pam
[pam]
debug_level = 0x0080
[nss]
timeout = 20
force_timeout = 600
debug_level = 0x0080
[domain/<joined domain>]
ad_domain = <joined domain>
krb5_realm = <JOINED DOMAIN>
realmd_tags = manages-system joined-with-samba
cache_credentials = true
id_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = True
use_fully_qualified_names = False
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = <AD group allowing logins>
krb5_use_kdc_info = False
entry_cache_timeout = 300
debug_level = 0x0080
ad_server = <active directory server>
As I've said - this works really well. We did have some stability issues initially, but they've been fixed by defining the 'ad_server' rather than using autodiscovery.
Logins work fine, kerberos TGTs are issued on login, and password changes are honoured correctly.
However, in general day to day use, we have noticed a few anomalies, that we just can't track down.
Firstly (this has happened a few times), a user will change their AD password (via a Windows PC).
Subsequent logins - sometimes with specific client software - fail with
pam_sss(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=<remote PC name> user=<username>
pam_sss(sshd:auth): received for user <username>: 17 (failure setting user credentials)
So in this example, the person concerned has changed their AD password. Further attempts to access this system via SSH work fine. However, using SFTP doesn't work (the above is output into /var/log/secure).
There are no local controls on sftp logins, and the user concerned was working fine (using both sftp and ssh) until they updated their password.
There is no separate sftp daemon running, and it only affects one individual currently (but we have seen some very similar instances before)
The second issue we have is around phantom groups in AD.
Hadoop uses an id -Gn command to see group membership for authorisation.
With some users - we've seen 6 currently - we see certain groups failing to be looked up:
id -Gn <username>
id: cannot find name for group ID xxxxyyyyy
<group name> <group name> <group name> <group name> <etc...>
The xxxxyyyyy indicates:
xxxx = hashed realm name
yyyyy = RID from group in AD
We can't find any group with that number on the AD side!
We can work around this by adding a local group (into /etc/group) for the GIDs affected. This means the id -Gn runs correctly, and the hadoop namenode can function correctly - but this is a workaround and we'd like to get to the bottom of the issue.
Rather than flooding this post now with logfiles, just thought I'd see if this looked familiar to anyone. Happy to upload any logs, amend logging levels, etc.
Many thanks
Simon
3 years, 11 months
1.16.2 test failure: sss_nss_idmap-tests
by Andreas Hasenack
Hi,
I'm building 1.16.2 with just
https://pagure.io/SSSD/sssd/c/a2cc554f438c220b3cc73eb93879dd87795a86cd?br...
applied (without it, it doesn't build in Ubuntu currently) and I'm
seeing this test failure:
[==========] Running 2 test(s).
[ RUN ] test_getsidbyname
[ ERROR ] --- 0x2 != 0
[ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:121: error: Failure!
[ FAILED ] test_getsidbyname
[ RUN ] test_getorigbyname
[ ERROR ] --- 0x2 != 0
[ LINE ] --- ../src/tests/cmocka/sss_nss_idmap-tests.c:140: error: Failure!
[ FAILED ] test_getorigbyname
[==========] 2 test(s) run.
[ PASSED ] 0 test(s).
[ FAILED ] 2 test(s), listed below:
[ FAILED ] test_getsidbyname
[ FAILED ] test_getorigbyname
2 FAILED TEST(S)
FAIL sss_nss_idmap-tests (exit status: 2)
I tried with samba 4.7.6 and 4.8.2 installed, and also with
--with-smb-idmap-interface-version 5 and 6, same result. Debian is at
1.16.2 and the tests pass there just fine, so I think I'm looking at
some dependency problem.
ldb is 1.3.1
tdb is 1.3.15
Any pointers? Maybe a way to run just that test, so I can add
debugging statements?
Thanks!
5 years, 1 month
id: cannot find name for group ID
by Mario Rossi
Hi All!
I am running into an issue where groups cannot be resolved upon login.
All servers on CentOS 6 work fine, so this is isolated to newer sssd
version on CentOS 7.
[user@snoopy ~]$ id
uid=100001012(user) *gid=1001* *groups=1001*,10(wheel),1102
[user@snoopy ~]$ getent -s sss passwd user
user:*:100001012:1001:User Name:/home/user:/bin/bash
However, a quick lookup against the group:
[user@snoopy ~]$ *getent -s sss group security*
security:*:1001:user
Subsequent id lookup works:
[user@snoopy ~]$ id
uid=100001012(user) *gid=1001(security)
**groups=1001(security)*,10(wheel),1102
Sudo also complains about the user, even after above command succeeds
[user@snoopy ~]$*sudo su -*
*sudo: unknown uid 100001012: who are you?*
A few seconds later sudo is no longer confused:
[user@snoopy ~]$*sudo su -*
*LDAP OnePassword for **user**:*
root@snoopy[~]#
SSSD config:
[sssd]
config_file_version = 2
sbus_timeout = 30
services = nss, pam, sudo, ssh
# BOUNCE DEV
domains = LOCAL, HOSTOPIA, DOMAIN1, DOMAIN2, DOMAIN3
[nss]
filter_users =
adm,apache,avahi,bin,daemon,dbus,ecryptfs,ftp,git,games,gopher,haldaemon,halt,hfallback,hdeploy,influxdb,ldap,lp,mail,mailnull,named,news,nfsnobody,nobody,nscd,nslcd,ntp,operator,oprofile,osse
c,postfix,puppet,puppet-dashboard,pulse,pulse-access,radiusd,root,rpc,rpcuser,rtkit,saslauth,sfallback,shutdown,slocate,smmsp,sshd,sync,tcpdump,tss,uucp,vcsa
filter_groups =
adm,apache,audio,bin,cdrom,cgred,daemon,dbus,dialout,dip,disk,ecryptfs,floppy,fuse,git,hfallback,hdeploy,influxdb,kmem,ldap,lock,lp,mail,mailnull,man,mem,nfsnobody,nobody,nscd,ntp,ossec,oprof
ile,postdrop,postfix,puppet,puppet-dashboard,pulse,pulse-access,root,rpc,rpcuser,rtkit,saslauth,sfallback,slocate,smmsp,sshd,sys,tape,tcpdump,tss,tty,users,utempter,utmp,vcsa,video
[pam]
debug_level = 0
reconnection_retries = 3
offline_credentials_expiration = 2
offline_failed_login_attempts = 3
offline_failed_login_delay = 5
pam_verbosity = 1
pam_pwd_expiration_warning = 21
pam_account_expired_message = Your LDAP password has expired, please use
selfservice portal to change your LDAP password.
[sudo]
debug_level = 0
[ssh]
# debug_level = 0
[domain/LOCAL]
description = LOCAL Users domain
id_provider = local
enumerate = true
min_id = 500
max_id = 999
default_shell = /bin/bash
base_directory = /home
create_homedir = false
remove_homedir = true
homedir_umask = 077
skel_dir = /etc/skel
mail_dir = /var/spool/mail
All domains have the following options set:
######### SECTION: HOSTOPIA
[domain/HOSTOPIA]
min_id = 499
debug_level = 0
cache_credentials = True
entry_cache_timeout = 864000
auth_provider = ldap
id_provider = ldap
access_provider = ldap
chpass_provider = none
sudo_provider = ldap
selinux_provider = none
autofs_provider = none
hostid_provider = none
ldap_use_tokengroups = false
#
https://jhrozek.wordpress.com/2015/08/19/performance-tuning-sssd-for-larg...
#ignore_group_members=True
lookup_family_order = ipv4_only
# LDAP Search
ldap_search_base = dc=hostopia,dc=com
ldap_group_search_base =
ou=groups,o=Hostopia,dc=hostopia,dc=com?subtree?(|(cn=almighties)(cn=security)(cn=systems)(cn=bounce-development)(cn=development-wholesale)(cn=development-retail)(cn=abuse))
ldap_user_search_base =
ou=users,o=hostopia,dc=hostopia,dc=com?subtree?(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hostopia,dc=hostopia
,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com))
# LDAP Custom Schema
ldap_group_member = hMemberDN
ldap_user_member_of = description
# ldap_schema can be set to "rfc2307", which stores group member names
in the
# "memberuid" attribute, or to "rfc2307bis", which stores group member
DNs in
# the "member" attribute. If you do not know this value, ask your LDAP
# administrator.
ldap_schema = rfc2307bis
ldap_network_timeout = 3
ldap_id_use_start_tls = False
ldap_tls_reqcert = never
ldap_tls_cacertdir = /etc/openldap/cacerts
# Ldap Servers
ldap_uri = ldaps://SERVER1, ldaps://SERVER2, ldaps://SERVER3
ldap_backup_uri = ldaps://1.1.1.1
ldap_default_authtok_type = obfuscated_password
ldap_default_bind_dn = ****
ldap_default_authtok = ******
ldap_user_ssh_public_key = sshPublicKey
ldap_pwd_policy = none
ldap_account_expire_policy = shadow
ldap_user_shadow_expire = shadowExpire
# shadowExpire: days since Jan 1, 1970 that account is disabled: $ echo
$(($(date --utc --date "$1" +%s)/86400))
ldap_chpass_update_last_change = false
ldap_access_order = filter, expire
ldap_access_filter =
(&(objectClass=posixAccount)(uidNumber=*)(hAccountInitialSetup=1)(|(description=cn=bounce-development,ou=groups,o=Hostopia,dc=hostopia,dc=com)(description=cn=almighties,ou=groups,o=Hosto
pia,dc=hostopia,dc=com)(description=cn=security,ou=groups,o=Hostopia,dc=hostopia,dc=com)))
# SUDO
ldap_sudo_search_base = ou=sudoers,o=Hostopia,dc=hostopia,dc=com
ldap_sudo_full_refresh_interval = 86400
ldap_sudo_smart_refresh_interval = 3600
#entry_cache_sudo_timeout = 5400
##### END DOMAIN SECTION #####
5 years, 1 month
sssd connecting to two AD domains
by Ondrej Valousek
Hi all,
I have a machine joined to AD domain "mydomain.com" and there is also domain "mydomain2.com". The two are connected with full two way trust.
SSSD can happily recognize users from "mydomain.com", but fails with users from "mydomain2.com" - sssd complains that:
(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x1000): Port status of port 389 for server 'server.mydomain2.com' is 'not working'
(Mon Jul 30 08:26:38 2018) [sssd[be[adesto]]] [get_port_status] (0x0080): SSSD is unable to complete the full connection request, this internal status does not necessarily indicate network port issues.
But I can connect to that server with ldapsearch just fine (using a TGT obtained with kinit -k hostname$).
Earlier in the logs I spotted that SSSD is trying to obtain TGT with a wrong principal "host/hostname@REALM" instead of "hostname$@REALM":
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Client 'host/hostname(a)mydomain.COM' not found in Kerberos database], expired on [0]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address]
(Mon Jul 30 08:32:34 2018) [sssd[be[adesto]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158226](Authentication Failed)
I am wondering why is SSSD trying now, all of sudden, to obtain a TGT using wrong principal?
Using RHEL-7.
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.
5 years, 1 month
sssd 1.9.6
by Laack, Andrea P
I downloaded sssd 1.9.6 for centos 5 from https://copr-be.cloud.fedoraproject.org/results/sgallagh/sssd-1.9-rhel5/e....
Unfortunately the contents of krb5-1.12.2-14.fc21/ are not there. I have downloaded krb5-workstation, libs, and devel for krb-1.12.2-14 from other places, but the list of dependencies are daunting. Is there anyplace I can get the original contents of this directory?
Thanks
Andrea
Andrea Laack
Host Systems
[cid:image002.jpg@01D428D3.44B28E30]
2401 S. 31st Street
Temple, TX 76508
Mailstop: MS-2-1.41
Office: 254-724-9490
andrea.laack(a)bswhealth.org<mailto:andrea.laack@bswhealth.org>
[cid:image003.png@01D428D0.527EFE70] <https://www.youracclaim.com/badges/d2b9b13f-0db9-4666-860e-146c70d45d36> [cid:image004.png@01D428D0.527EFE70]
**********************************************************************
The information contained in this e-mail may be privileged and/or confidential, and protected from disclosure, and no waiver of any attorney-client, work product, or other privilege is intended. If you are the intended recipient, further disclosures are prohibited without proper authorization. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail is strictly forbidden and possibly a violation of federal or state law and regulations. The sender and Baylor Scott & White Health, and its affiliated entities, hereby expressly reserve all privileges and confidentiality that might otherwise be waived as a result of an erroneous or misdirected e-mail transmission. No employee or agent is authorized to conclude any binding agreement on behalf of Baylor Scott & White Health, or any affiliated entity, by e-mail without express written confirmation by the CEO, the Senior Vice President of Supply Chain Services or other duly authorized representative of Baylor Scott & White Health.
5 years, 2 months
one user can't be looked up
by Peter Moody
(apologies if this gets sent twice, there was apparently an issue with
my subscription to the sssd-users list)
this is admittedly low priority since this is all just a test network
at this point, but we're looking to deploy sssd at work so I'd like to
make sure all the kinks I know about are well understood/fixed
I have an openldap install with the following users (pmoody, peter)
with uidNumbers (1001, 1002) respectively.
sssd works for both users from freebsd 11.2 prelease (sssd-1.11.7_11,
whew, that's old).
sssd works for pmoody from debian stretch (1.15.0-3). it does *not*
work for the user peter.
this is what happens for the user peter.
pmoody@deb:~$ sudo sss_cache -E
pmoody@deb:~$ getent passwd pmoody
pmoody:*:1001:500:Peter Moody:/home/pmoody:/bin/bash
pmoody@deb:~$ getent passwd peter
pmoody:*:1001:500:Peter Moody:/home/pmoody:/bin/bash
pmoody@deb:~$
I've tried version 1.16.1-1, same results.
These are the ldap entries for the aforementioned users:
# peter, people, x.com
dn: uid=peter,ou=people,dc=x,dc=com
cn: peter
givenName: peter
sn: moody
uid: peter
uidNumber: 1002
homeDirectory: /home/peter
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
gidNumber: 500
loginShell: /usr/local/bin/fish
# pmoody, people, x.com
dn: uid=pmoody,ou=people,dc=x,dc=com
cn: Peter Moody
givenName: Peter
sn: Moody
uid: pmoody
uidNumber: 1001
homeDirectory: /home/pmoody
objectClass: top
objectClass: posixAccount
objectClass: shadowAccount
objectClass: inetOrgPerson
objectClass: organizationalPerson
loginShell: /usr/local/bin/fish
gidNumber: 500
on the debian box that exhibits this error, I see the following in the logs:
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [ldb] (0x4000): cancel
ldb transaction (nesting: 2)
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]]
[sysdb_set_cache_entry_attr] (0x0080): ldb_modify failed: [No such
object](32)[ldb_wait from ldb_modify with LDB_WAIT_ALL: No such object
(32)]
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]]
[sysdb_set_cache_entry_attr] (0x0400): No such entry
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_set_entry_attr]
(0x0080): Cannot set attrs for
name=peter(a)x.com,cn=users,cn=x.com,cn=sysdb, 2 [No such file or
directory]
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_store_user]
(0x0040): Cache update failed: 2
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [ldb] (0x4000): cancel
ldb transaction (nesting: 1)
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sysdb_store_user]
(0x0400): Error: 2 (No such file or directory)
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sdap_save_user]
(0x0020): Failed to save user [peter(a)x.com]
(Mon Jun 18 20:39:44 2018) [sssd[be[x.com]]] [sdap_save_users]
(0x0040): Failed to store user 0. Ignoring.
it kind of looks like what was reported here :
https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahoste...
but I don't see a resolution to that report.
any suggestions on what I can do to fix this? logs/configs I can
provide to help isolate the problem?
Cheers,
peter
5 years, 2 months
Missing group memberships with sssd (when using tokengroups)
by Spike White
All,
Below is a writeup of missing AD groups for accounts when using
tokengroups. When not using tokengroups, sssd is rock solid.
Yes, most of the missing AD groups are universal or global groups -- but
not all! For some accounts, even domain-local AD groups are missed from
their group memberships. (when using tokengroups).
*Missing group memberships with sssd (when using tokengroups):*
July, 2018.
Cross-subdomain AD authentication partially working. (fully working with
ldap_use_tokengroups = False)
When set ldap_use_tokengroups = True, some AD groups for some accounts
missing. Full details below.
Test server is in AMER.DELL.COM
*Accounts and their missing AD group memberships (when ldap_use_tokengroups
= True)*
*AdmJesse_Chan *(account resides in APAC.DELL.COM)
tokengroups-enabled SSSD reports membership in:
uid=525641(admjesse_chan) gid=525641(admjesse_chan)
groups=525641(admjesse_chan),1008(apacunixusers),1000(apaclinuxeng),1001(apaclinuxsup)
vas-enabled Linux server reports membership in:
uid=525641(admjesse_chan) gid=525641(admjesse_chan)
groups=525641(admjesse_chan),1000(apaclinuxeng),1001(apaclinuxsup),1008(apacunixusers),
1041(linux-core-engineering),1069(users)
diff is:
1041(linux-core-engineering),1069(users)
Both are AMER-only "local domain" groups.
linux-core-engineering is a AMER-only "domain local" group with GID
1041.
And actually, admjesse_chan is a member of 'users', but that's an
APAC.DELL.COM domain AD group (that's not unix-enabled).
VAS is (mistakenly) reporting Jesse as a member of the AMER.DELL.COM
'users' group, which has a GID of 1069.
*AdmPaulBowen *(account resides in EMEA.DELL.COM)
tokengroups-enabled SSSD reports membership in:
uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen)
groups=2103156(admpaul_bowen),1009(emeaunixusers)
vas-enabled Linux server reports membership in:
uid=2103156(admpaul_bowen) gid=2103156(admpaul_bowen)
groups=2103156(admpaul_bowen),1153(emea_server_mgmt),1005(emealinuxsup)
,1009(emeaunixusers)
diff is:
1153(emea_server_mgmt),1005(emealinuxsup),
EMEA_SERVER_MGMT is a universal AD group. with GID 1153.
EMEALINUXSUP is a universal AD group. with GID 1005.
EMEAUNIXUSERS is a global AD group. with GID 1009.
*AdmDennis_Kennedy* (account resides in EMEA.DELL.COM)
tokengroups-enabled SSSD:
uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy)
groups=2890335(admdennis_kennedy),1009(emeaunixusers)
vas:
uid=2890335(admdennis_kennedy) gid=2890335(admdennis_kennedy)
groups=2890335(admdennis_kennedy),1153(emea_server_mgmt),1004(emealinuxeng),
1009(emeaunixusers),1041(linux-core-engineering)
diff:
1153(emea_server_mgmt),1004(emealinuxeng),1041(linux-core-engineering)
EMEA_SERVER_MGMT is a universal AD group. with GID 1153.
EMEALINUXENG is a universal AD group. with GID 1003.
linux-core-engineering is a AMER-only "domain local" group with GID 1041.
*AdmSpike_White* (account resides in AMER.DELL.COM)
tokengroups-enabled SSSD:
uid=2025431(admspike_white) gid=2025431(admspike_white)
groups=2025431(admspike_white),1002(amerlinuxeng)
vas:
uid=2025431(admspike_white) gid=2025431(admspike_white)
groups=2025431(admspike_white),1002(amerlinuxeng),
1041(linux-core-engineering),1069(users)
diff:
1041(linux-core-engineering),1069(users)
linux-core-engineering is a AMER-only "domain local" group with GID 1041.
users is an AMER-only "builtin local" group with GID 1069.
*AdmCesar_Guillen* (account found in AMER.DELL.COM)
NOTE: AdmCesar_Guillen is found in AMERICAS.
tokengroups-enabled SSSD:
uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen)
groups=2669411(admcesar_guillen),1010(amerunixusers)
vas:
uid=2669411(admcesar_guillen) gid=2669411(admcesar_guillen)
groups=2669411(admcesar_guillen),1033(amer_server_mgmt),1002(amerlinuxeng)
,1010(amerunixusers),2284031(esg_bios_code_rw)
diff:
1033(amer_server_mgmt),1002(amerlinuxeng),2284031(esg_bios_code_rw)
amer_server_mgmt is an AMER global group with GID 1033. <--- why is sssd
not reporting this?!?
amerlinuxeng is a universal AD group with GID 1002. <---------- why is
sssd not reporting this?!? It's reported for AdmSpike_White, but not for
AdmPatrick_Wheeler or AdmCesar_Guillen.
esg_bios_code_rw is a universal AD group with GID 2284031. <---------- why
is sssd not reporting this?!?
*Admpatrick_wheeler* (account resides in AMER.DELL.COM)
tokengroups-enabled SSSD:
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1010(amerunixusers)
tokengroups-disabled SSSD:
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),1033(amer_server_mgmt),1010(amerunixusers),1003(amerlinuxsup),1156(gbl_server_support),2284161(amerserveradministrator),2283573(dfs_gil_sit_auth),2283577(delta_bd_create_emea),2283643(gebs_read_prd),2283611(xxgl0370_prod),2283578(delta_bd_create),2283256(infa_developer),2283623(xxgl0363_prod),2283615(xxgl0503_prod),2283607(xxpa2891_prod),2283869(cowcprodsupport)
vas:
uid=2604370(admpatrick_wheeler) gid=2604370(admpatrick_wheeler)
groups=2604370(admpatrick_wheeler),
1033(amer_server_mgmt),1003(amerlinuxsup),1010(amerunixusers)
diff is:
1033(amer_server_mgmt)
1003(amerlinuxsup)
amer_server_mgmt is an AMER global group with GID 1033. <--- why is sssd
not reporting this?!?
amerlinuxsup is an AMER universal group with GID 1003.
Here is my /etc/sssd/sssd.conf file:
[nss]
debug_level = 9
filter_groups = root
filter_users = root
#entry_cache_timeout = 300
entry_cache_nowait_percentage = 75
[sssd]
debug_level = 6
#domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com,dell.com
domains = amer.dell.com,apac.dell.com,emea.dell.com,japn.dell.com
# Unnecessary. If missing, will search in order specified in "domains"
lines above.
#domain_resolution_order = amer.dell.com, emea.dell.com, apac.dell.com,
japn.dell.com, dell.com
config_file_version = 2
services = nss,pam
reconnection_retries = 3
#ldap_user_member_of = member
[pam]
pam_verbosity = 3
debug_level = 9
[domain/amer.dell.com]
debug_level = 9
id_provider = ad
access_provider = simple
#access_provider = ad
auth_provider = ad
ad_domain = amer.dell.com
krb5_realm = AMER.DELL.COM
default_shell = /bin/bash
#use_fully_qualified_names = False
ldap_id_mapping = False
subdomains_provider = none
auto_private_groups = True
realmd_tags = joined-with-adcli
cache_credentials = True
krb5_store_password_if_offline = True
fallback_homedir = /home/%u
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
#TEST REMOVAL. July 4 2018. SW
#ad_enabled_domains = amer.dell.com,apac.dell.com,emea.dell.com,
japn.dell.com,dell.com
dyndns_update = False
# TEST -- commented out July 4 to not use tokengroups.
ldap_use_tokengroups = False
simple_allow_groups = amerlinuxsup(a)AMER.DELL.COM, amerlinuxeng(a)AMER.DELL.COM,
emealinuxsup(a)EMEA.DELL.COM, AMER.DELL.COM, emealinuxeng(a)EMEA.DELL.COM,
apaclinuxsup(a)EMEA.DELL.COM, apaclinuxeng(a)EMEA.DELL.COM
# also look at
https://lists.fedorahosted.org/pipermail/sssd-users/2015-February/002648....
[domain/apac.dell.com]
debug_level = 9
auto_private_groups = True
#use_fully_qualified_names = False
ad_domain = apac.dell.com
krb5_realm = APAC.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
#TEST REMOVAL. July 4 2018. SW
#ad_enabled_domains = amer.dell.com, apac.dell.com, apac.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
# TEST -- commented out July 4 to not use tokengroups.
ldap_use_tokengroups = False
simple_allow_groups = apaclinuxsup(a)APAC.DELL.COM, apaclinuxeng(a)APAC.DELL.COM
[domain/emea.dell.com]
debug_level = 9
auto_private_groups = True
#use_fully_qualified_names = False
ad_domain = emea.dell.com
krb5_realm = EMEA.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
#TEST REMOVAL. July 4 2018. SW
#ad_enabled_domains = amer.dell.com, apac.dell.com, emea.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
# TEST -- commented out July 4 to not use tokengroups.
ldap_use_tokengroups = False
simple_allow_groups = emealinuxsup(a)EMEA.DELL.COM, emealinuxeng(a)EMEA.DELL.COM
[domain/japn.dell.com]
debug_level = 9
auto_private_groups = True
#use_fully_qualified_names = False
ad_domain = japn.dell.com
krb5_realm = JAPN.DELL.COM
cache_credentials = True
id_provider = ad
auth_provider = ad
krb5_store_password_if_offline = True
default_shell = /bin/bash
ldap_id_mapping = False
fallback_homedir = /home/%u
access_provider = simple
ldap_schema = rfc2307bis
ldap_sasl_authid = host/spikerealmd02.us.dell.com(a)AMER.DELL.COM
#ldap_sasl_authid = SPIKEREALMD02$(a)AMER.DELL.COM
#ldap_sasl_authid = spikerealmd02(a)AMER.DELL.COM
#TEST REMOVAL. July 4 2018. SW
#ad_enabled_domains = amer.dell.com, apac.dell.com, japn.dell.com,
japn.dell.com, dell.com
dyndns_update = False
subdomains_provider = none
# TEST -- commented out July 4 to not use tokengroups.
ldap_use_tokengroups = False
simple_allow_groups = japnlinuxsup(a)JAPN.DELL.COM, japnlinuxeng(a)JAPN.DELL.COM
5 years, 2 months
Group members are ignored, nothing to do. If you see this message it might indicate an error in the group processing logic.
by TomK
Hey Guy's,
After implementing the LDAP_MATCHING_RULE_IN_CHAIN , we're seeing these
messages in the sssd domain log file:
(Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17444] failed with status [1].
(Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17451] failed with status [1].
(Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17457] failed with status [1].
(Tue Jul 24 12:59:41 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17463] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17469] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17477] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17486] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17493] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17500] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17506] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17512] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17519] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17525] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17532] failed with status [1].
(Tue Jul 24 12:59:42 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [17540] failed with status [1].
(Tue Jul 24 13:12:11 2018) [sssd[be[MYDOM]]] [child_sig_handler]
(0x0020): child [34068] failed with status [2].
(Tue Jul 24 13:13:54 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:15:39 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:15:39 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:16:07 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:16:07 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:17:18 2018) [sssd[be[MYDOM]]] [ad_get_slave_domain_done]
(0x0020): Unable to lookup slave domain data [110]: Connection timed out
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
(Tue Jul 24 13:19:20 2018) [sssd[be[MYDOM]]] [sdap_save_grpmem]
(0x0020): Group members are ignored, nothing to do. If you see this
message it might indicate an error in the group processing logic.
ad_access_filter =
DOM:MYDOM:(|(memberOf=CN=group01,OU=Groups,OU=MYOU,DC=MYDOM,DC=COM)(memberOf:1.2.840.113556.1.4.1941:=CN=group02,OU=Groups,OU=MYOU,DC=MYDOM,DC=COM))
python2-sssdconfig-1.15.3-0.el6.noarch
sssd-ldap-1.15.3-0.el6.x86_64
sssd-ad-1.15.3-0.el6.x86_64
sssd-ipa-1.15.3-0.el6.x86_64
sssd-1.15.3-0.el6.x86_64
sssd-krb5-common-1.15.3-0.el6.x86_64
sssd-krb5-1.15.3-0.el6.x86_64
sssd-common-pac-1.15.3-0.el6.x86_64
sssd-common-1.15.3-0.el6.x86_64
sssd-client-1.15.3-0.el6.x86_64
sssd-proxy-1.15.3-0.el6.x86_64
We're not using NFS NFS at all here. Did a number of searches but
wasn't able to find out more online. Has anyone encountered the same
and nudge me further along?
Authentication works and we can login however even with DEBUG LEVEL at
10, that's pretty much all that's printed in the above log file.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.
5 years, 2 months