[Freeipa-users] PKINIT support in FreeIPA 4.2.0
Nik Lam
nik.eb.inc at gmail.com
Thu Feb 11 00:16:14 UTC 2016
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.
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.
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.
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
of this stuff easy and well-documented. Hats off to the developers (and Red
Hat for sponsoring the project).
Cheers,
Nik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/freeipa-users/attachments/20160211/1e989e2a/attachment.htm>
More information about the Freeipa-users
mailing list