Is it possible to allow hosts in specific subnets to connect to a FreeIPA-connected server over NFS anonymously?
e.g. I'm wondering if I could setup a HBAC rule by doing something like the following:
ipa hbacsvc-add nfs-mount
Then attach that to the NFS server
And then allow "anyone" to connect over NFS to that server
Bonus points if there's a way to restrict the source NFS connection by IP address or subnet
Is this possible?
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"
- 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?
- Is granting write permissions on "userCertificate" service attribute the best
alternative to "managedBy" for our use case?
- What is the best way to keep a service principal alias list up-to-date with a
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.
I followed the guide at
to migrate my server (including CA renewal master).
When I try to uninstall tho old server according to
I get the following error message:
ipa server-del idm1.linux.mydomain.at
Removing ipa1.linux.mydomain.at from replication topology, please wait...
ipa: ERROR: Server removal aborted:
Removal of 'ipa1.linux.mydomain.at' leads to disconnected topology in
Topology does not allow server idm1.linux.mydomain.at to replicate with
Topology does not allow server ipa2.linux.mydomain.at to replicate with
Topology does not allow server ipa5.linux.mydomain.at to replicate with
Topology does not allow server ipa6.linux.mydomain.at to replicate with
How do I get rid of the remaining replication agreements?
I should do a "ipa-csreplica-manage list" on the new server after having
run "ipa-replica-install" The verbose output in the RedHat-Document has
a different output of "ipa-csreplica-manage" than mine. The document
says "Incremental update succeeded" whereas mine reports "No replication
sessions started since server startup".
Is this a problem or should replication not have already taken place at
this migration step?
We have 3 IPA servers which we are in the process of updating from RHEL
7.7 to RHEL 7.8.
Servers X, Z are at: ipa-server-4.6.6-11.el7.x86_64 (RHEL 7.8)
Server W is at: ipa-server-4.6.5-11.el7_7.3.x86_64 (RHEL 7.7)
Server X was updated some time ago, and server Z was updated last Thursday.
I was doing some checks of the log files before our planned update of
server W to RHEL 7.8 tomorrow and found the following in
[26/Apr/2020:22:00:21.704887592 +0100] - INFO - dblayer_copy_directory -
Backing up file 119
[26/Apr/2020:22:00:23.627421118 +0100] - ERR - NSMMReplicationPlugin -
changelog program - cl5DBData2Entry - Invalid data version
[26/Apr/2020:22:00:24.760704543 +0100] - INFO - dblayer_copyfile -
[26/Apr/2020:22:00:24.776815976 +0100] - ERR - NSMMReplicationPlugin -
changelog program - cl5DBData2Entry - Invalid data version
The errors were generated during our cronjob that runs this each night:
/sbin/ipa-backup --data --online
The errors don't seem to have been present the last two nights.
Would I be right to assume that this is just some transient
inconsistency caused by doing the online backup or should I be more
worried even though the error hasn't occurred since?
Thanks for any insights on this.
I want to ask if it's possible setup and if so then how,
IPA's DNSes forward directly to each other (let be only two
or however many you might have) while those IPAs "fqdn" are
"disconnected" - and all this without disabling DNSSEC? In
most basic example: private.dom <=> domain.priv
many thanks, L.
I did something pretty vanilla:
$ ipa-adtrust-install --unattended --admin-password=xxx
Process showed first some warning about "unattended" but then this:
[1/24]: validate server hostname
[2/24]: stopping smbd
[3/24]: creating samba domain object
[4/24]: retrieve local idmap range
[5/24]: creating samba config registry
[6/24]: writing samba config file
[7/24]: adding cifs Kerberos principal
[8/24]: adding cifs and host Kerberos principals to the adtrust agents
[9/24]: check for cifs services defined on other replicas
[10/24]: adding cifs principal to S4U2Proxy targets
[11/24]: adding admin(group) SIDs
[12/24]: adding RID bases
[13/24]: updating Kerberos config
'dns_lookup_kdc' already set to 'true', nothing to do.
[14/24]: activating CLDAP plugin
[15/24]: activating sidgen task
[16/24]: map BUILTIN\Guests to nobody group
[17/24]: configuring smbd to start on boot
[18/24]: adding special DNS service records
[19/24]: restarting Directory Server to take MS PAC and LDAP plugins
changes into account
[20/24]: adding fallback group
[21/24]: adding Default Trust View
[22/24]: setting SELinux booleans
[23/24]: starting CIFS services
ipaserver.install.adtrustinstance: CRITICAL CIFS services failed to start
[24/24]: restarting smbd
Done configuring CIFS.
Now, Samba would not start and I wonder what that might have to do with
tarting Samba SMB Daemon...
[2020/02/14 11:21:34.801358, 0]
No builtin nor plugin backend for ipasam found
smb.service: Main process exited, code=exited, status=1/FAILURE
smb.service: Failed with result 'exit-code'.
Failed to start Samba SMB Daemon.
Or is is it unrelated? Hot to troubleshoot & fix it?
I'm on Centos 8 with ipa-server-4.8.0-13.module_el8.1.0+265+e1e65be4.x86_64
many thanks, L.
I'd like to do a test run of a script that I use to sync our HR data with
our freeipa infrastructure. Is it possible to pause replication, or
essentially fence a server off, so that if I run the updated script against
it, I can limit the changes to that target server until I've checked the
changes look sound?
Thanks as always,