sssd-users January 2018

sssd-users@lists.fedorahosted.org

13 participants
16 discussions

Problem with tgt when using user-initiated VPN-connection and yubikey-based PKINIT
by tallinn1960＠yahoo.de 23 Jan '18

23 Jan '18

I am aware that sssd by design issues an invalid tgt upon login when it is operating in offline mode. The tgt has a expire date of the epoch. There is a configuration option for storing the login passwd within sssd to enable it to issue a correct ticket once it enters online mode again. Now, we are using yubikey-based PKINIT as our login and cannot use this configuration option. The problematic scenario runs like this: - Notebook is offline. - user logs in with yubikey - user starts a user program that establishes a vpn connection This results in a tgt expired at epoch. Two questions: 1. Is there a way to avoid this behaviour? 2. Is issuing a kinit after setting up the vpn connection to obtain a valid tgt a valid workaround? Thanks in advance

2 4

User accounts from AD domain, sudo rules from LDAP domain
by Johannes-Ulrich Menzebach 21 Jan '18

21 Jan '18

We're currently evaluating moving our CentOS6 Linux workstations and servers from OpenLDAP to AD, but would like to avoid the AD schema customization needed to put sudo rules and autofs mappings there. So we thought about keeping sudo and autofs info on the OpenLDAP infrastructure, while authenticating against AD. The latter works very nicely using "id_provider=ad". Regarding sudo and autofs info, in sssd.conf I have set up a 2nd domain with id_provider=ldap and auth_provider=none, referring to the old OpenLDAP server. Indeed I've got autofs working this way (mapping NFS home directories). sudo however does not work. It seems sssd_sudo only searches in the cache file containing info of the AD domain (which has no sudo info). The OpenLDAP domain ( it's ldb cache file actually carries the sudo rules as per ldbsearch output) is apparently ignored - seems like the function sudosrv_get_sudorules_from_cache() just looks into the AD domain's cache ( where the account info of the current user stems from) Is my "split" approach totally flawed? Is there a way to make it work without patching the sssd_sudo sources to iterate over all domain caches ? I can provide sssd.conf and log files. Just wanted to hear first about whether the approach should work at all and possible alternatives ... Many thanks for comments/hints/proposals, Uli

2 1

Creating an active domain group that is seen by SSSD.
by Mark London 08 Jan '18

08 Jan '18

Hi - Sorry if this is not completely an SSSD question. We use SSSD on Redhat, to authenticate against the LDAP server, that is part of the Windows Active Domain server. In the old versions of the Windows server, there was software that provided integration with the LDAP server (i.e. there was a Unix tab, that could be seen, when viewing a user or group in the Active Doman.). Using this method, it was possible to create a group in Active Domain, that could be seen on the Redhat side, via a "unix tab" ,that would appear on the active domain interface. This unix integration software was removed a long time ago. But it possible using another method, to create a group in the Active Domai, that the LDAP server also sees, and thus can be seen in Redhat) Without having to switchto using AD authentication in SSSD. Thanks. - Mark

2 1

SSD / chown on initial automated installation
by Vadim Bulst 04 Jan '18

04 Jan '18

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

2 1

any relationship between "entry_cache_timeout" and "cached_auth_timeout"?
by Lin Yuan 03 Jan '18

03 Jan '18

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?

2 1

sssd_be eat up all memory
by Lin Yuan 02 Jan '18

02 Jan '18

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

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

sssd-users January 2018