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
1 month
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
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, 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, 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
4 months
ipa: ERROR: CIFS server communication error: code "3221225506", message "{Access Denied} A process has requested access to an object but has not been granted those access rights." (both may be "None")
by Bernard Lheureux
Hi all,
After a fresh install of FreeIPA 4.6.5-11.el7.centos.x86_64, fully updated from update repo on a CentOS7 x64 server, it appears that it is totally impossible to establish a trust with an AD running on local AD servers, we did it a few times ago with exactly the same distribution and had really no problem, we tried to completely reinstall the machine and the IPA wit always the same results,
ipa: ERROR: CIFS server communication error: code "3221225506", message "{Access Denied} A process has requested access to an object but has not been granted those access rights." (both may be "None")
Could someone point me to the direction to look for, because we are going nuts on this ?
We found some tips in the /var/log/httpd/errors, but nothing seems to provide sufficient infos...
[Wed Oct 02 12:54:57.868830 2019] [:error] [pid 2036] ipa: INFO: [jsonserver_session] admin(a)DOMAIN.INTRA: trust_add/1(u'domain.intra', trust_type=u'ad', realm_admin=u'admin', realm_passwd=u'********', bidirectional=True, version=u'2.231'): RemoteRetrieveError
The IPA server and the AD servers are in the same VLan with no firewall between them
samba version on the IPA server is the latest available: 4.9.1-6.el7.noarch
Thanks for your help...
5 months, 1 week
Allow AD users to manage FreeIPA
by White, David
I'm reviewing the documentation at https://www.freeipa.org/page/V4/Allow_AD_users_to_manage_FreeIPA, as I am hoping to allow members of certain AD groups to login to FreeIPA from the web GUI.
Does this documentation only apply to the FreeIPA CLI, or does it also affect access to manage through the web GUI?
Let's say we have an AD group named "engineers", and I want those engineers to have admin access over FreeIPA.
If the above documentation only affects the CLI, that feels a little bit redundant, because we can of course easily create Sudo / Su rules to allow members of "engineers" to have control over the FreeIPA nodes using HBAC rules and such.
(This is already done and working -- members of `engineers` already have CLI admin access over FreeIPA -- I now want them to have GUI admin access).
I'm also a little bit confused why the documentation says to add a domain user to the AD "administrators" group (as an ID Override).
That feels like a security risk, because I don't want the user to be considered an Active Directory administrator -- I only want the person (well, any members of the `engineers` group) to have admin access over FreeIPA.
It sounds like this would have to be done on a user-by-user basis (and is not something we could apply to an entire AD group that already exists)?
I ran:
`id administrator(a)ad.domain.com` and verified that I do have stdout.
But then I ran:
`ipa group-show administrator(a)ad.domain.com` and stdout included:
ipa: ERROR: administrator(a)ad.domain.com: group not found
Is there any way to accomplish what I want?
-----
David White
Engineer II, Fiber Systems Engineering
6 months, 1 week
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.
6 months, 1 week
Re: Issues with certificates: X509: KEY_VALUES_MISMATCH
by Rob Crittenden
Dmitri Moudraninets wrote:
> Hi Rob,
>
> I recovered the key file. Restarted FreeIPA and certmonger. Now issue
> looks different:
> image.png
>
> Subjects disappeared. If I click on a certificate 29 I see this:
> cannot connect to
> 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial':
> [Errno 13] Permission denied
Set the same ownership/permissions on the key as you did the cert and
run restorecon on it.
rob
>
> пн, 25 нояб. 2019 г. в 13:58, Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>>:
>
> Dmitri Moudraninets wrote:
> > Hi Rob,
> >
> >
> >
> > I did the following:
> > I removed original ra-agent.pem and ra-agent key
> > and
> > openssl x509 -in /root/debug.cert -out /var/lib/ipa/ra-agent.pem
> > chown root:ipaapi /var/lib/ipa/ra-agent.pem
> > chmod 0440 /var/lib/ipa/ra-agent.pem
> > restorecon /var/lib/ipa/ra-agent.pem
>
> You removed the key!? I sure hope you have a backup of it.
>
> Put it back and I think that will resolve things.
>
> >
> > Successfully restarted FreeIPA:
> > Directory Service: RUNNING
> > krb5kdc Service: RUNNING
> > kadmin Service: RUNNING
> > named Service: RUNNING
> > httpd Service: RUNNING
> > ipa-custodia Service: RUNNING
> > ntpd Service: RUNNING
> > pki-tomcatd Service: RUNNING
> > smb Service: RUNNING
> > winbind Service: RUNNING
> > ipa-otpd Service: RUNNING
> > ipa-dnskeysyncd Service: RUNNING
> > ipa: INFO: The ipactl command was successful
>
> The agent cert is not required for the CA to operate.
>
> > Now GUI shows different error:
> > cannot connect to
> > 'https://freeipa.corp.mydomain.de:443/ca/agent/ca/displayBySerial':
> > [Errno 2] No such file or directory
> >
> >
> > [root@freeipa ~]# getcert list -f /var/lib/ipa/ra-agent.pem
> > Number of certificates and requests being tracked: 16.
> > Request ID '20180912151611':
> > status: NEED_CSR
> > stuck: no
> > key pair storage: type=FILE,location='/var/lib/ipa/ra-agent.key'
> > certificate: type=FILE,location='/var/lib/ipa/ra-agent.pem'
> > CA: dogtag-ipa-ca-renew-agent
> > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>
> > subject: CN=IPA RA,O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > expires: 2019-11-25 15:32:12 UTC
> > key usage:
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > eku: id-kp-serverAuth,id-kp-clientAuth
> > pre-save command: /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> > post-save command: /usr/libexec/ipa/certmonger/renew_ra_cert
> > track: yes
> > auto-renew: yes
>
> This shows that the certificate has the right subject now which is good
> but you removed its private key so it won't work.
>
> rob
>
> >
> > сб, 23 нояб. 2019 г. в 20:26, Rob Crittenden <rcritten(a)redhat.com
> <mailto:rcritten@redhat.com>
> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>:
> >
> > Dmitri Moudraninets wrote:
> > > Hi Rob,
> > >
> > > ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory manager' -W
> > > -b uid=ipara,ou=People,o=ipaca usercertificate
> > >
> > > shows me the following:
> > >
> > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>,
> > > CN=Certificate Authority
> > > Validity
> > > Not Before: Dec 5 15:32:12 2017 GMT
> > > Not After : *Nov 25 15:32:12 2019* GMT
> > >
> > > It's going to expire on Monday. Can it be a problem?
> >
> > You didn't provide the cert subject so I can't be sure this is
> the right
> > cert. If it contains CN = IPA RA then it is.
> >
> > And yes, it expires in two days. What you'd need to do is
> restore it per
> > my previous instruction into /var/lib/ipa/ra-agent.pem on the
> renewal
> > master (ipa config-show to see which one it is).
> >
> > Then run:
> >
> > # getcert resubmit -f /var/lib/ipa/ra-agent.pem
> >
> > That should renew the cert.
> >
> > On the other masters I'd run the same command and that may fix
> things
> > there as well.
> >
> > rob
> >
> > > I tried this command:
> > > openssl x509 -text -in /var/lib/ipa/ra-agent.pem
> > >
> > > and it shows the following:
> > > Certificate:
> > > Data:
> > > Version: 3 (0x2)
> > > Serial Number: 28 (0x1c)
> > > Signature Algorithm: sha256WithRSAEncryption
> > > Issuer: O=CORP.MYDOMAIN.DE <http://CORP.MYDOMAIN.DE>
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>,
> > > CN=Certificate Authority
> > > Validity
> > > Not Before: Oct 29 10:39:47 2019 GMT
> > > Not After : Oct 29 09:39:47 2021 GMT
> > > Subject: O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN=dmud
> > > Subject Public Key Info:
> > > Public Key Algorithm: rsaEncryption
> > > Public-Key: (2048 bit)
> > > Modulus:
> > >
> 00:ba:09:81:99:9b:17:99:07:5a:10:28:c8:7a:03:
> > > ...
> > >
> 18:db:02:ce:b4:66:ce:5a:e9:12:af:d3:da:bf:f7:
> > > 66:5f
> > > Exponent: 65537 (0x10001)
> > > X509v3 extensions:
> > > X509v3 Authority Key Identifier:
> > > keyid:D2:...70:BF
> > >
> > > X509v3 Subject Key Identifier:
> > > DE:...:51:0A
> > > X509v3 Subject Alternative Name:
> > > email:dmud@corp.mydomain.de
> <mailto:email%3Admud@corp.mydomain.de>
> > <mailto:email%3Admud@corp.mydomain.de
> <mailto:email%253Admud@corp.mydomain.de>>
> > > <mailto:email%3Admud@corp.mydomain.de
> <mailto:email%253Admud@corp.mydomain.de>
> > <mailto:email%253Admud@corp.mydomain.de
> <mailto:email%25253Admud@corp.mydomain.de>>>
> > > Authority Information Access:
> > > OCSP -
> URI:http://ipa-ca.corp.mydomain.de/ca/ocsp
> > >
> > >
> > > I did nothing to /var/lib/ipa/ra-agent.pem yet.
> > >
> > >
> > > чт, 21 нояб. 2019 г. в 16:54, Rob Crittenden
> <rcritten(a)redhat.com <mailto:rcritten@redhat.com>
> > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>
> > > <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>
> <mailto:rcritten@redhat.com <mailto:rcritten@redhat.com>>>>:
> > >
> > > Dmitri Moudraninets wrote:
> > > > Hi Rob,
> > > >
> > > > Yes both masters are failing the same way. Output
> of openssl
> > x509
> > > -noout
> > > > -modulus -in /var/lib/ipa/ra-agent.pem is the same on both
> > masters.
> > > > Output of openssl rsa -noout -modulus -in
> > /var/lib/ipa/ra-agent.key is
> > > > also the same on both masters. But the output of the first
> > command is
> > > > not the same as the output of the second command.
> > > >
> > > > I can't remember that I troubleshoot any other
> problems but we
> > > tried to
> > > > generate some personal certificates for some users.
> Also we
> > tried to
> > > > generate certificates with key files for some of our
> internal
> > > services.
> > > > We did that for the first time and it worked at the
> end. Also I
> > > changed
> > > > the admin password not so long ago.
> > > >
> > > >
> > > > Below you can find the output of the requested commands:
> > > >
> > > >
> > > > [root@second_master ~]# getcert list -f
> > /var/lib/ipa/ra-agent.pem
> > > > Number of certificates and requests being tracked: 9.
> > > > Request ID '20180912151730':
> > > > status: MONITORING
> > > > stuck: no
> > > > key pair storage:
> type=FILE,location='/var/lib/ipa/ra-agent.key'
> > > > certificate:
> type=FILE,location='/var/lib/ipa/ra-agent.pem'
> > > > CA: dogtag-ipa-ca-renew-agent
> > > > issuer: CN=Certificate Authority,O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE>
> > > <http://CORP.MYDOMAIN.DE>
> > > > <http://CORP.MYDOMAIN.DE>
> > > > subject: CN=dmud,O=CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>
> > > <http://CORP.MYDOMAIN.DE>
> > > > *<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<< I see a username here.
> > Does it have
> > > > to be like that?*
> > > > expires: 2021-10-29 09:39:47 UTC
> > > > email: dmud(a)corp.mydomain.de
> <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de>>
> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>
> <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>>
> > > <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de> <mailto:dmud@corp.mydomain.de
> <mailto:dmud@corp.mydomain.de>>
> > <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>
> <mailto:dmud@corp.mydomain.de <mailto:dmud@corp.mydomain.de>>>>
> > > > key usage:
> > >
> digitalSignature,nonRepudiation,keyEncipherment,dataEncipherment
> > > > eku: id-kp-serverAuth,id-kp-clientAuth
> > > > pre-save command:
> /usr/libexec/ipa/certmonger/renew_ra_cert_pre
> > > > post-save command:
> /usr/libexec/ipa/certmonger/renew_ra_cert
> > > > track: yes
> > > > auto-renew: yes
> > >
> > > Right, someone overwrote the RA agent certificate.
> > >
> > > Look to see if the user entry in the CA has the right cert:
> > >
> > > $ ldapsearch -LLL -o ldif-wrap=no -x -D 'cn=directory
> manager'
> > -W -b
> > > uid=ipara,ou=People,o=ipaca usercertificate
> > >
> > > Put the base64 value of the usercertificate attribute into a
> > file and
> > > add a prefix/suffix around it:
> > >
> > > -----BEGIN CERTIFICATE-----
> > > MII....blah=
> > > -----END CERTIFICATE-----
> > >
> > > $ openssl x509 -text -in /path/to/file
> > >
> > > If the Subject is O = CORP.MYDOMAIN.DE
> <http://CORP.MYDOMAIN.DE>
> > <http://CORP.MYDOMAIN.DE> <http://CORP.MYDOMAIN.DE>, CN
> > > = IPA RA then that's a good
> > > start. Also look at the expires date to be sure it is
> still valid.
> > >
> > > Assuming that is ok then re-run the openssl modulus commands
> > to ensure
> > > they are the same.
> > >
> > > Assuming that too is ok then you have the proper, valid RA
> > agent cert.
> > > In that case I'd move the current file out of the way, who
> > knows what it
> > > is, then run:
> > >
> > > # openssl x509 -in /path/to/file -out
> > /var/lib/ipa/ra-agent.pem (just to
> > > properly format the agent cert)
> > > # chown root:ipaapi /var/lib/ipa/ra-agent.pem
> > > # chmod 0440 /var/lib/ipa/ra-agent.pem
> > > # restorecon /var/lib/ipa/ra-agent.pem
> > >
> > > Then try something like: ipa cert-show 1
> > >
> > > This will exercise the RA agent cert and as long as you
> don't
> > get an
> > > error back things are working again.
> > >
> > > The cert is common among all masters so you can copy the
> file
> > to your
> > > other master(s), ensuring proper ownership, permissions and
> > SELinux
> > > context.
> > >
> > > rob
> > >
> > >
> > >
> > > --
> > > WBR
> > > Dmitry
> >
> >
> >
> > --
> > With best regards/Mit freundlichen Grüßen
> >
> > Moudraninets Dmitry, RHCSA
> > http://www.linkedin.com/in/moudraninets
> > http://www.xing.com/profile/Dmitry_Mudraninets
>
>
>
> --
> With best regards/Mit freundlichen Grüßen
>
> Moudraninets Dmitry, RHCSA
> http://www.linkedin.com/in/moudraninets
> http://www.xing.com/profile/Dmitry_Mudraninets
7 months
How to make ipa root certificate available system wide
by Kevin Vasko
Hello,
I’m wanting to make our https servers use a trusted certificate within our LAN only. So for example if I have websrv1.ny.example.com when a user uses a machine that’s enrolled into our realm and they visit https://websrv1.ny.example.com they shouldn’t be prompted to accept the self signed certificate.
I think I’m pretty close but I’m missing a small part.
The ipa server is all setup and working. Hosts are enrolled to ipa and have the /etc/ipa/ca.crt.
I have created a service for the http server in IPA. I have obtained a .key file and .crt file for my web server. Those keys for the web server are in the appropriate location and the web server is pointing at the certs correctly.
On my clients when I go to the web servers URl I am no longer getting a “self signed cert” error message in the browser.
That message has now changed to “unverified certificate authority”. Which basically indicates to me that the browser doesn’t know if this certificate authority should/can be trusted.
If i go in the browser (firefox or chrome) in the certificate authority section and import the /etc/ipa/ca.crt i get no errors in the browser about it being unverified.
So my question is, what am I missing to make the /etc/ipa/ca.crt file globally available for browsers to pick up the certificate automatically?
when we enroll a host we simply do
freeipa-install-client —domain=example.com —realm=EXAMPLE.COM —mkhomedir
Accept the defaults, put in the password to enroll and that’s it. Is there something I’m missing?
-Kevin
7 months
