Only IPv4 addresses in /var/lib/sss/pubconf/kdcinfo.DOMAIN
by Brian J. Murrell
On my dual-stack network where some machines actually don't have IPv4
connectivity I am finding that whatever is writing IP addresses into
/var/lib/sss/pubconf/kdcinfo.DOMAIN is only writing the IPv4 addresses
and not the KDC's IPv6 addresses.
The result is that such an IPv6 machine cannot reach a KDC until I
remove that file. It ends up being recreated at some subsequent point
again with only the KDC's IPv4 addresses.
Is this a bug or a problem with my configuration?
Cheers,
b.
4 months, 3 weeks
sssd 1.16.5 gives no results for other domains in the AD Forest
by Bill Conn
I'm working on a university's research cluster with nodes that all run CentOS7 and are joined to the school's Active Directory domain. Our domain is part of a statewide forest that contains every state university, and we have used this arrangement to grant cluster access to users from other Universities to our cluster.
Recently, a user from outside my Universities domain have said they cannot log in anymore which caused me to look into this issue. I found that if I issue an id command for a user in a different domain in the forest, it gives me the error "no such user". I know that our setup used to work, and after looking into it and trying to replicate the old and new behavior I found out that CentOS7 machines with sssd 1.16.4 can get results from other domains in the forest, but machines with 1.16.5 cannot.
Is there some setting that changed between these minor versions that would cause this? Is it possible this is not caused by sssd? I'm testing a node with CentOS 7.9.2009 which doesn't return other domains in the forest and a node with CentOS 7.7.1908 which does return results from other domains.
1 year, 8 months
tgt-renewal and AD
by Francis Augusto Medeiros-Logeay
Hi,
I currently have some machines that joined a domain on Active Directory, and we were dealing with the challenges of renewing tickets beyond the TGT "renew until" limit. I realised that after version 2.5.0 it is now possible to configure the `tgt_renewal=true`. I changed our configuration to use KCM to store the tickets.
To test, I get one-day valid TGT's, and saw that the tickets do not get renewed by themselves, and I wonder if I missed a step when configuring AD and/or the clients.
Here's a bit of my configuration:
/etc/sssd/sssd.conf:
```
[domain/MYDOMAIN.COM]
id_provider = ad
auth_provider = ad
access_provider = ad
autofs_provider = ad
chpass_provider = ad
ldap_id_mapping = false
ldap_user_principal = nosuchattribute
# getent on users with more -- results in a lot of noise
enumerate = false
cache_credentials = true
# Setup schema, rfc2307 is for OpenLDAP, rfc2307bis is A/D-close, and ad is A/D
#ldap_schema = rfc2307
dns_discovery_domain = mydomain.com
krb5_realm = MYDOMAIN.COM
# how long including renewals may a ticket be valid for
krb5_renewable_lifetime = 1d
# time in seconds between checking if a ticket must be renewed
krb5_renew_interval = 3600
# template used for placing kerberos tickets by default
# krb5_ccname_template = FILE:%d/krb5cc_%U
ad_gpo_map_interactive = +gdm-vmwcred
#tgt_renewal = true
[kcm]
tgt_renewal = true
tgt_renewal_inherit = MYDOMAIN.COM
krb5_renew_interval = 60m
debug_level = 10
socket_patch = /var/run/.heim_org.h5l.kcm-socket
```
And /etc/krb5.conf:
```
[libdefaults]
default_ccache_name = KCM:
kcm_socket = /var/run/.heim_org.h5l.kcm-socket
```
Anything else I should have done? I see that the tickets are stored on KCM, but I don't know why they aren't been renewed.
Best,
Francis
1 year, 8 months
AVC alerts for process working in /var/lib/sss
by Brian J. Murrell
I am getting some SELinux AVC alerts for a given process in a given domain that seems to want to be able to read files in /var/lib/sss/.
strace(1)ing the (unprivileged) process it seem to want to do the following:
4024612 openat(AT_FDCWD, "/var/lib/sss/mc/passwd", O_RDONLY|O_CLOEXEC) = -1 EACCES (Permission denied)
and
4024612 connect(3, {sa_family=AF_UNIX, sun_path="/var/lib/sss/pipes/nss"}, 110) = -1 EACCES (Permission denied)
in /var/lib/sss/ which as you can see SELinux is currently denying. But nothing about the running of the process seems to be a-miss despite these EPERMs
Ultimately I am just trying to gauge the potential issues with following the least-privilege principle and setting these to ignore rather than allow. I.e. what might not be functioning correctly (even though they appear to be from all outward appearances) if these EPERMs continue instead of being allowed.
Any ideas why this process would be wanting to access those paths and why and what the problem might be with denying it?
Cheers,
b.
1 year, 8 months
is the sssd monitor even necessary?
by James Ralston
For recent versions of sssd, the monitor (the sssd.service) won’t even
start unless at least one domain is configured.
As sssd.conf(5) notes, all sssd services can be socket-activated when
needed. There is no need to list any services in the "services"
parameter in [sssd].
So, this leads to a question: if all configured services are
configured via systemd to start via socket activation… then what is
the monitor actually monitoring? In this configuration, what does it
actually do? And is there any reason to even run the monitor at all?
If the answer is, “the monitor performs necessary housekeeping
functions so it should be running even if all services are
socket-activated,” then shouldn’t it be the case that the monitor
should run even if no domains are configured?
1 year, 8 months
LDAP servers(not AD) and nested netgroups
by Don Drake
Our implementation of netgroups has objects that identify groups of servers, the use the nisnetgrouptriple attribute where users are assigned without domain or server information. i.e. 'nisnetgrouptriple=(,USERID,)', this is called an administrative group. Each server has its own netgroup object that uses the membernisnetgroup attribute to connect the server to an administrative netgroup. i.e. memberNisNetgroup=admngroup. this has worked for us for years. we cann find a way in SSSD to implement this. What am i missing?
1 year, 9 months
