Re: gss_accept_sec_context fails intermittently
No to try and rain on your parade but... Wouldn't it be easier to use the standard mod_auth_kerb lib and write an apple only directory service apache module (if it doesn't already exist), and set up the auth kerb as non-authoritative? Cheers Edward On Mon, 2008-01-21 at 10:55 -0700, Nathan Mellis wrote: Greetings! I am writing a module for Apache that does Kerberos authentication as well as providing Basic authentication as a fallback and authorization via Apple's Directory Services. I have followed both Apple's sample code and the code from mod_auth_kerb and think I've got my mind wrapped around the whole process. I am running into a problem though where gss_accept_sec_context will sometimes return properly and let everything go through. Other times it will return with a major error of 851968 (Unexpected error) and a minor error of 0 (No error). Needless to say, this has me somewhat stumped. Does anyone know where else I can look to see what exactly it is not liking on the times that it fails? Thanks in advance! Nathan Mellis Application Developer Mission Aviation Fellowship [EMAIL PROTECTED] Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote: Hi, I am new to kerberos world.. so forgive my noviceness I have a KDC running on linux and my client server are also on linux.. After registering the user principals and service principals when client is connecting to server, I can see from the klist that the service ticket is generated properly. However, at the server end..after succesfully executing gss_acquire_cred(), I am failing in gss_accept_sec_context with maj_stat: 851968, min_stat: -1765328154 However, after some googling... I can see that kerberos error code goes only as far as -1765328157L... It looks like a big coincidence that we are getting that close an error to be an INCORRECT error Any pointers? Manoj From krb5.h: #define KRB5_KT_KVNONOTFOUND (-1765328154L) This indicates that the client is getting a service ticket which was produced with a key version (KVNO) that the server does not have in its keytab file. I'd assume that you did a 'ktadd' for the service and failed to update the keytab that the service is using. (Or the client has an old service ticket and the server's keytab no longer has that older version of the key.) Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote: Thanks Kevin.. that suggestion helped a lot!! when I did ktutil of my keytab file.. I had 2 entries (with KVNO 2)... I deleted the file and recreated it with ktadd but with -e option to add only one encryption type and then the accept_context worked. What is the usual practice? Should we always do ktadd with -e option? Why is it generating 2 entries when I do only ktadd (without -e) .. when in my krb5.conf there is only one encryption listed like this: [libdefaults] default_realm = EXAMPLE.IBM.COM default_keytab_name = FILE:/etc/krb5.keytab default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc ktadd does not look at those enctype definitions on the local machine where you run ktadd. What is used is the supported_enctypes defined for the realm in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. Another strange observation is that...when I add service key to keytab file via ktadd.. and then performed kinit for the service.. kinit fails like this: kinit sso_11x/lxvm-l141.ibm.com Password for sso_11x/[EMAIL PROTECTED]: kinit(v5): Password incorrect while getting initial credentials The password I provided is correct. It works only when i do kinit first followed by ktadd. The reverse is not working. What is the reason for this ? ktadd generates a new random key and puts it in both the keytab file and in the KDC's database. That key is not based on a password. In order to use the new random key with kinit, you need to specify: kinit -k -t keytab_file sso_11x/lxvm-l141.ibm.com Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
On Nov 2, 2007, at 13:54, Kevin Coffman wrote: On 11/2/07, Manoj Mohan [EMAIL PROTECTED] wrote: when I did ktutil of my keytab file.. I had 2 entries (with KVNO 2)... I deleted the file and recreated it with ktadd but with -e option to add only one encryption type and then the accept_context worked. What is the usual practice? Should we always do ktadd with -e option? Why is it generating 2 entries when I do only ktadd (without -e) .. when in my krb5.conf there is only one encryption listed like this: [libdefaults] default_realm = EXAMPLE.IBM.COM default_keytab_name = FILE:/etc/krb5.keytab default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc ktadd does not look at those enctype definitions on the local machine where you run ktadd. What is used is the supported_enctypes defined for the realm in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. We wouldn't want to look at the *default* ticket encryption types on the server anyways, but the set of supported enctypes on the server. If that list isn't being used (as specified, or the compiled-in default), in addition to the KDC-side restrictions, it's probably a bug, I think. Ken Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context
On Fri, Nov 02, 2007 at 01:54:07PM -0400, Kevin Coffman wrote: default_tkt_enctypes = des-cbc-crc default_tgs_enctypes = des-cbc-crc ktadd does not look at those enctype definitions on the local machine where you run ktadd. What is used is the supported_enctypes defined for the realm in the kdc configuration. If your service doesn't support all the enctypes listed there, then you must limit the list with the -e option when doing the ktadd. Er, it's a bit more complicated than that. kadmin ktadd without a -e argument lets kadmind pick an enctype list, namely, the supported_enctypes list (note: that's the KDC-side setting of supported_enctypes). kadmin ktadd with a -e argument specifies which enctypes to use. On Solaris 10 and up it's a bit more complicated still: without a -e argument kadmin ktadd behaves as if you had used -e with the list of permitted_enctypes (note: that's the client-side setting of permitted_enctypes). And the Solaris 10 and up kadmind uses 1DES enctypes only for clients that use the randkey-without-enctypes RPC. Bottom-line: - when doing ktadd you really want to specify what enctypes to use or else default to the *local* permitted_enctypes value, and of the enctypes you do specify, if you do, at least one should be in listed in the local permitted_enctypes; - if you're using straight MIT krb5's kadmin client then you should just always use the -e argument to ktadd, always. I think MIT should change kadmin's ktadd command to work more or less as the Solaris one does. The above applies only to ktadd, not chpass. Nico -- Kerberos mailing list Kerberos@mit.edu https://mailman.mit.edu/mailman/listinfo/kerberos
Re: gss_accept_sec_context server principal
Cesar == Cesar Garcia [EMAIL PROTECTED] writes: Cesar Hi, I'm am trying to change the behavior of a functioning Cesar GSS-enabled application server such that the server Cesar principal and corresponding keytab entry used by Cesar gss_accept_sec_context is determined dynamically based on Cesar the server principal named in the client's ticket Cesar (implicitly specified by the input token to Cesar gss_accept_sec_context). GSS_C_NO_CREDENTIAL will do this in 1.3. The patches would be mildly difficult for me to extract right now though. Kerberos mailing list [EMAIL PROTECTED] https://mailman.mit.edu/mailman/listinfo/kerberos
