ipa-replica-install failing
by Mitchell Smith
Hi list,
I wanted to repost this issue with a more appropriate subject line, in
case anyone has come across this issue before and has a work around.
To provide some context, I have two FreeIPA instances running FreeIPA
4.3.1 on Ubuntu 16.04 LTS.
I want to migrate to FreeIPA 4.5.4 running on CentOS 7.
I have a way to migrate by dumping all the users out with ldapsearch
and adding them to the new instance with ldapadd but it is a bit messy
and will result in all users having to reset their password, as it
won't let me add in already encrypted passwords.
My initial thought was to add the new instance as a replica and then
eventually retire the old one.
I ran in to some problems with the ‘ipa-replica-install’ command though.
I was able to join as a client no problem, but when I went to run
‘ipa-replica-install’ it failed while configuring the directory server
component.
[25/42]: restarting directory server
[26/42]: creating DS keytab
[27/42]: ignore time skew for initial replication
[28/42]: setting up initial replication
[error] DatabaseError: Server is unwilling to perform: modification
of attribute nsds5replicareleasetimeout is not allowed in replica
entry
Your system may be partly configured.
Run /usr/sbin/ipa-server-install --uninstall to clean up.
I thought this might have something to do with differences between
4.3.1 and 4.5.4 but I wasn’t entirely sure.
If there is a work around for this issue, it would be a significantly
easier transition to the new FreeIPA instance.
Cheers,
Mitch
3 weeks, 6 days
IPA healthcheck for older versions
by Rob Crittenden
Over the summer we announced the freeipa-healthcheck project which is
designed to look at an IdM cluster and look for common problems so you
can have some level of assurance that the system is running as it should.
It was built against the IPA 4.8.x branch and originally released only
for Fedora 29+. It is also included in the newly released RHEL 8.1.0.
My curious nature led me to see if it would also work in in the IPA
4.6.x branch. It was a bit of a challenge backing down to Python 2 but I
was able to get something working. I tested primarily on Fedora 27 but
it should also work in RHEL/CentOS 7 (I smoke tested 7.8).
I made an EPEL 7 build in COPR,
https://copr.fedorainfracloud.org/coprs/rcritten/ipa-healthcheck/
Enable the repo and do: yum install freeipa-healthcheck
Then run: ipa-healthcheck --failures-only
Ideally there will be no output but an empty list []. Otherwise the
output is JSON and hopefully has enough information to point you in the
right direction. Feel free to ask if need help.
False positives are always a possibility and many of the checks run
independently so it's possible to get multiple issues from a single root
problem. It's hard to predict all possible installations so some
fine-tuning may be required.
I'd recommend running it every now and then at least, like prior to
updating IPA packages, creating a new master, etc, if not daily. It
will, for example, warn of impending cert expiration.
The more feedback I get on it the better and more useful I can make it.
This is my own personal backport and is not officially supported by
anyone but me. It's preferred to report issues on this mailing list.
I'll see them and others may be able to chime in as well.
rob
3 weeks, 6 days
Replication issue with CSN generator
by Morgan Marodin
Hi.
Into my environment I have two IPA server, replicating each other.
They are both 7.6 OS systems, ipa-server RPM version is
4.6.4-10.0.1.el7_6.2.x86_64.
The first server installed was srv01 (many years ago), then I installed the
replica into srv02 (like a year later the 1st node).
When I had a single server I did also a trust with my corporate Active
Directory.
VMs are running in 2 different hypervisor clusters.
Now the replication doesn't works. Into log files I have this error:
*[16/Apr/2020:12:25:36.856632697 +0200] - ERR - csngen_adjust_time -
Adjustment limit exceeded; value - 23221226, limit -
86400[16/Apr/2020:12:25:36.857909222 +0200] - ERR - NSMMReplicationPlugin -
repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com
<http://meTosrv01.ipa.mydomain.com>" (srv01:389): Fatal error - too much
time skew between replicas![16/Apr/2020:12:25:36.862233147 +0200] - ERR -
NSMMReplicationPlugin - repl5_inc_run - agmt="cn=meTosrv01.ipa.mydomain.com
<http://meTosrv01.ipa.mydomain.com>" (srv01:389): Incremental update failed
and requires administrator action*
I tried to force the replica, but the limit exceeded problem doesn't allow
the sync.
I know that the problem is that CSN generator has become grossly skewed.
Using the external script readNsState.py I found that there was as offset
time for about a month, so ... I waited for a month and then the issue
disappeared.
But now the offset is about 9 months ... I can't wait so much time :)
*[root@srv01 scripts]# ./readNsState.py
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldifnsState is
BAAAAAAAAACCN/xfAAAAAHbiBAAAAAAABCgAAAAAAAANdQAAAAAAAA==Little EndianFor
replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping
tree,cn=con fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN
generator state: Replica ID : 4 Sampled Time : 1610364802 Gen
as csn : 5ffc37822996500040000 Time as str : Mon Jan 11 12:33:22
2021 Local Offset : 320118 Remote Offset : 10244 Seq. num :
29965 System time : Tue Apr 21 15:03:45 2020 Diff in sec. :
-22890577 Day:sec diff : -265:5423nsState is
YAAAAAAAAAADLZheAAAAAAAAAAAAAAAAXSgAAAAAAAATAAAAAAAAAA==Little EndianFor
replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state:
Replica ID : 96 Sampled Time : 1587031299 Gen as csn :
5e982d03001900960000 Time as str : Thu Apr 16 12:01:39 2020 Local
Offset : 0 Remote Offset : 10333 Seq. num : 19 System time
: Tue Apr 21 15:03:45 2020 Diff in sec. : 442926 Day:sec diff :
5:10926[root@srv02 scripts]# ./readNsState.py
/etc/dirsrv/slapd-IPA-MYDOMAIN-COM/dse.ldifnsState is
AwAAAAAAAABU7p5eAAAAAAAAAAAAAAAAsVNiAQAAAAAAAAAAAAAAAA==Little EndianFor
replica cn=replica,cn=dc\3Dipa\2Cdc\3Dmydomain\2Cdc\3Dcom,cn=mapping
tree,cn=con fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN
generator state: Replica ID : 3 Sampled Time : 1587474004 Gen
as csn : 5e9eee54000000030000 Time as str : Tue Apr 21 15:00:04
2020 Local Offset : 0 Remote Offset : 23221169 Seq. num : 0
System time : Tue Apr 21 15:02:38 2020 Diff in sec. : 154
Day:sec diff : 0:154nsState is
YQAAAAAAAAAuLZheAAAAAEUBAAAAAAAA7SYAAAAAAAASAAAAAAAAAA==Little EndianFor
replica cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
fmtstr=[H6x3QH6x] size=40 len of nsstate is 40 CSN generator state:
Replica ID : 97 Sampled Time : 1587031342 Gen as csn :
5e982d2e001800970000 Time as str : Thu Apr 16 12:02:22 2020 Local
Offset : 325 Remote Offset : 9965 Seq. num : 18 System time
: Tue Apr 21 15:02:38 2020 Diff in sec. : 442816 Day:sec diff :
5:10816*
As you can see in the 1st node the Time as str is Jan 11 of 2021.
With timedatectl command I see that both VMs use the same Time zone and the
clock is correct.
I found this old article to fix my issue:
*https://www.redhat.com/archives/freeipa-users/2014-February/msg00007.html
<https://www.redhat.com/archives/freeipa-users/2014-February/msg00007.html>*
But ... I had the same issue in the past, always in the 1st server. So, in
my mind I don't want to try to use that fix.
I have a new hypervisor cluster, so I would prefer to reinstall the 1st
server, using these steps:
1) check if all roles (also the CA) is installed in srv02
You can find here some data about the VMs:
*[root@srv01 ~]# ipa server-show srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com> Server name: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com> Managed suffixes: domain, ca Min domain
level: 0 Max domain level: 1 Enabled server roles: CA server, IPA master,
DNS server, NTP server, AD trust controller[root@srv02 ~]# ipa server-show
srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> Server name:
srv02.ipa.mydomain.com <http://srv02.ipa.mydomain.com> Managed suffixes:
domain, ca Min domain level: 0 Max domain level: 1 Enabled server roles:
CA server, IPA master, DNS server, NTP server[root@srv01 ~]# ipa
config-show Maximum username length: 32 Home directory base: /home
Default shell: /bin/bash Default users group: ipausers Default e-mail
domain: ipa.mydomain.com <http://ipa.mydomain.com> Search time limit: 2
Search size limit: 100 User search fields:
uid,givenname,sn,telephonenumber,ou,title Group search fields:
cn,description Enable migration mode: FALSE Certificate Subject base:
O=IPA.MYDOMAIN.COM <http://IPA.MYDOMAIN.COM> Password Expiration
Notification (days): 4 Password plugin features: AllowNThash SELinux user
map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types:
MS-PAC, nfs:NONE IPA masters: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA CA servers: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA NTP servers: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA CA renewal master:
srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>[root@srv02 ~]# ipa
config-show Maximum username length: 32 Home directory base: /home
Default shell: /bin/bash Default users group: ipausers Default e-mail
domain: ipa.mydomain.com <http://ipa.mydomain.com> Search time limit: 2
Search size limit: 100 User search fields:
uid,givenname,sn,telephonenumber,ou,title Group search fields:
cn,description Enable migration mode: FALSE Certificate Subject base:
O=IPA.MYDOMAIN.COM <http://IPA.MYDOMAIN.COM> Password Expiration
Notification (days): 4 Password plugin features: AllowNThash SELinux user
map order:
guest_u:s0$xguest_u:s0$user_u:s0$staff_u:s0-s0:c0.c1023$unconfined_u:s0-s0:c0.c1023
Default SELinux user: unconfined_u:s0-s0:c0.c1023 Default PAC types:
MS-PAC, nfs:NONE IPA masters: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA CA servers: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA NTP servers: srv01.ipa.mydomain.com
<http://srv01.ipa.mydomain.com>, srv02.ipa.mydomain.com
<http://srv02.ipa.mydomain.com> IPA CA renewal master:
srv01.ipa.mydomain.com <http://srv01.ipa.mydomain.com>[root@srv01 ~]#
ipactl statusDirectory Service: RUNNINGkrb5kdc Service: RUNNINGkadmin
Service: RUNNINGnamed Service: RUNNINGhttpd Service: RUNNINGipa-custodia
Service: RUNNINGntpd Service: RUNNINGpki-tomcatd Service: STOPPEDsmb
Service: RUNNINGwinbind Service: RUNNINGipa-otpd Service:
RUNNINGipa-dnskeysyncd Service: RUNNINGipa: INFO: The ipactl command was
successful[root@srv02 ~]# ipactl statusDirectory Service: RUNNINGkrb5kdc
Service: RUNNINGkadmin Service: RUNNINGnamed Service: RUNNINGhttpd Service:
RUNNINGipa-custodia Service: RUNNINGntpd Service: RUNNINGpki-tomcatd
Service: STOPPEDipa-otpd Service: RUNNINGipa-dnskeysyncd Service:
RUNNINGipa: INFO: The ipactl command was successful[root@srv01 ~]# certutil
-L -d /etc/pki/pki-tomcat/aliasCertificate Nickname
Trust Attributes
SSL,S/MIME,JAR/XPIServer-Cert cert-pki-ca
u,u,usubsystemCert cert-pki-ca
u,u,ucaSigningCert cert-pki-ca
CTu,Cu,CuocspSigningCert cert-pki-ca
u,u,uauditSigningCert cert-pki-ca
u,u,Pu[root@srv02 ~]# certutil -L -d /etc/pki/pki-tomcat/aliasCertificate
Nickname Trust Attributes
SSL,S/MIME,JAR/XPIServer-Cert cert-pki-ca
u,u,usubsystemCert cert-pki-ca
u,u,ucaSigningCert cert-pki-ca
CTu,u,uocspSigningCert cert-pki-ca
u,u,uauditSigningCert cert-pki-ca u,u,Pu*
It seems that AD trust controller role, IPA CA renewal master, smb and
windbind are only in the 1st server.
And also caSigningCert cert-pki-ca entry is different (CTu,Cu,Cu vs
CTu,u,u).
I can see only in the 1st server these DNS records:
*_kerberos._tcp.Default-First-Site-Name._sites.dc._msdcs SRV 0 100 88
srv01_kerberos._tcp.dc._msdcs SRV 0 100 88
srv01_kerberos._udp.Default-First-Site-Name._sites.dc._msdcs SRV 0 100 88
srv01_kerberos._udp.dc._msdcs SRV 0 100 88
srv01_ldap._tcp.Default-First-Site-Name._sites.dc._msdcs 0 100 389
srv01_ldap._tcp.dc._msdcs 0 100 389 srv01*
Srv01 is the first master, I know, but is the server VM that has clock
problems, in both situations.
So I want to keep srv02 and install a new one.
What do I have to do to let the 2nd VM be a single server?
Could I use these URLs?
*https://www.freeipa.org/page/Backup_and_Restore#One_Server_Loss_-_First_Master
<https://www.freeipa.org/page/Backup_and_Restore#One_Server_Loss_-_First_M...>https://www.freeipa.org/page/V4/Server_Roles#Upgrade
<https://www.freeipa.org/page/V4/Server_Roles#Upgrade>*
2) uninstall ipa-server from the 1st server (srv01) and then powering off
it, assuming that all data into the 2nd one are ok (srv02)
3) update freeipa and all other RPM packages into the VM srv02
4) install a new fresh VM, always with 7 release, and create a new replica
Could I use the same old hostname (srv01) and IP address for this new VM?
Or is better to use the same IP but a new name, like srv03?
Do you think this is the right way to solve my issue?
Or do you have any better idea?
Please let me know, thanks.
Bye, Morgan
1 month, 1 week
kinit -n asking for password on clients
by John Ratliff
When trying to do pkinit, if I do kinit -n on one of the IdM servers, it
works fine. If I try on a client machine, it asks me for the password
for WELLKNOWN/ANONYMOUS@REALM.
I have the pkinit_anchors setup for the realm. As I'm trying to do
anonymous pkinit, I think I don't need a client certificate.
On the server, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[13061] 1518402857.924212: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[13061] 1518402857.929673: Sending request (200 bytes) to IDM.EXAMPLE.COM
[13061] 1518402857.931830: Initiating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.932241: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402857.939162: Received answer (359 bytes) from stream
10.77.9.101:88
[13061] 1518402857.939180: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402857.939284: Response was from master KDC
[13061] 1518402857.939380: Received error from KDC:
-1765328359/Additional pre-authentication required
[13061] 1518402857.939474: Processing preauth types: 16, 15, 14, 136,
19, 147, 2, 133
[13061] 1518402857.939499: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402857.939509: Received cookie: MIT
[13061] 1518402857.939563: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402857.940352: PKINIT client computed kdc-req-body checksum
9/D98A0144E7E4ACC66B63EBCA98379AB9F055D143
[13061] 1518402857.940369: PKINIT client making DH request
[13061] 1518402858.935: Preauth module pkinit (16) (real) returned:
0/Success
[13061] 1518402858.956: Produced preauth for next request: 133, 16
[13061] 1518402858.994: Sending request (1408 bytes) to IDM.EXAMPLE.COM
[13061] 1518402858.1091: Initiating TCP connection to stream 10.77.9.101:88
[13061] 1518402858.1187: Sending TCP request to stream 10.77.9.101:88
[13061] 1518402858.43063: Received answer (2880 bytes) from stream
10.77.9.101:88
[13061] 1518402858.43088: Terminating TCP connection to stream
10.77.9.101:88
[13061] 1518402858.43198: Response was from master KDC
[13061] 1518402858.43258: Processing preauth types: 17, 19, 147
[13061] 1518402858.43273: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[13061] 1518402858.43300: Preauth module pkinit (147) (info) returned:
0/Success
[13061] 1518402858.44150: PKINIT client verified DH reply
[13061] 1518402858.44189: PKINIT client found id-pkinit-san in KDC cert:
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM
[13061] 1518402858.44199: PKINIT client matched KDC principal
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM against id-pkinit-san; no EKU
check required
[13061] 1518402858.62345: PKINIT client used KDF 2B06010502030602 to
compute reply key aes256-cts/00E0
[13061] 1518402858.62395: Preauth module pkinit (17) (real) returned:
0/Success
[13061] 1518402858.62402: Produced preauth for next request: (empty)
[13061] 1518402858.62414: AS key determined by preauth: aes256-cts/00E0
[13061] 1518402858.62547: Decrypted AS reply; session key is:
aes256-cts/96F0
[13061] 1518402858.62589: FAST negotiation: available
[13061] 1518402858.62692: Initializing
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 with default princ
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS
[13061] 1518402858.62770: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62846: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: fast_avail: yes
[13061] 1518402858.62878: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/fast_avail/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
[13061] 1518402858.62933: Storing config in
KEYRING:persistent:760400007:krb_ccache_f3PFEy1 for
krbtgt/IDM.EXAMPLE.COM(a)IDM.EXAMPLE.COM: pa_type: 16
[13061] 1518402858.62954: Storing
WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS ->
krb5_ccache_conf_data/pa_type/krbtgt\/IDM.EXAMPLE.COM\@IDM.EXAMPLE.COM(a)X-CACHECONF:
in KEYRING:persistent:760400007:krb_ccache_f3PFEy1
But on the client, I get this:
$ KRB5_TRACE="/dev/stderr" kinit -n
[2941] 1518402820.155827: Getting initial credentials for
WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM
[2941] 1518402820.156298: Sending request (200 bytes) to IDM.EXAMPLE.COM
[2941] 1518402820.158723: Resolving hostname paine.example.com.
[2941] 1518402820.159975: Resolving hostname phantom.example.com.
[2941] 1518402820.160757: Resolving hostname paine.example.com.
[2941] 1518402820.161411: Initiating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.162065: Sending TCP request to stream 204.89.253.101:88
[2941] 1518402820.168495: Received answer (359 bytes) from stream
204.89.253.101:88
[2941] 1518402820.168532: Terminating TCP connection to stream
204.89.253.101:88
[2941] 1518402820.169917: Response was from master KDC
[2941] 1518402820.169974: Received error from KDC:
-1765328359/Additional pre-authentication required
[2941] 1518402820.170029: Processing preauth types: 16, 15, 14, 136, 19,
147, 2, 133
[2941] 1518402820.170051: Selected etype info: etype aes256-cts, salt
"IDM.EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
[2941] 1518402820.170062: Received cookie: MIT
Password for WELLKNOWN/ANONYMOUS(a)IDM.EXAMPLE.COM:
[2941] 1518402833.34612: Preauth module encrypted_timestamp (2) (real)
returned: -1765328252/Password read interrupted
kinit: Pre-authentication failed: Password read interrupted while
getting initial credentials
Suggestions on what I'm missing?
Thanks.
2 months, 1 week
Plans for integrating DHCP
by Ronald Wimmer
Hi there,
are there any plans to integrate a DHCP server into FreeIPA. We have
several environments where a lack of DHCP is a showstopper at the moment.
Cheers,
Ronald
2 months, 2 weeks
automember hostgroup by account?
by Amos
Is it possible to have an automember rule to add a host to a hostgroup
based on the account used with ipa-install-client?
Amos
3 months, 1 week
Problems after replacing SSL certificates
by Andreas Bulling
Dear all,
I have recently started using FreeIPA (4.8.1 on Ubuntu) and now wanted to replace the original SSL certificates for the web UI and the LDAP server with official ones issued by our university.
I've followed the procedure described here (no errors):
https://www.freeipa.org/page/Using_3rd_part_certificates_for_HTTP/LDAP
I could confirm in the browser that the certificate for the web UI has been replaced and I therefore assume so has the LDAP certificate. Authentication from other hosts/services using LDAP still works but in the server log file I see errors like these for all hosts in the domain:
Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: NEEDED_PREAUTH: host/X@X for krbtgt/X@X, Additional pre-authentication required
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Apr 20 19:57:11 auth krb5kdc[24895]: AS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for krbtgt/X@X
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Apr 20 19:57:11 auth krb5kdc[24895]: TGS_REQ (8 etypes {18 17 20 19 16 23 25 26}) X: ISSUE: authtime 1587405431, etypes {rep=18 tkt=18 ses=18}, host/X@X for ldap/X@X
Apr 20 19:57:11 auth krb5kdc[24895]: closing down fd 12
Also, ipa-certupdate on the respective clients shows
ipa-certupdate
trying https://X/ipa/json
[try 1]: Forwarding 'schema' to json server 'https://X/ipa/json'
cannot connect to 'https://X/ipa/json': [SSL: CERTIFICATE_VERIFY_FAILED] certificate verify failed (_ssl.c:727)
The ipa-certupdate command failed.
Also, I can't login to the web UI anymore. I tried
ipa-getkeytab -s X -p HTTP/X@X -k /var/lib/ipa/gssproxy/http.keytab
on the freeipa server (followed by ipactl restart) but this didn't help.
Any idea/suggestions for how to get everything working again?
Thanks a lot!
3 months, 2 weeks
IPA and legacy systems
by Ronald Wimmer
What would be a good solution to add systems where the FQDN cannot be
changed?
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!
Cheers,
Ronald
3 months, 3 weeks
IPA CA renewal and duplicate CA certs
by Sigbjorn Lie
Hi,
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?
Thanks.
Regards,
Siggi
4 months, 1 week
Plugin problem after upgrade
by Frederic AYRAULT
Bonjour,
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 ?
Thank you
Regards,
Frederic
Frédéric AYRAULT
Administrateur Systèmes et Réseaux
Laboratoire d'Informatique de l'Ecole polytechnique
<http://www.lix.polytechnique.fr>
fred(a)lix.polytechnique.fr
4 months, 1 week
