<div dir="ltr">On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose <<a href="mailto:sbose@redhat.com" target="_blank">sbose@redhat.com</a>> wrote: <div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class=""><div class="h5">On Wed, Feb 10, 2016 at 11:07:14PM +1100, Nik Lam wrote: > On Wed, Feb 10, 2016 at 7:43 PM, Sumit Bose <<a href="mailto:sbose@redhat.com">sbose@redhat.com</a>> 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 <<a href="mailto:sbose@redhat.com">sbose@redhat.com</a>> 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 <<a href="mailto:sbose@redhat.com">sbose@redhat.com</a>> > > 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 <<a href="mailto:sbose@redhat.com">sbose@redhat.com</a>> > > 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 > > > > > > > > > > > > > > > > > > > > <a href="http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html" rel="noreferrer" target="_blank">http://web.mit.edu/kerberos/krb5-1.14/doc/admin/pkinit.html</a> > > > > > > > > > > > > > > > > > > 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/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>' 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/<a href="mailto:admin@EXAMPLE.COM">admin@EXAMPLE.COM</a> 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 <a href="mailto:admin@EXAMPLE.COM">admin@EXAMPLE.COM</a>: > > > > > WARNING: no policy specified for WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>; > > > > > defaulting to no policy > > > > > add_principal: Operation requires ``add'' privilege while creating > > > > > "WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>". > > > > > # > > > > > > > > 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/<a href="mailto:admin@EXAMPLE.COM">admin@EXAMPLE.COM</a> with password. > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > > WARNING: no policy specified for WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>; > > > defaulting to no policy > > > Principal "WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>" created. > > > kadmin.local: quit > > > # > > > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > > <a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>' not found in Kerberos database. > > > > > > However, I'm being prompted for a password for the anonymous principal. > > > > > > $ kinit -n > > > Password for WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>: > > > 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/ > <a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a> > [9199] 1455105392.575132: Sending request (186 bytes) to <a href="http://EXAMPLE.COM" rel="noreferrer" target="_blank">EXAMPLE.COM</a> > [9199] 1455105392.575314: Initiating TCP connection to stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105392.576513: Sending TCP request to stream <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105393.370873: Received answer (483 bytes) from stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105393.370885: Terminating TCP connection to stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [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 </div></div>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? <div><div class="h5"> > [9199] 1455105393.371040: Selected etype info: etype aes256-cts, salt > "EXAMPLE.COMWELLKNOWNANONYMOUS", params "" > [9199] 1455105393.371046: Received cookie: MIT > Password for WELLKNOWN/<a href="mailto:ANONYMOUS@EXAMPLE.COM">ANONYMOUS@EXAMPLE.COM</a>: > [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 <a href="http://EXAMPLE.COM" rel="noreferrer" target="_blank">EXAMPLE.COM</a> > [9199] 1455105400.912674: Initiating TCP connection to stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105400.913894: Sending TCP request to stream <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105400.937778: Received answer (197 bytes) from stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [9199] 1455105400.937788: Terminating TCP connection to stream > <a href="http://10.93.178.73:88" rel="noreferrer" target="_blank">10.93.178.73:88</a> > [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. </div></div>Please find the package with debugging enabled at <a href="https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm" rel="noreferrer" target="_blank">https://kojipkgs.fedoraproject.org//work/tasks/8127/12928127/krb5-pkinit-1.13.2-10.el7sb.x86_64.rpm</a> 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. <div class=""><div> HTH bye, Sumit </div></div></blockquote><div> </div><div>Thanks so much Sumit. </div><div>I've upgraded that package on both the IdM server and the (problem) client. </div><div>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. </div><div>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. </div><div>I installed the GA version of krb5-pkinit and it all just works! </div><div> [testuser@client01-756712 ~]$ kinit -n [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_842000006 Default principal: WELLKNOWN/ANONYMOUS@WELLKNOWN:ANONYMOUS Valid starting Expires Service principal 02/10/2016 23:28:46 02/11/2016 23:28:46 krbtgt/<a href="mailto:EXAMPLE.COM@EXAMPLE.COM">EXAMPLE.COM@EXAMPLE.COM</a> [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ kinit -T /tmp/krb5cc_842000006 testuser Enter OTP Token Value: [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ [testuser@client01-756712 ~]$ klist Ticket cache: FILE:/tmp/krb5cc_842000006 Default principal: <a href="mailto:testuser@EXAMPLE.COM">testuser@EXAMPLE.COM</a> Valid starting Expires Service principal 02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/<a href="mailto:EXAMPLE.COM@EXAMPLE.COM">EXAMPLE.COM@EXAMPLE.COM</a> [testuser@client01-756712 ~]$ </div><div>So it looks like the absence of the krb5-pkinit package was the reason why kinit was prompting for the WELLKNOWN/ANONYMOUS password. </div><div>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). </div><div> </div><div>So, I think we've got everything we need to start using it. Thanks again for your help. </div><div>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). </div><div>Cheers, Nik </div><div> </div></div> </div></div>