June 2024 - FreeIPA-users - Fedora mailing-lists

ipa-server upgrades not possible on RHEL 9 - samba-client-libs outdated
by Sam Morris 12 Jun '24

12 Jun '24

Hi folks. On a RHEL 9 system I'm getting: # dnf upgrade Updating Subscription Management repositories. Last metadata expiration check: 3:01:24 ago on Tue Jun 11 05:37:06 2024. Error: Problem 1: cannot install the best update candidate for package ipa-server-4.11.0-10.el9_4.x86_64 - nothing provides samba-client-libs >= 4.19.4-105.el9_4 needed by ipa-server-4.11.0-15.el9_4.x86_64 from rhel-9-for-x86_64-appstream-rpms Problem 2: [...] etc. Currently only the older version of samba-client-libs is available: # dnf list samba-client-libs Not root, Subscription Management repositories not updated Last metadata expiration check: 8:22:10 ago on Tue Jun 11 00:17:42 2024. Installed Packages samba-client-libs.x86_64 4.19.4-104.el9 @rhel-9-for-x86_64-baseos-rpms Available Packages samba-client-libs.i686 4.19.4-104.el9 rhel-9-for-x86_64-baseos-rpms I guess this will fix itself soon but I wanted to check on the chance that I've managed to break something locally... Thanks -- Sam Morris <https://robots.org.uk/> PGP: rsa4096/CAAA AA1A CA69 A83A 892B 1855 D20B 4202 5CDA 27B9

2 2

Fedora 40/FreeIPA 4.12
by Jochen Kellner 10 Jun '24

10 Jun '24

Hi, I've re-installed my test system with Fedora 40. ipa-healthcheck says: { "source": "ipahealthcheck.ipa.files", "check": "TomcatFileCheck", "result": "WARNING", "uuid": "0cad1a21-d450-4c68-845f-e72a640af360", "when": "20240610020014Z", "duration": "0.000986", "kw": { "key": "_var_lib_pki_pki-tomcat_conf_ca_CS.cfg_mode", "path": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg", "type": "mode", "expected": "0660", "got": "0664", "msg": "Permissions of /var/lib/pki/pki-tomcat/conf/ca/CS.cfg are too permissive: 0664 and should be 0660" } }, Otherwise the system seems to run fine. Might be a packaging problem... Jochen -- This space is intentionally left blank.

2 2

FreeIPA 4.12.1
by Antonio Torres 10 Jun '24

10 Jun '24

The FreeIPA team would like to announce FreeIPA 4.12.1 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora distributions will be available from the official repository soon. Full release notes are available at: https://www.freeipa.org/release-notes/4-12-1.html

1 0

FreeIPA 4.11.2
by Antonio Torres 10 Jun '24

10 Jun '24

The FreeIPA team would like to announce FreeIPA 4.11.2 release! It can be downloaded from http://www.freeipa.org/page/Downloads. Builds for Fedora distributions will be available from the official repository soon. Full release notes are available at: https://www.freeipa.org/release-notes/4-11-2.html

1 0

[SSSD] Announcing SSSD 2.10.0-beta1
by Pavel Březina 07 Jun '24

07 Jun '24

# SSSD 2.10.0-beta1 The SSSD team is announcing the release of version 2.10.0-beta1 of the System Security Services Daemon. The tarball can be downloaded from: https://github.com/SSSD/sssd/releases/tag/2.10.0-beta1 See the full release notes at: https://sssd.io/release-notes/sssd-2.10.0-beta1.html RPM packages will be made available for Fedora shortly. ## Feedback Please provide comments, bugs and other feedback via the sssd-devel or sssd-users mailing lists: https://lists.fedorahosted.org/mailman/listinfo/sssd-devel https://lists.fedorahosted.org/mailman/listinfo/sssd-users # SSSD 2.10-beta1 Release Notes ## Highlights ### General information * **IMPORTANT note for downstream maintainers!** This release features significant improvements of "running with less privileges (under unprivileged service user)" feature. There is still a `./configure` option `--with-sssd-user=` available that allows downstream package maintainers to choose if support of non-root service user should be built. In case such support is built, a preferred way to configure service user is simply by starting SSSD under this user; for example, using `User=/Group=` options of systemd sssd.service file. Upstream defaults are to build `--with-sssd-user=sssd` and to install systemd service with `User=/Group=sssd`. In this case, only several helper processes - `ldap_child`, `krb5_child` and `selinux_child` - are executed with elevated capabilities (that are now granted using fine grained file capabilities instead of SUID bit). All other SSSD components run without any capabilities. In this scenario it's still possible to re-configure SSSD to run under `root` (if needed for some reason): besides changing `User/Group=` options, some other tweaks of systemd service files are required. A legacy method to configure a service user - sssd.conf `user` option - is now deprecated and its support isn’t built by default. It can be enabled using `--with-conf-service-user-support` `./configure` option if needed (for example, due to backward compatibility requirements of stable releases). Further, no matter if SSSD is built `--with-sssd-user=sssd` or `--with-sssd-user=root`, when it's configured to run under `root` (in both cases) it still runs without capabilities, the same way as when it's configured to run under `sssd` user. The only difference is from the DAC perspective. Important note: owner of `/etc/sssd/sssd.conf` file (and snippets) should match the user configured to start SSSD service. Upstream spec file changes ownership of existing `sssd.conf` to `sssd` during package installation for seamless upgrades. Additionally, this release fixes a large number of issues with "socket activation of responders" feature, making it operable out-of-the-box when the package is built `--with-sssd-user=sssd`. Please take a note, that user configured to run main sssd.service and socket activated responders (if used) should match (i.e. if sssd.service is re-configured from upstream defaults to `root` then responders services also should be re-configured). Downstream package maintainers are advised to carefully inspect changes in `contrib/sssd.spec.in`, `src/sysv/systemd/*` and `./configure` options that this release brings! * sssctl `cache-upgrade` command was removed. SSSD performs automatic upgrades at startup when needed. * Support of `enumeration` feature (i.e. ability to list all users/groups using `getent passwd/group` without argument) for AD/IPA providers is deprecated and might be removed in further releases. Those who are interested to keep using it awhile should configure its build explicitly using `--with-extended-enumeration-support` ./configure option. ### New features * The new tool `sss_ssh_knownhosts` can be used with ssh's KnownHostsCommand configuration option to retrieve the host's public keys from a remote server (FreeIPA, LDAP, etc.). This new tool, which is more reliable, replaces `sss_ssh_knownhostsproxy`. Please consider switching to using the new tool as the old one will be removed. ### Packaging changes * Building SSSD now unconditionally requires availability of `ucred`/ `SO_PEERCRED` to enforce certain security checks at runtime (see `man 7 unix` for details). * SSSD now requires `libini` not older than v1.3 * Explicit `--with-semanage` ./configure switch was removed, going forward `--with-selinux` includes this. ### Configuration changes * Default `ldap_id_use_start_tls` value changed from `false` to `true` for improved security. * Added a `ldap_use_ppolicy` option for backends with broken ppolicy extension handling. * Obsolete `config_file_version` option was removed.

1 1

ipa host-add one time password validity period?
by Masanari Iida 07 Jun '24

07 Jun '24

" ipa host-add hostname -random " create a random one time password for this system. My question is, is there any expiring date for this random one time password? Let's say, if the random password expires in 7 days, I should mention my co-worker to let them add the hosts within that period. So far, I don't see such limitation online manual "Add Hosts to IPA" section. Just I want to double check this with developer. Masa

2 2

Is there a way to change a private group to a normal user group?
by Djerk Geurts 06 Jun '24

06 Jun '24

Hi all, Working on NFS access for local system accounts I found that one NFS client was only able to use a primary group to gain access to an NFS share via group privileges, and not a secondary group. But now, I’ve run into an issue where I need to grant others access to the same files, and their use of secondary group membership isn’t a problem. So now I’m considering if I can change the private group to a normal group and still have it as the primary group for the system account. I don’t want to have to change the group ownership of 10TB of files and folders again as this takes a long time. So the gid must stay ideally stay the same. Can I: Change the group type, so it shows up in the IPA GUI and add another group to it. Delete the private group and recreate it as a normal group with the same gid and name? Or am I screwed and need to remove the user and group and recreate them from scratch? Thanks, Djerk Geurts

2 4

Setting up FreeIPA to work with Windows and other Linux Boxes
by Duncan Small 05 Jun '24

05 Jun '24

I am attempting to follow this guide (https://www.rootusers.com/how-to-login-to-windows-with-a-freeipa-account/) to add a windows box to my cluster of FreeIPA-managed linux (rhel 8/9 and ubuntu) boxes. I have gotten to the point where I have a user account on the windows box connected to FreeIPA, I change the password (since it always starts expired) but then I am hit with this error: “To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Remote Desktop Users group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from the Remote Desktop Users group, you need to be granted this right manually.” My user account is in the "Remote Desktop Users" and I have verified that this group has the correct permissions to allow logon via RDP (as well as verifying that no user groups are denied from logging onto the box). I also added the user to the Remote Desktop Services group policy, but that did not work. I am able to RDP in as Administrator, so I tried adding the user to Administrator just to ensure it had the right permissions, but that did not work. I have been able to replicate this behavior with a fresh box and different FreeIPA accounts. Any help, advice, or resources would be greatly appreciated. TIA

2 2

Setting up FreeIPA to work with Windows and other Linux Boxes
by Duncan Small 05 Jun '24

05 Jun '24

I am attempting to follow this guide (https://www.rootusers.com/how-to-login-to-windows-with-a-freeipa-account/) to add a windows box to my cluster of FreeIPA-managed linux (rhel 8/9 and ubuntu) boxes. I have gotten to the point where I have a user account on the windows box connected to FreeIPA, I change the password (since it always starts expired) but then I am hit with this error: “To sign in remotely, you need the right to sign in through Remote Desktop Services. By default, members of the Remote Desktop Users group have this right. If the group you’re in doesn’t have this right, or if the right has been removed from the Remote Desktop Users group, you need to be granted this right manually.” My user account is in the "Remote Desktop Users" and I have verified that this group has the correct permissions to allow logon via RDP (as well as verifying that no user groups are denied from logging onto the box). I also added the user to the Remote Desktop Services group policy, but that did not work. I am able to RDP in as Administrator, so I tried adding the user to Administrator just to ensure it had the right permissions, but that did not work. I have been able to replicate this behavior with a fresh box and different FreeIPA accounts. Any help, advice, or resources would be greatly appreciated. TIA

1 0

pki-tomcatd service stopped
by Natxo Asenjo 05 Jun '24

05 Jun '24

hi, after a botched update (https://access.redhat.com/solutions/7065748) and rolling back the changes, this service will not start: # ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING httpd Service: RUNNING ipa-custodia Service: RUNNING pki-tomcatd Service: STOPPED smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING 1 service(s) are not running in journalctl I found this stdout/stderr messages: May 24 11:40:35 kdc1.sub.domain.tld named[27437]: zone sub.domain.tld/IN: sending notifies (serial 1716543629) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: ERROR: Unable to parse version number: "11.5.0" May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Traceback (most recent call last): May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/server/pkiserver.py", line 41, in <module> May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: cli.execute(sys.argv) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/server/cli/__init__.py", line 145, in execute May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: super().execute(args) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/cli/__init__.py", line 217, in execute May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: module.execute(module_args) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 144, in execute May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: self.upgrade( May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/server/cli/upgrade.py", line 178, in upgrade May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: upgrader.upgrade() May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/upgrade.py", line 481, in upgrade May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: versions = self.versions() May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/upgrade.py", line 238, in versions May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version = self.get_current_version() May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/upgrade.py", line 341, in get_current_version May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: current_version = self.get_tracker().get_version() May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/upgrade.py", line 141, in get_version May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: return pki.util.Version(version) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: File "/usr/lib/python3.9/site-packages/pki/util.py", line 613, in __init__ May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: raise Exception('Unable to parse version number: %s' % obj) May 24 11:40:35 kdc1.sub.domain.tld pki-server[27758]: Exception: Unable to parse version number: "11.5.0" May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: pki-tomcatd(a)pki-tomcat.service: Control process exited, code=exited, status=1/FAILURE May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: pki-tomcatd(a)pki-tomcat.service: Failed with result 'exit-code'. May 24 11:40:35 kdc1.sub.domain.tld systemd[1]: Failed to start PKI Tomcat Server pki-tomcat. So it seems something is broken on this upgrade script. This is in in almalinux 9.3 ipa-server-4.10.2-5.el9_3.alma.1.x86_64 I cannot upgrade because I get bitten by the named ldap thing, even though the versions are newer. I will create a replicat to a rhel host but first I need to get the CA up and running obviously :-). Any ideas? Thanks! -- regards, natxo -- -- Groeten, natxo

3 11

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users June 2024