I’d like to avoid having to use a second cache to armor 2FA requests. My impression was that SPAKE was supposed to fix this. I just installed a new kdc (replica of an old one) in Centos 8. It understands SPAKE, offering it as preauthebtication for normal users. But a user with 2FA is not offered SPAKE preach. I still have to use FAST.
Have I misunderstood, or is extra configuration needed?
Charles Hedrick via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
I’d like to avoid having to use a second cache to armor 2FA requests. My impression was that SPAKE was supposed to fix this. I just installed a new kdc (replica of an old one) in Centos 8. It understands SPAKE, offering it as preauthebtication for normal users. But a user with 2FA is not offered SPAKE preach. I still have to use FAST.
Have I misunderstood, or is extra configuration needed?
SPAKE is a variant preauthentication mechanism for acquiring TGTs. It is fully supported in el8. However, what you're looking for is an appropriate 2FA mechanism - currently none of those have been created yet.
What you're after is a planned future goal (but requires me to have more time to work on it :) ).
Thanks, --Robbie
Thanks. So if we’re going to continue using FAST, it would be nice to get “kinit -n” working properly.
We currently use external certificates. The KDC generates certificates for kinit -n if we don’t supply an external cert, and they work, but then I have to get them on all the clients, and update them when they expire. I’d prefer to use an external cert, which could be verified using the normal certificate infrastructure (I assume). However the MIT documentation doesn’t say how to generate a certificate request. I describe how to put the right extension in if I sign it myself but not how to get them into a cert request that an external CA can sign.
Can you point to instructions for generating an appropriate certificate request?
(At the moment I use a local program instead of kinit -n. It generates an anonymous credential cache itself. I prefer to use standard mechanisms where possible.)
On Oct 18, 2019, at 2:47 PM, Robbie Harwood rharwood@redhat.com wrote:
Charles Hedrick via FreeIPA-users freeipa-users@lists.fedorahosted.org writes:
I’d like to avoid having to use a second cache to armor 2FA requests. My impression was that SPAKE was supposed to fix this. I just installed a new kdc (replica of an old one) in Centos 8. It understands SPAKE, offering it as preauthebtication for normal users. But a user with 2FA is not offered SPAKE preach. I still have to use FAST.
Have I misunderstood, or is extra configuration needed?
SPAKE is a variant preauthentication mechanism for acquiring TGTs. It is fully supported in el8. However, what you're looking for is an appropriate 2FA mechanism - currently none of those have been created yet.
What you're after is a planned future goal (but requires me to have more time to work on it :) ).
Thanks, --Robbie
Charles Hedrick hedrick@rutgers.edu writes:
Thanks. So if we’re going to continue using FAST, it would be nice to get “kinit -n” working properly.
We currently use external certificates. The KDC generates certificates for kinit -n if we don’t supply an external cert, and they work, but then I have to get them on all the clients, and update them when they expire. I’d prefer to use an external cert, which could be verified using the normal certificate infrastructure (I assume). However the MIT documentation doesn’t say how to generate a certificate request. I describe how to put the right extension in if I sign it myself but not how to get them into a cert request that an external CA can sign.
Can you point to instructions for generating an appropriate certificate request?
(At the moment I use a local program instead of kinit -n. It generates an anonymous credential cache itself. I prefer to use standard mechanisms where possible.)
I'm not a cert expert, so hopefully someone can reply with better information. I would look at what krb5 does for its test suite, which can be seen here: https://github.com/krb5/krb5/tree/master/src/tests/dejagnu/pkinit-certs
Thanks, --Robbie
actually I found a solution to this. You can use a normal commercial cert for PKINIT. You just need a couple of extra lines in /etc/krb5.conf. The only disadvantage is that you have to have a line in /etc/krb5.conf for each KDC. That means you lose the ability to add a KDC and depend upon DNS discovery. Not a big deal in our context.
It doesn’t appear that ipa-server-certinstall -k works with a normal commercial cert, but it’s not hard to edit /var/kerberos/krb5kdc/kdc.conf to point to the cert.
On Oct 23, 2019, at 11:09 AM, Robbie Harwood via FreeIPA-users freeipa-users@lists.fedorahosted.org wrote:
Charles Hedrick hedrick@rutgers.edu writes:
Thanks. So if we’re going to continue using FAST, it would be nice to get “kinit -n” working properly.
We currently use external certificates. The KDC generates certificates for kinit -n if we don’t supply an external cert, and they work, but then I have to get them on all the clients, and update them when they expire. I’d prefer to use an external cert, which could be verified using the normal certificate infrastructure (I assume). However the MIT documentation doesn’t say how to generate a certificate request. I describe how to put the right extension in if I sign it myself but not how to get them into a cert request that an external CA can sign.
Can you point to instructions for generating an appropriate certificate request?
(At the moment I use a local program instead of kinit -n. It generates an anonymous credential cache itself. I prefer to use standard mechanisms where possible.)
I'm not a cert expert, so hopefully someone can reply with better information. I would look at what krb5 does for its test suite, which can be seen here: https://github.com/krb5/krb5/tree/master/src/tests/dejagnu/pkinit-certs
Thanks, --Robbie _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/freeipa-users@lists.fedorahoste...
freeipa-users@lists.fedorahosted.org