Problem with tgt when using user-initiated VPN-connection and yubikey-based PKINIT
by tallinn1960@yahoo.de
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
6 years, 2 months
User accounts from AD domain, sudo rules from LDAP domain
by Johannes-Ulrich Menzebach
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
6 years, 2 months
Creating an active domain group that is seen by SSSD.
by Mark London
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
6 years, 3 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
6 years, 3 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?
6 years, 3 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
6 years, 3 months