# SSSD 2.4.0
The SSSD team is proud to announce the release of version 2.4.0 of the
System Security Services Daemon. The tarball can be downloaded from:
See the full release notes at:
RPM packages will be made available for Fedora shortly.
Please provide comments, bugs and other feedback via the sssd-devel
or sssd-users mailing lists:
- `libnss` support was dropped, SSSD now supports only `openssl`
### New features
- Session recording can now exclude specific users or groups when
`scope` is set to `all` (see `exclude_users` and `exclude_groups` options)
- Active Directory provider now sends CLDAP pings over UDP protocol to
Domain Controllers in parallel to determine site and forest to speed up
### Packaging changes
- python2 bindings are disable by default, use `--with-python2-bindings`
to build it
### Documentation Changes
- Default value of `client_idle_timeout` changed from 60 to 300 seconds
for KCM, this allows more time for user interaction (e.g. during `kinit`)
- Added `exclude_users` and `exclude_groups` option to
`session_recording` section, this allows to exclude user or groups from
session recording when `scope` is set to `all`
- Added `ldap_library_debug_level` option to enable debug messages from
- Added `dyndns_auth_ptr` to set authentication mechanism for PTR DNS
- Added `ad_allow_remote_domain_local_groups` to be compatible with
Angus Clarke via FreeIPA-users wrote:
> We have a single mesh of FreeIPA servers in several different locations,
> we capture logs (apache ErrorLog directive) to a log server in each of
> those locations. When auditors ask us questions we have to trawl log
> servers from all locations as our IdM administrators might have used any
> of the IdM servers to make changes.
> To limit that access to one site, I am considering stopping and
> disabling apache on all IdM servers at other sites and just wanted to
> check there are no unintended consequences in that action.
> I'm not looking for enforcement, merely a means of persuading the team
> to use the web interface or command line tools at one site.
It's completely untested so if something went wrong you'd be pretty far
out on the ledge.
You're purposely creating a single-point-of-failure. You'd need to work
out some system to transition the web server to another server.
The chosen server would need to run a CA, otherwise it will try to find
one and fail at connecting since the CA connect is proxied through Apache.
Establishing a new CA would likewise almost certainly be problematic.
The ipa-ca CNAME is used so clients can use OCSP. You'd have to manually
limit this value to only the available web server. Same with CRL.
Running other administrative commands on those hosts would fail
miserably (ipa-certupdate, ipa-cacert-manage for sure).
I'm not certain if ipa-server-upgrade which is also run at package
installation needs local API access. IPA servers make certain
assumptions about what basic services are available.
So this could well be the kind of thing that seems to work, you relax
and forget about it, then all heck breaks loose.
Either way, masking/stopping the service wouldn't really work since it
is managed via ipactl. You'd have to mark the service as disabled in
IPA, and I'm not sure you can do that to an IPA service so you'd
probably have to do it manually using ldapmodify.
We have an application that does some data processing on our NFS server. Users typically just ssh into a box which then has a kerberos key generated for them, which allows them access the NFS share and run the script.
We are wanting to set this up in a more automated fashion. Such as running the script in the background as a service. However, after a few days the kerberos keys become invalid killing access to the NFS share and the data.
Is there a way to generate some account/keys that will have permanent access for service level stuff like this?
My dirsrv(a)IPA-MYDOMAIN-COM.service on IPA server fails to start due to missing configuration. How can I re-create one ?
ds_systemd_ask_password_acl: grep: /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif: No such file or directory
ns-slapd: INFO - dse_check_file - The config /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif can not be accessed. Attempting restore ... (reason: 0)
ns-slapd: INFO - dse_check_file - The backup /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif.bak can not be accessed. Check it exists and permissions.
ns-slapd: ERR - slapd_bootstrap_config - No valid configurations can be accessed! You must restore /etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldif from ba>
ns-slapd: EMERG - main - The configuration files in directory /etc/dirsrv/slapd-IPA-MYDOMAIN-COM could not be read or were not found. Please refer to>
systemd: dirsrv(a)IPA-MYDOMAIN-COM.service: Main process exited, code=exited, status=1/FAILURE
systemd: dirsrv(a)IPA-MYDOMAIN-COM.service: Failed with result 'exit-code'.
systemd: Failed to start 389 Directory Server IPA-MYDOMAIN-COM..
-- Subject: Unit dirsrv(a)IPA-MYDOMAIN-COM.service has failed
$ ls /etc/dirsrv/
drwxr-xr-x 2 root root 82 Nov 13 2019 config
-rw------- 1 dirsrv dirsrv 570 Sep 18 2019 ds.keytab
drwxr-xr-x 2 root root 25 Nov 13 2019 schema
drwxr-x--- 4 dirsrv dirsrv 4096 Oct 7 21:26 slapd-HOME-MYDOMAIN-COM
drwxr-x--- 2 dirsrv dirsrv 37 Sep 18 2019 slapd-HOME-MYDOMAIN-COM.removed
drwxr-x--- 2 dirsrv dirsrv 37 Feb 18 2019 slapd-IPA-MYDOMAIN-COM.removed
There is one ".removed" - not sure why and if i can maybe re-use it ?
We have a single mesh of FreeIPA servers in several different locations, we capture logs (apache ErrorLog directive) to a log server in each of those locations. When auditors ask us questions we have to trawl log servers from all locations as our IdM administrators might have used any of the IdM servers to make changes.
To limit that access to one site, I am considering stopping and disabling apache on all IdM servers at other sites and just wanted to check there are no unintended consequences in that action.
I'm not looking for enforcement, merely a means of persuading the team to use the web interface or command line tools at one site.
We operate our own certificate authority for our internal infrastructure and I'd like to replace the certificate that comes with the FreeIPA installation with one we've generated for this host. This is FreeIPA, version: 4.6.6, running on CentOS Linux release 7.8.2003 (Core).
I looked around in the docs and couldn't see anything for this particular task. I did add a certificate to the FreeIPA host (under Identity->Host), but that doesn't seem to be the correct (or only) thing to do. In the certificates area, it appears, but has incomplete information and isn't marked VALID. What is the procedure for doing this?
I just started working for a new company and they handed me this IPA replication server with an issue logging on to the web UI. I get errors when we try to login. I have been all over the web looking for answers. I have check the permission of all the certs and they are correct all have 0644 on them. I have done strace on the WSGI pids with no answers. I have no idea if this ever worked from the install since I just started working for the company last week and the guy who built it is no longer there. I have noticed that since it cannot authenticate it will not write to ccache in /var/run/ipa/ccaches. Everything works from the command line with no issue. I can also run kinit admin and put the password in with no issues. If I run a curl from command it works no issues. Just cant login in from the browser. I have restart ipa using ipactl restart. All the services are running just fine. However I noticed in the log file for the install there were errors. I don't know if this ever worked
or not. This is replicating back to known working servers just fine. I was added and it shows up in the server.
stderr=kinit: Client 'WELLKNOWN/ANONYMOUS@.example.us' not found in Kerberos database while getting initial credentials
CalledProcessError: Command '/usr/bin/kinit -n -c /var/run/ipa/ccaches/armor_25969 -X X509_anchors=FILE:/var/kerberos/krb5kdc/kdc.crt -X X509_anchors=FILE:/var/lib/ipa-client/pki/kdc-ca-bundle.pem' returned non-zero exit status 1
[root@Server ccaches]# klist
Ticket cache: KEYRING:persistent:0:0
Default principal: admin(a)example.us
Valid starting Expires Service principal
10/06/2020 15:09:44 10/06/2020 20:56:18 HTTP/Server.US
10/05/2020 20:56:30 10/06/2020 20:56:18