Broken ipa replica
by Giulio Casella
Hi everyone,
I'm stuck with a broken replica. I had a setup with two ipa server in
replica (ipa-server-4.6.4 on CentOS 7.6), let's say "idc01" and "idc02".
Due to heavy load idc01 crashed many times, and was not working anymore.
So I tried to redo the replica again. At first I tried to
"ipa-replica-manage re-initialize", with no success.
Now I'm trying to redo from scratch the replica setup: on idc02 I
removed the segments (ipa topologysegment-del, for both ca and domain
suffix), on idc01 I removed everything (ipa-server-install --uninstall),
then I joined domain (ipa-client-install), and everything is working so far.
When doing "ipa-replica-install" on idc01 I get:
[...]
[28/41]: setting up initial replication
Starting replication, please wait until this has completed.
Update in progress, 22 seconds elapsed
[ldap://idc02.my.dom.ain:389] reports: Update failed! Status: [Error
(-11) connection error: Unknown connection error (-11) - Total update
aborted]
And on idc02 (the working server), in
/var/log/dirsrv/slapd-MY-DOM-AIN/errors I find lines stating:
[20/Mar/2019:09:28:06.545187923 +0100] - INFO - NSMMReplicationPlugin -
repl5_tot_run - Beginning total update of replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)".
[20/Mar/2019:09:28:26.528046160 +0100] - ERR - NSMMReplicationPlugin -
perform_operation - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Failed
to send extended operation: LDAP error -1 (Can't contact LDAP server)
[20/Mar/2019:09:28:26.530763939 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_log_operation_failure - agmt="cn=meToidc01.my.dom.ain"
(idc01:389): Received error -1 (Can't contact LDAP server): for total
update operation
[20/Mar/2019:09:28:26.532678072 +0100] - ERR - NSMMReplicationPlugin -
release_replica - agmt="cn=meToidc01.my.dom.ain" (idc01:389): Unable to
send endReplication extended operation (Can't contact LDAP server)
[20/Mar/2019:09:28:26.534307539 +0100] - ERR - NSMMReplicationPlugin -
repl5_tot_run - Total update failed for replica
"agmt="cn=meToidc01.my.dom.ain" (idc01:389)", error (-11)
[20/Mar/2019:09:28:26.561763168 +0100] - INFO - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meToidc01.my.dom.ain" (idc01:389):
Replication bind with GSSAPI auth resumed
[20/Mar/2019:09:28:26.582389258 +0100] - WARN - NSMMReplicationPlugin -
repl5_inc_run - agmt="cn=meToidc01.my.dom.ain" (idc01:389): The remote
replica has a different database generation ID than the local database.
You may have to reinitialize the remote replica, or the local replica.
It seems that idc02 remembers something about the old replica.
Any hint?
Thank you in advance,
Giulio
1 month, 2 weeks
IPA CA allow CSR SAN names in external domains
by Steve Dainard
Hello
I have a RHEL7 IPA server installed as a subordinate CA. I'd like to be
able to add SAN's for a different dns domain than exists in the IPA realm.
The dns for 'otherdomain.com' is handled by active directory which my IPA
server has a cross-forest trust with.
ie:
host: client1.ipadomain.com
certificate: CN = client1.ipadomain.com, SAN = client1.ipadomain.com,
servicename.otherdomain.com
When I try to submit this CSR with 'ipa-getcert request' the IPA server
denies with: "The service principal for subject alt name
servicename.otherdomain.com in certificate request does not exist"
It seems that the default CAACL enforces a profile named
'caIPAserviceCert', but I'm having some trouble determining what can be
modified (or cloned and changed in a new profile) that would allow the CA
to sign a CSR that contains *.ipadomain.com and *.otherdomain.com in the
SAN.
This is the only section in the profile that contains SAN:
policyset.serverCertSet.12.constraint.class_id=noConstraintImpl
policyset.serverCertSet.12.constraint.name=No Constraint
policyset.serverCertSet.12.default.class_id=commonNameToSANDefaultImpl
policyset.serverCertSet.12.default.name=Copy Common Name to Subject
Alternative Name
Thanks,
Steve
3 months, 2 weeks
ipa-dnskeysyncd DEBUG messages
by Kees Bakker
Hi,
On the two CentOS 8 Stream masters (upgraded a few days ago) we now get quite
a few DEBUG messages. I haven't seen these before.
There is also a WARN - content-sync-plugin.
Is this something to be worried about?
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=example.com.,cn=dns,dc=example,dc=com 1e89eb86-e201-11e8-8820-f96efc0c60a4
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206227
Jul 13 14:06:56 linge.example.com named-pkcs11[283005]: zone example.com/IN: sending notifies (serial 1626178016)
Jul 13 14:06:56 linge.example.com named-pkcs11[283005]: client @0x7f54e416c880 172.16.16.31#45677: received notify for zone 'example.com'
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=example.com.,cn=dns,dc=example,dc=com 1e89eb86-e201-11e8-8820-f96efc0c60a4
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206230
Jul 13 14:06:56 linge.example.com ns-slapd[282944]: [13/Jul/2021:14:06:56.745067868 +0200] - WARN - content-sync-plugin - sync_update_persist_betxn_pre_op - DB retried operation targets "changenumber=206231,cn=changelog" (op=0x7fd372024000 idx_pl=1) => op not changed in PL
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=example.com.,cn=dns,dc=example,dc=com 1e89eb86-e201-11e8-8820-f96efc0c60a4
Jul 13 14:06:56 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206232
Jul 13 14:06:56 linge.example.com named-pkcs11[283005]: client @0x7f54e416c880 172.16.16.75#48866: received notify for zone '30.16.172.in-addr.arpa'
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=example.com.,cn=dns,dc=example,dc=com 1e89eb86-e201-11e8-8820-f96efc0c60a4
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206235
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=30.16.172.in-addr.arpa.,cn=dns,dc=example,dc=com d79d0401-e29b-11e8-8820-f96efc0c60a4
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206236
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG Detected modify of entry: idnsname=30.16.172.in-addr.arpa.,cn=dns,dc=example,dc=com d79d0401-e29b-11e8-8820-f96efc0c60a4
Jul 13 14:06:57 linge.example.com ipa-dnskeysyncd[283246]: ipaserver.dnssec.syncrepl: DEBUG New cookie is: linge.example.com:389#krbprincipalname=ipa-dnskeysyncd/linge.example.com@example.com,cn=services,cn=accounts,dc=example,dc=com:cn=dns,dc=example,dc=com:(|(objectClass=idnsZone)(objectClass=idnsSecKey)(objectClass=ipk11PublicKey))#206237
--
Kees
3 months, 4 weeks
Need help with confusing query results
by Edward Valley
Hi there.
I'm using latest FreeIPA available on Rocky Linux 8.5
VERSION: 4.9.6, API_VERSION: 2.245
When I run the following LDAP query:
ldapsearch -H "ldap://idm-host:389" -x -s sub \
-D "cn=Directory Manager" -w "dm-password" \
-b "cn=users,cn=accounts,dc=..." \
'(objectClass=inetOrgPerson)' \
uid entryUUID
I get the following result: (entryUUID is present)
# user1, users, accounts, ...
dn: uid=user1,cn=users,cn=accounts,dc=...
uid: user1
entryUUID: aaaaaaaa-bbbb-cccc-dddd-eeeeeeeeeeee
# user2, users, accounts, ...
dn: uid=user2,cn=users,cn=accounts,dc=...
uid: user2
entryUUID: aaaaaaaa-bbbb-cccc-dddd-ffffffffffff
But, when I use this query:
ldapsearch -H "ldap://idm-host:389" -x -s sub \
-D "cn=Directory Manager" -w "dm-password" \
-b "cn=users,cn=accounts,dc=..." \
'(&(objectClass=inetOrgPerson)(uid=user1))' \
uid entryUUID
The result is this one: (No entryUUID attribute)
# user1, users, accounts, ...
dn: uid=user1,cn=users,cn=accounts,dc=...
uid: user1
Can somebody please guide me on what's happening here?
If you need more info just tell me.
Thank you very much.
4 months, 2 weeks
"getent group -s sss" behaves differently on centos 7 vs centos 8. Why?
by Russell Jones
Hi all,
I am very confused on why I am not able to enumerate the group members on a
centos 8 machine with the above command, but I can on a centos 7 machine.
[root@centos8-1 log]# getent group -s sss video
video:x:39:
[root@centos7-n11 log]# getent group -s sss video
video:*:39:<lots of users>
Both are configured with the same sssd.conf file, and both have "enumerate
= True" in the domain section.
In addition, if I just do "getent group" without the "-s sss" the group and
all of its members show up properly on both machines.
Super confused here. Thanks in advance for the help!
4 months, 2 weeks
'transportCert cert-pki-kra' mix up
by GH
I've got two ancient (3.1?) IPA servers that have been upgraded over time. Last January things got really goofy with certificates and I got it all sorted. However, now I've got an old issue creeping back in. The 'transportCert cert-pki-kra' is mismatched between the CS.cfg and the tracked certificate. This is a multi-master setup. The signing master seems to be the one that's off. It's tracking the updated original 'transportCert cert-pki-kra' certificate. However, the "secondary" master is tracking a newly generated 'transportCert cert-pki-kra', which is also what both CS.cfg's are referencing. Neither one of the certificates is expired. Everything else seems to be in working order. Here is ipa-healthcheck's only relevant error:
"source": "ipahealthcheck.dogtag.ca",
"kw": {
"msg": "Certificate 'transportCert cert-pki-kra' does not match the value of ca.connector.KRA.transportCert in /var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"configfile": "/var/lib/pki/pki-tomcat/conf/ca/CS.cfg",
"directive": "ca.connector.KRA.transportCert",
"key": "transportCert cert-pki-kra"
},
So, what should I copy where to get this sorted? It seems like the updated original 'transportCert cert-pki-kra' should be copied into the CS.cfg and then manually scp the NSS files from "primary" to "secondary"? What commands would you use to do this? I've got a lot of commands noted and am beginning to get confused as to which ones should be used to get this sorted. Thanks.
4 months, 3 weeks
IPA WebGUI login fails with "Login failed due to an unknown reason"
by code bugs
Hello,
-IPA WebGUI login fails with "Login failed due to an unknown reason"
-After upgrading IPA, can no longer log into the WebGUI
Version/Release/Distribution
$ cat /etc/centos-release
CentOS Linux release 8.5.2111
$ rpm -q freeipa-server freeipa-client ipa-server ipa-client 389-ds-base
pki-ca krb5-server
package freeipa-server is not installed
package freeipa-client is not installed
ipa-server-4.9.6-10.module_el8.5.0+1055+c415bbe9.x86_64
ipa-client-4.9.6-10.module_el8.5.0+1055+c415bbe9.x86_64
389-ds-base-1.4.3.23-12.module_el8.5.0+1056+b3c5a4b9.x86_64
pki-ca-10.11.2-2.module_el8.5.0+945+a81e57da.noarch
krb5-server-1.18.2-14.el8.x86_64
Additional info:
tail /var/log/httpd/error_log
[wsgi:error] [pid 8833:tid 139812622513920] [remote 10.2.3.80:51404] ipa:
INFO: 401 Unauthorized: Major (851968): Unspecified GSS failure. Minor code
may provide more information, Minor (2598844948): TGT has been revoked
further,
1. default "admin" user can IPA WebGUIlogin
2. other users cannot login IPA WebGUIlogin, but can login using cli
(kinit)
3. when i create a new user, the new user can login IPA WebGUI.
4 months, 3 weeks
freeipa with sudo and 2FA (OTP)
by John Ratliff
I'm trying to setup freeipa with OTP. I created a TOTP under my user in
freeipa and updated my user to use 2FA (password + OTP).
When I try to do sudo, it only asks for my password and it fails every
time (presumably because it isn't getting the OTP first).
I didn't see anything useful in the sss_sudo logs, even after adding
debug_level = 6 in the config.
What can I do to further troubleshoot this?
Thanks.
4 months, 3 weeks
missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"
by Brian J. Murrell
I'm trying to add a replica but it's failing on step "[23/38]: creating DS keytab" with:
[error] CalledProcessError: CalledProcessError(Command ['/usr/sbin/ipa-getkeytab', '-k', '/etc/dirsrv/ds.keytab', '-p', 'ldap/server.example.com(a)EXAMPLE.COM', '-H', 'ldaps://server-staging.example.com'] returned non-zero exit status 9: 'Failed to parse result: Insufficient access rights\n\nRetrying with pre-4.0 keytab retrieval method…\nFailed to parse result: Insufficient access rights\n\nFailed to get keytab!\nFailed to get keytab\n')
This is trying to add back an ipa server that was previously removed (for O/S major version upgrade per the supported upgrade/migration process). Maybe the previous removal was not complete?
After running the recommended --uninstall and then examining the principals in the master server, I see an ldap/server.example.com(a)EXAMPLE.COM still remaining. Surely that should not be there, correct?
So I tried to remove it, but that gave yet another error:
missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"
and logged the error:
ERR - oc_check_required - Entry "krbprincipalname=ldap/server.example.com(a)EXAMPLE.COM,cn=services,cn=accounts,dc=interlinx,dc=bc,dc=ca" missing attribute "krbPrincipalName" required by object class "ipaKrbPrincipal"
in the journal.
So how to proceed now?
4 months, 3 weeks
1 server not syncing with the others
by Russell Jones
Hi all,
I have a setup of 4 FreeIPA servers, version 4.6.5, all on CentOS 7.
I've discovered that #4 is not syncing a new "video" group I created, while
the other 3 all have the group.
When looking at dirsrv error log, I am seeing the following after running
an ipactl stop / ipactl start:
[27/Jan/2022:11:35:55.158724429 -0600] - ERR - set_krb5_creds - Could not
get initial credentials for principal
[ldap/freeipa4.cluster(a)US.EP.CORP.LOCAL] in keytab
[FILE:/etc/dirsrv/ds.keytab]: -1765328228 (Cannot contact any KDC for
requested realm)
[27/Jan/2022:11:35:55.169790450 -0600] - INFO - slapd_daemon - slapd
started. Listening on All Interfaces port 389 for LDAP requests
[27/Jan/2022:11:35:55.173079823 -0600] - INFO - slapd_daemon - Listening on
All Interfaces port 636 for LDAPS requests
[27/Jan/2022:11:35:55.175096801 -0600] - INFO - slapd_daemon - Listening on
/var/run/slapd-US-EP-CORP-LOCAL.socket for LDAPI requests
[27/Jan/2022:11:35:55.235218894 -0600] - ERR - schema-compat-plugin -
schema-compat-plugin tree scan will start in about 5 seconds!
[27/Jan/2022:11:35:58.368835716 -0600] - ERR - NSMMReplicationPlugin -
bind_and_check_pwp - agmt="cn=meTofreeipa.us.ep.corp.local" (freeipa:389) -
Replication bind with GSSAPI auth failed: LDAP error 49 (Invalid
credentials) ()
I am unsure what the issue is or how to resolve this. Could I get some
assistance with being pointed in the right direction?
Thank you!
4 months, 3 weeks
