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.
3 weeks, 1 day
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
1 month, 3 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
2 months, 1 week
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...
3 months, 2 weeks
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
4 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.
4 months, 2 weeks
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
5 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
5 months
FreeIPA 4.8.1 on Fedora 31 (upgraded from F30) fails to start
by Wulf C. Krueger
Hello,
my FreeIPA installation was working well on Fedora 30. After upgrading
to F31, though, it fails to start:
----
# ipactl start
IPA version error: data needs to be upgraded (expected version
'4.8.1-4.fc31', current version '4.8.1-1.fc30')
Automatically running upgrade, for details see /var/log/ipaupgrade.log
Be patient, this may take a few minutes.
Automatic upgrade failed: Update complete
Upgrading the configuration of the IPA services
[Verifying that root certificate is published]
[Migrate CRL publish directory]
CRL tree already moved
IPA server upgrade failed: Inspect /var/log/ipaupgrade.log and run
command ipa-server-upgrade manually.
Unexpected error - see /var/log/ipaupgrade.log for details:
CalledProcessError: CalledProcessError(Command ['/bin/systemctl',
'start', 'pki-tomcatd(a)pki-tomcat.service'] returned non-zero exit status
1: 'Job for pki-tomcatd(a)pki-tomcat.service failed because a timeout was
exceeded.\nSee "systemctl status pki-tomcatd(a)pki-tomcat.service" and
"journalctl -xe" for details.\n')
The ipa-server-upgrade command failed. See /var/log/ipaupgrade.log for
more information
See the upgrade log for more details and/or run
/usr/sbin/ipa-server-upgrade again
Aborting ipactl
----
Logs:
ipaupgrade.log: https://mailstation.de/ipa-logs/ipaupgrade.log
pki-tomcatd@pki-tomcat log:
https://mailstation.de/ipa-logs/pki-tomcatd@pki-tomcat.log
pki-tomcat-ca-debug log:
https://mailstation.de/ipa-logs/pki-tomcat-ca-debug.2019-11-02.log
So it looks like the LDAP server isn't reachable but its log says it's
running: https://mailstation.de/ipa-logs/dirsrv@MAILSTATION-DE.log
There's nothing listening on ports 389 and 636, though.
Help would be highly appreciated.
Best regards, Wulf
6 months
WARNING Could not update DNS SSHFP records.
by Ron Blom
Hi,
We have problems with client’s registering dns records at enrollment. Most of the time all works ok but about 10% of the machines don’t create the A records or the SHHFP records. Sometimes they don’t create both. In the ipaclient-install.log we see the following on machines that doesn’t create the records. In this example the creation of the A records succeeded but the creation of the SSHFP records failed with the following error:
2019-12-20T13:19:51Z INFO Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub
2019-12-20T13:19:51Z INFO Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub
2019-12-20T13:19:51Z INFO Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub
2019-12-20T13:19:51Z INFO [try 1]: Forwarding 'host_mod' to json server 'https://freeipa-002.ipa.cloud/ipa/session/json'
2019-12-20T13:19:51Z DEBUG HTTP connection keep-alive (freeipa-002.ipa.cloud)
2019-12-20T13:19:51Z DEBUG received Set-Cookie (<type 'list'>)'['ipa_session=MagBearerToken=tR1VkWrpjmoNh7aZDYiPzXSwFlkhsp1ENg%2b5y8orMo9P7EkiLQXey11TH9wIgc2xJjJ2xdly2hFyi6v58o2HhzEeQBi%2fcR%2flZ7nwFv8VX3WxCSwS%2beDVSu7%2f%2fjsSB%2b1NzyVHTNe5jkJK9pGXL1nR7QMtNrV2gFY7RyFrJns50dEC%2fi5C%2fEn0BgZAE4aLAiThG4SW3iGc0bfOGy%2bDpAGE17XzB8G978uKpqqHGC9aFDmMmXVFCfpwHoIWoBtJctgy7y6Q97rJnpkjbe2heYMwLQFbDkrTRlrjSDfla0XXCNvd7in6zEu0MZloOXqyXHiu;path=/ipa;httponly;secure;']'
2019-12-20T13:19:51Z DEBUG storing cookie 'ipa_session=MagBearerToken=tR1VkWrpjmoNh7aZDYiPzXSwFlkhsp1ENg%2b5y8orMo9P7EkiLQXey11TH9wIgc2xJjJ2xdly2hFyi6v58o2HhzEeQBi%2fcR%2flZ7nwFv8VX3WxCSwS%2beDVSu7%2f%2fjsSB%2b1NzyVHTNe5jkJK9pGXL1nR7QMtNrV2gFY7RyFrJns50dEC%2fi5C%2fEn0BgZAE4aLAiThG4SW3iGc0bfOGy%2bDpAGE17XzB8G978uKpqqHGC9aFDmMmXVFCfpwHoIWoBtJctgy7y6Q97rJnpkjbe2heYMwLQFbDkrTRlrjSDfla0XXCNvd7in6zEu0MZloOXqyXHiu;' for principal host/adm-sdrn6419-2062.aal.ipa.cloud(a)RINIS.CLOUD
2019-12-20T13:19:51Z DEBUG Writing nsupdate commands to /etc/ipa/.dns_update.txt:
2019-12-20T13:19:51Z DEBUG debug
update delete adm-sdrn6419-2062.aal.ipa.cloud. IN SSHFP
show
send
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 1 1 6134C7CDE12FDDFA33A068A273941697928FBCD7
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 1 2 2F41772E6CAD9C328730BFCED0E27350A6C20DE8499E60158635ED8419BF2022
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 3 1 FFE99F20A5C32D857535D13425A7F85F3A63E198
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 3 2 D2C7FC741E834D4E1FE51B7867AFA2D34D0685C769D9019D98093E01C8312118
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 4 1 ED5416B39F419E4F631AB6C9A9CFC0139907232E
update add adm-sdrn6419-2062.aal.ipa.cloud. 1200 IN SSHFP 4 2 7794DBAA391B2939476EDD3A0173162F9CD3BBE1E16B52754BB8C6B56DA26435
show
send
2019-12-20T13:19:51Z DEBUG Starting external process
2019-12-20T13:19:51Z DEBUG args=/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt
2019-12-20T13:19:51Z DEBUG Process finished, return code=1
2019-12-20T13:19:51Z DEBUG stdout=Outgoing update query:
;; ->>HEADER<<- opcode: UPDATE, status: NOERROR, id: 0
;; flags:; ZONE: 0, PREREQ: 0, UPDATE: 0, ADDITIONAL: 0
;; UPDATE SECTION:
adm-sdrn6419-2062.aal.ipa.cloud. 0 ANY SSHFP
Outgoing update query:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22636
;; flags:; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 1
;; QUESTION SECTION:
;3648384014.sig-freeipa-001.ipa.cloud. ANY TKEY
;; ADDITIONAL SECTION:
3648384014.sig-freeipa-001.ipa.cloud. 0 ANY TKEY gss-tsig. 1576847991 1576847991 3 NOERROR 677 YIICoQYJKoZIhvcSAQICAQBuggKQMIICjKADAgEFoQMCAQ6iBwMFACAA AACjggGCYYIBfjCCAXqgAwIBBaENGwtSSU5JUy5DTE9VRKIpMCegAwIB AaEgMB4bA0ROUxsXYWRtLWFhYS0wMDEucmluaXMuY2xvdWSjggE3MIIB M6ADAgESoQMCAQKiggElBIIBIWJzJaNElw4aQs2ZFHDopnUdH6vqowdG ojmiCBIpmgFjPsHEl98zY+UX6OqfF3ovB/uMAuCF1eq3spIRtPjb7hUO +lva9UtuvUJSV0pT9WI1B0ROZxzspkBQmZEYLRUCACxjW3Kw1F123ryy Ga4JJ4cROOFf1GtTdEW3CmIJLlyKqWXDFSQzgnqvP/acb0mQIr0Wid6P DJFaxYmm+uRHw5KBTg7hjeAQPFwgZxNdardv9hUvfhzElxtOK0Kj3ZDy 9lFdpemEtO+osfnwrwyX28xWGLZds/Gfpy0kfdihkUxT082eTWNftaE7 dX0LOb46j9sbMAFDbgHESCkXq5VFRBmtotnf3SRru/eBQFdbYq0/o/oY PCmaTJ4HSymhjbkrVVqkgfAwge2gAwIBEqKB5QSB4tPwDLt7qpKesLJg lGFXpoNqHOsGlFheQslzzkcWzjgoJDDRSJtjoaLgLFv0cITj+rr4dXcu tdMNESwRObXQofsbO9E0HYfZWijSDEIVJlXETm+x8ca4Qf938u3RHV/U +ZXmepZIBnMR4d70Vo+vz6CuXt0+HI0Dh6ot2whzX5g0MWHI0SfJElhO pgWN59uMUC4E8HtLzNEoWljX25acK3mi8ZBgq8iFihfObfEP0Xmx11NE Gru9QOiwMoxRUblws44U3sNOFRUgF9Ua3kKWXEfJ4wpPC3GwdMUajMkr V3wCXBc= 0
2019-12-20T13:19:51Z DEBUG stderr=Reply from SOA query:
;; ->>HEADER<<- opcode: QUERY, status: NXDOMAIN, id: 13244
;; flags: qr aa rd ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 1, ADDITIONAL: 0
;; QUESTION SECTION:
;adm-sdrn6419-2062.aal.ipa.cloud. IN SOA
;; AUTHORITY SECTION:
aal.ipa.cloud. 0 IN SOA freeipa-001.ipa.cloud. hostmaster.aal.ipa.cloud. 1576848002 3600 60 1209600 60
Found zone name: aal.ipa.cloud
The master is: freeipa-001.ipa.cloud
start_gssrequest
Found realm from ticket: RINIS.CLOUD
send_gssrequest
recvmsg reply from GSS-TSIG query
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 22636
;; flags: qr ra; QUESTION: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;3648384014.sig-freeipa-001.ipa.cloud. ANY TKEY
;; ANSWER SECTION:
3648384014.sig-freeipa-001.ipa.cloud. 0 ANY TKEY gss-tsig. 0 0 3 BADNAME 0 0
dns_tkey_gssnegotiate: TKEY is unacceptable
2019-12-20T13:19:51Z DEBUG nsupdate failed: Command '/usr/bin/nsupdate -g /etc/ipa/.dns_update.txt' returned non-zero exit status 1
2019-12-20T13:19:51Z WARNING Could not update DNS SSHFP records.
When I run the nsupdate command manually after enrollment it will succeed and add the missing records.
any ideas?
6 months, 2 weeks
