January 2024 - FreeIPA-users - Fedora mailing-lists

FreeIPA Upgrade - overwrites custom authselect config
by Finn Fysj 06 Feb '24

06 Feb '24

I've recently tried to run an upgrade of my IPA server (4.10.2) because of some CVE fix for 4.10.3. At the end of upgrade the IPA server tries to run: CalledProcessError(Command ['/usr/bin/authselect', 'select', 'sssd', 'with-sudo', '--force'], why does it do this? The upgrade in my case fails because I've set made following files immutable: /etc/authselect/{password-auth,system-auth}.

3 10

CentOS 7 FreeIPA upgrade, 4.5 to 4.6.8: certmonger hanger
by Melissa Ferreira da Silva Boiko 05 Feb '24

05 Feb '24

Hello all. I'm trying to replace an ancient FreeIPA 4.5.0 master (and primary CA master) on CentOS 7.4. I am having problems trying to make replicas with FreeIPA 4.11, and past threads suggest the errors are due to incompatibility of password hash algorithms, which are supposed to be fixed on the older releases rather than the newer. Therefore I'm trying to upgrade the old server to the current version in the CentOS 7 repos, 4.6.8, to try to create fresh replicas from there. But I'm having issues with the certmonger systemd service hanging, and breaking ipa-server-upgrade--whether I update the whole CentOS to 7.9.2009, or just ipa-server and its dependencies, the result is the same. This is where ipa-server-upgrade breaks: [Verifying that root certificate is published] [Migrate CRL publish directory] CRL tree already moved [Verifying that CA proxy configuration is correct] IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run command ipa-server-upgrade manually. Unexpected error - see /var/log/ipaupgrade.log for details: CalledProcessError: Command '/bin/systemctl start certmonger.service' returned non-zero exit status 1 The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for more information This is because certmonger.service hangs until timeout. That happens when starting the service manually, too. Logs for certmonger.service are not informative: -- Subject: Unit certmonger.service has begun start-up -- Unit certmonger.service has begun starting up. Jan 31 14:38:59 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: certmonger.service start operation timed out. Terminating. Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: certmonger.service stop-sigterm timed out. Killing. Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: certmonger.service: main process exited, code=killed, status=9/KILL -- Subject: Unit certmonger.service has failed -- Unit certmonger.service has failed. Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: Unit certmonger.service entered failed state. Jan 31 14:40:29 vm-ipa-1.intra.viaboxxsystems.de systemd[1]: certmonger.service failed. root@vm-ipa-1.intra.viaboxxsystems.de[lxc](e:0,1s)(j:0) ~ Running `certmonger -S -n -d 9` seems to run ok. The only difference in the systemd service file is, I think, whatever it is that the BusName setting does. dbus is running seemingly without issue, nothing on logs. Restarting dbus.service doesn't help. The machine is an LXC container with 4GiB RAM, which doesn't come close to being exhausted when trying to restart certmonger. No OOM in logs. I saw this thread about certmonger problems with ulimit in containers: https://bugzilla.redhat.com/show_bug.cgi?id=1656519 But the suggested workaround (make sure ulimit -n is the same in container and host) doesn't apply because it's already the same for us. How should I proceed from here?

3 4

Issues with sudo permissions
by slek kus 05 Feb '24

05 Feb '24

Hi, created an account which is meant to automate things with Ansible AWX. Tried to grant this account sudo access to the linux clients but things seem not to work out. Not sure why. hbactests returns OK. ---- [root@idm01 ~]# ipa hbactest --user=ansible --host=debclient1.linux.<redacted>.services --service=sshd -------------------- Access granted: True -------------------- Matched rules: allow_ansible_ssh2idm Not matched rules: allow_systemd-user Not matched rules: test_aduser [root@idm01 ~]# ipa hbactest --user=ansible --host=debclient1.linux.<redacted>.services --service=sudo-i -------------------- Access granted: True -------------------- Matched rules: allow_ansible_ssh2idm Not matched rules: allow_systemd-user Not matched rules: test_aduser [root@idm01 ~]# ipa hostgroup-show all_clients_hg Host-group: all_clients_hg Description: This group contains all clients registered to this IdM. Member hosts: debclient2.linux.<redacted>.services, debclient1.linux.<redacted>.services Member of HBAC rule: allow_ansible_ssh2idm, test_aduser [root@idm01 ~]# ipa hbacrule-show allow_ansible_ssh2idm Rule name: allow_ansible_ssh2idm Enabled: True Users: ansible Host Groups: ipaservers, all_clients_hg HBAC Services: sshd, sudo, sudo-i HBAC Service Groups: Sudo ---- I can login with user ansible onto debclient2, using a ssh pub key set in IDM just fine. But when trying to sudo, this is not allowed. Even though I have locally enabled it in sudoers (which should't be nessecary). ---- root@debclient2:~# su - ansible@linux.<redacted>.services su: Permission denied root@debclient2:~# getent passwd ansible@linux.<redacted>.services ansible:*:996000008:996000008:Automation User:/home/ansible:/bin/bash ansible@debclient2:~$ sudo -i [sudo] password for ansible: ansible is not allowed to run sudo on debclient2. ansible@debclient2:~$ id uid=996000008(ansible) gid=996000008(ansible) groups=996000008(ansible) -----

4 7

FreeIPA cluster, backup and restore
by Finn Fysj 02 Feb '24

02 Feb '24

Have a cluster setup with is setup using Ansible FreeIPA roles ipaserver & ipareplica. Running ipabackup using script as the ipabackup role doesn't work as wanted or intended, meaning not able to take backup of data. Multiple master, only one with CA installed. When I run ipabackup to backup data I get the following: Error: Local roles do not match globally used roles CA. A backup done on this host would not be complete enough to restore a fully functional, identical cluster. The ipa-backup command failed. See /var/log/ipabackup.log for more information. The error message is somewhat understandable. We don't use FreeIPA CA capabilities, so that's the reason we don't have it installed on replicas, unless you guys would recommend otherwise? I've tried to test a little using these ansible roles. What happens if my Master with the only backup goes down? Yes, I'll have a replica making sure everything works as normal, so I can scrap the master, rebuild it and restore the data backup I took. However, once the node is restored, there's still not any connection between the two nodes now, since a re-run of the ipareplica won't do anything since it's already installed. Does that mean we need to rebuild this node as well? A normal data restore of a node will stop the replication connection between the two nodes, meaning it needs to be "re-connected", this is also not something that can be done using these roles? One final question: If we have a working cluster setup, and some sausage fingers manages to delete the replica from the "CA node". How can I re-initalize this with the ansible replica role, or is rebuild the only option?

4 6

Re: issues ssh'ing as AD user to freeipa client
by Sumit Bose 01 Feb '24

01 Feb '24

Am Wed, Dec 13, 2023 at 11:49:00PM +0000 schrieb Ostrom, Erik via FreeIPA-users: > Hi, > > I'm having some issues ssh'ing as an AD user to a freeipa client, but I can successfully ssh as the same user to the IPA master. > Our IPA domain, ipa.subdomain.contoso.com, is set up with a one-way trust with ad.contoso.com (IPA trusts ADs users). I have the standard "allow all" HBAC rule in place on FreeIPA for testing purposes. ad.contoso.com is a relatively huge AD, with over 400,000 user accounts. > > ssh erik-ipa(a)freeipa1.ipa.subdomain.contoso.com --- (IPA user to FreeIPA master), works > ssh erik-ad@ad.contso.com@freeipa1.ipa.subdomain.contoso.com --- (AD user to FreeIPA master), works > ssh erik-ipa(a)rl9-ipa-client1.in.subdomain.contoso.com --- (IPA user to FreeIPA client), works > ssh erik-ad@ad.contoso.com@rl9-ipa-client1.in.subdomain.contoso.com --- (AD user to FreeIPA client), doesn't work > > I'm not sure what to look at in the SSSD logs to see what's going wrong here. I have uploaded sanitized SSSD logs from rl9-ipa-client1.in.subdomain.contoso.com for a failed login attempt (listed above as not working) at the following link:https://privatebin.net/?55e82c73463ae145#A59jSajU1ZwEwr3nEKhPqsT8Um4QX… Hi, according to the logs, the IPA server needs too much time to prepare the data of the AD user which the client requested. (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_get_acct_info_send] (0x0400): [RID#229] Sending request_type: [REQ_FULL_WITH_MEMBERS] for trust user [erik-ad] to IPA server (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x0400): [RID#229] Executing extended operation (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [ipa_s2n_exop_send] (0x2000): [RID#229] ldap_extended_operation sent, msgid = 41 (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_op_add] (0x2000): [RID#229] New operation 41 timeout 6 (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: sh[0x55e456f262f0], connected[1], ops[0x55e456efac80], ldap[0x55e455ed5310] (2023-12-12 16:31:13): [be[ipa.subdomain.contoso.com]] [sdap_process_result] (0x2000): Trace: end of ldap_result list (2023-12-12 16:31:19): [be[ipa.subdomain.contoso.com]] [sdap_op_timeout] (0x1000): [RID#229] Issuing timeout [ldap_opt_timeout] for message id 41 Typically this means that the server has to refresh some or all cached data of the user, which in this case will include all group-memberships and for some technical reasons this means refreshing all related expired groups and their members. At least for the group members this can be speed up by setting ignore_group_members = True subdomain_inherit = ignore_group_members in the [domain/...] section on IPA servers and clients. Another option is to set refresh_expired_interval = 4000 in the [domain/...] sections on the IPA servers to make sure that SSSD will try every 4000s to refresh cached entries which are about to expire. As a result the IPA servers should be able to always reply to request form IPA client with cached data without the need to refresh it. HTH bye, Sumit > > If anyone can tell what my issue is here, or if other logs would be helpful let me know. I appreciate the help! > > Thanks, > Erik > -- > _______________________________________________ > FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave(a)lists.fedorahosted.org > Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

2 1

XRDP certificates via FreeIPA fails with an SELinux error
by Bo Lind 31 Jan '24

31 Jan '24

I'm rolling out some servers providing a graphical desktop, and everything is fine except this: our desktop software of choice is XRDP which needs a certificate. It ships with a self-signed one, but that gives warnings on the clients, so I'd much rather go with a FreeIPA managed one. So after installing XRDP, I issue the command: ipa-getcert request -f /etc/xrdp/cert.pem -k /etc/xrdp/key.pem -r -w Problem is, this fails with SELinux enabled, because ipa-getcert is not permitted to write to /etc/xrdp. Proposed solution 1: Use a better dir, the certificate and key are configured in /etc/xrdp/xrdp.conf so I'm guessing certs can reside anywhere. What's a good default one? Somewhere in /etc/pki? Proposed solution 2: Make and install a SELinux policy that allows ipa-getcert to access that directory. Searching a bit, I can see that the issue comes up on occasion, with other software packages such as Puppet etc.

2 1

FreeIPA -Airtight- No access to Internet - How to update/upgrade package installation.
by Marcelo Carvalho 30 Jan '24

30 Jan '24

I have an FreeIPA host that has to be out of reach of Internet. I can update the host OS and packages by syncing RHEL repo to my LocalRepo. No issues there for every package installed, but I am not able to update FreeIPA. From https://www.freeipa.org/page/Upgrade we have instruction on upgrades: FreeIPA 3.3.0 or newer # yum update freeipa-server I have not tried because the purpose is to bring "freeipa-server" package to the LocalRepo for host access. I cannot find the repository for "freeipa-server." Please advise on how to identify FreeIPA repo for RHEL-9, or how to proceed with offline FreeIPA upgrade. Many thanks. Marcelo Carvalho IT Senior System Administrator Astranis Space Technologies Corp. mcarvalho(a)astranis.com https://www.astranis.com/ P.S. Will "# yum update freeipa-server" work? I do not see it as output of the repository when the development host is available to them. The host is running on AWS and using a Linux RHEL-9 from AWS.

3 4

Cannot login to FreeIPA as 'admin' user...
by Tom Spettigue 26 Jan '24

26 Jan '24

Hey all - I'm having an odd bug when I try to login to the web interface as the FreeIPA 'admin' user. I get the following error message: Login failed due to an unknown reason. Not sure where that's coming from, but per this post (https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost…) I went ahead and checked the validity period of the `/var/kerberos/krb5kdc/kdc.crt` with the `openssl x509 -text -in /var/kerberos/krb5kdc/kdc.crt` command. Sure as shoot, that certificate expired on the 22nd of January at about 7:00 AM GMT - and I'm stuck unable to login and manage my domain. :( Now according to the end of that thread, the problem just up and fixed itself but I'm up against a wall here in that I... definitely need to to be able to get in pretty soon, as I have a new host I need to provision. Is there any way to manually jumpstart this process?

1 2

Permission / privilege to unlock accounts
by Russell Long 25 Jan '24

25 Jan '24

I'm trying to create a set of limited users who have the ability to unlock all other user accounts and change their passwords. I've got the password portion figured out, however when a user with the limited permissions tries to run the `unlock` operation they get the following message: Insufficient access: Insufficient 'write' privilege to the 'krbLoginFailedCount' attribute of entry... I have attempted to create a permission granting this access, but it does not appear to work. I'll attach an image of the existing permission, not sure how the list will handle the image. --Russ

3 2

Is there even one freeipa dev that knows everything about upgrading across major OS releases?
by Harry G Coin 25 Jan '24

25 Jan '24

Hi! This is meant for the good future of freeipa, a package I've appreciated for some years, so across the user cultures and languages please understand it as supportive and not a complaint! For all freeipa's 'master-master' replica technology, there remain 'some instances more primary than others' even if the topology diagrams claim equivalence. Lose 'that one that's even more primary' and (absent high-learning-curve, on-site capability, and intervention that calls for high-bar mastery of seldom used subsystems) -- you're on a track to breakage. Why? Because it's when, not if, that 'primary' system will need a major OS point release (8 to 9 in the present situation). In that case, there is as yet no 'just works' upgrade path. With 'not the super special 'even more master than other' master replicas, it's easy and 'it just works'... but 'for that one...' freeipa is not ready for 'prime time'. For example, should site admins 'just know' whether there is a current kasp.db maintained in more than one place? How many know about ipa-crlgen-manage, or whether /etc/pki/pki-tomcat/ca/CS.cfg should or shouldn't have ca.certStatusUpdateInterval=0, or have the command ipa config-mod --ca-renewal-master-server at the top of their mind? SID range assignments? Fundamentally, the fair question is: Which freeipa subsystems that I don't happen to have studied in dev-level detail have similar 'deep gotchas that are obvious to the one who specializes in that, but opaque to everyone else'? Not even the freeipa devs who write the docs collect all the steps in one place. While there are 'characterizations of worries' those come without steps, the advice doesn't say what steps will work, just what won't. ('don't leapp upgrade'). The way forward I think is fairly doable. First is to have each 'dev that's an expert in their thing' (dns, kra, etc. etc.) make sure all 'master' level replicas have, updated, whatever 'special files' might be necessary, even if they aren't 'the extra special primary replica', and may never get used. Second is an 'orchestration' command, to be run on a master-replica that is 'the latest os', that will, 'all in one', do all the magic to become 'the extra special primary master' and take those options off 'the old primary', even if it means installing trust/dns/etc subsystems extant on the 'old master' but missing from the 'soon to be new primary master'. An orchestration command that manages everything from moving which fqdn is authoritative in SOA records, to magic tiny entries in CA.cfg files. When that command is done, the 'old primary' becomes 'just another master replica that happens to be using an older os'. Then the 'old primary' can be discarded and replaced with the latest os and a fresh install as a master replica. At that point, it's optional whether to move the 'special primary' status 'back' to the 'now new OS master system'. The admin pain involved at present 'for that one system that's the extra special primary' at os major release upgrade time -- it sets too high an education bar, obviously higher than even one freeipa-dev has, as the docs prove-- and as such needs a team approach to address,, before OS 9 to 10 please! Thanks for all you've done so far! Harry Coin

2 5

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users January 2024