What would be a good solution to add systems where the FQDN cannot be
Would it make sense to add a second DNS A Record in the IPA domain for
each of these systems?
Is there any experience on how to deal with such a situation?
Thanks a lot in advance!
We recently renewed our IPA CA cert using the "ipa-cacert-manage renew” command. The renewal was successful, and our CA cert no longer expires in 2020, but in 2040.
Running “ipa-certupdate” on existing IPA clients and ipa-client-install on new IPA clients also works, however both the new and the old CA cert is pulled down to the IPA client and stored in /etc/ipa/ca.crt.
This creates some issues as most applications reading /etc/ipa/ca.crt only reads the first entry, which happens to be the old CA cert.
For the moment everything works OK as the old CA cert is still valid, however this will become a major issue in a few months time.
Is this expected? To continue to service both the old and the new CA certificate to old and new IPA clients?
Will the old certificate be automatically removed at some point?
If not, what is the safe steps to remove the old CA certificate from the IPA servers?
I upgraded my Centos servers from 7.7.1908 to 7.8.2003 and ipa upgrades
from 4.6.5 to 4.6.6
In the directory /usr/share/ipa/ui/js/plugins/bureau , I am using the
enclosed file bureau.js
to show the room number field in the gui. But after the upgrade, the
field is there, but empty.
I deleted one of my servers, downgrade ipa packages et reinstall ipa,
and the plugin is working,
I can see the value in the field.
Do you have any idea ?
Administrateur Systèmes et Réseaux
Laboratoire d'Informatique de l'Ecole polytechnique
If you've tried to use container engines such as podman, and other tools that rely on newuidmap/newgidmap for the configuration of user namespaces on systems where users are defined in FreeIPA, you've probably had to create entries in /etc/subuid and /etc/subgid manually.
I created a PAM module that automatically creates /etc/subuid and /etc/subgid entries when a user logs in. It can be found at <https://github.com/yrro/pam_subuid>. It's pretty rudimentary, but it does work on my machines; I hope other users of FreeIPA may find it useful, and maybe even send bug reports and pull requests. :)
I hope this isn't considered spamming--I created it in order to use it as a stopgap measure until shadow/sssd/FreeIPA are able to manage subordinate user/group IDs themselves.
Sam Morris <https://robots.org.uk/>
I've encountered a minor annoyance when using the 'enrollement
I created a user for ipa-client enrolment and made the user a member of the
'enrollement administrator' role.
I've tested it and it was capable of enrolling clients.
After this I disabled the allow_all policy.
Cleared the sssd cache on the ipa server and tried again.
Now the user get's a 'No permission to join this host to the IPA domain.'
It works for ipa admin accounts.
I guess I need to allow a service for the 'enrollement administrator' role.
But I don't know which one.
What service do I need to allow for the 'enrollement administrator' role to
function properly ?
Thank you for answering this quickly.
>From: Alexander Bokovoy <abokovoy(a)redhat.com>
>Sent: Wednesday 29th April 2020 15:48
>To: FreeIPA users list <freeipa-users(a)lists.fedorahosted.org>
>Cc: Julien Rische <julien.rische(a)cern.ch>
>Subject: Re: [Freeipa-users] Administration delegation for multiple hosts services
>On ke, 29 huhti 2020, Julien Rische via FreeIPA-users wrote:
>>To properly support load-balanced services, we need FreeIPA-managed service
>>hosts to be able to retrieve the following elements, without the intervention
>>of any user (only starting with the host keytab):
>>- Keytab containing keys for:
>> - Service canonical principal
>> - When accessed via service DNS alias (Kerberos rDNS lookup disabled)
>> - Service principal alias for host
>> - When accessed via service DNS alias (Kerberos rDNS lookup enabled)
>> - When accessed via host canonical FQDN
>>- X.509 certificate for:
>> - Service alias FQDN
>> - Host actual FQDN
>>In order to obtain each element of this list, we need to:
>>- Allow the host to retrieve the service key
>> - Creation/reset of the key should be forbidden
>>- Allow the host to request a certificate for both its own FQDN and the service
>> DNS alias (which matches the service canonical principal)
>> - Preferably only these 2 subject names should be allowed
>>- Create a service principal alias matching the host's FQDN
>>We are managing hundreds of services spread across tens of thousands of hosts.
>>Each service is managed by a different user group, hence we can't afford to
>>grant all these users the "Service Administrators" privilege.
>>Ideally, each service would be configured just once (with just maybe a few
>>exceptional updates). On the contrary, hostgroup(s) containing the service
>>hosts would be continuously updated. This way, FreeIPA administrator would give
>>their blessing at service creation, and then let service administrators manage
>>We think the following configuration could be applied for each service:
>>- A hostgroup containing all the service hosts, allowed to:
>> - Retrieve the service key
>> - Request certificate with alternative suject name by:
>> - Being assigned the to "managedBy" service attribute
>> - Or being granted the permission to write the "userCertificate"
>> service attribute
>>- A service administrators group, allowed to:
>> - Write the "member" attribute of the hostgroup
>> - Create/reset the service key
>>The keytab creation/retrieval part is quite straight forward to deal with. But
>>this is not necessarily the case for certificates and service principal aliases:
>>We observed the "managedBy" setting has 2 downsides:
>>- It grants the host the permission to request a certificate with subject
>> alternative names, but it also grants the permission to create/reset the key,
>> which we don't want.
>>- It consists of a list of hosts that must be continuously maintained, since it
>> cannot refer to the hostgroup directly.
>>Therefore it seems that a permission granting the hostgroup to update the
>>service's "userCertificate" attribute sounds more flexible. But both options
>>have the downside of granting any host from the hostgroup to request any other
>>as the alternative subject name.
>>Regarding the service principal aliases, we haven't found any way to
>>dynamically update the list as the service hostgroup changes. We could either
>>grant the service hostgroup the permission to update the "krbPrincipalName"
>>service attribute, but it sounds like an excessive permission. We could also
>>implement a background service continuously updating principal alias list of
>>services according to their associated hostgroups.
>>So I would summarise my questions this way:
>>- Are assumptions used in this message true?
>Yes. Quite good summary, thanks for that.
>>- Is granting write permissions on "userCertificate" service attribute the best
>> alternative to "managedBy" for our use case?
>With FreeIPA 4.8.4+ we have support for member managers which define who
>can write to the member attribute of the group. See
>more details. Since this applies to any group, you can have a service
>administrators group to manage a hostgroup membership and to define a
>group that has write permissions to userCertificate through the normal
The "member manager" feature looks convenient indeed to avoid configuring an
extra role and permission for the service administrators group. That's
especially something less to cleanup in case the hostgroup is deleted.
I would have 2 extra questions about the "managedBy" attribute:
- What is the exact list of the permissions it is granting (in addition to
write permission on "userCertificate" service attribute and service key
- Would it make sense to extend its scope to hostgroups?
>>- What is the best way to keep a service principal alias list up-to-date with a
>To add a KrbPrincipalName alias to a specific service principal on a hostgroup
>change, it is probably would be easier to extend automember feature (see
>details in 'ipa help automember'). Right now it is hard-coded to use two
>types: hostgroup and group even though automember plugin in 389-ds
>allows to define an attribute that would be used for grouping feature
>and define what entry's attribute to use to populate the value.
>The problem is that it only takes a value as it is from the entry, there
>is no way to transform it to some other value. If you'd look into
>install/updates/40-automember.update file, you'll see that hostgroup
>poluation is taking a 'dn' value of an entry and asks to add that as a
>'member' of a hostgroup:
>default: objectclass: autoMemberDefinition
>default: cn: Hostgroup
>default: autoMemberScope: cn=computers,cn=accounts,$SUFFIX
>default: autoMemberFilter: objectclass=ipaHost
>default: autoMemberGroupingAttr: member:dn
>So I would imagine that one could do something like that for
>krbPrincipalName:some-attribute. And that 'some-attribute' needs to be
>populated in the (host) entry itself to be used by the automember
>plugin. This is not implemented right now in the 389-ds automember
>To dive deeper into a rabbit hole, we can generate krbPrincipalName in
>the service entries with the help of CoS plugin. This is a bit more
>weird plugin and you need to read a lot of details about it in RHDS
>documentation, but you can see how I did desktop profile rules pull into
>a host entry with https://github.com/abbra/freeipa-desktop-profile.
>defines CoS configuration that pulls ipaDeskData attribute into the host
So relying on the automember plugin we could import the principal alias from an
attribute of the member host. Here also, I guess the main advantage is there
would be no need to cleanup the service principal alias list whenever a host is
removed from the hostgroup.
It's a shame we cannot generate the service principal alias itself, but I
suppose it would require some sort of string composition plugin:
I had a look at RHDS documentation about CoS, it looks like a kind of
template engine. I am not sure to understand if it can be used to concatenate
multiple values. Is it the case?
>>Since it is my first message on this mailing list, I would like to pay tribute
>>to the development team of FreeIPA and its community. Even if there is still
>>work to do, FreeIPA is a quite impressive piece of work given the complexity of
>>the environment it is trying to integrate into, and the variety of use cases it
>>has to support.
>/ Alexander Bokovoy
>Sr. Principal Software Engineer
>Security / Identity Management Engineering
>Red Hat Limited, Finland
In the company I am working for DNS is managed by a separate department.
Delegating the linux.mydomain.at zone is not an option. Entering DNS
entries (for IPA servers) is done by clicking around in a web interface.
Entries have to be entered manually one by one.
An alternative would be to use nsupdate for the linux.mydomain.at zone
(and subzones). Does IPA provide a way for using nsupdate in combination
with all the required DNS entries upon a IPA server/replica installation?
I've managed to successfully migrate my ipa server #1 (including CA
renewal master) to RHEL8. After a few checks I found out that the trust
controller role was missing on the new system. So I ran
ipa-adtrust-install. However, the command "id myuser(a)ad.domain" did not
return any results. ipactl status revealed that smbd and winbind were
not running. ipactl restart did not help.
Any ideas on how to get the trust controller role working again on the
I see this subject might have been poked around many times, a couple
times at least for sure. But, I thought I'll poke again and hopefully
get some latest comments & thoughts on - how to make IPA's Samba allow
password authentication to Win clients from outside of IPA/AD domains?
Would there, by now, possibly be a semi-official (by IPA team) way of
getting there, since the subject first came up a longer while ago?
many thanks, L.