FreeIPA-users February 2025

freeipa-users@lists.fedorahosted.org

31 participants
45 discussions

Re: Prevent user from changing its password
by Rob Crittenden 19 Feb '25

19 Feb '25

Ronald Wimmer wrote: > On 19.02.25 13:48, Rob Crittenden via FreeIPA-users wrote: >> Ronald Wimmer wrote: >>> >>> >>> On 13.02.25 17:42, Rob Crittenden wrote: >>>> Ronald Wimmer wrote: >>>>> On 12.02.25 19:15, Rob Crittenden wrote: >>>>>> More specifics would help. How did it not work as expected? What >>>>>> is the >>>>>> full ACI you came up with? >>>>>> >>>>>> The idea is that this is granted to all authenticated users EXCEPT >>>>>> those >>>>>> in the, in your case, iam-managed-users and admins groups. >>>>>> >>>>> We did not user RBAC much up to now. So it is very likely that I >>>>> did not >>>>> fully grasp the whole concept yet. >>>>> >>>>> What I did was adding users to a group called >>>>> cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at >>>>> and modifying the target filter to >>>>> (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=linux,dc=mydomain,dc=at))). >>>>> >>>>> >>>>> >>>>> >>>>> Nothing else. Because I thought the "System: Change User" permission >>>>> applies to all IPA users by default. This assumption might probably be >>>>> wrong... >>>>> >>>>> >>>> >>>> It is controlled by 'Self can write own password' >>>> >>>> $ ipa selfservice-show 'Self can write own password' >>>> Self-service name: Self can write own password >>>> Permissions: write >>>> Attributes: userpassword, krbprincipalkey, sambalmpassword, >>>> sambantpassword >>>> >>>> aci: (targetattr = "userpassword || krbprincipalkey || sambalmpassword >>>> || sambantpassword")(version 3.0; acl "selfservice:Self can write own >>>> password"; allow (write) userdn="ldap:///self";) >>> >>> ipapermtargetfilter: >>> (&(!(memberOf=cn=iam-managed-users,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))) >>> >>> >>> ipapermissiontype: SYSTEM >>> ipapermissiontype: V2 >>> ipapermissiontype: MANAGED >>> aci: (targetattr = "krbpasswordexpiration || krbprincipalkey || >>> passwordhistory || sambalmpassword || sambantpassword || >>> userpassword")(targetfilter = >>> "(&(!(memberOf=cn=admins,cn=groups,cn=accounts,dc=ipatest,dc=mydomain,dc=at))(objectclass=posixaccount))")(version >>> >>> 3.0;acl "permission:System: Change User password";allow (write) groupdn >>> = "ldap:///cn=System: Change User >>> password,cn=permissions,cn=pbac,dc=ipatest,dc=mydomain,dc=at";) >>> >>> Modifying the ipapermtargetfilter (manually in LDAP) did not produce the >>> aci I was expecting. Do I have to modify it by IPA API means (eg. CLI?) >>> or did I modify the wrong attribute? >> >> This is the wrong permission. This handles who can change someone else's >> password. To manage who can change their own you have to modify 'Self >> can write own password' via the selfservice plugin. > > I see. But when I remove all the password relevant attributes as an > admin users are still able to change their passwords... > You're saying users that are also admins can change their own passwords? admins are special so there may be additional ACIs involved. rob

2 4

Prevent user from changing its password
by Ronald Wimmer 19 Feb '25

19 Feb '25

What would be the best way to do this? Cheers, Ronald

2 10

automount location custom auto.master
by Thomas Berry 18 Feb '25

18 Feb '25

I'm wondering if there is a way to associate an enrolled host with a location and a customized auto.master map for a variety of host groups. I have created an automount location with a customer's many automount maps. This is a case where the associated hosts should only use a handful of the automount maps in the location. But, separating the automount maps across different locations is problematic as some of the maps are consistent across hosts and automount map changes would have to be managed across multiple locations. I'm hoping instead that custom auto.master maps can be created with relevant references to the maps, such as auto.master.host_a , auto.master.host_b, auto.master.host_c, then each host's sssd.conf might be configured--in the domain section--with a reference to the appropriate auto.master custom map. Is there a sssd.conf setting that allows the admin to set a custom auto.master entry in the location, or an alternative method of doing this that I have yet to come across.

2 1

ansible as freeipa service authenticated with keytab on ssh connection
by Clement Bouvier 18 Feb '25

18 Feb '25

Hello everyone, I am hitting a current problem because I might misunderstand how to work different functionnality present on freeIPA. As an administrator with an user account on freeipa, I can operate with ansible on different enrolled freeipa hosts in using my kerberos ticket and using GSSAPIAuthentication with the ssh client. I usually use the ansible collection freeipa.ansible_freeipa and an admin kerberos ticket with an GSSAPI authentication on ssh without problem. However as an administrator, now I would like that my ansible playbook run inside a pipeline environment in which I would inject a keytab for authenticating the playbook as a service on IPA. The pipeline is running on a host not enrolled on the freeIPA domain. The typical usecase would be that this ansible "service" (this word might be uncorrect) can enroll an IPA client on a IPA domain. So I would expect to create a IPA service (let's name it for this example "ansible" with the principal ansible/mypipeline.test(a)IPA.TEST) not attached to any host. I would expect to create a keytab for this service and this keytab would be injected in the pipeline task. I even add this service in a group admin and create a HBAC rule where the admins group can login on ipaservers with sshd. Based on this usecase, I got the problem that my service ansible/mypipeline.test cannot get any ssh connection on a ipaserver in using the GSSAPI authentication with the ssh client. I scanned the forum threads like this one: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahost… where the capacity of a FreeIPA service are illustrated (service not attached to any host and can be added as member of a group). I would image that the ssh connection with a service cannot work or it is not supported. Is it the case? The alternative way would be to create a IPA user named "ansible", request a keytab for this user and consumme this keytab in my pipeline? I can be more explicit with an example that I have in my lab but currently I think that my problem is more on my understanding on the IPA concepts and how to apply them to my workflow, so what why I am not so explicit right now. Thanks.

2 1

Changing an existing attributes properties (e.g. displayname)
by Andreas Moog 17 Feb '25

17 Feb '25

Hello there, I need to change the length and default value of an existing attribute for a user. In this case, the displayname. I thought I could simply add a plugin with: from ipaserver.plugins.user import user from ipalib import Str, _ user.takes_params += ( Str('displayname?', label=_('Display name'), default_from=lambda givenname, sn: '%s%s' % (givenname[0], sn[0:3]), maxlength=5, autofill=True, ), ) But that results in an error: AttributeError: cannot override NameSpace.displayname value... What am I doing wrong? Is this not the right way to do it? This is with FreeIPA 4.9.13 on RedHat 8. Thanks for any suggestions!

2 1

HBAC rule precedence
by Ronald Wimmer 11 Feb '25

11 Feb '25

Let's say we have a host somewhatsap.mydomain.at that is member of a hostgroup saphosts that has an HBAC rule saphhosts-ssh assigned. The host somwhatsap.mydomain.at has another HBAC rule (saphosts-ssh-somecountry) directly assigned. The user we wanted to grant access to somewhatsap.mydomain.at was only assigned to the saphosts-ssh-someounctry HBAC rule so the user could not access that particular host. ipa hbactest --user=myuser(a)MYDOMAIN.at --host=somewhatsap.mydomain.at --service=sshd -------------------- Access granted: True -------------------- Matched rules: saphosts-ssh Not matched rules: saphosts-ssh-somecountry The moment we put that user into the saphosts-ssh HBAC rule the user could access the host. So... is there some kind of HBAC rule precedence I am not aware of? I could not find an answer to this question in the official documentation... (and why does hbactest say the users is granted access when it actually is not?) Cheers, Ronald

2 1

Re: FreeIPA Client Not Auto-Discovering New Server & DNS Issues
by Florence Blanc-Renaud 10 Feb '25

10 Feb '25

Hi, As a side-note, please keep the mailing list in the recipients list. On Mon, Feb 10, 2025 at 5:40 PM azeem <azeemshopping93(a)gmail.com> wrote: > Hi Florence, > > Thanks for the response. > > Yes, I have added the new FreeIPA server's hostname in the /etc/hosts > file, and when I add the new FreeIPA server's IP to /etc/resolv.conf, the > client is able to discover the new FreeIPA server. However, do I need to > manually add the new FreeIPA server IP in the /etc/resolv.conf file every > time I set up a new client? I thought the command: > > ipa-client-install --hostname=$(hostname -f) --mkhomedir --server= > newfreeipa.ipa.testing.com --domain=ipa.testing.com --realm= > IPA.TESTING.COM > would automatically discover the FreeIPA server without needing to > manually add it to the /etc/resolv.conf file. > Please read the "Autodiscovery" section of the man page for ipa-client-install. Autodiscovery means that the installer finds the right server based on its own domain and the DNS records for _ldap._tcp.$DOMAIN or _ldap._tcp.$PARENTDOMAIN etc... The client must be properly configured for DNS otherwise it won't find any SRV record for _ldap._tcp.$DOMAIN. As Rafael pointed out, if you use ansible to automate the client installation, it is possible to have ansible-freeipa automate the DNS setup for you. If you are using the command-line, the DNS configuration is a prerequisite. Hope this clarifies, flo > > Also, when I run this command on the client, before adding the new FreeIPA > server IP to /etc/resolv.conf: > > dig _ldap._tcp.ipa.clear-markets.com SRV > > It lists the old FreeIPA servers instead of the new one. This is where I’m > stuck – it seems like auto-discovery isn’t working unless I explicitly add > the new FreeIPA server's IP in /etc/resolv.conf. > > On Mon, Feb 10, 2025 at 5:36 AM Florence Blanc-Renaud <flo(a)redhat.com> > wrote: > >> Hi, >> >> do your clients use the new IPA server as DNS server? This can be done >> prior to calling ipa-client-install. >> flo >> >> On Fri, Feb 7, 2025 at 5:01 PM azeem via FreeIPA-users < >> freeipa-users(a)lists.fedorahosted.org> wrote: >> >>> Hello All, >>> >>> I have two FreeIPA servers running in AWS—one primary and one >>> replica—with the DNS entry ipa.testing.com. These servers are running >>> an older version of FreeIPA on CentOS 7 with expired certificates. I >>> inherited this setup from a previous admin. >>> >>> Since the certificates have expired, I attempted multiple renewal >>> methods, including rolling back the system time, but nothing worked. As a >>> solution, I set up a new FreeIPA primary server with the same DNS entry ( >>> ipa.testing.com) and added it to the AWS DHCP configuration alongside >>> the old servers. >>> Steps Taken: >>> >>> 1. >>> >>> Added the new FreeIPA server to the /etc/hosts 123.234.543 >>> test.ipa.testing.com test >>> 2. >>> >>> Installed FreeIPA using the following command:- ipa-server-install >>> --setup-dns --allow-zone-overlap >>> 3. >>> >>> The installation completed successfully. I can log into the UI, >>> create users, and manage configurations without issues. >>> >>> The Problem: >>> >>> When installing a FreeIPA client, it does not auto-discover the new >>> FreeIPA server unless I explicitly specify it in the command: >>> >>> ipa-client-install --hostname=$(hostname -f) --mkhomedir --server=newfreeipa.ipa.testing.com --domain=ipa.testing.com --realm=IPA.TESTING.COM >>> >>> Without the --server parameter, auto-discovery fails. >>> >>> Additionally, after successfully enrolling two clients (client-a and >>> client-b), I am unable to resolve their hostnames between them. When I >>> attempt to ping client-a from client-b, I receive: >>> >>> Name or service not known >>> >>> What am I missing? >>> >>> - >>> >>> Why isn’t the client auto-discovering the new FreeIPA server? >>> - >>> >>> Why can’t the clients resolve each other’s hostnames after >>> enrollment? >>> - >>> >>> Is there anything I need to adjust in DNS or DHCP to ensure proper >>> resolution and discovery? >>> >>> Any help would be greatly appreciated! Thanks in advance. >>> -- >>> _______________________________________________ >>> 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

FreeIPA Client Not Auto-Discovering New Server & DNS Issues
by azeem 10 Feb '25

10 Feb '25

Hello All, I have two FreeIPA servers running in AWS—one primary and one replica—with the DNS entry ipa.testing.com. These servers are running an older version of FreeIPA on CentOS 7 with expired certificates. I inherited this setup from a previous admin. Since the certificates have expired, I attempted multiple renewal methods, including rolling back the system time, but nothing worked. As a solution, I set up a new FreeIPA primary server with the same DNS entry ( ipa.testing.com) and added it to the AWS DHCP configuration alongside the old servers. Steps Taken: 1. Added the new FreeIPA server to the /etc/hosts 123.234.543 test.ipa.testing.com test 2. Installed FreeIPA using the following command:- ipa-server-install --setup-dns --allow-zone-overlap 3. The installation completed successfully. I can log into the UI, create users, and manage configurations without issues. The Problem: When installing a FreeIPA client, it does not auto-discover the new FreeIPA server unless I explicitly specify it in the command: ipa-client-install --hostname=$(hostname -f) --mkhomedir --server=newfreeipa.ipa.testing.com --domain=ipa.testing.com --realm=IPA.TESTING.COM Without the --server parameter, auto-discovery fails. Additionally, after successfully enrolling two clients (client-a and client-b), I am unable to resolve their hostnames between them. When I attempt to ping client-a from client-b, I receive: Name or service not known What am I missing? - Why isn’t the client auto-discovering the new FreeIPA server? - Why can’t the clients resolve each other’s hostnames after enrollment? - Is there anything I need to adjust in DNS or DHCP to ensure proper resolution and discovery? Any help would be greatly appreciated! Thanks in advance.

3 2

FreeIPA servers falling out of sync?
by Martin Jackson 10 Feb '25

10 Feb '25

I'm experiencing this pretty regularly. srv-ds-2 will show messages of the following type: ``` [14/Dec/2024:15:29:58.343703946 -0600] - ERR - NSMMReplicationPlugin - changelog program - repl_plugin_name_cl - agmt="cn=meTosrv-ds-1.imladris.lan" (srv-ds-1:389): CSN 675de299000600140000 not found, we aren't as up to date, or we purged [14/Dec/2024:15:29:58.354587507 -0600] - ERR - NSMMReplicationPlugin - send_updates - agmt="cn=meTosrv-ds-1.imladris.lan" (srv-ds-1:389): Data required to update replica has been purged from the changelog. If the error persists the replica must be reinitialized. [14/Dec/2024:15:30:01.404036067 -0600] - ERR - agmt="cn=meTosrv-ds-1.imladris.lan" (srv-ds-1:389) - clcache_load_buffer - Can't locate CSN 675de299000600140000 in the changelog (DB rc=-12797). If replication stops, the consumer may need to be reinitialized. ``` Both are on current Fedora 41 (specifically 389-ds-base 3.1.1-3 and freeipa-server 4.12.2-6) using lmdb databases (I just finished migrating this domain to lmdb, by deleting the previous ipa servers one at a time and rebuilding new ones in their place.) Is there a way to configure how long to keep the changelog? I can (and have) re-initialized ds-2 a couple of times at this point, but after the third time in as many days, it seems like I should look for other solutions than re-initialization. Thanks!

3 2

Re: Upgrade from 4.12.2-1.el9 to 4.12.2-7.el9 on centos stream 9 failed
by Rob Crittenden 05 Feb '25

05 Feb '25

Russell Long wrote: > Here is the obfuscated sosreport. It looks like the CA restart that happened immediately before the first 404 was successful. At least it doesn't report any errors beyond the usual LDAP connection failures at startup. The startup looks to be basically done around 2025-02-03 14:37:56 The CA returned 404's at 2025-02-03T19:39:34Z in the upgrade log. We don't have the tomcat access logs in the sosreport so we can't see the requests but they would likely also report 404 and no other details. If you manually start things can you communicate with the CA? # ipactl --skip-version-check Does the CA start? If not add --ignore-service-failures Once everything else is up and settled, if the CA start failed run: systemctl restart pki-tomcatd@pki-tomcat And see if that is successful. I think it should succeed since it appears to have done so in the recent past. If so try a basic cert command: # openssl x509 -serial -noout -in /etc/ipa/ca.crt # ipa cert-show <that serial number> Does it give you data or a connection error? rob > > > On Wed, Feb 5, 2025 at 2:33 AM Alexander Bokovoy <abokovoy(a)redhat.com > <mailto:abokovoy@redhat.com>> wrote: > > On Пан, 03 лют 2025, Russell Long via FreeIPA-users wrote: > >Here is the log, sorry for the delay. Logs are redacted, but the > only thing > >changed was the domain names and DNs. > > The upgrade log chokes on the CA application not being registered in > tomcat container (the corresponding /ca/rest/... path is giving 404 > error). > > So we get back to the same point as before. An upgrade has been in > progress but somehow was interrupted. Directory server was having some > of listeners disabled to avoid external communication during the upgrade > and those listeners weren't recovered due to an interruption. You > recovered some of them but it looks like there is still something that > messes up. > > If you are saying all services are working fine, just the upgrade kicks > in every time 'ipactl restart' is run (which is part of ipa.service > machinery), it means the logged IPA data version is older than what IPA > sees in the RPM database. Temporarily, this can be fixed by looking at > /var/lib/ipa/sysupgrade/sysupgrade.state and changing ipa.data_version > value to be exact same as the RPM package version-release values. > > However, it would help to understand why an upgrade causes CA apps to > fail to register with the tomcat container. It looks like we have at > least three such cases on this list over past week or so, all on CentOS > 9 Stream, so there might be something? > > May be you can install sos report tool and collect a larger amount of > data altogether so that we can see a greater picture? > > # dnf install sos > # sos report --profile={identity,security,system,services,network} > --clean -a > > This should produce logs with consistently obfuscated hostnames and > domains across all files. You can add more domains to obfuscate with > `--domains={domain1,domain2,..}` to `sos report` tool. > > > > > > > > >On Wed, Jan 29, 2025 at 4:51 PM Rob Crittenden <rcritten(a)redhat.com > <mailto:rcritten@redhat.com>> wrote: > > > >> Russ Long via FreeIPA-users wrote: > >> > Things are functional, however IPA still thinks it needs an > upgrade, so > >> any time the service restarts, it breaks again. > >> > > >> > >> If you have time to run the upgrade again and send us a compressed > >> /var/log/ipaupgrade.log we can see if we can identify the root cause. > >> > >> rob > >> > >> > > > > > -- > / Alexander Bokovoy > Sr. Principal Software Engineer > Security / Identity Management Engineering > Red Hat Limited, Finland >

1 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users February 2025