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, 10 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...
4 years
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
4 years, 1 month
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, 4 months
sss_override - when to run it?
by John Hearns
We have an existing set of users in a local passwd file
I want to run sss_override to create mappings from the AD SID numbers to
the existing uid numbers.
What is the concensus on running sss_override?
I can script it to either parse through the existing passwd file and make
an override entry per user,
or to parse the file and create an import file which is run once with
import-user
But when is a good time to run this?
In a daily cron job
When sssd is started, which would involve editing the systemd unit file
Creating a new systemd service which depends on sssd.service . This service
runs sss_override and then restarts sssd.service
Or am I misunderstanding something?
I am assuming here we have on-disk sssd databases. If the databases are on
a tmpfs then clearly the sss_override must be run at boot time by one of
the above methods also.
5 years, 5 months
sss_override user-export is empty
by vadud3@gmail.com
I made a change in UID for a user with sss_override but user-export to a
file does not export anything. I am using sssd version 1.15.2. Is this a
bug or may be I am doing something wrong? I followed the steps from this
https://jhrozek.wordpress.com/2016/02/15/sssd-local-overrides/
I ran these as root
# sssd --version
1.15.2
# sss_override user-add mwvande -u 4311
# systemctl restart sssd
# sss_override user-export foo
# cat foo
(no output)
I also tried it without the restart
# sss_override user-add mwvande -u 4311
# sss_override user-export foo
# cat foo
(no output)
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
5 years, 5 months
Logging of scheduled tasks - password renewal
by John Hearns
After 30 days of running sssd I found that my test workstation no longer
connected to the domain.
The machine account password had timed out.
I now run a daily cron job using msktutil wihch will auto-update the
password.
However I should not have to do this. sssd should update the machine
password.
I can see entries in the logs such that the machine account password
renewal task is enabled.
Then:
[be_ptask_execute] (0x0400): Task [AD machine account password renewal]:
executing task, timeout 60 seconds
How though can I see if this taks is successful or not?
I realise that if the machine account is less than 30 days old the task
probably silently completes OK without any logging.
The version of sssd is 16.1 running on Ubuntu
John Hearns
5 years, 5 months
Who and w not nss aware?
by John Hearns
It seems bizarre, but the who and w utilities say there are no users on my
system.
My account is an Active Direcotry account and sssd is running.
johe@ibis:~$ who
johe@ibis:~$ w
10:09:26 up 16:47, 0 users, load average: 0.60, 0.59, 0.48
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
I guess this is known behaviour?
5 years, 5 months
sssd login fails for some users
by vadud3@gmail.com
sssd login fails for some user when point to ldaps://127.0.0.1
I checked the accounts with ldapsearch -D and there is no issue
ldapsearch -LLL -x -W -D ou=People,dc=example.dc=net -H ldaps://127.0.0.1
uid=johnny
Enter LDAP Password: (pass)
gets the ldap entry fine
When I point sssd to ldaps://corporate.ip all account login works fine
Log shows ..
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_get_account_info_handler]
(0x0200): Got request for [0x3][BE_REQ_INITGROUPS][name=johnny@ldap]
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state]
(0x1000): Domain LDAP is Active
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP
Request [Initgroups #27]: New request. Flags [0x0001].
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state]
(0x1000): Domain LDAP is Active
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP
Request [Initgroups #27]: Receiving request data.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_reply_gen_error]
(0x0080): DP Request [Initgroups #27]: Finished. Backend is currently
offline.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_table_value_destructor]
(0x0400): Removing [0:1:0x0001:3::LDAP:name=johnny@ldap] from reply table
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400):
DP Request [Initgroups #27]: Request removed.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400):
Number of active DP request: 0
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_pam_handler] (0x0100): Got
request with the following data
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
command: SSS_PAM_ACCT_MGMT
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
domain: LDAP
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
user: johnny@ldap
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
service: sshd
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100): tty:
ssh
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
ruser:
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
rhost: localhost
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
authtok type: 0
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
newauthtok type: 0
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
priv: 1
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
cli_pid: 16946
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [pam_print_data] (0x0100):
logon name: not set
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400): DP
Request [PAM Account #28]: New request. Flags [0000].
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_attach_req] (0x0400):
Number of active DP request: 1
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sss_domain_get_state]
(0x1000): Domain LDAP is Active
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_send] (0x0400):
Performing access check for user [johnny@ldap]
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_filter_send]
(0x0400): Performing access filter check for user [johnny@ldap]
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_decide_offline]
(0x0400):* Access denied by cached credentials*
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [sdap_access_done]
(0x0400): *Access
was denied*.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_done] (0x0400): DP
Request [PAM Account #28]: Request handler finished [0]: Success
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [_dp_req_recv] (0x0400): DP
Request [PAM Account #28]: Receiving request data.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400):
DP Request [PAM Account #28]: Request removed.
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_req_destructor] (0x0400):
Number of active DP request: 0
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_method_enabled] (0x0400):
Target selinux is not configured
(Tue Jun 26 18:48:10 2018) [sssd[be[LDAP]]] [dp_pam_reply] (0x1000): DP
Request [PAM Account #28]: Sending result [6][LDAP]
Jun 26 18:48:10 host sshd[16946]: pam_sss(sshd:auth): authentication
success; logname= uid=0 euid=0 tty=ssh ruser= rhost=localhost user=blodgen
Jun 26 18:48:10 host sshd[16946]: pam_sss(sshd:account): Access denied for
user blodgen: 6 (Permission denied)
Jun 26 18:48:10 host sshd[16938]: error: PAM: User account has expired for
blodgen from localhost
Here is the sssd config and using sssd version 1.16
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss,pam,sudo
domains = LDAP
homedir_substring = undef
[nss]
reconnection_retries = 3
filter_groups = root,wheel
filter_users = root
[pam]
reconnection_retries = 3
offline_credentials_expiration = 0
[sudo]
[domain/LDAP]
debug_level = 7
chpass_provider = ldap
access_provider = ldap
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307bis
ldap_id_use_start_tls = true
ldap_search_base = ou=People,dc=example,dc=net
#ldap_uri = ldaps://192.168.1.100:1636
ldap_uri = ldaps://127.0.0.1
ldap_access_order = filter
ldap_access_filter = objectClass=mnetperson
ldap_user_uid_number = mnetid
ldap_user_gid_number = mnetid
ldap_group_gid_number = mnetid
ldap_group_object_class = inetOrgPerson
ldap_user_object_class = mnetPerson
ldap_user_fullname = uid
ldap_group_name = uid
ldap_network_timeout = 3
ldap_tls_reqcert = allow
ldap_tls_cacert = /etc/ssl/certs/host.cer
ldap_chpass_update_last_change = true
ldap_pwd_policy = none
ldap_account_expire_policy = none
ldap_default_authtok_type = password
ldap_default_bind_dn = uid=binduid,ou=People,dc=example,dc=net
ldap_default_authtok = secret
enumerate = false
sudo_provider = ldap
ldap_sudo_search_base = ou=People,dc=example,dc=net
ldap_sudorule_object_class = mnetperson
cache_credentials = true
default_shell = /bin/bash
fallback_homedir = /home/%u
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
5 years, 5 months
CVE-2018-10852: information leak from the sssd-sudo responder
by Jakub Hrozek
=============== A security bug in SSSD 1.8 and later =========================
Subject: information leak from the sssd-sudo responder
CVE ID: CVE-2018-10852
Summary: The UNIX socket that is used for communication between the sudo
utility and the sssd-sudo responder had its permissions set to world-readable
and writable, which means that anyone who can send a message using the same
raw protocol that sudo and SSSD use can read the sudo rules available for
any user.
Impact: low
Affects default configuration: When configured with tools like
ipa-client-install
Introduced with: SSSD 1.8
== Description ==
SSSD uses a UNIX pipe, typically located at /var/lib/sss/pipes/sudo for
communication between sudo and the sssd-sudo responder. When SSSD created
this pipe, the umask() call was set to be too permissive, which resulted
in the pipe being readable and writable. Then, if an attacker used the
same communication protocol that sudo uses to talk to SSSD, they could
obtain the list of sudo rules for any user who stores their sudo rules in
a remote directory.
While the sudo responder is not started by default by SSSD itself, utilities
like ipa-client-install configure the sudo responder to be started.
One way of mitigating the issue would be, for systems that run a recent SSSD
version and use the systemd service manager to remove sudo from the list
of services started by SSSD, then augment the sssd-sudo.socket service file
with the “SocketMode=0600” directive and finally configure the sssd-sudo
socket to be activated by systemd (systemctl enable sssd-sudo.socket).
== Patch avaliability ===
* master: https://pagure.io/SSSD/sssd/c/ed90a20a0f0e936eb00d268080716c0384ffb01d
* sssd-1-14: https://pagure.io/SSSD/sssd/c/3a0397b4c2b2d9c47e8bd0da808f5a1797244439
* sssd-1-13: https://pagure.io/SSSD/sssd/c/b0614512bee0b07ab1ab9c314220402c7c4680ac
5 years, 5 months