[Freeipa-users] PKINIT support in FreeIPA 4.2.0
Sumit Bose
sbose at redhat.com
Thu Feb 11 08:28:52 UTC 2016
On Thu, Feb 11, 2016 at 11:16:14AM +1100, Nik Lam wrote:
> On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose <sbose at redhat.com> wrote:
>
> > On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote:
> > > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose <sbose at redhat.com> wrote:
> > >
> > > > On Wed, Feb 10, 2016 at 12:07:45PM +1100, Nik Lam wrote:
> > > > > On Wed, Feb 10, 2016 at 3:04 AM, Sumit Bose <sbose at redhat.com>
> > wrote:
> > > > >
> > > > > > On Wed, Feb 10, 2016 at 02:08:55AM +1100, Nik Lam wrote:
> > > > > > > On Mon, Feb 8, 2016 at 11:53 PM, Sumit Bose <sbose at redhat.com>
> > > > wrote:
> > > > > > >
> > > > > > > > On Thu, Feb 04, 2016 at 07:25:29PM +1100, Nik Lam wrote:
> > > > > > > > > On Wed, Feb 3, 2016 at 8:08 PM, Sumit Bose <sbose at redhat.com
> > >
> > > > wrote:
> > > > > > > > >
> > > > > > > > > > On Wed, Feb 03, 2016 at 10:29:49AM +1100, Nik Lam wrote:
> > > > > > > > > > > Hello,
> > > > > > > > > > >
> > > > > > > > > > > I installed ipa-server on Centos 7.1 and later did and
> > > > upgrade
> > > > > > of the
> > > > > > > > > > whole
> > > > > > > > > > > system to Centos 7.2.
> > > > > > > > > > >
> > > > > > > > > > > I think the FreeIPA version changed from 4.1.0 to 4.2.0
> > > > between
> > > > > > these
> > > > > > > > > > > Centos/RHEL minor releases.
> > > > > > > > > > >
> > > > > > > > > > > We'd now like to try integrating with a 2FA provider via
> > a
> > > > radius
> > > > > > > > proxy
> > > > > > > > > > and
> > > > > > > > > > > want to use anonymous PKINIT to secure the initial
> > > > communications
> > > > > > > > between
> > > > > > > > > > > the client and the KDC.
> > > > > > > > > > >
> > > > > > > > > > > We've tried following the MIT Kerberos PKINIT
> > configuration
> > > > > > > > documentation
> > > > > > > > > > >
> > > > > > > > > > >
> > > > http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html
> > > > > > > > > > >
> > > > > > > > > > > generating our own certs manually with openssl but
> > haven't
> > > > had
> > > > > > any
> > > > > > > > luck.
> > > > > > > > > > > We're seeing this in the kdc log:
> > > > > > > > > > >
> > > > > > > > > > > preauth pkinit failed to initialize: No realms
> > configured
> > > > > > > > correctly
> > > > > > > > > > for
> > > > > > > > > > > pkinit support
> > > > > > > > > >
> > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the
> > IPA
> > > > CA to
> > > > > > > > sign
> > > > > > > > > > the certificate or some other CA?
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I've noticed there are many new pkinit-related options
> > that
> > > > have
> > > > > > been
> > > > > > > > > > added
> > > > > > > > > > > to the ipa-server-install script in 4.2.0, so it looks
> > like
> > > > > > PKINIT is
> > > > > > > > > > > available in this version of FreeIPA. Is that the case?
> > > > > > > > > >
> > > > > > > > > > Which options are you referring to?
> > > > > > > > > >
> > > > > > > > > > bye,
> > > > > > > > > > Sumit
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > And if it is, what is the recommended way to enable it
> > given
> > > > > > that it
> > > > > > > > > > seems
> > > > > > > > > > > to have been disabled in the original install that I
> > did? Or
> > > > > > would it
> > > > > > > > > > just
> > > > > > > > > > > be easier to start from scratch with a 4.2.0
> > > > ipa-server-install?
> > > > > > > > (It's a
> > > > > > > > > > > test instance that doesn't have too much in it - it will
> > > > take a
> > > > > > > > several
> > > > > > > > > > > hours to rebuild from scratch.)
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Nik
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > Thanks Sumit.
> > > > > > > > >
> > > > > > > > > It sounds like PKINIT is available but clearly I'm doing it
> > > > wrong.
> > > > > > > > >
> > > > > > > > > > Which changes did you apply to krb5.conf? Did you use the
> > IPA
> > > > CA
> > > > > > to
> > > > > > > > sign
> > > > > > > > > the certificate or some other CA?
> > > > > > > > >
> > > > > > > > > Actually, I modified the kdc.conf file - placed the kdc.pem,
> > > > > > kdckey.pem
> > > > > > > > and
> > > > > > > > > cacert.pem files in /var/kerberos/krb5kdc/ that I generated
> > via
> > > > > > openssl
> > > > > > > > > commands in the MIT Kerberos documentation. The only change
> > to
> > > > > > kdc.conf
> > > > > > > > > file was to append the location of the kdckey.pem file to
> > > > > > > > pkinit_identity.
> > > > > > > > >
> > > > > > > > > pkinit_identity = FILE:/var/kerberos/krb5kdc/kdc.pem
> > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
> > > > > > > > >
> > > > > > > > > became
> > > > > > > > >
> > > > > > > > > pkinit_identity =
> > > > > > > > >
> > > > FILE:/var/kerberos/krb5kdc/kdc.pem,/var/kerberos/krb5kdc/kdckey.pem
> > > > > > > > > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
> > > > > > > > >
> > > > > > > > > Should I have been modifying krb5.conf instead? It aslo
> > sounds
> > > > like I
> > > > > > > > need
> > > > > > > >
> > > > > > > > no, kdc.conf is the right place, I actually meant kdc.conf but
> > > > > > > > accidentially types krb5.conf.
> > > > > > > >
> > > > > > > > > to use a certificate signed by the IPAs CA - is this
> > something
> > > > that
> > > > > > > > should
> > > > > > > > > be generated using ipa-getcert? Or do I just find the IPA
> > CA's
> > > > > > private
> > > > > > > > key
> > > > > > > > > and use openssl following the MIT Kerberos documentation?
> > > > > > > > >
> > > > > > > > > > Which options are you referring to?
> > > > > > > > >
> > > > > > > > > When I looked at the --help text for 4.1.0 and 4.2.0
> > versions of
> > > > > > > > > ipa-server-install, I noticed that 4.2.0 has these in the
> > > > > > "certificate
> > > > > > > > > system options":
> > > > > > > > >
> > > > > > > > > --no-pkinit disables pkinit setup steps
> > > > > > > > >
> > > > > > > > > --pkinit-cert-file=FILE
> > > > > > > > > File containing the Kerberos KDC SSL
> > > > > > certificate
> > > > > > > > and
> > > > > > > > > private key
> > > > > > > > >
> > > > > > > > > --pkinit-pin=PIN The password to unlock the Kerberos
> > KDC
> > > > > > private
> > > > > > > > key
> > > > > > > > >
> > > > > > > > > --pkinit-cert-name=NAME
> > > > > > > > > Name of the Kerberos KDC SSL
> > certificate
> > > > to
> > > > > > > > install
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Seeing that first one, I was a little hopeful that pkinit is
> > > > enabled
> > > > > > by
> > > > > > > > > default in 4.2.0 but on a fresh install I just tried, I'm
> > still
> > > > > > seeing
> > > > > > > > the
> > > > > > > >
> > > > > > > > no, unfortunately pkinit is currently disabled by default
> > > > > > > >
> > > > > > > > > following in krb5kdc.log when IPA is started up, so clearly
> > it
> > > > isn't.
> > > > > > > > >
> > > > > > > > > (Error): preauth pkinit failed to initialize: No realms
> > > > configured
> > > > > > > > > correctly for pkinit support
> > > > > > > >
> > > > > > > > I get the same error when I put the certificate and the key
> > into
> > > > > > > > separate files. Can you try to put both into one and use this
> > for
> > > > the
> > > > > > > > pkinit_identity option?
> > > > > > > >
> > > > > > > > HTH
> > > > > > > >
> > > > > > > > bye,
> > > > > > > > Sumit
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Thanks Sumit, it did!
> > > > > > >
> > > > > > > I concatenated the cert and the key into a single file and the
> > error
> > > > has
> > > > > > > indeed gone away from krb5kdc.log
> > > > > > >
> > > > > > > The odd thing is that I can't reproduce the error by splitting
> > into
> > > > two
> > > > > > > separate files and restarting ipa.service again.
> > > > > > >
> > > > > > > Ignoring that mystery, how do I go about setting up the
> > > > > > WELLKNOWN/ANONYMOUS
> > > > > > > principal?
> > > > > > >
> > > > > > > I'm pretty sure it's needed for anonymous pkinit:
> > > > > > >
> > > > > > > $ kinit
> > > > > > > kinit: Generic preauthentication failure while getting initial
> > > > > > credentials
> > > > > > > $
> > > > > > >
> > > > > > > $ kinit -n
> > > > > > > kinit: Client 'WELLKNOWN/ANONYMOUS at EXAMPLE.COM' not found in
> > > > Kerberos
> > > > > > > database while getting initial credentials
> > > > > > > $
> > > > > > >
> > > > > > > Using kadmin per the MIT documentation doesn't seem to work
> > > > > > (authenticated
> > > > > > > as an IPA admin)
> > > > > > >
> > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS'
> > > > > > > Authenticating as principal admin/admin at EXAMPLE.COM with
> > password.
> > > > > > > kadmin: Client not found in Kerberos database while initializing
> > > > kadmin
> > > > > > > interface
> > > > > > > #
> > > > > > >
> > > > > > > # kadmin -q 'addprinc -randkey WELLKNOWN/ANONYMOUS' -p admin
> > > > > > > Authenticating as principal admin with password.
> > > > > > > Password for admin at EXAMPLE.COM:
> > > > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM
> > ;
> > > > > > > defaulting to no policy
> > > > > > > add_principal: Operation requires ``add'' privilege while
> > creating
> > > > > > > "WELLKNOWN/ANONYMOUS at EXAMPLE.COM".
> > > > > > > #
> > > > > >
> > > > > > Please try
> > > > > >
> > > > > > kadmin.local -x ipa-setup-override-restrictions
> > > > > >
> > > > > > bye,
> > > > > > Sumit
> > > > > >
> > > > > >
> > > > > Thanks Sumit.
> > > > >
> > > > > That seems to have worked to get the principal created.
> > > > >
> > > > > # kadmin.local -x ipa-setup-override-restrictions
> > > > > Authenticating as principal admin/admin at EXAMPLE.COM with password.
> > > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS
> > > > > WARNING: no policy specified for WELLKNOWN/ANONYMOUS at EXAMPLE.COM;
> > > > > defaulting to no policy
> > > > > Principal "WELLKNOWN/ANONYMOUS at EXAMPLE.COM" created.
> > > > > kadmin.local: quit
> > > > > #
> > > > >
> > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/
> > > > > ANONYMOUS at EXAMPLE.COM' not found in Kerberos database.
> > > > >
> > > > > However, I'm being prompted for a password for the anonymous
> > principal.
> > > > >
> > > > > $ kinit -n
> > > > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM:
> > > > > kinit: Password incorrect while getting initial credentials
> > > > > $
> > > > >
> > > > > That doesn't sound right to me - and indeed it doesn't provide an
> > armor
> > > > > cache that I can use for authenticating my client user.
> > > >
> > > > Can you run
> > > >
> > > > KRB5_TRACE=/dev/stdout kinit -n
> > > >
> > > > this will show the list of preauthentication methods offered to the
> > > > client and I would suspect that pkinit is not among of them.
> > > >
> > > > My guess is that there is something wrong with the certificate or the
> > > > configuration, e.g. did you try to set pkinit_kdc_hostname to the
> > > > hostname matching the one in the KDC certificate? Maybe
> > > > pkinit_eku_checking = none might help as well?.
> > > >
> > > > To analyse this further the most easy way is an instrumented build of
> > > > the pkinit module with debugging enabled. If you can tell me the exact
> > > > version of your krb5-pkinit package I can prepare a build for you.
> > > >
> > > > HTH
> > > >
> > > > bye,
> > > > Sumit
> > > >
> > >
> > > Thank you Sumit.
> > >
> > > I've checked that the hostname in the KDC's cert matches what I've put in
> > > the client's krb.conf's pkinit_hostname.
> > >
> > > I've also tried setting pkinit_eku_checking = none in there.
> > >
> > > $ KRB5_TRACE=/dev/stdout kinit -n
> > > [9199] 1455105392.574916: Getting initial credentials for WELLKNOWN/
> > > ANONYMOUS at EXAMPLE.COM
> > > [9199] 1455105392.575132: Sending request (186 bytes) to EXAMPLE.COM
> > > [9199] 1455105392.575314: Initiating TCP connection to stream
> > > 10.93.178.73:88
> > > [9199] 1455105392.576513: Sending TCP request to stream 10.93.178.73:88
> > > [9199] 1455105393.370873: Received answer (483 bytes) from stream
> > > 10.93.178.73:88
> > > [9199] 1455105393.370885: Terminating TCP connection to stream
> > > 10.93.178.73:88
> > > [9199] 1455105393.370956: Response was from master KDC
> > > [9199] 1455105393.370977: Received error from KDC: -1765328359/Additional
> > > pre-authentication required
> > > [9199] 1455105393.371014: Processing preauth types: 16, 15, 14, 136, 19,
> > > 147, 2, 133
> >
> > ok, 147 means that the server added the needed preauthentication data
> > for anonymous pkinit.
> >
> > Did you set
> >
> > pkinit_anchors = FILE:/var/kerberos/krb5kdc/cacert.pem
> >
> > in /etc/krb5.conf as well becasue the client must know the CA
> > certificate as well?
> >
> > > [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt
> > > "EXAMPLE.COMWELLKNOWNANONYMOUS", params ""
> > > [9199] 1455105393.371046: Received cookie: MIT
> > > Password for WELLKNOWN/ANONYMOUS at EXAMPLE.COM:
> > > [9199] 1455105400.912468: AS key obtained for encrypted timestamp:
> > > aes256-cts/09BF
> > > [9199] 1455105400.912546: Encrypted timestamp (for 1455105400.914484):
> > > plain 301AA011180F32303136303231303131353634305AA10502030DF434, encrypted
> > >
> > DD840BC3D6F697529D987E73EDD1C9FF82FEC91A0FB408179E6FA9AF49627912BEF49BA4E4EE8FF469BED5672943592A1E7DFBBF781C1E5B
> > > [9199] 1455105400.912576: Preauth module encrypted_timestamp (2) (real)
> > > returned: 0/Success
> > > [9199] 1455105400.912581: Produced preauth for next request: 133, 2
> > > [9199] 1455105400.912601: Sending request (281 bytes) to EXAMPLE.COM
> > > [9199] 1455105400.912674: Initiating TCP connection to stream
> > > 10.93.178.73:88
> > > [9199] 1455105400.913894: Sending TCP request to stream 10.93.178.73:88
> > > [9199] 1455105400.937778: Received answer (197 bytes) from stream
> > > 10.93.178.73:88
> > > [9199] 1455105400.937788: Terminating TCP connection to stream
> > > 10.93.178.73:88
> > > [9199] 1455105400.937835: Response was from master KDC
> > > [9199] 1455105400.937852: Received error from KDC: -1765328353/Decrypt
> > > integrity check failed
> > > kinit: Password incorrect while getting initial credentials
> > > $
> > >
> > > The module package we're using right now is
> > > krb5-pkinit-1.13.2-10.el7.x86_64.
> >
> > Please find the package with debugging enabled at
> >
> > https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm
> >
> > It might be possible to install it with
> >
> > rpm -Uhv --nodeps krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm
> >
> > to get around yum's dependency checking but after testing
> >
> > yum downgrade krb5-pkinit
> >
> > should be able to install the original version again. Please do not
> > forget to revert to the original version, otherwise SSSD's Kerberos
> > authentication might break because the pkinit module will print the
> > debug messages just to stdout.
> >
> > As an alternative you can just extract
> > /usr/lib64/krb5/plugins/preauth/pkinit.so with rpm2cpio from the package
> > and replace the original one. Do not forget to make a copy of the
> > original module in a different directory to be able to revert the
> > change.
> >
> > HTH
> >
> > bye,
> > Sumit
> >
>
> Thanks so much Sumit.
>
> I've upgraded that package on both the IdM server and the (problem) client.
>
> I haven't looked *really* closely at the logs or the trace output, but it
> doesn't look like I'm getting any additional output.
ok, please do not forget to replace the debug packages which the
original version.
>
> However, on a whim, went to another client. This time I went to check what
> version of krb5-pkinit was installed, and discovered it wasn't installed
> along with the rest of the ipa-client package dependencies.
>
> I installed the GA version of krb5-pkinit and it all just works!
>
> [testuser at client01-756712 ~]$ kinit -n
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_842000006
> Default principal: WELLKNOWN/ANONYMOUS at WELLKNOWN:ANONYMOUS
>
> Valid starting Expires Service principal
> 02/10/2016 23:28:46 02/11/2016 23:28:46 krbtgt/EXAMPLE.COM at EXAMPLE.COM
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$ kinit -T /tmp/krb5cc_842000006 testuser
> Enter OTP Token Value:
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$
> [testuser at client01-756712 ~]$ klist
> Ticket cache: FILE:/tmp/krb5cc_842000006
> Default principal: testuser at EXAMPLE.COM
>
> Valid starting Expires Service principal
> 02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/EXAMPLE.COM at EXAMPLE.COM
> [testuser at client01-756712 ~]$
>
> So it looks like the absence of the krb5-pkinit package was the reason why
> kinit was prompting for the WELLKNOWN/ANONYMOUS password.
that makes sense
>
> To confirm, all that is needed on the client's krb5.conf file is to have
> pkinit_anchors pointing to a copy of the belonging to the CA that was used
> to create the KDC's cert (which in our case was a self-generated one not
> freeIPA/Dogtag's one).
>
> So, I think we've got everything we need to start using it. Thanks again
> for your help.
you're welcome, glad I could help.
>
> With respect to the future plans - is there anything we need to beware of
> in terms of our manual creation of the WELLKNOWN/ANONYMOUS principal via
> "kadmin.local -x ipa-setup-override-restrictions"?
> Is freeIPA likely to have a fully-integrated anonymous PKINIT solution in
> the near future? You people have done such a great job of making the rest
yes, anonymous PKINIT somewhat felt between the cracks after some
changes to the FreeIPA CA some time ago. All the code is still there, we
just need to make sure we have a proper certificate for the KDC.
> of this stuff easy and well-documented. Hats off to the developers (and Red
> Hat for sponsoring the project).
Thank you.
bye,
Sumit
>
> Cheers,
>
> Nik
More information about the Freeipa-users
mailing list