We currently do rsync backups of our server. On an MIT server, you’d want to omit the stash file. But IPA doesn’t use that. Is there anything like that that should be omitted? I’m not sure just how freeipa bootstraps trust when it starts up.
I have one IPA server dirsrv001 and newone dirsrv002
dirsrv001 is old server from where I want to unroll my VPS’s and join to
new server. I do some testing with Ubuntu VPS’s and that works perfect.
I have problem with one Centos 7 server.
I join client to dirsrv002 without problems but when I want to login I
login over ssh but I can’t do sudo. Ask me for pass and than three times
and that is.
Sudo permission on IPA server is configured as well because works on other.
If I run on that Centos client command:
and when I enter pass everything is ok.
If I check syslog, I get this error:
[sssd[krb5_child]]: Key version is not available
I found that is problem with /etc/krb5.keytab file. But I tried to unroll
client, move that file and join again, problem was same.
Please, does someone have some idea?
I have client machines bound to my FreeIPA domain correctly as best I can
tell. I have noticed however that the "finger" command appears to not be
matching on user's names anymore like it does with my older NIS clients.
Finger appears to only work when passing it the actual username of a user,
not their first or last names.
/etc/nsswitch.conf is configured properly for user matching on the client.
What am I missing?
passwd: files sss
shadow: files sss
group: files sss
#initgroups: files sss
#hosts: db files nisplus nis dns
hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname
# Example - obey only what nisplus tells us...
#services: nisplus [NOTFOUND=return] files
#networks: nisplus [NOTFOUND=return] files
#protocols: nisplus [NOTFOUND=return] files
#rpc: nisplus [NOTFOUND=return] files
#ethers: nisplus [NOTFOUND=return] files
#netmasks: nisplus [NOTFOUND=return] files
bootparams: nisplus [NOTFOUND=return] files
services: files sss
netgroup: nisplus sss
automount: files nisplus sss
aliases: files nisplus
sudoers: files sss
I've run into an issue with RetroCL (I think) on our IPA server. This is the sole master, there is no replication:
# ipa-replica-manage list
The problem appeared during an attempted group rename, but every subsequent attempt to change results in the same error:
[27/Jan/2020:11:29:49.590558266 +0000] - ERR - managed-entries-plugin - mep_rename_managed_entry - Unable to rename managed entry "cn=matstudio2016,cn=groups,cn=accounts,<domain>" to "cn=matstudio,cn=groups,cn=accounts,<domain>" (Already exists).
[27/Jan/2020:11:29:49.897693314 +0000] - ERR - ldbm_back_modrdn - SLAPI_PLUGIN_BE_TXN_POST_MODRDN_FN plugin returned error but did not set SLAPI_RESULT_CODE
[27/Jan/2020:13:23:16.986652546 +0000] - ERR - DSRetroclPlugin - write_replog_db - An error occured while adding change number 264303, dn = changenumber=264303,cn=changelog: Already exists.
[27/Jan/2020:13:23:16.989427768 +0000] - ERR - DSRetroclPlugin - retrocl_postob - Operation failure 
[27/Jan/2020:13:23:16.993607315 +0000] - ERR - managed-entries-plugin - mep_add_managed_entry - Unable to add managed entry "cn=materialsstudio,cn=groups,cn=accounts,<domain>" for origin entry "uid=materialsstudio,cn=users,cn=accounts,<domain>" (Already exists).
[27/Jan/2020:13:23:16.998637893 +0000] - ERR - DSRetroclPlugin - write_replog_db - An error occured while adding change number 264303, dn = changenumber=264303,cn=changelog: Already exists.
[27/Jan/2020:13:23:17.001620504 +0000] - ERR - DSRetroclPlugin - retrocl_postob - Operation failure 
[27/Jan/2020:13:23:17.005510536 +0000] - ERR - managed-entries-plugin - mep_add_managed_entry - Unable to add managed entry "cn=materialsstudio,cn=groups,cn=accounts,<domain>" for origin entry "uid=materialsstudio,cn=users,cn=accounts,<domain>" (Already exists).
[27/Jan/2020:13:23:55.016578895 +0000] - ERR - DSRetroclPlugin - write_replog_db - An error occured while adding change number 264302, dn = changenumber=264302,cn=changelog: Already exists.
[27/Jan/2020:13:23:55.020029522 +0000] - ERR - DSRetroclPlugin - retrocl_postob - Operation failure 
I note that the changenumber decreased by 1 as well. Unfortunately the access log has rotated several times since the change, so I can't extract anything from there. My colleague did have a record of the commands that were run:
# ipa user-mod --rename=matstudio matstudio2016
# ipa user-mod --rename=matstudio2016 matstudio
# ipa user-mod --rename=matstudio matstudio2016
There is no group-mod command, so I assume that the group rename attempt was ipa trying to rename the private group matstudio2016 to matstudio, which already existed:
# ipa group-show matstudio2016
Group name: matstudio2016
Description: User private group for matstudio2016
# ipa group-show matstudio
Group name: matstudio
Member users: blanked
I've tried to delete the groups, both via ipa and ldapmodify (tried to remove the mepManagedEntry objectclass and mepManagedBy attribute), but always encounter the changelog error. Alas there is no backup prior to this change from which to restore, so I am trying to fix things online. Thankfully authorisation and authentication is still working for now, but we can't add users, modify groups, etc.
Incidentally, ipa user-show --all --raw returns nothing for either uid, but ldapsearch does. The old user (matstudio2016) and group (matstudio) were migrated at least once from the ipa database of older clusters, possibly twice. I've pulled out the pertinent entries from each record:
# ldapsearch -Y GSSAPI uid=matstudio2016
# matstudio, users, accounts, <domain>
displayName: MatStudioAccount MatStudioAccount
cn: MatStudioAccount MatStudioAccount
# ldapsearch -Y GSSAPI uid=matstudio
# matstudio, users, compat, <domain>
gecos: MatStudioAccount MatStudioAccount
cn: MatStudioAccount MatStudioAccount
I'm scratching my head here; any suggestions will be most gratefully received!
I'm in the process of testing a CentOS 6 to CentOS 7 migration of our IPA
servers (ipa-server-3.0.0 to ipa-server-4.6.5). I have successfully added a
4.6.5 IPA server to my 3.0.0 replicas in my testing environment, and
replication is working fine. I have a few aci differences that I'm still
weeding out, but no show stoppers.
When we initially installed freeipa, we were planning on using the CA
capabilities, but have never actually used it after the initial install. My
question is, if we have never used it, can I simply just not worry about
creating a CA replica, and then renew my certificates using an external CA
after the migration is complete?
Thanks in advance
Systems Engineering Lead | Salesforce
I have ran into a bit of a surprise (for me anyway). After adding a second
NIC to my FreeIPA server in order to provide IPA services for the same
realm to a second network, I am unable to join clients to it and am getting
the following error:
2020-01-29T19:15:55Z DEBUG stderr=
2020-01-29T19:15:55Z DEBUG trying to retrieve CA cert via LDAP from
2020-01-29T19:15:55Z DEBUG get_ca_certs_from_ldap() error: Insufficient
access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure.
Minor code may provide more information (Server krbtgt/CLUSTER@<original
domain> not found in Kerberos database)
2020-01-29T19:15:55Z DEBUG Insufficient access: SASL(-1): generic failure:
GSSAPI Error: Unspecified GSS failure. Minor code may provide more
information (Server krbtgt/CLUSTER@<original domain> not found in Kerberos
After doing quite a bit of Googling it appears that multi-homed IPA servers
are not currently supported?
I decided to try something and added the FQDN for the FreeIPA server to the
client's /etc/hosts file, and pointed the FQDN to the secondary IP of the
server, and that appears to have worked properly. The client install
completed without any error via the second network.
Is this the bandaid approach that is currently the best method of doing
this? Is there a better way?
Thanks for the insight!
I'm running "ipa-client-install --force-join --no-nisdomain -U", and it
auto discovers my freeipa servers, but places both _srv_ and the first
server under the "ipa_server" line. This results in the first server being
listed twice when running "sssctl domain-status".
Is this expected behavior? Is this behavior that I actually want?
Just trying to understand better. Thank you for any insight!
I'm building a cluster with 8 servers divided into 2 sites of 4 servers.
I understand from the documentation that only the first server should be installed as a server, all others can be installed as replicas from the first one.
Am I understanding this right?
Is there some difference between a server and a replica from an operational point of view?
we just upgraded servers to centos 8.1, by dealing them and recreating them.
On a few systems when I try to use the IPA command I get
ipa: ERROR: No valid Negotiate header in server response
This doesn’t happen on all hosts. The IPA command works fine on the server itself. Since it’s only on some hosts the obvious suspicion is that something is cached from the old server. Any idea what’s going on?