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 for one-way trusted AD domain
by Ondrej Valousek
Hi List,
Question, we have joined machine into AD domain B. This domain has one way trust to domain A. No direct connection from domain B network to DCs in domain A is possible.
Can we use SSSD to authenticate members in domain A.
In windows, this works - but can't get it working in Linux via SSSD (Fedora 25, used realmd for AD join).
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, 6 months
SSD / chown on initial automated installation
by Vadim Bulst
Hi sssd-users,
i'm using SSSD for the auth on our compute clusters - about 130 nodes in
total. The installation is done by Foreman and Puppet. Most of our
clusters are on CentOS 7.3 and we are planning to upgrade to 7.4 by
reinstall all nodes.
Here is my question:
In my puppet scripts i'm not able to change the group of a specific
folder from local group to a netgroup. Even if i successfully call
"getent group g_netgroup" before - my puppet module is trowing an error.
Can i change this particular behavior?
Error message:
notice /Stage[main]/Puppet_urzzfs/Exec[checkgroup]/returns executed
successfully
err Puppet Could not set 'directory' on ensure: Could not find group
g_urz_bigdata at
/etc/puppetlabs/code/environments/production/modules/puppet_urzzfs/manifests/init.pp:73
Puppet call:
exec {'checkgroup':
command => 'getent group g_urz_bigdata',
unless => 'getfacl /scratch_zfsvol | grep g_urz_bigdata',
require => File['/etc/sysconfig/modules/zfs.modules'],
notify => File[$mount_point],
}
file { $mount_point:
ensure => 'directory',
owner => 'root',
group => 'g_urz_bigdata',
mode => '0775',
require => Exec['checkgroup'],
notify => Exec['LoadZFSmodule'],
}
sssd.conf:
[sssd]
config_file_version = 2
services = nss, pam
domains = mydomain
debug_level = 3
[domain/mydomain]
id_provider = ad
access_provider = ad
auth_provider = ad
ldap_schema = ad
krb5_realm = MYDOMAIN
ignore_group_members = true
ad_server = mydomainadserver
cache_credentials = true
ad_domain = mydomain
default_shell = /bin/bash
use_fully_qualified_names = false
fallback_homedir = /home/%d/%u
dyndns_update = true
dyndns_refresh_interval = 43200
dyndns_update_ptr = true
dyndns_ttl = 3600
ad_gpo_cache_timeout = 5
debug_level = 3
Thanks in advance and Merry Christmas,
Vadim
--
Vadim Bulst
Universität Leipzig / URZ
04109 Leipzig, Augustusplatz 10
phone: +49-341-97-33380
mail: vadim.bulst(a)uni-leipzig.de
5 years, 11 months
any relationship between "entry_cache_timeout" and "cached_auth_timeout"?
by Lin Yuan
Hello SSSD experts
I am a bit confused about the relationship between these 2 parameters.
In my setup test, it seems there 2 parameters are independent. If I set
"cached_auth_timeout" longer than "entry_cache_timeout", when
"entry_cache_timeout" expires and "cached_auth_timeout" not, I can still
login with cached credentials.
Even if I clean all cache by "sss_cache -E", login with cached credentials
still work as long as it is within the timeout period.
So my questions
- where is cached credential stored? Is it also the /var/lib/sss/db/* ?
Then why it cannot be invalidated by "sss_cache -E"?
- how can I invalidate it without restarting the sssd service?
5 years, 11 months
sssd_be eat up all memory
by Lin Yuan
Hello sssd experts
We have a monitoring service login our linux servers with an AD account
periodically, 1 or 2 times every 5 minutes (that is ~500 logins per day, I
do not think this frequency is that high). But we find the login through
sssd fails almost every month and have to restart the sssd service to bring
it back.
After increasing the debug level, we found there are some memory issues for
sssd_be
(Mon Dec 18 10:48:37 2017) [sssd[be[tls.ad]]] [fork_child] (0x0020): fork
failed [12][Cannot allocate memory].
(Mon Dec 18 10:48:37 2017) [sssd[be[tls.ad]]] [handle_child_send] (0x0020):
fork_child failed.
(Mon Dec 18 10:48:37 2017) [sssd[be[tls.ad]]] [krb5_auth_done] (0x0020):
child failed (12 [Cannot allocate memory])
(Mon Dec 18 10:48:37 2017) [sssd[be[tls.ad]]] [krb5_auth_queue_done]
(0x0040): krb5_auth_recv failed with: 12
For a typical server configured with 4G RAM, sssd_be will consume 12% of
RAM (~500M) after 5 days. I googled a bit and tried to tune parameters, but
did not see significant improvement. Here is my current configuration:
[sssd]
domains = lab.local
config_file_version = 2
services = nss, pam
[pam]
pam_id_timeout = 86400
[domain/lab.local]
ad_domain = lab.local
krb5_realm = LAB.LOCAL
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
fallback_homedir = /home/%d/%u
access_provider = simple
simple_allow_groups = admins(a)lab.local
ldap_user_principal = nosuchattribute
entry_cache_timeout = 86400
ldap_referrals = false
use_fully_qualified_names=false
ignore_group_members = true
cached_auth_timeout = 86400
We want our Linux servers to use local credential to authenticate users
whenever possible to reduce load on our ADs. The phenomenon I can see is:
in the 1st day (within the timeout period 86400), sssd_be's memory usage
remains stable, around 20M. But after the 1st day, the memory usage
increases steadily, and finally the login service fails.
Do you have any idea about this problem? It looks like memory leak
Our system is
- Centos 7.4.1708 x86_64
- sssd 1.15.2-50
5 years, 11 months
sudo for Active Directory group
by Viktor Ekl
Hello.
Sssd 1.15.2-50 on Centos 7. I'm trying to grant sudo access to members of known AD group (say, "linux_admin"), but with no success:
"<user> is not allowed to run sudo on <host>. This incident will be reported"
Can't understand why, according to sssd_domain.log group and members found ?
My configuration, /etc/sudoers:
%wheel ALL=(ALL) ALL
%linux_admin ALL=(ALL) ALL
part of /etc/sssd/sssd.conf:
sudo_provider = ldap
Part of sudo_debug log:
sudo[1069] sudo_getgrnam: group linux_admin [] -> gid 10001 [] (cached)
...
sudo[1069] sudo_get_gidlist: looking up group IDs for testadmin
...
sudo[1069] user_in_group: user testadmin NOT in group linux_admin
Part of sssd_testdomain.com.log:
[sssd[be[testdomain.com]]] [dp_get_account_info_handler] (0x0200): Got request for [0x2][BE_REQ_GROUP][name=linux_admin(a)testdomain.com]
[sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): DP Request [Account #11]: New request. Flags [0x0001].
[sssd[be[testdomain.com]]] [dp_attach_req] (0x0400): Number of active DP request: 1
[sssd[be[testdomain.com]]] [sss_domain_get_state] (0x1000): Domain testdomain.com is Active
[sssd[be[testdomain.com]]] [sdap_get_groups_next_base] (0x0400): Searching for groups with base [cn=users,dc=testdomain,dc=com]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(cn=linux_admin)(objectClass=posixGroup)(cn=*)(&(gidNumber=*)(!(gidNumber=0))))][cn=users,dc=testdomain,dc=com].
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userPassword]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [gidNumber]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUid]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [modifyTimestamp]
[sssd[be[testdomain.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [uSNChanged]
[sssd[be[testdomain.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [CN=linux_admin,CN=Users,DC=testdomain,DC=com].
[sssd[be[testdomain.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
[sssd[be[testdomain.com]]] [sdap_get_groups_process] (0x0400): Search for groups, returned 1 results.
[sssd[be[testdomain.com]]] [sdap_has_deref_support] (0x0400): The server supports deref method ASQ
[sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 0 users found in the hash table
[sssd[be[testdomain.com]]] [sdap_nested_group_recv] (0x0400): 1 groups found in the hash table
[sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] attribute. [0][Success]
[sssd[be[testdomain.com]]] [sdap_get_primary_name] (0x0400): Processing object linux_admin
[sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Processing group linux_admin(a)testdomain.com
[sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): The group has 1 members
[sssd[be[testdomain.com]]] [sdap_process_ghost_members] (0x0400): Group has 1 members
[sssd[be[testdomain.com]]] [sdap_save_group] (0x0400): Storing info for group linux_admin(a)testdomain.com
[sssd[be[testdomain.com]]] [sysdb_store_group] (0x1000): The group record of linux_admin(a)testdomain.com did not change, only updated the timestamp cache
[sssd[be[testdomain.com]]] [sdap_attrs_get_sid_str] (0x1000): No [objectSID] attribute. [0][Success]
[sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Failed to get group sid
[sssd[be[testdomain.com]]] [sdap_get_primary_name] (0x0400): Processing object linux_admin
[sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Processing group linux_admin(a)testdomain.com
[sssd[be[testdomain.com]]] [sdap_save_grpmem] (0x0400): Adding member users to group [linux_admin(a)testdomain.com]
[sssd[be[testdomain.com]]] [sdap_fill_memberships] (0x0080): Member [testadmin] is it out of domain scope?
[sssd[be[testdomain.com]]] [sdap_fill_memberships] (0x0080): Member [testadmin] was not found in cache. Is it out of scope?
[sssd[be[testdomain.com]]] [sysdb_set_entry_attr] (0x0200): Entry [name=linux_admin(a)testdomain.com,cn=groups,cn=testdomain.com,cn=sysdb] has set [ts_cache] attrs.
[sssd[be[testdomain.com]]] [dp_req_done] (0x0400): DP Request [Account #11]: Request handler finished [0]: Success
[sssd[be[testdomain.com]]] [_dp_req_recv] (0x0400): DP Request [Account #11]: Receiving request data.
[sssd[be[testdomain.com]]] [dp_req_reply_list_success] (0x0400): DP Request [Account #11]: Finished. Success.
[sssd[be[testdomain.com]]] [dp_req_reply_std] (0x1000): DP Request [Account #11]: Returning [Success]: 0,0,Success
5 years, 11 months
eToken CN Lenght
by Мастренко Иван
Hello!
I'm catch error of cryptoapy when certificate cn length is 29 symbols. (Doesn't mean if I use subj or SUBJ).
May it some restriction of length of openssl\openvpn\ms crypto api or it some error with certificcate on eToken?
BR Ivan Mastrenko
5 years, 11 months
Passwordless SUDO commands in AD
by Max DiOrio
Hi,
We use Active Directory to manage our Linux access including SUDO
permissions.
We need to have a particular account run a passwordless command. I created
a new sudoRule in AD, added the following:
sudoCommand /bin/systemctl restart wildfly.service
sudoHost +DevTestLinuxServer (our group of servers)
sudoOption !authenticate
sudoOrder 1
sudoUser svc_Jenkins_DTS
From what I'm reading, sudoOrder should be 0 when not defined, which it
isn't in the other sudoRoles. So with this having a sudoOrder 1, it should
take precedence when there's more than one match for the command. The
other sudoRole is ALL:ALL, but requires a password, and that one works fine.
On the client side, logged in as svc_Jenkins_DTS, I see the following in
the sudo log:
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sort_sudo_rules] (0x0400): Sorting
rules with higher-wins logic
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_fetch_rules] (0x0400):
Returning 2 rules for [svc_jenkins_dts(a)internal.ieeeglobalspec.com@
internal.ieeeglobalspec.com]
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000):
error: [0]
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000):
rules_num: [0]
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000):
rule [1]/[2]
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:jenkins
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:/bin/systemctl restart wildfly.service
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServer
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOption:!authenticate
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoOrder:1
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_build_response] (0x2000):
rule [2]/[2]
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): cn:DevTest
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): objectClass:sudoRule
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoCommand:ALL
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoHost:+DevTestLinuxServers
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoRunAsUser:ALL
(Mon Dec 4 14:58:55 2017) [sssd[sudo]] [sudosrv_response_append_attr]
(0x2000): sudoUser:#1002202276
So it knows of both rules, and sorted them properly.
But doing a sudo -l showing the following:
[svc_jenkins_dts@la-1dglsesgap01 ~]$ sudo -l
[sudo] password for svc_jenkins_dts:
Matching Defaults entries for svc_jenkins_dts on la-1dglsesgap01:
!visiblepw, always_set_home, match_group_by_gid, env_reset,
env_keep="COLORS DISPLAY HOSTNAME
HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG
LC_ADDRESS LC_CTYPE",
env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES",
env_keep+="LC_MONETARY
LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL
LANGUAGE LINGUAS
_XKB_CHARSET XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin
User svc_jenkins_dts may run the following commands on la-1dglsesgap01:
(ALL) ALL
So
1) why does it not show in the list it can run the command
2) why does it keep prompting for a password when I try to run the command
Thanks!
Max
5 years, 11 months
Ubuntu Xenial failures
by Jay McCanta
After an update to Ubuntu Xenial, sssd_pam always fails with a system error(4) error.
Dec 18 20:07:22 sv5cismfgcr01 sshd[27263]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.11.129 user=mccanta
Dec 18 20:07:22 sv5cismfgcr01 sshd[27263]: pam_sss(sshd:account): Access denied for user mccanta: 4 (System error)
I have debug_level 10 logs I can send. Didn't want to post thos to the mailing list.
Jay
5 years, 11 months