Hi Andrew, >Given the non-invasive nature of this patch, I'll add it without the >#ifdef. Would it be possible for you to add 'write' support to this? >(Changing the password and storing it into that keytab).
Shouldn't be too hard: note, though, we don't store the cleartext password in the keytab (although that would be possible by defining a new enctype) so it may only be useful in a limited set of circumstances. >Any chance we can implement this in our client code? This would >certainly help in testing. Do you mean "any chance I can implement this in our client code?" :-) I could certainly take a look; in the mean time, I would expect that it would ignore the AP_REP (given that Windows 2000 appears to always do mutual authentication on SMB). >Have you looked at SMB signing with this key? Or how SMB signing is >done on a kerberos connection? No. I expect SMB signing uses GSS_Wrap() and GSS_Unwrap(). This need not necessarily use an RC4 key, but the "SMB session key" (for want of a better phrase) must be an RC4 key. >> Caveats: I haven't tested for MIT compat (although I have tried to avoid >> any obvious breakage), and because ENCTYPE_ARCFOUR_HMAC_MD5 is an enum >> in Heimdal, it should really be tested for in configure... > >Yes - can you knock up such a test? OK. >> +#ifdef KV5M_ALT_METHOD >> case KRB5_KPASSWD_INITIAL_FLAG_NEEDED: >> return KRB5KDC_ERR_BADOPTION; >> /* return KV5M_ALT_METHOD; MIT-only define */ >> break; >> +#endif > >I'm not quite sure what you are doing here... KV5M_ALT_METHOD was not defined for Heimdal but, I see, you've noticed that too, I hadn't updated the patch :-) >Firstly - can we have a configure test for the Heimdal name. Secondly - >why is this restricted to the type 23 key? If we do a login without a >type 23 key, why can't we use some other session key? Or will the >client indicate what session key to use? The ticket includes a session key. The ticket session key may be used as the SMB session key for encrypting passwords in SamrSetInformationUser(), for example. >Secondly, I'm not quite sure why this isn't in kerberos_verify.c? Or if >we can also use this client-side, can you add that? It would greatly >assist in testing... I put it in clikrb5.c for portability; didn't want to put tests for MIT or Heimdal specific functionality in kerberos_verify.c >This needs to be 'False', as FALSE isn't a portable define. Ouch, I always forget that. >Doesn't the kerberos deal with the byte order? Or shouldn't we create a >asn1_write function to do this? The token ID is not ASN.1. Read RFC 1964. >Can we have a name for this magic number? A define in asn_1.h or >similar? Again, see RFC 1964. Actually, they probably shouldn't be little- endian shorts; my bad (but they certainly weren't ASN.1 booleans! :-)) Better to do: #define TOK_ID_KRB_AP_REQ "\x01\x00" #define TOK_ID_KRB_AP_REP "\x02\x00" I'll knock up another patch later today... cheers, -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com