On Thu, Feb 11, 2016 at 1:42 AM, Sumit Bose <[email protected]> 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> > > > 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 <[email protected] > > > > > 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/[email protected]' 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/[email protected] 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 [email protected]: > > > > > > WARNING: no policy specified for WELLKNOWN/[email protected] > ; > > > > > > defaulting to no policy > > > > > > add_principal: Operation requires ``add'' privilege while > creating > > > > > > "WELLKNOWN/[email protected]". > > > > > > # > > > > > > > > > > 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/[email protected] with password. > > > > kadmin.local: addprinc -randkey WELLKNOWN/ANONYMOUS > > > > WARNING: no policy specified for WELLKNOWN/[email protected]; > > > > defaulting to no policy > > > > Principal "WELLKNOWN/[email protected]" created. > > > > kadmin.local: quit > > > > # > > > > > > > > I'm no longer seeing the error from the client about 'WELLKNOWN/ > > > > [email protected]' not found in Kerberos database. > > > > > > > > However, I'm being prompted for a password for the anonymous > principal. > > > > > > > > $ kinit -n > > > > Password for WELLKNOWN/[email protected]: > > > > 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/ > > [email protected] > > [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/[email protected]: > > [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@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/[email protected] [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: [email protected] Valid starting Expires Service principal 02/10/2016 23:29:14 02/11/2016 23:29:07 krbtgt/[email protected] [testuser@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
-- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
