Heimdahl Kerberos on MacOSX 10.9.5 using pkinit produces verify error

2015-08-23 Thread Glenn Machin
The MIT KDC version is 1-10-3 When I perform a kinit on MacOSX 10.9.5 (Maverick) kinit -C KEYCHAIN -D KEYCHAIN: It produces the following error on the KDC: Aug 22 19:23:35 as36snllx krb5kdc[25098]: preauth (pkinit) verify failure: error:0D08303A:asn1 encoding routines:ASN1_TEMPLATE_NOEX

Re: [EXTERNAL] Re: Heimdahl Kerberos on MacOSX 10.9.5 using pkinit produces verify error

2015-08-24 Thread Glenn Machin
2015 12:59 PM, Glenn Machin wrote (off list): >> Here is the raw packet. Let me know if there is anything else I can do. > I am unfortunately not able to duplicate the error in my setup using > either krb5 1.10.x or the master branch, sending this exact packet to > the KDC. If I te

Re: [EXTERNAL] Re: Heimdahl Kerberos on MacOSX 10.9.5 using pkinit produces verify error

2015-08-25 Thread Glenn Machin
I find. Glenn On 8/25/15 8:41 AM, Greg Hudson wrote: > On 08/25/2015 12:50 AM, Glenn Machin wrote: >> Looks like it is an openssl issue, apparently fixed in version 1.0.1f >> . Seems I asked a similar question then and found this on the >> krb5-bugs list - >> http:

MacOSX 10.6 pkinit problem with 1.8.3 KDC

2010-12-18 Thread Glenn Machin
I am testing MacOSX 10.6 pkinit capabilities using a PIV card per the attached Apple pkinit configuration document. When I test against the MIT 1.8.3 KDC using the command: /System/Library/PrivateFrameworks/Heimdal.framework/Helpers/kinit -C KEYCHAIN: -D KEYCHAIN: The MIT 1.8.3 KDC fails with

Re: Help: Why SSL must be enabled when using mod_auth_kerb in httpd?

2011-03-05 Thread Glenn Machin
You might want to take a look at whether replay is a factor. Mod_auth_kerb I believe handles both Basic and Negotiate (SPNEGO) authentication. If using Basic where the Kerberos password is passed over base64 encoded in the HTTP header, you are disclosing the Kerberos password. If you are using

Re: [EXTERNAL] Rate limiting Kerberos Requests

2012-09-25 Thread Glenn Machin
A performance issue we have seen has to do when a KDC has a heavy load and cannot provide a response within 1 sec. The Kerberos client libraries apparently expect a response within a sec and if they don't get it they move on to the next KDC in the list for the realm and so on for both udp and tc