FreeIPA-users February 2025

freeipa-users@lists.fedorahosted.org

31 participants
43 discussions

How to install replica as trust-controller
by Finn Krein-Schuch 24 Feb '25

24 Feb '25

Hello all, I'm planning to set up freeipa with two replicated servers. As there are only two servers both should be able to handle all tasks (CA, Trust). As I understood the recommendation is to at least have two trust-controllers. I know that I can install a replica as a trust-agent with --add-agents but could not find out how to install it as a trust-controller. How do I install a replica as a trust-controller? Thank you for your help Finn

2 2

can't enroll ubuntu 24
by Dmitry Krasov 24 Feb '25

24 Feb '25

Hello. Trying to enroll Ubuntu 24.04 to domain, but it says "certificate verify failed: Hostname mismatch, certificate is not valid for 'ipa2.dom.loc'. (_ssl.c :1000)" But when I trying ipa web adress via browser it's seems fine. It's selfsigned like always, but date and name are fine. And just recently I have successfully added another one host How can I fix it? Maybe I can disable certificate checking somehow, just for start? sudo ipa-client-install --hostname dit-ntb-spc39-1797875.dom.loc --server=ipa2.dom.loc --enable-dns-updates --domain dom.loc --mkhomedir -p admin -w Password --force-join This program will set up IPA client. Version 4.11.1 WARNING: conflicting time&date synchronization service 'ntp' will be disabled in favor of chronyd Using existing certificate '/etc/ipa/ca.crt'. Autodiscovery of servers for failover cannot work with this configuration. If you proceed with the installation, services will be configured to always access the discovered server for all operations and will not fail over to other servers in case of failure. Proceed with fixed values and no DNS discovery? [no]: y Do you want to configure chrony with NTP server or pool address? [no]: Client hostname: dit-ntb-spc39-1797875.dom.loc Realm: dom.loc DNS Domain: dom.loc IPA Server: ipa2.dom.loc BaseDN: dc=l3874,dc=ru Continue to configure the system with these values? [no]: y Removed old keys for realm dom.loc from /etc/krb5.keytab Synchronizing time Configuration of chrony was changed by installer. Attempting to sync time with chronyc. Time synchronization was successful. Enrolled in IPA realm dom.loc Created /etc/ipa/default.conf Domain dom.loc is already configured in existing SSSD config, creating a new one. The old /etc/sssd/sssd.conf is backed up and will be restored during uninstall. Configured /etc/sssd/sssd.conf Connection to https://ipa2.dom.loc/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'ipa2.dom.loc'. (_ssl.c :1000) Connection to https://ipa.dom.loc/ipa/json failed with [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed: Hostname mismatch, certificate is not valid for 'ipa.dom.loc'. (_ssl.c:1000) cannot connect to 'любой из настроенных серверов': https://ipa2.dom.loc/ipa/json, https://ipa.dom.loc/ipa/json The ipa-client-install command failed. See /var/log/ipaclient-install.log for more information

4 39

How to add another host as CA?
by Boris 20 Feb '25

20 Feb '25

Hi, I just got two IPA servers handed over and those are a mess. To get this sorted out I want to start with having both as a CA host. Even the webUI says "It is strongly recommended to keep the following services installed on more than one server: CA" I have basically 0 knowledge about IPA, the named is crashing ragularly with asseratation errors, the login on the 2nd IPA webinterface fails "due to unknown reason", updates on the first IPA are not working and the host ist started with "ipactl start --force" and no one know the directorymanager password anymore. So I thought to start small and get the second CA running. -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groÃƒ¼en Saal.

3 11

IPA DogTag vs. RedHat Certificate System
by Ronald Wimmer 20 Feb '25

20 Feb '25

Is the dogtag instance IPA uses comparable to RH Certificate Sytem (https://access.redhat.com/products/red-hat-certificate-system )? Could IPA's dogtag act as a fully fledged CA for other purposes? Cheers, Ronald

2 1

20 Feb '25

Hi list, as I am currently sorting out our freeipa problems we stumbled across another problem. After the last reboot of our 2ndary IPA host, we can no longer login into the webui on the 2nd host. The webui on the first host works. I've checked some logs but was only able to find meaningful entries in the httpd log which is this: mod_wsgi (pid=1137): Exception occurred processing WSGI script '/usr/share/ipa/wsgi.py'. Traceback (most recent call last): File "/usr/lib/python3.10/site-packages/ipaserver/wsgi.py", line 71, in application return api.Backend.wsgi_dispatch(environ, start_response) File "/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 301, in __call__ return self.route(environ, start_response) File "/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 313, in route return app(environ, start_response) File "/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 1066, in __call__ result = attempt_kinit(user_principal, password, File "/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 996, in attempt_kinit self.kinit(user_principal, password, File "/usr/lib/python3.10/site-packages/ipaserver/rpcserver.py", line 1094, in kinit kinit_armor( File "/usr/lib/python3.10/site-packages/ipalib/install/kinit.py", line 129, in kinit_armor run(args, env=env, raiseonerr=True, capture_error=True) File "/usr/lib/python3.10/site-packages/ipapython/ipautil.py", line 599, in run raise CalledProcessError( ipapython.ipautil.CalledProcessError: CalledProcessError(Command ['/usr/bin/kinit', '-n', '-c', '/run/ipa/ccaches/armor_1137', '-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: 'kinit: Cannot read password while getting initial credentials\\n') Does someone know in which direction I need to debug further? Cheers Boris -- Die Selbsthilfegruppe "UTF-8-Probleme" trifft sich diesmal abweichend im groÃƒ¼en Saal.

2 7

unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000
by Chris Jacobs 20 Feb '25

20 Feb '25

I have tried (providing password and our actual domain name scrubbed below): clean dangling ruvs using ``` root(a)ipa01.mgmt ~ # ipa-replica-manage clean-dangling-ruv unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000 unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000 unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000 unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000 No dangling RUVs found ``` cleaning that ruv specifically: ``` root@ipa01 ~ # ipa-replica-manage --force --cleanup clean-ruv 27 unable to decode: {replica 27} 60771c010007001b0000 60771c010007001b0000 Replica ID 27 not found ``` ldapmodify - which runs without error and no change: ``` root@ipa01 ~ # cat clean-27.ldif dn: cn=clean 27,cn=cleanallruv,cn=tasks,cn=config changetype: add objectclass: top objectclass: extensibleObject replica-base-dn: dc=ipa,dc=example,dc=net replica-id: 27 cn: clean 27 root@ipa01 ~ # ldapmodify -D "cn=directory manager" -f clean-27.ldif adding new entry "cn=clean 27,cn=cleanallruv,cn=tasks,cn=config" ``` Here's the topology (you can see ipa and idm nodes - working to eventually replace the CentOS 7 ipa nodes with RHEL8 idm nodes - but this replica 27 has been around ... forever as far as I'm concerned): ``` root@ipa01 ~ # ipa topologysegment-find domain ------------------ 9 segments matched ------------------ Segment name: idm01.example.net-to-idm02.example.net Left node: idm01.example.net Right node: idm02.example.net Connectivity: both Segment name: idm01.example.net-to-ipa01.example.net Left node: idm01.example.net Right node: ipa01.example.net Connectivity: both Segment name: idm02.example.net-to-idm04.example.net Left node: idm02.example.net Right node: idm04.example.net Connectivity: both Segment name: idm03.example.net-to-idm01.example.net Left node: idm03.example.net Right node: idm01.example.net Connectivity: both Segment name: idm04.example.net-to-idm03.example.net Left node: idm04.example.net Right node: idm03.example.net Connectivity: both Segment name: ipa01.example.net-to-ipa02.example.net Left node: ipa01.example.net Right node: ipa02.example.net Connectivity: both Segment name: ipa01.example.net-to-ipa03.example.net Left node: ipa01.example.net Right node: ipa03.example.net Connectivity: both Segment name: ipa02.example.net-to-ipa04.example.net Left node: ipa02.example.net Right node: ipa04.example.net Connectivity: both Segment name: ipa03.example.net-to-ipa04.example.net Left node: ipa03.example.net Right node: ipa04.example.net Connectivity: both ---------------------------- Number of entries returned 9 ---------------------------- root@ipa01 ~ # ipa topologysegment-find ca ------------------ 9 segments matched ------------------ Segment name: idm01.example.net-to-idm02.example.net Left node: idm01.example.net Right node: idm02.example.net Connectivity: both Segment name: idm01.example.net-to-ipa01.example.net Left node: idm01.example.net Right node: ipa01.example.net Connectivity: both Segment name: idm02.example.net-to-idm04.example.net Left node: idm02.example.net Right node: idm04.example.net Connectivity: both Segment name: idm03.example.net-to-idm01.example.net Left node: idm03.example.net Right node: idm01.example.net Connectivity: both Segment name: idm04.example.net-to-idm03.example.net Left node: idm04.example.net Right node: idm03.example.net Connectivity: both Segment name: ipa01.example.net-to-ipa02.example.net Left node: ipa01.example.net Right node: ipa02.example.net Connectivity: both Segment name: ipa01.example.net-to-ipa03.example.net Left node: ipa01.example.net Right node: ipa03.example.net Connectivity: both Segment name: ipa02.example.net-to-ipa04.example.net Left node: ipa02.example.net Right node: ipa04.example.net Connectivity: both Segment name: ipa03.example.net-to-ipa04.example.net Left node: ipa03.example.net Right node: ipa04.example.net Connectivity: both ---------------------------- Number of entries returned 9 ---------------------------- ``` I've even gone off the rails and manually deleted the nsds50ruv and nsruvReplicaLastModified entries for these on sub entries of cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config (where I found *something* referencing it). I've pored over the google results for this - including some from this mailing list - the unsuccessful threads seem to simply die from lack of response, while the successful ones found a segment they could delete. Any help would be appreciated. Thanks, - chris

3 6

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

20 Feb '25

Ronald Wimmer wrote: > > > On 19.02.25 19:37, Rob Crittenden wrote: >> Ronald Wimmer via FreeIPA-users wrote: >>> On 19.02.25 16:40, Rob Crittenden via FreeIPA-users wrote: >>>> Ronald Wimmer via FreeIPA-users wrote: >>>>> On 19.02.25 15:54, Rob Crittenden via FreeIPA-users wrote: >>>>>> 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. >>>>> >>>>> No. My eypectation was that regular users cannot change their >>>>> passwords >>>>> anymore after I removed the password attributes from the selfservice >>>>> permission you named above. >>>> >>>> It is very difficult to help you if you don't show your work. >>>> >>>> What does the selfservice entry look like? >>>> >>>> How are you testing the password change? >>> >>> Sorry. I try to be more specific. Initially I wanted to forbid password >>> change for a certain user group. But now I just wanted to see it working >>> in general. So... the IPA installation is completely unmodified in this >>> regard. >>> >>> What did I try? >>> Taking away all password-related attributes I found in the "Self can >>> write own password" permission. I did this with the IPA admin user. >> >> You still haven't shown the selfservice permission. > > ipa selfservice-show --raw > Self-service name: Self can write own password > aci: (targetattr = "krbprincipalkey")(version 3.0;acl > "selfservice:Self can write own password";allow (write) userdn = > "ldap:///self";) > > >> >> How did you remove all attributes? It should throw an error about >> invalid or missing values. > > Logged into IPA via the WebGUI as admin. Went to IPA Server->RBAC->Self > Service Permissions. Clicked on "Self can write own password". Unchecked > "userpassword". Clicked on "save". Logged out and logged back in as a > non-admin. Tried password change. Worked. (and my expectation was it > should not have worked.) > krbprincipalkey is also the password, as are all the other attributes in the permission. If you delete the permission then the next upgrade will re-create it so I'd suggest removing all attributes from it and adding something a user already has for themselves, like ipasshpubkey. rob

2 2

Re: automount location custom auto.master
by Berry, Thomas M (US 198D) 19 Feb '25

19 Feb '25

Rob, We did manage to figure out how to align autofs and automount properly on the enrolled host so that LDAP setup with those services are aligned with domain location-based server SRV records. After enrolling the host with the domain, /etc/autofs.conf can be configured with the domain settings # adding lookup_srv_rr enables SRV awareness in the autofs/automount relevant LDAP configuration lookup_srv_rr = yes # set the search bases specific to the automount location and domain search_base = "cn=my_automount_loc,cn=automount,dc=idm,dc=domain” # align autofs with the IPA schema map_object_class = automountMap entry_object_class = automount map_attribute = automountMapName entry_attribute = automountKey value_attribute= automountInformation Then enable ldap for automount in /etc/nsswitch.conf automount: ldap files Finally, configure a custom auto.master include file in /etc/auto.master.d/custom.master.autofs which has key and value (information) pairs similar to auto.master entry in the automount location (amloc specified in the searchbase of autofs) on the domain, for example: /mnt auto.mnt /home auto.home Restarting autofs services was the last action to perform and the automounts specified in custom.master.autofs were accessible. I will have to figure out how to submit a feature request; it would be nice if we were able to use an sssd.conf setting like ipa_automount_master = auto.master.custom to go along with ipa_automount_location to specify a custom default auto.master map entry in the designated automount location.

1 0

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

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

FreeIPA-users February 2025