From ghudson at MIT.EDU Thu Oct 1 11:22:38 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Thu, 1 Oct 2009 11:22:38 -0400 (EDT) Subject: Little conveniences Message-ID: <200910011522.n91FMcLM003199@outgoing.mit.edu> As part of the encryption performance work, I'm finding myself dearly wanting a couple of internal conveniences. So, these are likely to hit k5-int.h in the trunk in the next few weeks. First: static inline void zapfree(void *ptr, size_t len) { if (ptr) { zap(ptr, len); free(ptr); } } This builds on the existing zap() macro or function. Particularly in the crypto code, it avoids the need for a lot of repeated four-line cleanups. Second: /* Allocate zeroed memory; set *code to 0 on success or ENOMEM on failure. */ static inline void *k5alloc(size_t size, krb5_error_code *code) { void *ptr; ptr = calloc(size, 1); *code = (ptr == NULL) ? ENOMEM : 0; return ptr; } This is to save three lines in the (very common) allocate/check/error pattern used all over the code. With k5alloc that can be three lines instead of five: ptr = k5alloc(size, &ret); if (!ptr) goto cleanup; The downside is that everyone knows what malloc() does, but not everyone will immediately know what k5alloc does. It also uses krb5_error_code in a funny way, since the more common construction ("ret = k5alloc(size, &ptr);") can't be written as a C function due to the way C void pointers work. So I'm not 100% pleased with this one. But the alternative is to spend an awful lot of code space when allocating multiple chunks of memory, as is commonly done in the crypto code. From jhutz at cmu.edu Thu Oct 1 12:55:35 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Thu, 01 Oct 2009 12:55:35 -0400 Subject: Little conveniences In-Reply-To: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> Message-ID: <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> --On Thursday, October 01, 2009 11:22:38 AM -0400 ghudson at mit.edu wrote: > The downside is that everyone knows what malloc() does, but not > everyone will immediately know what k5alloc does. It also uses > krb5_error_code in a funny way, since the more common construction > ("ret = k5alloc(size, &ptr);") can't be written as a C function due to > the way C void pointers work. Huh? What's wrong with this? static inline krb5_error_code k5alloc(size_t size, void **ptrp) { *ptrp = calloc(size, 1); return (*ptrp == NULL) ? ENOMEM : 0; } -- Jeff From ghudson at MIT.EDU Thu Oct 1 13:04:28 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 01 Oct 2009 13:04:28 -0400 Subject: Little conveniences In-Reply-To: <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> Message-ID: <1254416668.14544.74.camel@ray> On Thu, 2009-10-01 at 12:55 -0400, Jeffrey Hutzelman wrote: > Huh? What's wrong with this? > > static inline krb5_error_code k5alloc(size_t size, void **ptrp) > { > *ptrp = calloc(size, 1); > return (*ptrp == NULL) ? ENOMEM : 0; > } First and probably foremost, you'd have to cast the address of every pointer you passed in, or you'd get a compiler warning. That's uglier than switching around the return pointer and error code. Second, even with the casts, it wouldn't be correct C. C (the standardized language) does not assume that all pointer types are represented equally. When you write "charptr = voidptr;" you give the compiler an option to add code to convert the pointer representations. When you cast &charptr to a void ** and assign through that, you do not. Of course, it works fine in C (the language we actually use on platforms anyone has ever heard of) because in reality all pointer types are usually represented equally. From paul.moore at centrify.com Thu Oct 1 13:29:35 2009 From: paul.moore at centrify.com (Paul Moore) Date: Thu, 1 Oct 2009 10:29:35 -0700 Subject: Little conveniences In-Reply-To: <1254416668.14544.74.camel@ray> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu><1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> Message-ID: or even static inline void k5alloc(size_t size) { return calloc(size, 1); } since the results is either good or ENOMEM, there not a lot of point in returning the failure reason or simply #define k5alloc(sz) calloc(sz,1) -----Original Message----- From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Greg Hudson Sent: Thursday, October 01, 2009 10:04 AM To: Jeffrey Hutzelman Cc: krbdev at mit.edu Subject: Re: Little conveniences On Thu, 2009-10-01 at 12:55 -0400, Jeffrey Hutzelman wrote: > Huh? What's wrong with this? > > static inline krb5_error_code k5alloc(size_t size, void **ptrp) > { > *ptrp = calloc(size, 1); > return (*ptrp == NULL) ? ENOMEM : 0; > } First and probably foremost, you'd have to cast the address of every pointer you passed in, or you'd get a compiler warning. That's uglier than switching around the return pointer and error code. Second, even with the casts, it wouldn't be correct C. C (the standardized language) does not assume that all pointer types are represented equally. When you write "charptr = voidptr;" you give the compiler an option to add code to convert the pointer representations. When you cast &charptr to a void ** and assign through that, you do not. Of course, it works fine in C (the language we actually use on platforms anyone has ever heard of) because in reality all pointer types are usually represented equally. _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From raeburn at MIT.EDU Thu Oct 1 14:39:24 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Thu, 1 Oct 2009 14:39:24 -0400 Subject: Little conveniences In-Reply-To: References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu><1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> Message-ID: On Oct 1, 2009, at 13:29, Paul Moore wrote: > or even > > static inline void k5alloc(size_t size) > { > return calloc(size, 1); > } > > since the results is either good or ENOMEM, there not a lot of point > in > returning the failure reason I assume part of the idea was to avoid doing the ENOMEM setting explicitly at every call site. I'll note, though, that a NULL return value may not mean failure, if the requested size was zero. Open-coding that additional check, at every call site that hasn't been checked to ensure that zero couldn't be passed in, would also be annoying. If zero-sized allocations are allowed and aren't adjusted to allocate at least one byte, then the caller needs to check the error code and not the pointer, in the general case; certainly there will be a number of calls where zero can't be passed. Ken From remi.ferrand at cc.in2p3.fr Fri Oct 2 04:57:24 2009 From: remi.ferrand at cc.in2p3.fr (Remi Ferrand) Date: Fri, 02 Oct 2009 10:57:24 +0200 Subject: Ticket Granting Ticket forge Message-ID: <4AC5C074.6070805@cc.in2p3.fr> Hye, I'm working with MIT Kerberos5 1.6.3 I would like to be able to refresh an existing TGT on my local machine, without using the KDC. My first idea was to decrypt the TGT, modifying its informations (start time, end time, renewable time) and encrypt it again. Is it possible ? Which key of the KDC do I need to do this little hack ? (the Master Key K/M at REALM ?) I'm reading the source code of the subdir src/kdc/ and especially do_tgs_req.c. I hope it could work ... Thanks in advance Remi -- Remi Ferrand | Institut National de Physique Nucleaire Tel. +33(0)4.78.93.08.80 | et de Physique des Particules Fax. +33(0)4.72.69.41.70 | Centre de Calcul - http://cc.in2p3.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4055 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091002/8307a86c/smime.bin From raeburn at MIT.EDU Fri Oct 2 07:23:33 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Fri, 2 Oct 2009 07:23:33 -0400 Subject: Ticket Granting Ticket forge In-Reply-To: <4AC5C074.6070805@cc.in2p3.fr> References: <4AC5C074.6070805@cc.in2p3.fr> Message-ID: <96013C9E-3A1D-46CA-A25D-0DADB9D9DA73@mit.edu> On Oct 2, 2009, at 04:57, Remi Ferrand wrote: > I'm working with MIT Kerberos5 1.6.3 > > I would like to be able to refresh an existing TGT on my local > machine, without using the KDC. > > My first idea was to decrypt the TGT, modifying its informations > (start time, end time, renewable time) and encrypt it again. > > Is it possible ? > Which key of the KDC do I need to do this little hack ? (the Master > Key K/M at REALM ?) You would need the key for the krbtgt/YOUR.REALM at YOUR.REALM principal in order to do this. In fact, with that key, you can forge a TGT for any client principal at all, without needing an existing TGT, so if anyone else gets their hands on it, your realm's security is compromised. So unless your local machine is secure enough that you could run a KDC on it, this would be a really bad idea. And even then, running a KDC as root is probably a better idea than leaving the TGS key sitting around accessible under your regular account. Ken From remi.ferrand at cc.in2p3.fr Fri Oct 2 12:58:23 2009 From: remi.ferrand at cc.in2p3.fr (Remi Ferrand) Date: Fri, 02 Oct 2009 18:58:23 +0200 Subject: Ticket Granting Ticket forge In-Reply-To: <96013C9E-3A1D-46CA-A25D-0DADB9D9DA73@mit.edu> References: <4AC5C074.6070805@cc.in2p3.fr> <96013C9E-3A1D-46CA-A25D-0DADB9D9DA73@mit.edu> Message-ID: <4AC6312F.8040305@cc.in2p3.fr> Ken Raeburn a ?crit : > You would need the key for the krbtgt/YOUR.REALM at YOUR.REALM principal > in order to do this. In fact, with that key, you can forge a TGT for > any client principal at all, without needing an existing TGT, so if > anyone else gets their hands on it, your realm's security is > compromised. So unless your local machine is secure enough that you > could run a KDC on it, this would be a really bad idea. And even > then, running a KDC as root is probably a better idea than leaving the > TGS key sitting around accessible under your regular account. > > Ken I'm sure I'm very close of my goal, but it's still not working ... My KeyTab has been created using : # kadmin.local -q 'ktadd -k /tmp/krbtgt.keytab -norandkey krbtgt/TEST.IN2P3.FR at TEST.IN2P3.FR' My Cache has been feed with # kinit test # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: test at TEST.IN2P3.FR Valid starting Expires Service principal 10/02/09 18:15:12 10/03/09 04:15:12 krbtgt/TEST.IN2P3.FR at TEST.IN2P3.FR renew until 10/03/09 18:15:11 I've written a little program to try to decrypt the TGT. This program is compiler using those libraries : /-lkrb5 -lkadm5srv -lkadm5clnt -lkdb5/ The main steps are : * read Keytab using krb5_kt_resolve, krb5_kt_start_seq_get, krb5_kt_next_entry, krb5_kt_end_seq_get. This step gives me a krb5_keytab_entry structure. * retrieve TGT from Ticket Cache using krb5_cc_default, krb5_cc_set_flags, krb5_cc_start_seq_get, krb5_cc_next_cred. This step gives me a krb5_creds structure. * My program then try to decode_ticket using krb5_decode_ticket and everything is successful. * The next step is to decrypt the TGT ticket with krb5_decrypt_tkt_part, but I encounter an error of this kind : *forge: Program lacks support for encryption type decrypting with krb5_decrypt_tkt_part* Debuging using GDB ensures me that krbtgt entry read from KeyTab has an enctype of 16 (Triple DES cbc mode with HMAC/sha1) and the same enctype for the ticket granting ticket krbtgt read from cache. Does anyone already encounter this kind of error using Kerberos V M.I.T API ? Do I have to load ciphers anywhere ? If you want me to send you my code, juste ask and I'll send you ... The main part of my code has been inspired from kinit or src/kdc/* utilities. Thanks in advance Remi -- Remi Ferrand | Institut National de Physique Nucleaire Tel. +33(0)4.78.93.08.80 | et de Physique des Particules Fax. +33(0)4.72.69.41.70 | Centre de Calcul - http://cc.in2p3.fr/ -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 4055 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091002/1a923958/smime.bin From pgp at psu.edu Fri Oct 2 16:01:49 2009 From: pgp at psu.edu (Phil Pishioneri) Date: Fri, 02 Oct 2009 16:01:49 -0400 Subject: Kerberos for Windows (kfw) and GSS-API in native 64 bit In-Reply-To: References: Message-ID: <4AC65C2D.1040903@psu.edu> On 9/30/09 4:00 PM, Tom Yu wrote: > There is an alpha release of kfw-3.2.3 that supports amd64. Please > try it and let us know if it suits your needs: > > http://web.mit.edu/kerberos/dist/testing.html > Does this alpha fix the problem mentioned below (related to the wrong header file)? > -------- Original Message -------- > Subject: Re: How do I use KfW kinit.exe with respect to the Windows > credentials cache? > Date: Wed, 29 Jul 2009 09:10:27 -0400 > From: Jeffrey Altman > To: Henry B.Hotz > CC: krbdev at mit.edu > > > ... > Beginning with Vista/2008 there is a new API that permits a ticket to be > forwarded to the LSA from third party applications. However, the > question indicated the platform is XP and the relevant functionality is > not available there. Even on platforms that do support this > functionality it cannot be used by KfW because MIT's build of the MSLSA: > support was made with the wrong ntsecapi.h header file version and as a > result the support was disabled. > -Phil From tlyu at MIT.EDU Fri Oct 2 16:12:39 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 02 Oct 2009 16:12:39 -0400 Subject: Kerberos for Windows (kfw) and GSS-API in native 64 bit In-Reply-To: <4AC65C2D.1040903@psu.edu> (Phil Pishioneri's message of "Fri, 2 Oct 2009 16:01:49 -0400") References: <4AC65C2D.1040903@psu.edu> Message-ID: Phil Pishioneri writes: > On 9/30/09 4:00 PM, Tom Yu wrote: >> There is an alpha release of kfw-3.2.3 that supports amd64. Please >> try it and let us know if it suits your needs: >> >> http://web.mit.edu/kerberos/dist/testing.html >> > > Does this alpha fix the problem mentioned below (related to the wrong > header file)? A newer SDK was used, so the "wrong ntsecapi.h header file" MSLSA ccache problem is not present. > >> -------- Original Message -------- >> Subject: Re: How do I use KfW kinit.exe with respect to the Windows >> credentials cache? >> Date: Wed, 29 Jul 2009 09:10:27 -0400 >> From: Jeffrey Altman >> To: Henry B.Hotz >> CC: krbdev at mit.edu >> >> >> ... >> Beginning with Vista/2008 there is a new API that permits a ticket to be >> forwarded to the LSA from third party applications. However, the >> question indicated the platform is XP and the relevant functionality is >> not available there. Even on platforms that do support this >> functionality it cannot be used by KfW because MIT's build of the MSLSA: >> support was made with the wrong ntsecapi.h header file version and as a >> result the support was disabled. >> > > -Phil From dalmeida at MIT.EDU Sat Oct 3 18:59:54 2009 From: dalmeida at MIT.EDU (Danilo Almeida) Date: Sat, 3 Oct 2009 15:59:54 -0700 Subject: Little conveniences In-Reply-To: <1254416668.14544.74.camel@ray> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> Message-ID: <032301ca447d$3dca4f70$b95eee50$@edu> Greg, Wrt the out pointer argument casting issues, you can do something like this: #define k5alloc(Size, PointerToPointer) \ ( !((*(PointerToPointer)) = calloc(Size, 1)) ? ENOMEM : 0 ) For C++, you need a cast in there, so a template does the trick: template int k5alloc(size_t Size, T* PointerToPointer) { return ( !((*(PointerToPointer)) = (T) calloc(Size, 1)) ? ENOMEM : 0 ); } Then you can always just do: ret = k5alloc(sizeof(foo), &foo); if (ret) ... - Danilo From ghudson at MIT.EDU Sun Oct 4 20:25:24 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Sun, 04 Oct 2009 20:25:24 -0400 Subject: Little conveniences In-Reply-To: <032301ca447d$3dca4f70$b95eee50$@edu> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> <032301ca447d$3dca4f70$b95eee50$@edu> Message-ID: <1254702324.14544.107.camel@ray> On Sat, 2009-10-03 at 18:59 -0400, Danilo Almeida wrote: > Wrt the out pointer argument casting issues, you can do something like this: > > #define k5alloc(Size, PointerToPointer) \ > ( !((*(PointerToPointer)) = calloc(Size, 1)) ? ENOMEM : 0 ) [...] > ret = k5alloc(sizeof(foo), &foo); Yeah, I was careful to say that it's not possible to write as a C function; it would be possible as a macro. (Even, as you illustrate, a macro using each of the arguments only once.) I'm a little reluctant to introduce a construction which can only be defined as a macro, but if people think it's worth that price to keep the order consistent, I'll switch it around. From dalmeida at MIT.EDU Mon Oct 5 03:05:45 2009 From: dalmeida at MIT.EDU (Danilo Almeida) Date: Mon, 5 Oct 2009 00:05:45 -0700 Subject: Little conveniences In-Reply-To: <1254702324.14544.107.camel@ray> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> <032301ca447d$3dca4f70$b95eee50$@edu> <1254702324.14544.107.camel@ray> Message-ID: <035101ca458a$437eb060$ca7c1120$@edu> Greg, > I'm a little reluctant to introduce a construction which can only be > defined as a macro, but if people think it's worth that price to keep > the order consistent, I'll switch it around. I'm curious, what is your concern? My understanding is that this is part of the internal API, so there is no ABI concern. If there were, I would want an allocation function. But in that case, I would just have a k5alloc_zero() or something like that and then have k5alloc() just be a macro on top of that. As I see it, the macro is simply a convenience on top of the raw API. Also, since this would only be present in the internal headers, it would not introduce any changes to the public API. Not being aware of any other issues, I would certainly vote for the consistency of having a krb5 error returned ask making the using code simpler. - Danilo From jmontmartin at gmail.com Mon Oct 5 03:58:18 2009 From: jmontmartin at gmail.com (Julien Montmartin) Date: Mon, 5 Oct 2009 09:58:18 +0200 Subject: Kerberos for Windows (kfw) and GSS-API in native 64 bit In-Reply-To: References: Message-ID: >2009/9/30 Tom Yu > >>Julien Montmartin writes: >> >> That's where I need some help : my implementation must support linking in >> native 64 bit. Dealing with 64 bit support, the kfw-3.2.2 release notes say > >There is an alpha release of kfw-3.2.3 that supports amd64. Please >try it and let us know if it suits your needs: > > http://web.mit.edu/kerberos/dist/testing.html Although I spent some time on the MIT/Kerberos website and docs, I totally missed it ! It solves my compiling/linking problems. Thanks a lot ! From raeburn at MIT.EDU Mon Oct 5 08:16:55 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 5 Oct 2009 08:16:55 -0400 Subject: Little conveniences In-Reply-To: <035101ca458a$437eb060$ca7c1120$@edu> References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> <032301ca447d$3dca4f70$b95eee50$@edu> <1254702324.14544.107.camel@ray> <035101ca458a$437eb060$ca7c1120$@edu> Message-ID: On Oct 5, 2009, at 03:05, Danilo Almeida wrote: > My understanding is that this is part of the internal API, so there > is no > ABI concern. If there were, I would want an allocation function. > But in > that case, I would just have a k5alloc_zero() or something like that > and > then have k5alloc() just be a macro on top of that. As I see it, > the macro > is simply a convenience on top of the raw API. Also, since this > would only > be present in the internal headers, it would not introduce any > changes to > the public API. Not being aware of any other issues, I would > certainly vote > for the consistency of having a krb5 error returned ask making the > using > code simpler. Where the current "spec" seems to require checking the error code on each call, and the style guide doesn't allow such constructs as if ((ptr = k5alloc(sz, &err)) == NULL && sz > 0) return err; anyways, I'm not sure it matters much in terms of convenience. But returning the pointer is consistent too -- with system allocation routines we're mimicking. I don't see a strong argument either way. I guess my preference would be very mildly in favor of returning the pointer, though I think there's also a performance argument to be made for returning the error code. I'm more concerned about the zero-size- allocation issue I brought up before... If you're considering going with forms that require macros, you might consider taking it a bit further: #define k5new(TYPE,NUM,ERR) ((TYPE *)k5calloc(NUM,sizeof(TYPE),&(ERR))) (or the error-code-returning equivalent), similar to C++'s new[] operator. (With the hypothetical "k5calloc" doing overflow checking, zero-size checking, etc.) The size specifications will usually involve "sizeof" anyways when you're not allocating a buffer of bytes or a string, and providing the type rather than its size adds to type safety checking at compile time via the cast. Some types like krb5_data and krb5_keyblock encapsulate buffers without fixed sizes, but helper functions/macros can create those fully initialized while hiding the signedness specification headaches of the internal buffer pointer types; k5buf and strdup deal with a lot of the string and buffer manipulations. Ken From hartmans at MIT.EDU Mon Oct 5 12:02:04 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 05 Oct 2009 12:02:04 -0400 Subject: Little conveniences In-Reply-To: <1254702324.14544.107.camel@ray> (Greg Hudson's message of "Sun\, 04 Oct 2009 20\:25\:24 -0400") References: <27025_1254410638_n91FNviJ026214_200910011522.n91FMcLM003199@outgoing.mit.edu> <1A9EA2D3C804D154459F1E70@atlantis.pc.cs.cmu.edu> <1254416668.14544.74.camel@ray> <032301ca447d$3dca4f70$b95eee50$@edu> <1254702324.14544.107.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> Yeah, I was careful to say that it's not possible to write as a C Greg> function; it would be possible as a macro. (Even, as you illustrate, a Greg> macro using each of the arguments only once.) I'm a little reluctant to Greg> introduce a construction which can only be defined as a macro, but if Greg> people think it's worth that price to keep the order consistent, I'll Greg> switch it around. My preference is to avoid introducing macros when we can and I don't see that the order is problematic. So I prefer your first approach. From ghudson at MIT.EDU Wed Oct 7 11:56:01 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 07 Oct 2009 11:56:01 -0400 Subject: Lockout In-Reply-To: References: Message-ID: <1254930961.9616.98.camel@ray> A few weeks ago, I asked Luke to think about whether it is really necessary to add a "lockout time" attribute for the purposes of account lockout. Because the lockout time attribute is new (the other three attributes already exist in the DB schema), it adds additional code complexity because it must be represented in TL data. My idea is that you can deduce whether the account is locked out from the fail count, and can determine the time of lockout from the last preauth failure time. I believe I mostly have Luke convinced, but we agreed that I should bring the issue up for discussion here before he does the work of simplifying the code. Note that this change causes lockout state to be dynamically derived from the policy. As a result: 1. If you increase the number of allowed failures in the policy, locked accounts will become unlocked. 2. If you decrease the number of allowed failures in the policy, unlocked accounts which have received failures could become locked. (However, note that any affected accounts were only "unlocked" in some theoretical sense. Successful preauth attempts reset the failure count, so no user could have observed the fact that his or her account was unlocked before the policy change.) I could see (1) used to justify the addition of a new field, but I still don't think it's worth the complexity. I don't think (2) is a concern. The new pseudo-code prior to the preauth check would be: if (entry.fail_auth_count >= policy.max_fail && (policy.lockout_duration == 0 || now < entry.last_failed + policy.lockout_duration)) result ::= CLIENT_REVOKED and after the preauth check: if ( preauth_success ) { entry.fail_auth_count ::= 0 entry.last_success ::= now } else if ( preauth_failure ) { if (policy.failcnt_interval != 0 && now > entry.last_failed + policy.failcnt_interval) { /* automatically reset fail_auth_count after failcnt_interval */ entry.fail_auth_count ::= 0 } entry.last_failed ::= now entry.fail_auth_count ::= entry.fail_auth_count + 1 } On Tue, 2009-09-15 at 14:56 -0400, Luke Howard wrote: > For review: > > http://k5wiki.kerberos.org/wiki/Projects/Lockout > > Note: code is not well tested (in case of LDAP, untested). > > -- Luke > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From ghudson at MIT.EDU Wed Oct 7 12:51:44 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 07 Oct 2009 12:51:44 -0400 Subject: Lockout In-Reply-To: <07905DB1-8863-45CC-8921-51F99DC748E4@padl.com> References: <1254930961.9616.98.camel@ray> <07905DB1-8863-45CC-8921-51F99DC748E4@padl.com> Message-ID: <1254934304.9616.113.camel@ray> On Wed, 2009-10-07 at 12:13 -0400, Luke Howard wrote: > > 1. If you increase the number of allowed failures in the policy, > > locked accounts will become unlocked. > > Also, are there any interactions with pw_failcnt_interval that need to > be considered? (This is the time after which the bad preauthentication > count is reset; this is independent of pw_lockout_duration, which is > the period in which lockout is enforced.) > > Do these become one and the same? Does this change the semantics of > the lockout policy? No, they do not become one and the same. The lockout duration applies if the account has already seen the allowed number of failures (i.e. the account is locked); the failcnt interval applies otherwise. The semantics of a static lockout policy do not change. The interactions with a changing pw_failcnt_interval are not altered; pw_failcnt_interval is consulted in exactly the same ways as it is currently. From lhoward at MIT.EDU Wed Oct 7 12:38:24 2009 From: lhoward at MIT.EDU (Luke Howard) Date: Wed, 7 Oct 2009 18:38:24 +0200 Subject: Fwd: Lockout References: <07905DB1-8863-45CC-8921-51F99DC748E4@padl.com> Message-ID: [resent; MIT is rejecting lukeh at padl.com] Begin forwarded message: > From: Luke Howard > Date: 7 October 2009 6:13:22 PM GMT+02:00 > To: Greg Hudson > Cc: MIT Kerberos Dev List > Subject: Re: Lockout > >> 1. If you increase the number of allowed failures in the policy, >> locked accounts will become unlocked. > > Also, are there any interactions with pw_failcnt_interval that need > to be considered? (This is the time after which the bad > preauthentication count is reset; this is independent of > pw_lockout_duration, which is the period in which lockout is > enforced.) > > Do these become one and the same? Does this change the semantics of > the lockout policy? > > -- Luke From lhoward at MIT.EDU Wed Oct 7 15:02:25 2009 From: lhoward at MIT.EDU (Luke Howard) Date: Wed, 7 Oct 2009 21:02:25 +0200 Subject: Lockout In-Reply-To: <1254930961.9616.98.camel@ray> References: <1254930961.9616.98.camel@ray> Message-ID: <61920D53-4B69-49B4-ADA7-2689E0238D39@mit.edu> > I believe I mostly have Luke convinced, but we agreed that I should > bring the issue up for discussion here before he does the work of > simplifying the code. One argument I had in favour of maintaining a separate lockout time which I will submit here for completeness, is consistency with the LDAP password policy draft and the Active Directory security model. -- Luke From raeburn at MIT.EDU Wed Oct 7 21:34:56 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 7 Oct 2009 21:34:56 -0400 Subject: Lockout In-Reply-To: <1254930961.9616.98.camel@ray> References: <1254930961.9616.98.camel@ray> Message-ID: <7F7175D7-4453-44D6-90D4-46A75ED8AE38@mit.edu> On Oct 7, 2009, at 11:56, Greg Hudson wrote: > Note that this change causes lockout state to be dynamically derived > from the policy. As a result: > [...] > I could see (1) used to justify the addition of a new field, but I > still > don't think it's worth the complexity. I don't think (2) is a > concern. (1) seems perfectly reasonable to me, unless there's some specific real-world end user case you've got in mind that requires it not to happen that way. Ken From raeburn at MIT.EDU Wed Oct 7 22:00:22 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Wed, 7 Oct 2009 22:00:22 -0400 Subject: svn rev #22866: trunk/src/lib/crypto/krb/ In-Reply-To: <200910071814.n97IEoXo016666@drugstore.mit.edu> References: <200910071814.n97IEoXo016666@drugstore.mit.edu> Message-ID: <7752B5FA-D853-41B6-AAE9-E460A9F6FC37@mit.edu> On Oct 7, 2009, at 14:14, ghudson at MIT.EDU wrote: > Log Message: > In krb5_c_make_checksum, avoid the structure copy of *input since we > don't care about input->magic. Squashes a bunch of unimportant > Coverity defects. So Coverity cares about uninitialized (I assume) fields in structure copies? Then for consistency, shouldn't our coding standards specify either never doing structure copies (ick), or always initializing the magic number fields? Ken From ghudson at MIT.EDU Thu Oct 8 00:17:19 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 08 Oct 2009 00:17:19 -0400 Subject: svn rev #22866: trunk/src/lib/crypto/krb/ In-Reply-To: <7752B5FA-D853-41B6-AAE9-E460A9F6FC37@mit.edu> References: <200910071814.n97IEoXo016666@drugstore.mit.edu> <7752B5FA-D853-41B6-AAE9-E460A9F6FC37@mit.edu> Message-ID: <1254975439.9616.136.camel@ray> On Wed, 2009-10-07 at 22:00 -0400, Ken Raeburn wrote: > On Oct 7, 2009, at 14:14, ghudson at MIT.EDU wrote: > > Log Message: > > In krb5_c_make_checksum, avoid the structure copy of *input since we > > don't care about input->magic. Squashes a bunch of unimportant > > Coverity defects. > > So Coverity cares about uninitialized (I assume) fields in structure > copies? Then for consistency, shouldn't our coding standards specify > either never doing structure copies (ick), or always initializing the > magic number fields? This was a case-by-case decision; we had over a dozen places in the code which weren't initializing the structure field, but only one structure copy. I don't know what to make of the magic fields in krb5. As a general C programming concept, they never really caught on. Within the krb5 code base, we rarely check them (killing any safety advantage) and set them haphazardly. We can't generally add checks without breaking the API. Mostly they just get in the way of doing structure copies without irritating static analysis tools. If we do want to clean up all of the krb5_data initializations so that we can do structure copies, perhaps a "data_init" helper would make it more palatable. We could have similar helpers for other small structures like krb5_octet_data and krb5_enc_data. From john at iastate.edu Thu Oct 8 07:47:24 2009 From: john at iastate.edu (John Hascall) Date: Thu, 08 Oct 2009 06:47:24 CDT Subject: Lockout In-Reply-To: Your message of Wed, 07 Oct 2009 11:56:01 -0400. <1254930961.9616.98.camel@ray> Message-ID: <26985.1255002444@malison.ait.iastate.edu> > A few weeks ago, I asked Luke to think about whether it is really > necessary to add a "lockout time" attribute for the purposes of account > lockout. Because the lockout time attribute is new (the other three > attributes already exist in the DB schema), it adds additional code > complexity because it must be represented in TL data. My idea is that > you can deduce whether the account is locked out from the fail count, > and can determine the time of lockout from the last preauth failure > time. Our implementation of lockout-n-release does not keep a lockout time, it imputes the state from lastfailtime and failcount. It looks like one thing we do differently is we keep counting failures (it looks like you stop an the lockout limit?) For example, given settings: 5-fails and 1 minute release, we would do: fail 1 fail 2 fail 3 fail 4 fail 5 (locked out) return fail for all attempts for 1 minute, but otherwise ignore fail 6 (unlocked as the minute is up) fail 7 fail 8 fail 9 fail 10 (locked out) return fail for all attempts for 1 minute, but otherwise ignore fail 11 (unlocked as the minute is up) ...etc... so our code is: if (fails && ((fails % limit) == 0)) ... we do this so we can see which accounts are getting hammered. (we log the fail count on lockout so our log scanner picks it up and sends it to Zymon/hoBBit/BB). John From sanribu at gmail.com Wed Oct 14 06:55:08 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Wed, 14 Oct 2009 12:55:08 +0200 Subject: Error calling function protocol status: 1312 Message-ID: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> Hi again, After some tough work, it seems I've got my test environment configured and working with DHCP server, DNS server, ldap and Domain Controller, running on a GNU Linux Debian platform. I've also configured KDC + AS services on that machine, and I'm glad to see that I'm able to create a secure context between the server and other GNU Linux machine. I'm using GSS-API in Java 1.6, and everything works fine. The problem comes when I run the same Java code on a Windows XP SP3 platform with jdk 1.5.0_21 version installed. Just before the context is created, I get the message: *Error calling function protocol status: 1312. A specified logon session does not exist. It may already have been terminated.* But the most curious thing is that execution continues and secure context is created indeed. I've also checked *krb5kdc.log* and verified that both TGT ans TGS tickets are generated and delivered correctly. I've searched the web and I've found many posible explanations, like: *"There is a problem with Windows API FormatMessage usage in a non English locale"* - forums.sun *"The identity associated with a **KerberosToken2* * security token is being used for constrained delegation, but constrained delegation is not configured correctly."* - msdn *"There is a bug in Java 1.5"* - other source ... but none of them convinces me. So the cuestion is: Why is that message appearing? Should I worry about it? How can I solve it? Thanks in advance! Regards, Santi From Weijun.Wang at Sun.COM Wed Oct 14 08:00:03 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Wed, 14 Oct 2009 20:00:03 +0800 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> Message-ID: <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> Java tries to get the credentials cache (ccache) from Windows LSA if you specify useTicketCache=true in the JAAS config file. In some cases, Java believes there's a ccache at the beginning, but finally it cannot get one. For example, you login as a AD account but then purge the TGT using klist or kerbtray. Then, you will see this error. Without the ccache, Java will try the Kerberos login itself, you'll need to provide username and password in your program. -- Max On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: > Hi again, > > After some tough work, it seems I've got my test environment > configured and > working with DHCP server, DNS server, ldap and Domain Controller, > running on > a GNU Linux Debian platform. I've also configured KDC + AS services > on that > machine, and I'm glad to see that I'm able to create a secure context > between the server and other GNU Linux machine. I'm using GSS-API in > Java > 1.6, and everything works fine. > > The problem comes when I run the same Java code on a Windows XP SP3 > platform > with jdk 1.5.0_21 version installed. Just before the context is > created, I > get the message: > > *Error calling function protocol status: 1312. A specified logon > session > does not exist. It may already have been terminated.* > > But the most curious thing is that execution continues and secure > context is > created indeed. I've also checked *krb5kdc.log* and verified that > both TGT > ans TGS tickets are generated and delivered correctly. > > I've searched the web and I've found many posible explanations, like: > > *"There is a problem with Windows API FormatMessage usage in a non > English > locale"* - forums.sun > *"The identity associated with a > **KerberosToken2* > > * security token is being used for constrained delegation, but > constrained > delegation is not configured correctly."* - msdn > *"There is a bug in Java 1.5"* - other source > > ... but none of them convinces me. > So the cuestion is: Why is that message appearing? Should I worry > about it? > How can I solve it? > > Thanks in advance! > > Regards, > Santi > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From sanribu at gmail.com Wed Oct 14 10:16:02 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Wed, 14 Oct 2009 16:16:02 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> Message-ID: <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> Well, I do specify "useTicketCache=true" in the JAAS config file, but there is something I must be missing, cause I cannot get it working with cached tickets. In fact, I must provide username and password in the config file (or via command line). I can obtain TGT tickets with both Leash32 and Network Identity Manager tools, but I cannot see where they are stored, if cached (just the same as /tmp/krb5cc_1000 file in Linux...) ?? So may be the cuestion should be: How do I configure the ticket cache in Windows? Is it mandatory to be configured through LSA? Thank you very much, Max! Regards, Santi 2009/10/14 Max (Weijun) Wang > Java tries to get the credentials cache (ccache) from Windows LSA if you > specify useTicketCache=true in the JAAS config file. In some cases, Java > believes there's a ccache at the beginning, but finally it cannot get one. > For example, you login as a AD account but then purge the TGT using klist or > kerbtray. Then, you will see this error. > > Without the ccache, Java will try the Kerberos login itself, you'll need to > provide username and password in your program. > > -- Max > > On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: > > Hi again, >> >> After some tough work, it seems I've got my test environment configured >> and >> working with DHCP server, DNS server, ldap and Domain Controller, running >> on >> a GNU Linux Debian platform. I've also configured KDC + AS services on >> that >> machine, and I'm glad to see that I'm able to create a secure context >> between the server and other GNU Linux machine. I'm using GSS-API in Java >> 1.6, and everything works fine. >> >> The problem comes when I run the same Java code on a Windows XP SP3 >> platform >> with jdk 1.5.0_21 version installed. Just before the context is created, I >> get the message: >> >> *Error calling function protocol status: 1312. A specified logon session >> does not exist. It may already have been terminated.* >> >> But the most curious thing is that execution continues and secure context >> is >> created indeed. I've also checked *krb5kdc.log* and verified that both TGT >> ans TGS tickets are generated and delivered correctly. >> >> I've searched the web and I've found many posible explanations, like: >> >> *"There is a problem with Windows API FormatMessage usage in a non English >> locale"* - forums.sun >> *"The identity associated with a >> **KerberosToken2*< >> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx> >> >> * security token is being used for constrained delegation, but constrained >> delegation is not configured correctly."* - msdn >> *"There is a bug in Java 1.5"* - other source >> >> ... but none of them convinces me. >> So the cuestion is: Why is that message appearing? Should I worry about >> it? >> How can I solve it? >> >> Thanks in advance! >> >> Regards, >> Santi >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> > > From jaltman at secure-endpoints.com Wed Oct 14 10:38:07 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Wed, 14 Oct 2009 10:38:07 -0400 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> Message-ID: <4AD5E24F.7020308@secure-endpoints.com> Santiago Rivas wrote: > Well, I do specify "useTicketCache=true" in the JAAS config file, but there > is something I must be missing, cause I cannot get it working with cached > tickets. In fact, I must provide username and password in the config file > (or via command line). > > I can obtain TGT tickets with both Leash32 and Network Identity Manager > tools, but I cannot see where they are stored, if cached (just the same as > /tmp/krb5cc_1000 file in Linux...) ?? > > So may be the cuestion should be: How do I configure the ticket cache in > Windows? Is it mandatory to be configured through LSA? > > Thank you very much, Max! > > Regards, > Santi MIT Kerberos for Windows defaults to using the CCAPI service to store its credentials. Java does not support the CCAPI. These caches are named API: by Network Identity Manager. The Microsoft LSA Kerberos ticket interface, known to MIT Kerberos for Windows and Network Identity Manager as MSLSA: provide a readonly interface. It is not really a cache on XP but a ticket request interface. If the user logged onto the machine using an active directory domain account and the machine had network access to the AD services at the time of login, the LSA interface can be used to request a Kerberos ticket granting ticket representing the logged on user. If the Logon Session was not authenticated with Kerberos, then there will be no ability to request a TGT from the LSA. Java supports via JAAS the ability to query the LSA for a TGT and it can also read from a MIT FILE: credential cache. Network Identity Manager can be configured to store the user's credentials in a FILE:: cache which can then be accessed via Java. If no cached credentials are available, username and password are used to obtain a TGT and then Java caches that TGT internally. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091014/46216870/smime.bin From deengert at anl.gov Wed Oct 14 12:01:12 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 14 Oct 2009 11:01:12 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> Message-ID: <4AD5F5C8.6010301@anl.gov> Santiago Rivas wrote: > Well, I do specify "useTicketCache=true" in the JAAS config file, but there > is something I must be missing, cause I cannot get it working with cached > tickets. In fact, I must provide username and password in the config file > (or via command line). > > I can obtain TGT tickets with both Leash32 and Network Identity Manager > tools, but I cannot see where they are stored, if cached (just the same as > /tmp/krb5cc_1000 file in Linux...) ?? On Unix, with JXplorer, I can add -Duser.krb5ccname=$KRB5CCNAME to the command line, and the JXplorer gssapi.conf has: com.ca.commons.jndi.JNDIOps { com.sun.security.auth.module.Krb5LoginModule required client=TRUE ticketCache="${user.krb5ccname}" doNotPrompt=TRUE useTicketCache=TRUE; }; On Windows it does not have the ticketCache= line, but I think it could try it. If Leash32 or Network Identity Manager is storing them in a file, say \tmp\krb5cc_username you could try ticketCache=\tmp\krb5cc_username > > So may be the question should be: How do I configure the ticket cache in > Windows? Is it mandatory to be configured through LSA? > > Thank you very much, Max! > > Regards, > Santi > > 2009/10/14 Max (Weijun) Wang > >> Java tries to get the credentials cache (ccache) from Windows LSA if you >> specify useTicketCache=true in the JAAS config file. In some cases, Java >> believes there's a ccache at the beginning, but finally it cannot get one. >> For example, you login as a AD account but then purge the TGT using klist or >> kerbtray. Then, you will see this error. >> >> Without the ccache, Java will try the Kerberos login itself, you'll need to >> provide username and password in your program. >> >> -- Max >> >> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >> >> Hi again, >>> After some tough work, it seems I've got my test environment configured >>> and >>> working with DHCP server, DNS server, ldap and Domain Controller, running >>> on >>> a GNU Linux Debian platform. I've also configured KDC + AS services on >>> that >>> machine, and I'm glad to see that I'm able to create a secure context >>> between the server and other GNU Linux machine. I'm using GSS-API in Java >>> 1.6, and everything works fine. >>> >>> The problem comes when I run the same Java code on a Windows XP SP3 >>> platform >>> with jdk 1.5.0_21 version installed. Just before the context is created, I >>> get the message: >>> >>> *Error calling function protocol status: 1312. A specified logon session >>> does not exist. It may already have been terminated.* >>> >>> But the most curious thing is that execution continues and secure context >>> is >>> created indeed. I've also checked *krb5kdc.log* and verified that both TGT >>> ans TGS tickets are generated and delivered correctly. >>> >>> I've searched the web and I've found many posible explanations, like: >>> >>> *"There is a problem with Windows API FormatMessage usage in a non English >>> locale"* - forums.sun >>> *"The identity associated with a >>> **KerberosToken2*< >>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx> >>> >>> * security token is being used for constrained delegation, but constrained >>> delegation is not configured correctly."* - msdn >>> *"There is a bug in Java 1.5"* - other source >>> >>> ... but none of them convinces me. >>> So the cuestion is: Why is that message appearing? Should I worry about >>> it? >>> How can I solve it? >>> >>> Thanks in advance! >>> >>> Regards, >>> Santi >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sanribu at gmail.com Wed Oct 14 12:46:56 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Wed, 14 Oct 2009 18:46:56 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <4AD5F5C8.6010301@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> Message-ID: <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> So, if I didn't misunderstood your words, I basically have at least 2 alternatives to achieve ticket collection from cache under Windows XP environment: 1) Configure Network Identity Manager to store credentials into a file, in order to read them from Java. 2) Set up the configuration so that logon session is authenticated with Kerberos, and then retrieve the TGT ticket from LSA querying via JAAS. Personally, I'm more interested on the second option, since the main target is to achieve single sign-on with kerberos. Anyway, I would appreciate to read some documentation on both tasks. Could you please tell me where I can find it? Thanks a lot, guys! Regards, Santi 2009/10/14 Douglas E. Engert > > > Santiago Rivas wrote: > >> Well, I do specify "useTicketCache=true" in the JAAS config file, but >> there >> is something I must be missing, cause I cannot get it working with cached >> tickets. In fact, I must provide username and password in the config file >> (or via command line). >> >> I can obtain TGT tickets with both Leash32 and Network Identity Manager >> tools, but I cannot see where they are stored, if cached (just the same as >> /tmp/krb5cc_1000 file in Linux...) ?? >> > > On Unix, with JXplorer, I can add -Duser.krb5ccname=$KRB5CCNAME > to the command line, and the JXplorer gssapi.conf has: > > com.ca.commons.jndi.JNDIOps { > com.sun.security.auth.module.Krb5LoginModule required client=TRUE > ticketCache="${user.krb5ccname}" > doNotPrompt=TRUE > useTicketCache=TRUE; > }; > > On Windows it does not have the ticketCache= line, > but I think it could try it. > > If Leash32 or Network Identity Manager is storing them in a file, > say \tmp\krb5cc_username > you could try ticketCache=\tmp\krb5cc_username > > > > >> So may be the question should be: How do I configure the ticket cache in >> Windows? Is it mandatory to be configured through LSA? >> >> Thank you very much, Max! >> >> Regards, >> Santi >> >> 2009/10/14 Max (Weijun) Wang >> >> Java tries to get the credentials cache (ccache) from Windows LSA if you >>> specify useTicketCache=true in the JAAS config file. In some cases, Java >>> believes there's a ccache at the beginning, but finally it cannot get >>> one. >>> For example, you login as a AD account but then purge the TGT using klist >>> or >>> kerbtray. Then, you will see this error. >>> >>> Without the ccache, Java will try the Kerberos login itself, you'll need >>> to >>> provide username and password in your program. >>> >>> -- Max >>> >>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>> >>> Hi again, >>> >>>> After some tough work, it seems I've got my test environment configured >>>> and >>>> working with DHCP server, DNS server, ldap and Domain Controller, >>>> running >>>> on >>>> a GNU Linux Debian platform. I've also configured KDC + AS services on >>>> that >>>> machine, and I'm glad to see that I'm able to create a secure context >>>> between the server and other GNU Linux machine. I'm using GSS-API in >>>> Java >>>> 1.6, and everything works fine. >>>> >>>> The problem comes when I run the same Java code on a Windows XP SP3 >>>> platform >>>> with jdk 1.5.0_21 version installed. Just before the context is created, >>>> I >>>> get the message: >>>> >>>> *Error calling function protocol status: 1312. A specified logon session >>>> does not exist. It may already have been terminated.* >>>> >>>> But the most curious thing is that execution continues and secure >>>> context >>>> is >>>> created indeed. I've also checked *krb5kdc.log* and verified that both >>>> TGT >>>> ans TGS tickets are generated and delivered correctly. >>>> >>>> I've searched the web and I've found many posible explanations, like: >>>> >>>> *"There is a problem with Windows API FormatMessage usage in a non >>>> English >>>> locale"* - forums.sun >>>> *"The identity associated with a >>>> **KerberosToken2*< >>>> >>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>>> > >>>> >>>> * security token is being used for constrained delegation, but >>>> constrained >>>> delegation is not configured correctly."* - msdn >>>> *"There is a bug in Java 1.5"* - other source >>>> >>>> ... but none of them convinces me. >>>> So the cuestion is: Why is that message appearing? Should I worry about >>>> it? >>>> How can I solve it? >>>> >>>> Thanks in advance! >>>> >>>> Regards, >>>> Santi >>>> _______________________________________________ >>>> krbdev mailing list krbdev at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > From deengert at anl.gov Wed Oct 14 14:33:27 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 14 Oct 2009 13:33:27 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> Message-ID: <4AD61977.3070600@anl.gov> Santiago Rivas wrote: > So, if I didn't misunderstood your words, I basically have at least 2 > alternatives to achieve ticket collection from cache under Windows XP > environment: > > 1) Configure Network Identity Manager to store credentials into a file, in > order to read them from Java. One of the other responder to your first e-mail, Jeff Altman, is the developer of Network Identity Manager, and said: " Network Identity Manager can be configured to store the user's credentials in a FILE:: cache which can then be accessed via Java." Start by looking under Options->Kerberos v5->Credential Cache > > 2) Set up the configuration so that logon session is authenticated with > Kerberos, and then retrieve the TGT ticket from LSA querying via JAAS. > Also see this: http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html It talks about using the LSA, or the ticketCache=file options and the use of the "TGT accessibility" registry setting for allowtgtsessionkey. Network Identity Manager also uses this registry setting. (This registry setting may be you main issue!) > Personally, I'm more interested on the second option, since the main target > is to achieve single sign-on with kerberos. Anyway, I would appreciate to > read some documentation on both tasks. Could you please tell me where I can > find it? A third option is to use the Microsoft runas /netonly /user:user at realm program This will run the program with a new LSA. Program could be cmd.exe or even explorer.exe > > Thanks a lot, guys! > > Regards, > Santi > > > 2009/10/14 Douglas E. Engert > >> >> Santiago Rivas wrote: >> >>> Well, I do specify "useTicketCache=true" in the JAAS config file, but >>> there >>> is something I must be missing, cause I cannot get it working with cached >>> tickets. In fact, I must provide username and password in the config file >>> (or via command line). >>> >>> I can obtain TGT tickets with both Leash32 and Network Identity Manager >>> tools, but I cannot see where they are stored, if cached (just the same as >>> /tmp/krb5cc_1000 file in Linux...) ?? >>> >> On Unix, with JXplorer, I can add -Duser.krb5ccname=$KRB5CCNAME >> to the command line, and the JXplorer gssapi.conf has: >> >> com.ca.commons.jndi.JNDIOps { >> com.sun.security.auth.module.Krb5LoginModule required client=TRUE >> ticketCache="${user.krb5ccname}" >> doNotPrompt=TRUE >> useTicketCache=TRUE; >> }; >> >> On Windows it does not have the ticketCache= line, >> but I think it could try it. >> >> If Leash32 or Network Identity Manager is storing them in a file, >> say \tmp\krb5cc_username >> you could try ticketCache=\tmp\krb5cc_username >> >> >> >> >>> So may be the question should be: How do I configure the ticket cache in >>> Windows? Is it mandatory to be configured through LSA? >>> >>> Thank you very much, Max! >>> >>> Regards, >>> Santi >>> >>> 2009/10/14 Max (Weijun) Wang >>> >>> Java tries to get the credentials cache (ccache) from Windows LSA if you >>>> specify useTicketCache=true in the JAAS config file. In some cases, Java >>>> believes there's a ccache at the beginning, but finally it cannot get >>>> one. >>>> For example, you login as a AD account but then purge the TGT using klist >>>> or >>>> kerbtray. Then, you will see this error. >>>> >>>> Without the ccache, Java will try the Kerberos login itself, you'll need >>>> to >>>> provide username and password in your program. >>>> >>>> -- Max >>>> >>>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>>> >>>> Hi again, >>>> >>>>> After some tough work, it seems I've got my test environment configured >>>>> and >>>>> working with DHCP server, DNS server, ldap and Domain Controller, >>>>> running >>>>> on >>>>> a GNU Linux Debian platform. I've also configured KDC + AS services on >>>>> that >>>>> machine, and I'm glad to see that I'm able to create a secure context >>>>> between the server and other GNU Linux machine. I'm using GSS-API in >>>>> Java >>>>> 1.6, and everything works fine. >>>>> >>>>> The problem comes when I run the same Java code on a Windows XP SP3 >>>>> platform >>>>> with jdk 1.5.0_21 version installed. Just before the context is created, >>>>> I >>>>> get the message: >>>>> >>>>> *Error calling function protocol status: 1312. A specified logon session >>>>> does not exist. It may already have been terminated.* >>>>> >>>>> But the most curious thing is that execution continues and secure >>>>> context >>>>> is >>>>> created indeed. I've also checked *krb5kdc.log* and verified that both >>>>> TGT >>>>> ans TGS tickets are generated and delivered correctly. >>>>> >>>>> I've searched the web and I've found many posible explanations, like: >>>>> >>>>> *"There is a problem with Windows API FormatMessage usage in a non >>>>> English >>>>> locale"* - forums.sun >>>>> *"The identity associated with a >>>>> **KerberosToken2*< >>>>> >>>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>>>> * security token is being used for constrained delegation, but >>>>> constrained >>>>> delegation is not configured correctly."* - msdn >>>>> *"There is a bug in Java 1.5"* - other source >>>>> >>>>> ... but none of them convinces me. >>>>> So the cuestion is: Why is that message appearing? Should I worry about >>>>> it? >>>>> How can I solve it? >>>>> >>>>> Thanks in advance! >>>>> >>>>> Regards, >>>>> Santi >>>>> _______________________________________________ >>>>> krbdev mailing list krbdev at mit.edu >>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>> >>>>> >>>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From deengert at anl.gov Wed Oct 14 14:54:48 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 14 Oct 2009 13:54:48 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <4AD61977.3070600@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> Message-ID: <4AD61E78.3080305@anl.gov> P.S. The other responder to your note, Weijun Wang, is the author of the Sun web page I listed below. Small world! Douglas E. Engert wrote: > > Santiago Rivas wrote: >> So, if I didn't misunderstood your words, I basically have at least 2 >> alternatives to achieve ticket collection from cache under Windows XP >> environment: >> >> 1) Configure Network Identity Manager to store credentials into a file, in >> order to read them from Java. > > One of the other responder to your first e-mail, Jeff Altman, is the > developer of Network Identity Manager, and said: > " Network Identity Manager can be configured to store the user's > credentials in a FILE:: cache which can then be > accessed via Java." > > Start by looking under Options->Kerberos v5->Credential Cache > >> 2) Set up the configuration so that logon session is authenticated with >> Kerberos, and then retrieve the TGT ticket from LSA querying via JAAS. >> > > Also see this: > http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html > > It talks about using the LSA, or the ticketCache=file options and > the use of the "TGT accessibility" registry setting for allowtgtsessionkey. > Network Identity Manager also uses this registry setting. > > (This registry setting may be you main issue!) > >> Personally, I'm more interested on the second option, since the main target >> is to achieve single sign-on with kerberos. Anyway, I would appreciate to >> read some documentation on both tasks. Could you please tell me where I can >> find it? > > A third option is to use the Microsoft runas /netonly /user:user at realm program > This will run the program with a new LSA. Program could be cmd.exe or even > explorer.exe > > >> Thanks a lot, guys! >> >> Regards, >> Santi >> >> >> 2009/10/14 Douglas E. Engert >> >>> Santiago Rivas wrote: >>> >>>> Well, I do specify "useTicketCache=true" in the JAAS config file, but >>>> there >>>> is something I must be missing, cause I cannot get it working with cached >>>> tickets. In fact, I must provide username and password in the config file >>>> (or via command line). >>>> >>>> I can obtain TGT tickets with both Leash32 and Network Identity Manager >>>> tools, but I cannot see where they are stored, if cached (just the same as >>>> /tmp/krb5cc_1000 file in Linux...) ?? >>>> >>> On Unix, with JXplorer, I can add -Duser.krb5ccname=$KRB5CCNAME >>> to the command line, and the JXplorer gssapi.conf has: >>> >>> com.ca.commons.jndi.JNDIOps { >>> com.sun.security.auth.module.Krb5LoginModule required client=TRUE >>> ticketCache="${user.krb5ccname}" >>> doNotPrompt=TRUE >>> useTicketCache=TRUE; >>> }; >>> >>> On Windows it does not have the ticketCache= line, >>> but I think it could try it. >>> >>> If Leash32 or Network Identity Manager is storing them in a file, >>> say \tmp\krb5cc_username >>> you could try ticketCache=\tmp\krb5cc_username >>> >>> >>> >>> >>>> So may be the question should be: How do I configure the ticket cache in >>>> Windows? Is it mandatory to be configured through LSA? >>>> >>>> Thank you very much, Max! >>>> >>>> Regards, >>>> Santi >>>> >>>> 2009/10/14 Max (Weijun) Wang >>>> >>>> Java tries to get the credentials cache (ccache) from Windows LSA if you >>>>> specify useTicketCache=true in the JAAS config file. In some cases, Java >>>>> believes there's a ccache at the beginning, but finally it cannot get >>>>> one. >>>>> For example, you login as a AD account but then purge the TGT using klist >>>>> or >>>>> kerbtray. Then, you will see this error. >>>>> >>>>> Without the ccache, Java will try the Kerberos login itself, you'll need >>>>> to >>>>> provide username and password in your program. >>>>> >>>>> -- Max >>>>> >>>>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>>>> >>>>> Hi again, >>>>> >>>>>> After some tough work, it seems I've got my test environment configured >>>>>> and >>>>>> working with DHCP server, DNS server, ldap and Domain Controller, >>>>>> running >>>>>> on >>>>>> a GNU Linux Debian platform. I've also configured KDC + AS services on >>>>>> that >>>>>> machine, and I'm glad to see that I'm able to create a secure context >>>>>> between the server and other GNU Linux machine. I'm using GSS-API in >>>>>> Java >>>>>> 1.6, and everything works fine. >>>>>> >>>>>> The problem comes when I run the same Java code on a Windows XP SP3 >>>>>> platform >>>>>> with jdk 1.5.0_21 version installed. Just before the context is created, >>>>>> I >>>>>> get the message: >>>>>> >>>>>> *Error calling function protocol status: 1312. A specified logon session >>>>>> does not exist. It may already have been terminated.* >>>>>> >>>>>> But the most curious thing is that execution continues and secure >>>>>> context >>>>>> is >>>>>> created indeed. I've also checked *krb5kdc.log* and verified that both >>>>>> TGT >>>>>> ans TGS tickets are generated and delivered correctly. >>>>>> >>>>>> I've searched the web and I've found many posible explanations, like: >>>>>> >>>>>> *"There is a problem with Windows API FormatMessage usage in a non >>>>>> English >>>>>> locale"* - forums.sun >>>>>> *"The identity associated with a >>>>>> **KerberosToken2*< >>>>>> >>>>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>>>>> * security token is being used for constrained delegation, but >>>>>> constrained >>>>>> delegation is not configured correctly."* - msdn >>>>>> *"There is a bug in Java 1.5"* - other source >>>>>> >>>>>> ... but none of them convinces me. >>>>>> So the cuestion is: Why is that message appearing? Should I worry about >>>>>> it? >>>>>> How can I solve it? >>>>>> >>>>>> Thanks in advance! >>>>>> >>>>>> Regards, >>>>>> Santi >>>>>> _______________________________________________ >>>>>> krbdev mailing list krbdev at mit.edu >>>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>>> >>>>>> >>>>> _______________________________________________ >>>> krbdev mailing list krbdev at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>>> >>> -- >>> >>> Douglas E. Engert >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sanribu at gmail.com Fri Oct 16 02:33:34 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Fri, 16 Oct 2009 08:33:34 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <4AD61E78.3080305@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> Message-ID: <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> Ok, here is what I've done: I changed the JAAS config file, setting "useTicketCache=". That was enough to make de 1312 status error dissappear. But I'm still not able to configure the ticket caching properly. I forgot to mention that I have had already tried to set some file path under NIM: Options->Kerberos v5->Credential Cache ... with no results. I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the text box and clicked the "Add" button, but it said something like "the credentials cache file was not found". If I only set the path to some folder (with no file name) there is no error message, but when I generate new tickets no file is created. I've reset the machine and verified that the user has privileges to access the path I'm typing son I don't known where I'm mistaking... ?? Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. Regards, Santi 2009/10/14 Douglas E. Engert > P.S. The other responder to your note, Weijun Wang, is the > author of the Sun web page I listed below. Small world! > > > Douglas E. Engert wrote: > >> >> Santiago Rivas wrote: >> >>> So, if I didn't misunderstood your words, I basically have at least 2 >>> alternatives to achieve ticket collection from cache under Windows XP >>> environment: >>> >>> 1) Configure Network Identity Manager to store credentials into a file, >>> in >>> order to read them from Java. >>> >> >> One of the other responder to your first e-mail, Jeff Altman, is the >> developer of Network Identity Manager, and said: >> " Network Identity Manager can be configured to store the user's >> credentials in a FILE:: cache which can then be >> accessed via Java." >> >> Start by looking under Options->Kerberos v5->Credential Cache >> >> 2) Set up the configuration so that logon session is authenticated with >>> Kerberos, and then retrieve the TGT ticket from LSA querying via JAAS. >>> >>> >> Also see this: >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >> >> It talks about using the LSA, or the ticketCache=file options and >> the use of the "TGT accessibility" registry setting for >> allowtgtsessionkey. >> Network Identity Manager also uses this registry setting. >> >> (This registry setting may be you main issue!) >> >> Personally, I'm more interested on the second option, since the main >>> target >>> is to achieve single sign-on with kerberos. Anyway, I would appreciate to >>> read some documentation on both tasks. Could you please tell me where I >>> can >>> find it? >>> >> >> A third option is to use the Microsoft runas /netonly /user:user at realmprogram >> This will run the program with a new LSA. Program could be cmd.exe or even >> explorer.exe >> >> >> Thanks a lot, guys! >>> >>> Regards, >>> Santi >>> >>> >>> 2009/10/14 Douglas E. Engert >>> >>> Santiago Rivas wrote: >>>> >>>> Well, I do specify "useTicketCache=true" in the JAAS config file, but >>>>> there >>>>> is something I must be missing, cause I cannot get it working with >>>>> cached >>>>> tickets. In fact, I must provide username and password in the config >>>>> file >>>>> (or via command line). >>>>> >>>>> I can obtain TGT tickets with both Leash32 and Network Identity Manager >>>>> tools, but I cannot see where they are stored, if cached (just the same >>>>> as >>>>> /tmp/krb5cc_1000 file in Linux...) ?? >>>>> >>>>> On Unix, with JXplorer, I can add -Duser.krb5ccname=$KRB5CCNAME >>>> to the command line, and the JXplorer gssapi.conf has: >>>> >>>> com.ca.commons.jndi.JNDIOps { >>>> com.sun.security.auth.module.Krb5LoginModule required client=TRUE >>>> ticketCache="${user.krb5ccname}" >>>> doNotPrompt=TRUE >>>> useTicketCache=TRUE; >>>> }; >>>> >>>> On Windows it does not have the ticketCache= line, >>>> but I think it could try it. >>>> >>>> If Leash32 or Network Identity Manager is storing them in a file, >>>> say \tmp\krb5cc_username >>>> you could try ticketCache=\tmp\krb5cc_username >>>> >>>> >>>> >>>> >>>> So may be the question should be: How do I configure the ticket cache in >>>>> Windows? Is it mandatory to be configured through LSA? >>>>> >>>>> Thank you very much, Max! >>>>> >>>>> Regards, >>>>> Santi >>>>> >>>>> 2009/10/14 Max (Weijun) Wang >>>>> >>>>> Java tries to get the credentials cache (ccache) from Windows LSA if >>>>> you >>>>> >>>>>> specify useTicketCache=true in the JAAS config file. In some cases, >>>>>> Java >>>>>> believes there's a ccache at the beginning, but finally it cannot get >>>>>> one. >>>>>> For example, you login as a AD account but then purge the TGT using >>>>>> klist >>>>>> or >>>>>> kerbtray. Then, you will see this error. >>>>>> >>>>>> Without the ccache, Java will try the Kerberos login itself, you'll >>>>>> need >>>>>> to >>>>>> provide username and password in your program. >>>>>> >>>>>> -- Max >>>>>> >>>>>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>>>>> >>>>>> Hi again, >>>>>> >>>>>> After some tough work, it seems I've got my test environment >>>>>>> configured >>>>>>> and >>>>>>> working with DHCP server, DNS server, ldap and Domain Controller, >>>>>>> running >>>>>>> on >>>>>>> a GNU Linux Debian platform. I've also configured KDC + AS services >>>>>>> on >>>>>>> that >>>>>>> machine, and I'm glad to see that I'm able to create a secure context >>>>>>> between the server and other GNU Linux machine. I'm using GSS-API in >>>>>>> Java >>>>>>> 1.6, and everything works fine. >>>>>>> >>>>>>> The problem comes when I run the same Java code on a Windows XP SP3 >>>>>>> platform >>>>>>> with jdk 1.5.0_21 version installed. Just before the context is >>>>>>> created, >>>>>>> I >>>>>>> get the message: >>>>>>> >>>>>>> *Error calling function protocol status: 1312. A specified logon >>>>>>> session >>>>>>> does not exist. It may already have been terminated.* >>>>>>> >>>>>>> But the most curious thing is that execution continues and secure >>>>>>> context >>>>>>> is >>>>>>> created indeed. I've also checked *krb5kdc.log* and verified that >>>>>>> both >>>>>>> TGT >>>>>>> ans TGS tickets are generated and delivered correctly. >>>>>>> >>>>>>> I've searched the web and I've found many posible explanations, like: >>>>>>> >>>>>>> *"There is a problem with Windows API FormatMessage usage in a non >>>>>>> English >>>>>>> locale"* - forums.sun >>>>>>> *"The identity associated with a >>>>>>> **KerberosToken2*< >>>>>>> >>>>>>> >>>>>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>>>>>> * security token is being used for constrained delegation, but >>>>>>> constrained >>>>>>> delegation is not configured correctly."* - msdn >>>>>>> *"There is a bug in Java 1.5"* - other source >>>>>>> >>>>>>> ... but none of them convinces me. >>>>>>> So the cuestion is: Why is that message appearing? Should I worry >>>>>>> about >>>>>>> it? >>>>>>> How can I solve it? >>>>>>> >>>>>>> Thanks in advance! >>>>>>> >>>>>>> Regards, >>>>>>> Santi >>>>>>> _______________________________________________ >>>>>>> krbdev mailing list krbdev at mit.edu >>>>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>>>> >>>>>>> >>>>>>> _______________________________________________ >>>>>> >>>>> krbdev mailing list krbdev at mit.edu >>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>> >>>>> >>>>> >>>>> -- >>>> >>>> Douglas E. Engert >>>> Argonne National Laboratory >>>> 9700 South Cass Avenue >>>> Argonne, Illinois 60439 >>>> (630) 252-5444 >>>> >>>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >> > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > From jaltman at secure-endpoints.com Fri Oct 16 10:53:12 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Fri, 16 Oct 2009 10:53:12 -0400 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> Message-ID: <4AD888D8.2030704@secure-endpoints.com> Santiago Rivas wrote: > Ok, here is what I've done: > > I changed the JAAS config file, setting "useTicketCache=". That > was enough to make de 1312 status error dissappear. But I'm still not able > to configure the ticket caching properly. > > I forgot to mention that I have had already tried to set some file path > under > > NIM: Options->Kerberos v5->Credential Cache ... with no results. This instructs NIM to monitor that FILE based credential cache for credentials that are obtained outside of NIM. For example, by a kinit or Java. > I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the text > box and clicked the "Add" button, but it said something like "the > credentials cache file was not found". That could be a bug if it is anything other than a warning. If you are prevented from adding the path to the list of credential caches, it is a bug. > If I only set the path to some folder > (with no file name) there is no error message, but when I generate new > tickets no file is created. I've reset the machine and verified that the > user has privileges to access the path I'm typing son I don't known where > I'm mistaking... ?? You need to update the Identity object to use a FILE: ccache. Did you do that? If not when you obtain a new credential it goes into the API: ccache which is the default. Jeffrey Altman -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091016/5da97c5b/smime.bin From deengert at anl.gov Fri Oct 16 12:44:45 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 16 Oct 2009 11:44:45 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> Message-ID: <4AD8A2FD.2050006@anl.gov> Santiago Rivas wrote: > Ok, here is what I've done: > > I changed the JAAS config file, setting "useTicketCache=". > That was enough to make de 1312 status error dissappear. But I'm still > not able to configure the ticket caching properly. > > I forgot to mention that I have had already tried to set some file path > under > > NIM: Options->Kerberos v5->Credential Cache ... with no results. > > I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the > text box and clicked the "Add" button, but it said something like "the > credentials cache file was not found". If I only set the path to some > folder (with no file name) there is no error message, but when I > generate new tickets no file is created. I've reset the machine and > verified that the user has privileges to access the path I'm typing son > I don't known where I'm mistaking... ?? Did you make the registry setting change as suggested bu both NIM and Java? I don't think Java actually writes tickets to the cache. It just reads a TGT from the cache, then keeps tickets in memory. (I could be wrong) The Java kinit.exe will write the TGT but I have never needed to use it. Windows and NIM/KfW also have kinit.exe files so be careful which one you are using. > > Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. > > Regards, > Santi > > > 2009/10/14 Douglas E. Engert > > > P.S. The other responder to your note, Weijun Wang, is the > author of the Sun web page I listed below. Small world! > > > Douglas E. Engert wrote: > > > Santiago Rivas wrote: > > So, if I didn't misunderstood your words, I basically have > at least 2 > alternatives to achieve ticket collection from cache under > Windows XP > environment: > > 1) Configure Network Identity Manager to store credentials > into a file, in > order to read them from Java. > > > One of the other responder to your first e-mail, Jeff Altman, is the > developer of Network Identity Manager, and said: > " Network Identity Manager can be configured to store the user's > credentials in a FILE:: cache which can then be > accessed via Java." > > Start by looking under Options->Kerberos v5->Credential Cache > > 2) Set up the configuration so that logon session is > authenticated with > Kerberos, and then retrieve the TGT ticket from LSA querying > via JAAS. > > > Also see this: > http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html > > It talks about using the LSA, or the ticketCache=file options and > the use of the "TGT accessibility" registry setting for > allowtgtsessionkey. > Network Identity Manager also uses this registry setting. > > (This registry setting may be you main issue!) > > Personally, I'm more interested on the second option, since > the main target > is to achieve single sign-on with kerberos. Anyway, I would > appreciate to > read some documentation on both tasks. Could you please tell > me where I can > find it? > > > A third option is to use the Microsoft runas /netonly > /user:user at realm program > This will run the program with a new LSA. Program could be > cmd.exe or even > explorer.exe > > > Thanks a lot, guys! > > Regards, > Santi > > > 2009/10/14 Douglas E. Engert > > > Santiago Rivas wrote: > > Well, I do specify "useTicketCache=true" in the JAAS > config file, but > there > is something I must be missing, cause I cannot get > it working with cached > tickets. In fact, I must provide username and > password in the config file > (or via command line). > > I can obtain TGT tickets with both Leash32 and > Network Identity Manager > tools, but I cannot see where they are stored, if > cached (just the same as > /tmp/krb5cc_1000 file in Linux...) ?? > > On Unix, with JXplorer, I can add > -Duser.krb5ccname=$KRB5CCNAME > to the command line, and the JXplorer gssapi.conf has: > > com.ca.commons.jndi.JNDIOps { > com.sun.security.auth.module.Krb5LoginModule required > client=TRUE > ticketCache="${user.krb5ccname}" > doNotPrompt=TRUE > useTicketCache=TRUE; > }; > > On Windows it does not have the ticketCache= line, > but I think it could try it. > > If Leash32 or Network Identity Manager is storing them > in a file, > say \tmp\krb5cc_username > you could try ticketCache=\tmp\krb5cc_username > > > > > So may be the question should be: How do I configure > the ticket cache in > Windows? Is it mandatory to be configured through LSA? > > Thank you very much, Max! > > Regards, > Santi > > 2009/10/14 Max (Weijun) Wang > > > Java tries to get the credentials cache (ccache) > from Windows LSA if you > > specify useTicketCache=true in the JAAS config > file. In some cases, Java > believes there's a ccache at the beginning, but > finally it cannot get > one. > For example, you login as a AD account but then > purge the TGT using klist > or > kerbtray. Then, you will see this error. > > Without the ccache, Java will try the Kerberos > login itself, you'll need > to > provide username and password in your program. > > -- Max > > On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: > > Hi again, > > After some tough work, it seems I've got my > test environment configured > and > working with DHCP server, DNS server, ldap > and Domain Controller, > running > on > a GNU Linux Debian platform. I've also > configured KDC + AS services on > that > machine, and I'm glad to see that I'm able > to create a secure context > between the server and other GNU Linux > machine. I'm using GSS-API in > Java > 1.6, and everything works fine. > > The problem comes when I run the same Java > code on a Windows XP SP3 > platform > with jdk 1.5.0_21 version installed. Just > before the context is created, > I > get the message: > > *Error calling function protocol status: > 1312. A specified logon session > does not exist. It may already have been > terminated.* > > But the most curious thing is that execution > continues and secure > context > is > created indeed. I've also checked > *krb5kdc.log* and verified that both > TGT > ans TGS tickets are generated and delivered > correctly. > > I've searched the web and I've found many > posible explanations, like: > > *"There is a problem with Windows API > FormatMessage usage in a non > English > locale"* - forums.sun > *"The identity associated with a > **KerberosToken2*< > > http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx > * security token is being used for > constrained delegation, but > constrained > delegation is not configured correctly."* - msdn > *"There is a bug in Java 1.5"* - other source > > ... but none of them convinces me. > So the cuestion is: Why is that message > appearing? Should I worry about > it? > How can I solve it? > > Thanks in advance! > > Regards, > Santi > _______________________________________________ > krbdev mailing list > krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > > _______________________________________________ > > krbdev mailing list krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > > -- > > Douglas E. Engert > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > > > -- > > Douglas E. Engert > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sanribu at gmail.com Fri Oct 16 13:56:58 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Fri, 16 Oct 2009 19:56:58 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <4AD8A2FD.2050006@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> Message-ID: <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> By the moment, my purpose is to *generate a TGT (anyhow, using kinit or NIM) and configure the cache so those credentials are stored in a file*, where Java will read them from later. *Step 1: Configure credentials cache* Since you told me to "*update the Identity object to use a FILE: ccache*", I went to NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) On "Kerberos v5" folder, I set the "Credential cache" option to *FILE:ccache *. And now I can see that a file named ccache is created or deleted everytime I generate or destroy the TGT. So I think now I have credentials cache configured properly. Am I right? *Step 2: Configure JAAS so that TGT is read from file (in order to obtain a TGS)* Here is my *jaas.conf* file for the client: *Client {* * com.sun.security.auth.module.Krb5LoginModule required* * useTicketCache=true* * ticketCache="c:\docume~1\santi\ccache";* *}* But when I run the client I get the following exception: *java.lang.SecurityException: Configuration Error :* * Line 4: expected [option key], found [null]* * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* * ...* I guess there some information missing about the credentials, but I don't know what. Any idea? I never tire for saying thank you! Regards, Santi 2009/10/16 Douglas E. Engert > > > Santiago Rivas wrote: > >> Ok, here is what I've done: >> I changed the JAAS config file, setting "useTicketCache=". That >> was enough to make de 1312 status error dissappear. But I'm still not able >> to configure the ticket caching properly. >> I forgot to mention that I have had already tried to set some file path >> under >> NIM: Options->Kerberos v5->Credential Cache ... with no results. >> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the >> text box and clicked the "Add" button, but it said something like "the >> credentials cache file was not found". If I only set the path to some folder >> (with no file name) there is no error message, but when I generate new >> tickets no file is created. I've reset the machine and verified that the >> user has privileges to access the path I'm typing son I don't known where >> I'm mistaking... ?? >> > > Did you make the registry setting change as suggested bu both NIM and Java? > > I don't think Java actually writes tickets to the cache. It just reads a > TGT > from the cache, then keeps tickets in memory. (I could be wrong) > The Java kinit.exe will write the TGT but I have never needed to use it. > Windows and NIM/KfW also have kinit.exe files so be careful which one you > are using. > > Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. >> Regards, >> Santi >> 2009/10/14 Douglas E. Engert > >> >> >> >> P.S. The other responder to your note, Weijun Wang, is the >> author of the Sun web page I listed below. Small world! >> >> >> Douglas E. Engert wrote: >> >> >> Santiago Rivas wrote: >> >> So, if I didn't misunderstood your words, I basically have >> at least 2 >> alternatives to achieve ticket collection from cache under >> Windows XP >> environment: >> >> 1) Configure Network Identity Manager to store credentials >> into a file, in >> order to read them from Java. >> >> >> One of the other responder to your first e-mail, Jeff Altman, is >> the >> developer of Network Identity Manager, and said: >> " Network Identity Manager can be configured to store the user's >> credentials in a FILE:: cache which can then be >> accessed via Java." >> >> Start by looking under Options->Kerberos v5->Credential Cache >> >> 2) Set up the configuration so that logon session is >> authenticated with >> Kerberos, and then retrieve the TGT ticket from LSA querying >> via JAAS. >> >> >> Also see this: >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >> >> It talks about using the LSA, or the ticketCache=file options and >> the use of the "TGT accessibility" registry setting for >> allowtgtsessionkey. >> Network Identity Manager also uses this registry setting. >> >> (This registry setting may be you main issue!) >> >> Personally, I'm more interested on the second option, since >> the main target >> is to achieve single sign-on with kerberos. Anyway, I would >> appreciate to >> read some documentation on both tasks. Could you please tell >> me where I can >> find it? >> >> >> A third option is to use the Microsoft runas /netonly >> /user:user at realm program >> This will run the program with a new LSA. Program could be >> cmd.exe or even >> explorer.exe >> >> >> Thanks a lot, guys! >> >> Regards, >> Santi >> >> >> 2009/10/14 Douglas E. Engert > > >> >> >> Santiago Rivas wrote: >> >> Well, I do specify "useTicketCache=true" in the JAAS >> config file, but >> there >> is something I must be missing, cause I cannot get >> it working with cached >> tickets. In fact, I must provide username and >> password in the config file >> (or via command line). >> >> I can obtain TGT tickets with both Leash32 and >> Network Identity Manager >> tools, but I cannot see where they are stored, if >> cached (just the same as >> /tmp/krb5cc_1000 file in Linux...) ?? >> >> On Unix, with JXplorer, I can add >> -Duser.krb5ccname=$KRB5CCNAME >> to the command line, and the JXplorer gssapi.conf has: >> >> com.ca.commons.jndi.JNDIOps { >> com.sun.security.auth.module.Krb5LoginModule required >> client=TRUE >> ticketCache="${user.krb5ccname}" >> doNotPrompt=TRUE >> useTicketCache=TRUE; >> }; >> >> On Windows it does not have the ticketCache= line, >> but I think it could try it. >> >> If Leash32 or Network Identity Manager is storing them >> in a file, >> say \tmp\krb5cc_username >> you could try ticketCache=\tmp\krb5cc_username >> >> >> >> >> So may be the question should be: How do I configure >> the ticket cache in >> Windows? Is it mandatory to be configured through LSA? >> >> Thank you very much, Max! >> >> Regards, >> Santi >> >> 2009/10/14 Max (Weijun) Wang > > >> >> >> Java tries to get the credentials cache (ccache) >> from Windows LSA if you >> >> specify useTicketCache=true in the JAAS config >> file. In some cases, Java >> believes there's a ccache at the beginning, but >> finally it cannot get >> one. >> For example, you login as a AD account but then >> purge the TGT using klist >> or >> kerbtray. Then, you will see this error. >> >> Without the ccache, Java will try the Kerberos >> login itself, you'll need >> to >> provide username and password in your program. >> >> -- Max >> >> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >> >> Hi again, >> >> After some tough work, it seems I've got my >> test environment configured >> and >> working with DHCP server, DNS server, ldap >> and Domain Controller, >> running >> on >> a GNU Linux Debian platform. I've also >> configured KDC + AS services on >> that >> machine, and I'm glad to see that I'm able >> to create a secure context >> between the server and other GNU Linux >> machine. I'm using GSS-API in >> Java >> 1.6, and everything works fine. >> >> The problem comes when I run the same Java >> code on a Windows XP SP3 >> platform >> with jdk 1.5.0_21 version installed. Just >> before the context is created, >> I >> get the message: >> >> *Error calling function protocol status: >> 1312. A specified logon session >> does not exist. It may already have been >> terminated.* >> >> But the most curious thing is that execution >> continues and secure >> context >> is >> created indeed. I've also checked >> *krb5kdc.log* and verified that both >> TGT >> ans TGS tickets are generated and delivered >> correctly. >> >> I've searched the web and I've found many >> posible explanations, like: >> >> *"There is a problem with Windows API >> FormatMessage usage in a non >> English >> locale"* - forums.sun >> *"The identity associated with a >> **KerberosToken2*< >> >> >> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >> * security token is being used for >> constrained delegation, but >> constrained >> delegation is not configured correctly."* - >> msdn >> *"There is a bug in Java 1.5"* - other source >> >> ... but none of them convinces me. >> So the cuestion is: Why is that message >> appearing? Should I worry about >> it? >> How can I solve it? >> >> Thanks in advance! >> >> Regards, >> Santi >> _______________________________________________ >> krbdev mailing list >> krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> _______________________________________________ >> >> krbdev mailing list krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> >> -- >> >> Douglas E. Engert > > >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> >> >> -- >> Douglas E. Engert > >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> >> > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > From Weijun.Wang at Sun.COM Fri Oct 16 19:57:40 2009 From: Weijun.Wang at Sun.COM (Max (Weijun) Wang) Date: Sat, 17 Oct 2009 07:57:40 +0800 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <46CD6C05-93AF-45AF-BC17-2711E5B99E01@sun.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> Message-ID: <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> Sorry I'm not an expert on NIM. On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote: > By the moment, my purpose is to *generate a TGT (anyhow, using kinit > or NIM) > and configure the cache so those credentials are stored in a file*, Then you can use any kinit.exe, the one from JDK or MIT. To use a file cache, you don't need to care about the registry key mentioned by Douglas at all. In fact, I had thought you were trying to use the LSA cache (non-file in-memory Windows-specific cache). BTW, if you do want to use the LSA cache, please make sure that the file cache is not there, since Java always try to use the file cache first. You can check this out by calling the klist.exe command in JDK. > where Java will read them from later. > > *Step 1: Configure credentials cache* > > Since you told me to "*update the Identity object to use a FILE: > ccache*", I > went to > > NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) > > On "Kerberos v5" folder, I set the "Credential cache" option to > *FILE:ccache > *. And now I can see that a file named ccache is created or deleted > everytime I generate or destroy the TGT. So I think now I have > credentials > cache configured properly. Am I right? > > *Step 2: Configure JAAS so that TGT is read from file (in order to > obtain a > TGS)* > > Here is my *jaas.conf* file for the client: > > *Client {* > * com.sun.security.auth.module.Krb5LoginModule required* > * useTicketCache=true* > * ticketCache="c:\docume~1\santi\ccache";* > *}* > > But when I run the client I get the following exception: > > *java.lang.SecurityException: Configuration Error :* > * Line 4: expected [option key], found [null]* > * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* > * ...* I think Java is complaining about the ticketCache value. It does not like Windows style "\" in path. You can try "\\" or "/". In fact, if you have not provided special argument to kinit, the cache file should be generated at the default location, and you don't need to specify ticketCache in the JAAS conf file at all. To debug, add "debug=true" into the JAAS conf file, *and* add - Dsun.security.krb5.debug=true into you Java command line, you will see a lot of things. Hope this helps Weijun (aka Max) > > I guess there some information missing about the credentials, but I > don't > know what. Any idea? > > I never tire for saying thank you! > > Regards, > Santi > > 2009/10/16 Douglas E. Engert > >> >> >> Santiago Rivas wrote: >> >>> Ok, here is what I've done: >>> I changed the JAAS config file, setting >>> "useTicketCache=". That >>> was enough to make de 1312 status error dissappear. But I'm still >>> not able >>> to configure the ticket caching properly. >>> I forgot to mention that I have had already tried to set some file >>> path >>> under >>> NIM: Options->Kerberos v5->Credential Cache ... with no results. >>> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into >>> the >>> text box and clicked the "Add" button, but it said something like >>> "the >>> credentials cache file was not found". If I only set the path to >>> some folder >>> (with no file name) there is no error message, but when I generate >>> new >>> tickets no file is created. I've reset the machine and verified >>> that the >>> user has privileges to access the path I'm typing son I don't >>> known where >>> I'm mistaking... ?? >>> >> >> Did you make the registry setting change as suggested bu both NIM >> and Java? >> >> I don't think Java actually writes tickets to the cache. It just >> reads a >> TGT >> from the cache, then keeps tickets in memory. (I could be wrong) >> The Java kinit.exe will write the TGT but I have never needed to >> use it. >> Windows and NIM/KfW also have kinit.exe files so be careful which >> one you >> are using. >> >> Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. >>> Regards, >>> Santi >>> 2009/10/14 Douglas E. Engert >> >> >>> >>> >>> >>> P.S. The other responder to your note, Weijun Wang, is the >>> author of the Sun web page I listed below. Small world! >>> >>> >>> Douglas E. Engert wrote: >>> >>> >>> Santiago Rivas wrote: >>> >>> So, if I didn't misunderstood your words, I basically have >>> at least 2 >>> alternatives to achieve ticket collection from cache under >>> Windows XP >>> environment: >>> >>> 1) Configure Network Identity Manager to store credentials >>> into a file, in >>> order to read them from Java. >>> >>> >>> One of the other responder to your first e-mail, Jeff >>> Altman, is >>> the >>> developer of Network Identity Manager, and said: >>> " Network Identity Manager can be configured to store the >>> user's >>> credentials in a FILE:: cache which can then >>> be >>> accessed via Java." >>> >>> Start by looking under Options->Kerberos v5->Credential >>> Cache >>> >>> 2) Set up the configuration so that logon session is >>> authenticated with >>> Kerberos, and then retrieve the TGT ticket from LSA >>> querying >>> via JAAS. >>> >>> >>> Also see this: >>> >>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>> >>> It talks about using the LSA, or the ticketCache=file >>> options and >>> the use of the "TGT accessibility" registry setting for >>> allowtgtsessionkey. >>> Network Identity Manager also uses this registry setting. >>> >>> (This registry setting may be you main issue!) >>> >>> Personally, I'm more interested on the second option, >>> since >>> the main target >>> is to achieve single sign-on with kerberos. Anyway, I >>> would >>> appreciate to >>> read some documentation on both tasks. Could you please >>> tell >>> me where I can >>> find it? >>> >>> >>> A third option is to use the Microsoft runas /netonly >>> /user:user at realm program >>> This will run the program with a new LSA. Program could be >>> cmd.exe or even >>> explorer.exe >>> >>> >>> Thanks a lot, guys! >>> >>> Regards, >>> Santi >>> >>> >>> 2009/10/14 Douglas E. Engert >> > >>> >>> >>> Santiago Rivas wrote: >>> >>> Well, I do specify "useTicketCache=true" in the >>> JAAS >>> config file, but >>> there >>> is something I must be missing, cause I cannot get >>> it working with cached >>> tickets. In fact, I must provide username and >>> password in the config file >>> (or via command line). >>> >>> I can obtain TGT tickets with both Leash32 and >>> Network Identity Manager >>> tools, but I cannot see where they are stored, if >>> cached (just the same as >>> /tmp/krb5cc_1000 file in Linux...) ?? >>> >>> On Unix, with JXplorer, I can add >>> -Duser.krb5ccname=$KRB5CCNAME >>> to the command line, and the JXplorer gssapi.conf has: >>> >>> com.ca.commons.jndi.JNDIOps { >>> com.sun.security.auth.module.Krb5LoginModule required >>> client=TRUE >>> ticketCache="${user.krb5ccname}" >>> doNotPrompt=TRUE >>> useTicketCache=TRUE; >>> }; >>> >>> On Windows it does not have the ticketCache= line, >>> but I think it could try it. >>> >>> If Leash32 or Network Identity Manager is storing them >>> in a file, >>> say \tmp\krb5cc_username >>> you could try ticketCache=\tmp\krb5cc_username >>> >>> >>> >>> >>> So may be the question should be: How do I >>> configure >>> the ticket cache in >>> Windows? Is it mandatory to be configured >>> through LSA? >>> >>> Thank you very much, Max! >>> >>> Regards, >>> Santi >>> >>> 2009/10/14 Max (Weijun) Wang >> > >>> >>> >>> Java tries to get the credentials cache (ccache) >>> from Windows LSA if you >>> >>> specify useTicketCache=true in the JAAS config >>> file. In some cases, Java >>> believes there's a ccache at the beginning, >>> but >>> finally it cannot get >>> one. >>> For example, you login as a AD account but >>> then >>> purge the TGT using klist >>> or >>> kerbtray. Then, you will see this error. >>> >>> Without the ccache, Java will try the Kerberos >>> login itself, you'll need >>> to >>> provide username and password in your program. >>> >>> -- Max >>> >>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas >>> wrote: >>> >>> Hi again, >>> >>> After some tough work, it seems I've got >>> my >>> test environment configured >>> and >>> working with DHCP server, DNS server, ldap >>> and Domain Controller, >>> running >>> on >>> a GNU Linux Debian platform. I've also >>> configured KDC + AS services on >>> that >>> machine, and I'm glad to see that I'm able >>> to create a secure context >>> between the server and other GNU Linux >>> machine. I'm using GSS-API in >>> Java >>> 1.6, and everything works fine. >>> >>> The problem comes when I run the same Java >>> code on a Windows XP SP3 >>> platform >>> with jdk 1.5.0_21 version installed. Just >>> before the context is created, >>> I >>> get the message: >>> >>> *Error calling function protocol status: >>> 1312. A specified logon session >>> does not exist. It may already have been >>> terminated.* >>> >>> But the most curious thing is that >>> execution >>> continues and secure >>> context >>> is >>> created indeed. I've also checked >>> *krb5kdc.log* and verified that both >>> TGT >>> ans TGS tickets are generated and >>> delivered >>> correctly. >>> >>> I've searched the web and I've found many >>> posible explanations, like: >>> >>> *"There is a problem with Windows API >>> FormatMessage usage in a non >>> English >>> locale"* - forums.sun >>> *"The identity associated with a >>> **KerberosToken2*< >>> >>> >>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>> * security token is being used for >>> constrained delegation, but >>> constrained >>> delegation is not configured >>> correctly."* - >>> msdn >>> *"There is a bug in Java 1.5"* - other >>> source >>> >>> ... but none of them convinces me. >>> So the cuestion is: Why is that message >>> appearing? Should I worry about >>> it? >>> How can I solve it? >>> >>> Thanks in advance! >>> >>> Regards, >>> Santi >>> >>> _______________________________________________ >>> krbdev mailing list >>> krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >>> _______________________________________________ >>> >>> krbdev mailing list krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >>> -- >>> >>> Douglas E. Engert >> > >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >>> >>> -- >>> Douglas E. Engert > >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> >>> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From raeburn at MIT.EDU Sun Oct 18 14:56:02 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Sun, 18 Oct 2009 14:56:02 -0400 Subject: svn rev #22919: branches/enc-perf/src/ include/ lib/crypto/krb/ lib/crypto/krb/dk/ In-Reply-To: <200910181828.n9IISR7D013031@drugstore.mit.edu> References: <200910181828.n9IISR7D013031@drugstore.mit.edu> Message-ID: <74572BBC-EC7E-4FD1-B078-1F73C0ABBFAD@mit.edu> Isn't this going to have thread safety problems, if two threads try to use the same key? They could collide updating the refcount, or updating the linked list pointers. Ken From ghudson at MIT.EDU Sun Oct 18 19:23:25 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Sun, 18 Oct 2009 19:23:25 -0400 Subject: svn rev #22919: branches/enc-perf/src/ include/ lib/crypto/krb/ lib/crypto/krb/dk/ In-Reply-To: <74572BBC-EC7E-4FD1-B078-1F73C0ABBFAD@mit.edu> References: <200910181828.n9IISR7D013031@drugstore.mit.edu> <74572BBC-EC7E-4FD1-B078-1F73C0ABBFAD@mit.edu> Message-ID: <1255908205.23997.117.camel@ray> On Sun, 2009-10-18 at 14:56 -0400, Ken Raeburn wrote: > Isn't this going to have thread safety problems, if two threads try to > use the same key? They could collide updating the refcount, or > updating the linked list pointers. I hadn't envisioned keys being sharable between threads, any more than contexts are. I can make that clearer in the comments. From lhoward at MIT.EDU Sun Oct 18 19:31:43 2009 From: lhoward at MIT.EDU (Luke Howard) Date: Sun, 18 Oct 2009 19:31:43 -0400 Subject: HDBBridge Message-ID: <94CC6276-7D06-4DC5-9536-6B54AD9A4DDC@mit.edu> A new project: http://k5wiki.kerberos.org/wiki/Projects/HDBBridge -- Luke From sanribu at gmail.com Mon Oct 19 06:21:32 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Mon, 19 Oct 2009 12:21:32 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> Message-ID: <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> It did help, Max! I started using kinit.exe from JDK and verified that credentials cache is stored, by default, in: "C:\Documents and Settings\santi\krb5cc_santi" <=> %HOMEPATH%\krb5cc_ Nothing new until here. But good news are that now *JVM is able to read credentials and obtain TGT from that cache* (which was my purpose). As you pointed out, my *jaas.conf* only specifies "useTicketCache=true", without any path to file, since I'm using the default settings. However, it's weird because if I set NIM to store credentials in the same location, the file is actually created, but then JVM throws the "1312 status" when it tries to read the cache. And this time the reason cannot be that "it's not finding the credentials cache" ... ?? Regards, Santi 2009/10/17 Max (Weijun) Wang > Sorry I'm not an expert on NIM. > > On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote: > > By the moment, my purpose is to *generate a TGT (anyhow, using kinit or >> NIM) >> and configure the cache so those credentials are stored in a file*, >> > > Then you can use any kinit.exe, the one from JDK or MIT. To use a file > cache, you don't need to care about the registry key mentioned by Douglas at > all. > > In fact, I had thought you were trying to use the LSA cache (non-file > in-memory Windows-specific cache). BTW, if you do want to use the LSA cache, > please make sure that the file cache is not there, since Java always try to > use the file cache first. You can check this out by calling the klist.exe > command in JDK. > > where Java will read them from later. >> >> *Step 1: Configure credentials cache* >> >> Since you told me to "*update the Identity object to use a FILE: ccache*", >> I >> went to >> >> NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) >> >> On "Kerberos v5" folder, I set the "Credential cache" option to >> *FILE:ccache >> *. And now I can see that a file named ccache is created or deleted >> everytime I generate or destroy the TGT. So I think now I have credentials >> cache configured properly. Am I right? >> >> *Step 2: Configure JAAS so that TGT is read from file (in order to obtain >> a >> TGS)* >> >> Here is my *jaas.conf* file for the client: >> >> *Client {* >> * com.sun.security.auth.module.Krb5LoginModule required* >> * useTicketCache=true* >> * ticketCache="c:\docume~1\santi\ccache";* >> *}* >> >> But when I run the client I get the following exception: >> >> *java.lang.SecurityException: Configuration Error :* >> * Line 4: expected [option key], found [null]* >> * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* >> * ...* >> > > I think Java is complaining about the ticketCache value. It does not like > Windows style "\" in path. You can try "\\" or "/". > > In fact, if you have not provided special argument to kinit, the cache file > should be generated at the default location, and you don't need to specify > ticketCache in the JAAS conf file at all. > > To debug, add "debug=true" into the JAAS conf file, *and* add > -Dsun.security.krb5.debug=true into you Java command line, you will see a > lot of things. > > Hope this helps > > Weijun (aka Max) > > >> I guess there some information missing about the credentials, but I don't >> know what. Any idea? >> >> I never tire for saying thank you! >> >> Regards, >> Santi >> >> 2009/10/16 Douglas E. Engert >> >> >>> >>> Santiago Rivas wrote: >>> >>> Ok, here is what I've done: >>>> I changed the JAAS config file, setting "useTicketCache=". >>>> That >>>> was enough to make de 1312 status error dissappear. But I'm still not >>>> able >>>> to configure the ticket caching properly. >>>> I forgot to mention that I have had already tried to set some file path >>>> under >>>> NIM: Options->Kerberos v5->Credential Cache ... with no results. >>>> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the >>>> text box and clicked the "Add" button, but it said something like "the >>>> credentials cache file was not found". If I only set the path to some >>>> folder >>>> (with no file name) there is no error message, but when I generate new >>>> tickets no file is created. I've reset the machine and verified that the >>>> user has privileges to access the path I'm typing son I don't known >>>> where >>>> I'm mistaking... ?? >>>> >>>> >>> Did you make the registry setting change as suggested bu both NIM and >>> Java? >>> >>> I don't think Java actually writes tickets to the cache. It just reads a >>> TGT >>> from the cache, then keeps tickets in memory. (I could be wrong) >>> The Java kinit.exe will write the TGT but I have never needed to use it. >>> Windows and NIM/KfW also have kinit.exe files so be careful which one you >>> are using. >>> >>> Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. >>> >>>> Regards, >>>> Santi >>>> 2009/10/14 Douglas E. Engert >>> deengert at anl.gov>> >>>> >>>> >>>> >>>> P.S. The other responder to your note, Weijun Wang, is the >>>> author of the Sun web page I listed below. Small world! >>>> >>>> >>>> Douglas E. Engert wrote: >>>> >>>> >>>> Santiago Rivas wrote: >>>> >>>> So, if I didn't misunderstood your words, I basically have >>>> at least 2 >>>> alternatives to achieve ticket collection from cache under >>>> Windows XP >>>> environment: >>>> >>>> 1) Configure Network Identity Manager to store credentials >>>> into a file, in >>>> order to read them from Java. >>>> >>>> >>>> One of the other responder to your first e-mail, Jeff Altman, is >>>> the >>>> developer of Network Identity Manager, and said: >>>> " Network Identity Manager can be configured to store the user's >>>> credentials in a FILE:: cache which can then be >>>> accessed via Java." >>>> >>>> Start by looking under Options->Kerberos v5->Credential Cache >>>> >>>> 2) Set up the configuration so that logon session is >>>> authenticated with >>>> Kerberos, and then retrieve the TGT ticket from LSA querying >>>> via JAAS. >>>> >>>> >>>> Also see this: >>>> >>>> >>>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>>> >>>> It talks about using the LSA, or the ticketCache=file options and >>>> the use of the "TGT accessibility" registry setting for >>>> allowtgtsessionkey. >>>> Network Identity Manager also uses this registry setting. >>>> >>>> (This registry setting may be you main issue!) >>>> >>>> Personally, I'm more interested on the second option, since >>>> the main target >>>> is to achieve single sign-on with kerberos. Anyway, I would >>>> appreciate to >>>> read some documentation on both tasks. Could you please tell >>>> me where I can >>>> find it? >>>> >>>> >>>> A third option is to use the Microsoft runas /netonly >>>> /user:user at realm program >>>> This will run the program with a new LSA. Program could be >>>> cmd.exe or even >>>> explorer.exe >>>> >>>> >>>> Thanks a lot, guys! >>>> >>>> Regards, >>>> Santi >>>> >>>> >>>> 2009/10/14 Douglas E. Engert >>> > >>>> >>>> >>>> Santiago Rivas wrote: >>>> >>>> Well, I do specify "useTicketCache=true" in the JAAS >>>> config file, but >>>> there >>>> is something I must be missing, cause I cannot get >>>> it working with cached >>>> tickets. In fact, I must provide username and >>>> password in the config file >>>> (or via command line). >>>> >>>> I can obtain TGT tickets with both Leash32 and >>>> Network Identity Manager >>>> tools, but I cannot see where they are stored, if >>>> cached (just the same as >>>> /tmp/krb5cc_1000 file in Linux...) ?? >>>> >>>> On Unix, with JXplorer, I can add >>>> -Duser.krb5ccname=$KRB5CCNAME >>>> to the command line, and the JXplorer gssapi.conf has: >>>> >>>> com.ca.commons.jndi.JNDIOps { >>>> com.sun.security.auth.module.Krb5LoginModule required >>>> client=TRUE >>>> ticketCache="${user.krb5ccname}" >>>> doNotPrompt=TRUE >>>> useTicketCache=TRUE; >>>> }; >>>> >>>> On Windows it does not have the ticketCache= line, >>>> but I think it could try it. >>>> >>>> If Leash32 or Network Identity Manager is storing them >>>> in a file, >>>> say \tmp\krb5cc_username >>>> you could try ticketCache=\tmp\krb5cc_username >>>> >>>> >>>> >>>> >>>> So may be the question should be: How do I configure >>>> the ticket cache in >>>> Windows? Is it mandatory to be configured through LSA? >>>> >>>> Thank you very much, Max! >>>> >>>> Regards, >>>> Santi >>>> >>>> 2009/10/14 Max (Weijun) Wang >>> > >>>> >>>> >>>> Java tries to get the credentials cache (ccache) >>>> from Windows LSA if you >>>> >>>> specify useTicketCache=true in the JAAS config >>>> file. In some cases, Java >>>> believes there's a ccache at the beginning, but >>>> finally it cannot get >>>> one. >>>> For example, you login as a AD account but then >>>> purge the TGT using klist >>>> or >>>> kerbtray. Then, you will see this error. >>>> >>>> Without the ccache, Java will try the Kerberos >>>> login itself, you'll need >>>> to >>>> provide username and password in your program. >>>> >>>> -- Max >>>> >>>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>>> >>>> Hi again, >>>> >>>> After some tough work, it seems I've got my >>>> test environment configured >>>> and >>>> working with DHCP server, DNS server, ldap >>>> and Domain Controller, >>>> running >>>> on >>>> a GNU Linux Debian platform. I've also >>>> configured KDC + AS services on >>>> that >>>> machine, and I'm glad to see that I'm able >>>> to create a secure context >>>> between the server and other GNU Linux >>>> machine. I'm using GSS-API in >>>> Java >>>> 1.6, and everything works fine. >>>> >>>> The problem comes when I run the same Java >>>> code on a Windows XP SP3 >>>> platform >>>> with jdk 1.5.0_21 version installed. Just >>>> before the context is created, >>>> I >>>> get the message: >>>> >>>> *Error calling function protocol status: >>>> 1312. A specified logon session >>>> does not exist. It may already have been >>>> terminated.* >>>> >>>> But the most curious thing is that execution >>>> continues and secure >>>> context >>>> is >>>> created indeed. I've also checked >>>> *krb5kdc.log* and verified that both >>>> TGT >>>> ans TGS tickets are generated and delivered >>>> correctly. >>>> >>>> I've searched the web and I've found many >>>> posible explanations, like: >>>> >>>> *"There is a problem with Windows API >>>> FormatMessage usage in a non >>>> English >>>> locale"* - forums.sun >>>> *"The identity associated with a >>>> **KerberosToken2*< >>>> >>>> >>>> >>>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>>> * security token is being used for >>>> constrained delegation, but >>>> constrained >>>> delegation is not configured correctly."* - >>>> msdn >>>> *"There is a bug in Java 1.5"* - other source >>>> >>>> ... but none of them convinces me. >>>> So the cuestion is: Why is that message >>>> appearing? Should I worry about >>>> it? >>>> How can I solve it? >>>> >>>> Thanks in advance! >>>> >>>> Regards, >>>> Santi >>>> _______________________________________________ >>>> krbdev mailing list >>>> krbdev at mit.edu >>>> >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>>> _______________________________________________ >>>> >>>> krbdev mailing list krbdev at mit.edu >>>> >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>>> >>>> -- >>>> >>>> Douglas E. Engert >>> > >>>> Argonne National Laboratory >>>> 9700 South Cass Avenue >>>> Argonne, Illinois 60439 >>>> (630) 252-5444 >>>> >>>> _______________________________________________ >>>> krbdev mailing list krbdev at mit.edu >>>> >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>>> >>>> >>>> -- >>>> Douglas E. Engert > >>>> Argonne National Laboratory >>>> 9700 South Cass Avenue >>>> Argonne, Illinois 60439 >>>> (630) 252-5444 >>>> >>>> >>>> >>>> -- >>> >>> Douglas E. Engert >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> > > From Weijun.Wang at sun.com Mon Oct 19 06:27:13 2009 From: Weijun.Wang at sun.com (Max (Weijun) Wang) Date: Mon, 19 Oct 2009 18:27:13 +0800 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140716m3f819c0i728c8d2a0b445fcc@mail.gmail.com> <4AD5F5C8.6010301@anl.gov> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> Message-ID: <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> Java first looks for cache from the file and then from LSA. If you see the 1312 error it means there's no cache in the file. Maybe the principal name is not the same with your JAAS conf setting? Or, NIM generates a file Java cannot parse. Can you show the content of the cache with klist.exe in JDK (not the one from Microsoft)? Also, add -Dsun.security.krb5.debug=true to your Java program and see what debug output is saying. -- Max On Oct 19, 2009, at 6:21 PM, Santiago Rivas wrote: > It did help, Max! > > I started using kinit.exe from JDK and verified that credentials > cache is stored, by default, in: > > "C:\Documents and Settings\santi\krb5cc_santi" <=> %HOMEPATH% > \krb5cc_ > > Nothing new until here. But good news are that now JVM is able to > read credentials and obtain TGT from that cache (which was my > purpose). As you pointed out, my jaas.conf only specifies > "useTicketCache=true", without any path to file, since I'm using the > default settings. > However, it's weird because if I set NIM to store credentials in the > same location, the file is actually created, but then JVM throws the > "1312 status" when it tries to read the cache. And this time the > reason cannot be that "it's not finding the credentials cache" ... ?? > > Regards, > Santi > > > 2009/10/17 Max (Weijun) Wang > Sorry I'm not an expert on NIM. > > > On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote: > > By the moment, my purpose is to *generate a TGT (anyhow, using kinit > or NIM) > and configure the cache so those credentials are stored in a file*, > > Then you can use any kinit.exe, the one from JDK or MIT. To use a > file cache, you don't need to care about the registry key mentioned > by Douglas at all. > > In fact, I had thought you were trying to use the LSA cache (non- > file in-memory Windows-specific cache). BTW, if you do want to use > the LSA cache, please make sure that the file cache is not there, > since Java always try to use the file cache first. You can check > this out by calling the klist.exe command in JDK. > > > where Java will read them from later. > > *Step 1: Configure credentials cache* > > Since you told me to "*update the Identity object to use a FILE: > ccache*", I > went to > > NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) > > On "Kerberos v5" folder, I set the "Credential cache" option to > *FILE:ccache > *. And now I can see that a file named ccache is created or deleted > everytime I generate or destroy the TGT. So I think now I have > credentials > cache configured properly. Am I right? > > *Step 2: Configure JAAS so that TGT is read from file (in order to > obtain a > TGS)* > > Here is my *jaas.conf* file for the client: > > *Client {* > * com.sun.security.auth.module.Krb5LoginModule required* > * useTicketCache=true* > * ticketCache="c:\docume~1\santi\ccache";* > *}* > > But when I run the client I get the following exception: > > *java.lang.SecurityException: Configuration Error :* > * Line 4: expected [option key], found [null]* > * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* > * ...* > > I think Java is complaining about the ticketCache value. It does not > like Windows style "\" in path. You can try "\\" or "/". > > In fact, if you have not provided special argument to kinit, the > cache file should be generated at the default location, and you > don't need to specify ticketCache in the JAAS conf file at all. > > To debug, add "debug=true" into the JAAS conf file, *and* add - > Dsun.security.krb5.debug=true into you Java command line, you will > see a lot of things. > > Hope this helps > > Weijun (aka Max) > > > I guess there some information missing about the credentials, but I > don't > know what. Any idea? > > I never tire for saying thank you! > > Regards, > Santi > > 2009/10/16 Douglas E. Engert > > > > Santiago Rivas wrote: > > Ok, here is what I've done: > I changed the JAAS config file, setting "useTicketCache=". > That > was enough to make de 1312 status error dissappear. But I'm still > not able > to configure the ticket caching properly. > I forgot to mention that I have had already tried to set some file > path > under > NIM: Options->Kerberos v5->Credential Cache ... with no results. > I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the > text box and clicked the "Add" button, but it said something like "the > credentials cache file was not found". If I only set the path to > some folder > (with no file name) there is no error message, but when I generate new > tickets no file is created. I've reset the machine and verified that > the > user has privileges to access the path I'm typing son I don't known > where > I'm mistaking... ?? > > > Did you make the registry setting change as suggested bu both NIM > and Java? > > I don't think Java actually writes tickets to the cache. It just > reads a > TGT > from the cache, then keeps tickets in memory. (I could be wrong) > The Java kinit.exe will write the TGT but I have never needed to > use it. > Windows and NIM/KfW also have kinit.exe files so be careful which > one you > are using. > > Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. > Regards, > Santi > 2009/10/14 Douglas E. Engert >> > > > > P.S. The other responder to your note, Weijun Wang, is the > author of the Sun web page I listed below. Small world! > > > Douglas E. Engert wrote: > > > Santiago Rivas wrote: > > So, if I didn't misunderstood your words, I basically have > at least 2 > alternatives to achieve ticket collection from cache under > Windows XP > environment: > > 1) Configure Network Identity Manager to store credentials > into a file, in > order to read them from Java. > > > One of the other responder to your first e-mail, Jeff Altman, is > the > developer of Network Identity Manager, and said: > " Network Identity Manager can be configured to store the user's > credentials in a FILE:: cache which can then be > accessed via Java." > > Start by looking under Options->Kerberos v5->Credential Cache > > 2) Set up the configuration so that logon session is > authenticated with > Kerberos, and then retrieve the TGT ticket from LSA querying > via JAAS. > > > Also see this: > > http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html > > It talks about using the LSA, or the ticketCache=file options and > the use of the "TGT accessibility" registry setting for > allowtgtsessionkey. > Network Identity Manager also uses this registry setting. > > (This registry setting may be you main issue!) > > Personally, I'm more interested on the second option, since > the main target > is to achieve single sign-on with kerberos. Anyway, I would > appreciate to > read some documentation on both tasks. Could you please tell > me where I can > find it? > > > A third option is to use the Microsoft runas /netonly > /user:user at realm program > This will run the program with a new LSA. Program could be > cmd.exe or even > explorer.exe > > > Thanks a lot, guys! > > Regards, > Santi > > > 2009/10/14 Douglas E. Engert > > > > Santiago Rivas wrote: > > Well, I do specify "useTicketCache=true" in the JAAS > config file, but > there > is something I must be missing, cause I cannot get > it working with cached > tickets. In fact, I must provide username and > password in the config file > (or via command line). > > I can obtain TGT tickets with both Leash32 and > Network Identity Manager > tools, but I cannot see where they are stored, if > cached (just the same as > /tmp/krb5cc_1000 file in Linux...) ?? > > On Unix, with JXplorer, I can add > -Duser.krb5ccname=$KRB5CCNAME > to the command line, and the JXplorer gssapi.conf has: > > com.ca.commons.jndi.JNDIOps { > com.sun.security.auth.module.Krb5LoginModule required > client=TRUE > ticketCache="${user.krb5ccname}" > doNotPrompt=TRUE > useTicketCache=TRUE; > }; > > On Windows it does not have the ticketCache= line, > but I think it could try it. > > If Leash32 or Network Identity Manager is storing them > in a file, > say \tmp\krb5cc_username > you could try ticketCache=\tmp\krb5cc_username > > > > > So may be the question should be: How do I configure > the ticket cache in > Windows? Is it mandatory to be configured through > LSA? > > Thank you very much, Max! > > Regards, > Santi > > 2009/10/14 Max (Weijun) Wang > > > > Java tries to get the credentials cache (ccache) > from Windows LSA if you > > specify useTicketCache=true in the JAAS config > file. In some cases, Java > believes there's a ccache at the beginning, but > finally it cannot get > one. > For example, you login as a AD account but then > purge the TGT using klist > or > kerbtray. Then, you will see this error. > > Without the ccache, Java will try the Kerberos > login itself, you'll need > to > provide username and password in your program. > > -- Max > > On Oct 14, 2009, at 6:55 PM, Santiago Rivas > wrote: > > Hi again, > > After some tough work, it seems I've got my > test environment configured > and > working with DHCP server, DNS server, ldap > and Domain Controller, > running > on > a GNU Linux Debian platform. I've also > configured KDC + AS services on > that > machine, and I'm glad to see that I'm able > to create a secure context > between the server and other GNU Linux > machine. I'm using GSS-API in > Java > 1.6, and everything works fine. > > The problem comes when I run the same Java > code on a Windows XP SP3 > platform > with jdk 1.5.0_21 version installed. Just > before the context is created, > I > get the message: > > *Error calling function protocol status: > 1312. A specified logon session > does not exist. It may already have been > terminated.* > > But the most curious thing is that execution > continues and secure > context > is > created indeed. I've also checked > *krb5kdc.log* and verified that both > TGT > ans TGS tickets are generated and delivered > correctly. > > I've searched the web and I've found many > posible explanations, like: > > *"There is a problem with Windows API > FormatMessage usage in a non > English > locale"* - forums.sun > *"The identity associated with a > **KerberosToken2*< > > > http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx > * security token is being used for > constrained delegation, but > constrained > delegation is not configured correctly."* - > msdn > *"There is a bug in Java 1.5"* - other source > > ... but none of them convinces me. > So the cuestion is: Why is that message > appearing? Should I worry about > it? > How can I solve it? > > Thanks in advance! > > Regards, > Santi > > _______________________________________________ > krbdev mailing list > krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > _______________________________________________ > > krbdev mailing list krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > > -- > > Douglas E. Engert > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > > https://mailman.mit.edu/mailman/listinfo/krbdev > > > > > -- > Douglas E. Engert > > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > From raeburn at MIT.EDU Mon Oct 19 08:03:35 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 19 Oct 2009 08:03:35 -0400 Subject: svn rev #22919: branches/enc-perf/src/ include/ lib/crypto/krb/ lib/crypto/krb/dk/ In-Reply-To: <1255908205.23997.117.camel@ray> References: <200910181828.n9IISR7D013031@drugstore.mit.edu> <74572BBC-EC7E-4FD1-B078-1F73C0ABBFAD@mit.edu> <1255908205.23997.117.camel@ray> Message-ID: <29CAC597-1368-4E03-AD9A-A815AF880C8D@mit.edu> On Oct 18, 2009, at 19:23, Greg Hudson wrote: > I hadn't envisioned keys being sharable between threads, any more than > contexts are. I can make that clearer in the comments. Contexts and auth contexts wouldn't be shared, but code using lower- level calls might conceivably share keys -- e.g., decrypt incoming messages in one thread, encrypt outgoing messages in another. Since the key data is essentially read-only in those calls in existing releases, it would work fine. I don't recall if we ever specified whether key data was shareable across threads, but I think I would've probably said it was. (I also ran across some email in the archives of this very list from someone wanting to do crypto work in multiple threads. Since that involved GSSAPI, there are other issues like sequence numbers that make it problematic, but still, the desire is there, and if it were the krb5 crypto API in use, it probably would've worked.) Ken From epeisach at MIT.EDU Mon Oct 19 19:30:25 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Mon, 19 Oct 2009 19:30:25 -0400 Subject: enc_perf merge causes crypto library to leak like a sieve.... Message-ID: <4ADCF691.3050005@mit.edu> Running valgrind on the various crypto_tests show memory leaks... For the trunk pre-merge there aren't any leaks (at least for the limited tests I have done)... Looks like a big leak in the yarrow code to start with.... 170 blocks below - within yarrow - seems excessive... For instance t_encrypt: ==24759== ==24759== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1) ==24759== malloc/free: in use at exit: 4,524 bytes in 239 blocks. ==24759== malloc/free: 1,434 allocs, 1,195 frees, 50,710 bytes allocated. ==24759== For counts of detected errors, rerun with: -v ==24759== searching for pointers to 239 not-freed blocks. ==24759== checked 116,668 bytes. ==24759== ==24759== 300 bytes in 60 blocks are definitely lost in loss record 2 of 3 ==24759== at 0x4006F3D: malloc (vg_replace_malloc.c:207) ==24759== by 0x40CB77B: krb5_derive_key (derive.c:55) ==24759== by 0x40CAF5F: krb5_dk_encrypt (dk_encrypt.c:93) ==24759== by 0x40E0466: krb5_k_encrypt (encrypt.c:54) ==24759== by 0x40E054E: krb5_c_encrypt (encrypt.c:69) ==24759== by 0x8048E78: main (t_encrypt.c:134) ==24759== ==24759== ==24759== 4,224 (4,080 direct, 144 indirect) bytes in 170 blocks are definitely lost in loss record 3 of 3 ==24759== at 0x4006F3D: malloc (vg_replace_malloc.c:207) ==24759== by 0x40E0A8E: krb5_k_create_key (key.c:45) ==24759== by 0x40D070B: krb5int_yarrow_cipher_init (ycipher.c:61) ==24759== by 0x40D04B2: krb5int_yarrow_init (yarrow.c:198) ==24759== by 0x40E28F9: krb5int_prng_init (prng.c:69) ==24759== by 0x40DFE00: cryptoint_initialize_library__aux (crypto_libinit.c:16) ==24759== by 0x40DFE94: krb5int_crypto_init (crypto_libinit.c:21) ==24759== by 0x40E2631: krb5_c_random_add_entropy (prng.c:89) ==24759== by 0x40E28BB: krb5_c_random_seed (prng.c:104) ==24759== by 0x8048C36: main (t_encrypt.c:97) ==24759== ==24759== LEAK SUMMARY: ==24759== definitely lost: 4,380 bytes in 230 blocks. ==24759== indirectly lost: 144 bytes in 9 blocks. ==24759== possibly lost: 0 bytes in 0 blocks. ==24759== still reachable: 0 bytes in 0 blocks. ==24759== suppressed: 0 bytes in 0 blocks. [epeisach at beast crypto_tests]$ Ezra From epeisach at MIT.EDU Mon Oct 19 20:21:52 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Mon, 19 Oct 2009 20:21:52 -0400 Subject: enc_perf merge causes crypto library to leak like a sieve.... In-Reply-To: <4ADCF691.3050005@mit.edu> References: <4ADCF691.3050005@mit.edu> Message-ID: <4ADD02A0.7090603@mit.edu> I have tracked down one leak.... in krb5int_yarrow_cipher_init the code looks like: krb5_k_free_key(NULL, ctx->key); ctx->key = NULL; . . . ret = krb5_k_create_key(NULL, &keyblock, &ctx->key); krb5_k_create_key allocates ctx->key and copies the keyblock contents but krb5_k_free_key only frees the keyblock contents - but not ctx->key. So - either the fix in ycipher.c is to free ctx->key before setting it to NULL - or krb5_k_free_key needs to be modified.... I leave it to Greg or someone better familiar with the intention on how to proceed - but I think krb5_k_free_key needs the modification.... Ezra Ezra Peisach wrote: > Running valgrind on the various crypto_tests show memory leaks... For > the trunk pre-merge there aren't any leaks (at least for the limited > tests I have done)... > > Looks like a big leak in the yarrow code to start with.... 170 blocks > below - within yarrow - seems excessive... > > For instance t_encrypt: > > > ==24759== > ==24759== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 23 from 1) > ==24759== malloc/free: in use at exit: 4,524 bytes in 239 blocks. > ==24759== malloc/free: 1,434 allocs, 1,195 frees, 50,710 bytes allocated. > ==24759== For counts of detected errors, rerun with: -v > ==24759== searching for pointers to 239 not-freed blocks. > ==24759== checked 116,668 bytes. > ==24759== > ==24759== 300 bytes in 60 blocks are definitely lost in loss record 2 of 3 > ==24759== at 0x4006F3D: malloc (vg_replace_malloc.c:207) > ==24759== by 0x40CB77B: krb5_derive_key (derive.c:55) > ==24759== by 0x40CAF5F: krb5_dk_encrypt (dk_encrypt.c:93) > ==24759== by 0x40E0466: krb5_k_encrypt (encrypt.c:54) > ==24759== by 0x40E054E: krb5_c_encrypt (encrypt.c:69) > ==24759== by 0x8048E78: main (t_encrypt.c:134) > ==24759== > ==24759== > ==24759== 4,224 (4,080 direct, 144 indirect) bytes in 170 blocks are > definitely lost in loss record 3 of 3 > ==24759== at 0x4006F3D: malloc (vg_replace_malloc.c:207) > ==24759== by 0x40E0A8E: krb5_k_create_key (key.c:45) > ==24759== by 0x40D070B: krb5int_yarrow_cipher_init (ycipher.c:61) > ==24759== by 0x40D04B2: krb5int_yarrow_init (yarrow.c:198) > ==24759== by 0x40E28F9: krb5int_prng_init (prng.c:69) > ==24759== by 0x40DFE00: cryptoint_initialize_library__aux > (crypto_libinit.c:16) > ==24759== by 0x40DFE94: krb5int_crypto_init (crypto_libinit.c:21) > ==24759== by 0x40E2631: krb5_c_random_add_entropy (prng.c:89) > ==24759== by 0x40E28BB: krb5_c_random_seed (prng.c:104) > ==24759== by 0x8048C36: main (t_encrypt.c:97) > ==24759== > ==24759== LEAK SUMMARY: > ==24759== definitely lost: 4,380 bytes in 230 blocks. > ==24759== indirectly lost: 144 bytes in 9 blocks. > ==24759== possibly lost: 0 bytes in 0 blocks. > ==24759== still reachable: 0 bytes in 0 blocks. > ==24759== suppressed: 0 bytes in 0 blocks. > [epeisach at beast crypto_tests]$ > > > Ezra > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > From ghudson at MIT.EDU Mon Oct 19 22:07:25 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 19 Oct 2009 22:07:25 -0400 Subject: enc_perf merge causes crypto library to leak like a sieve.... In-Reply-To: <4ADCF691.3050005@mit.edu> References: <4ADCF691.3050005@mit.edu> Message-ID: <1256004445.23997.178.camel@ray> I fixed three memory leaks (the two big ones were missing stuff in krb5_k_free_key) and verified that t_encrypt runs clean. From tlyu at MIT.EDU Mon Oct 19 23:48:06 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 19 Oct 2009 23:48:06 -0400 Subject: nightly snapshots resumed Message-ID: Due to a set of unexpected configuration changes not under our control, nightly snapshots of the krb5 source tree ceased to be published to the FTP server for a while. These configurations have been adjusted so that the snapshots will function correctly. As of Oct. 17, the snapshots are once again published to the FTP server. For more information about the nightly snapshots, please see: http://web.mit.edu/kerberos/krb5-current.html -- Tom Yu Development Team Leader MIT Kerberos Consortium From lukeh at padl.com Tue Oct 20 09:39:50 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 20 Oct 2009 09:39:50 -0400 Subject: Lockout In-Reply-To: <1254930961.9616.98.camel@ray> References: <1254930961.9616.98.camel@ray> Message-ID: <046C34F1-32F9-4D3D-B428-62E46C121511@padl.com> On 07/10/2009, at 11:56 AM, Greg Hudson wrote: > A few weeks ago, I asked Luke to think about whether it is really > necessary to add a "lockout time" attribute for the purposes of > account > lockout. Because the lockout time attribute is new (the other three > attributes already exist in the DB schema), it adds additional code > complexity because it must be represented in TL data. My idea is that > you can deduce whether the account is locked out from the fail count, > and can determine the time of lockout from the last preauth failure > time. > > I believe I mostly have Luke convinced, but we agreed that I should > bring the issue up for discussion here before he does the work of > simplifying the code. The work has been done and is in the users/lhoward/lockout2 branch. -- Luke From tsitkova at MIT.EDU Tue Oct 20 10:39:05 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Tue, 20 Oct 2009 10:39:05 -0400 Subject: export list symbols Message-ID: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> Hello! As part of the crypto modularity effort I have done a simple analysis of libk5crypto.export list and suggest to remove some of the symbols from this list. It may be done without hurting the kerb libs (link) integrity reducing the number of the symbols from ~160 to ~70. The attached libk5crypto.export_extras contains the list of the candidates for the removal. The updated libk5crypto.exports is also attached. Also, I suggest to rename the following APIs by prefixing them krb5int_ instead of krb5_ as these functions do not belong to the public API group. krb5_c_weak_enctype krb5_encrypt_data krb5_hmac krb5_arcfour_decrypt krb5_arcfour_encrypt krb5_arcfour_encrypt_length krb5_cksumtypes_length krb5_cksumtypes_list krb5_decrypt_data krb5_derive_key krb5_derive_random krb5_dk_decrypt krb5_dk_encrypt krb5_dk_encrypt_length krb5_dk_make_checksum krb5_enctypes_length krb5_enctypes_list krb5_MD4Final krb5_MD4Init krb5_MD4Update krb5_MD5Final krb5_MD5Init krb5_MD5Update krb5_nfold krb5_old_decrypt krb5_old_encrypt krb5_old_encrypt_length krb5_random_confounder krb5_raw_decrypt krb5_raw_encrypt Thanks, Zhanna From Nicolas.Williams at sun.com Tue Oct 20 11:08:21 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 10:08:21 -0500 Subject: export list symbols In-Reply-To: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> Message-ID: <20091020150821.GS892@Sun.COM> On Tue, Oct 20, 2009 at 10:39:05AM -0400, Zhanna Tsitkova wrote: > As part of the crypto modularity effort I have done a simple analysis > of libk5crypto.export list and suggest to remove some of the symbols > from this list. It may be done without hurting the kerb libs (link) > integrity reducing the number of the symbols from ~160 to ~70. The > attached libk5crypto.export_extras contains the list of the candidates > for the removal. The updated libk5crypto.exports is also attached. > > Also, I suggest to rename the following APIs by prefixing them > krb5int_ instead of krb5_ as these functions do not belong to the > public API group. How do you know this? There may be third party apps that do use these symbols, even if that seems wrong. Some interfaces may be legacy; some should never have been exported but were. > krb5_c_weak_enctype I don't know what krb5_c_weak_enctype() does, but it sounds potentially useful. At least these > krb5_nfold > krb5_derive_key > krb5_derive_random seems like public interfaces: any function that seems private, but which actually implements an interface from RFC3961 should be public since there may be krb5 applications and/or plugins that need them. Pre-auth and other plugins definitely have a legitimate need to use RFC3961 interfaces, but "raw" krb5 apps too have a legitimate need to use those. These: > krb5_encrypt_data > krb5_hmac > krb5_arcfour_decrypt krb5_arcfour_encrypt krb5_arcfour_encrypt_length > krb5_cksumtypes_length krb5_cksumtypes_list > krb5_decrypt_data > krb5_dk_decrypt krb5_dk_encrypt krb5_dk_encrypt_length krb5_dk_make_checksum > krb5_enctypes_length krb5_enctypes_list > krb5_MD4Final krb5_MD4Init krb5_MD4Update > krb5_MD5Final krb5_MD5Init krb5_MD5Update > krb5_old_decrypt krb5_old_encrypt krb5_old_encrypt_length > krb5_random_confounder > krb5_raw_decrypt krb5_raw_encrypt sure look like they are not intended for applications, or worse, legacy, but I've not looked carefully at which might be RFC3961 interfaces. Nico -- From tsitkova at MIT.EDU Tue Oct 20 11:36:30 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Tue, 20 Oct 2009 11:36:30 -0400 Subject: export list symbols In-Reply-To: <20091020150821.GS892@Sun.COM> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu>, <20091020150821.GS892@Sun.COM> Message-ID: <8DD7AD829AB61E499A433D6E558110A3144F14C9@EXPO7.exchange.mit.edu> The new libk5crypto.exports was generated based on the presence of the APIs from the original libk5crypto.exports in the kerb public headers and link requirements. Thanks, Zhanna ________________________________________ From: Nicolas Williams [Nicolas.Williams at sun.com] Sent: Tuesday, October 20, 2009 11:08 AM To: Zhanna Tsitkova Cc: krbdev at mit.edu Subject: Re: export list symbols On Tue, Oct 20, 2009 at 10:39:05AM -0400, Zhanna Tsitkova wrote: > As part of the crypto modularity effort I have done a simple analysis > of libk5crypto.export list and suggest to remove some of the symbols > from this list. It may be done without hurting the kerb libs (link) > integrity reducing the number of the symbols from ~160 to ~70. The > attached libk5crypto.export_extras contains the list of the candidates > for the removal. The updated libk5crypto.exports is also attached. > > Also, I suggest to rename the following APIs by prefixing them > krb5int_ instead of krb5_ as these functions do not belong to the > public API group. How do you know this? There may be third party apps that do use these symbols, even if that seems wrong. Some interfaces may be legacy; some should never have been exported but were. > krb5_c_weak_enctype I don't know what krb5_c_weak_enctype() does, but it sounds potentially useful. At least these > krb5_nfold > krb5_derive_key > krb5_derive_random seems like public interfaces: any function that seems private, but which actually implements an interface from RFC3961 should be public since there may be krb5 applications and/or plugins that need them. Pre-auth and other plugins definitely have a legitimate need to use RFC3961 interfaces, but "raw" krb5 apps too have a legitimate need to use those. These: > krb5_encrypt_data > krb5_hmac > krb5_arcfour_decrypt krb5_arcfour_encrypt krb5_arcfour_encrypt_length > krb5_cksumtypes_length krb5_cksumtypes_list > krb5_decrypt_data > krb5_dk_decrypt krb5_dk_encrypt krb5_dk_encrypt_length krb5_dk_make_checksum > krb5_enctypes_length krb5_enctypes_list > krb5_MD4Final krb5_MD4Init krb5_MD4Update > krb5_MD5Final krb5_MD5Init krb5_MD5Update > krb5_old_decrypt krb5_old_encrypt krb5_old_encrypt_length > krb5_random_confounder > krb5_raw_decrypt krb5_raw_encrypt sure look like they are not intended for applications, or worse, legacy, but I've not looked carefully at which might be RFC3961 interfaces. Nico -- From ghudson at MIT.EDU Tue Oct 20 11:57:06 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 20 Oct 2009 11:57:06 -0400 Subject: export list symbols In-Reply-To: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> Message-ID: <1256054226.23997.232.camel@ray> On Tue, 2009-10-20 at 10:39 -0400, Zhanna Tsitkova wrote: > krb5_c_weak_enctype Tom, you prototyped this in k5-int.h but otherwise defined it in a way appropriate for an API function. What was your thinking on this? In my opinion, we shouldn't define internal functions with "might become part of the API in mind"; it's better to rename the symbol in the future if and when we decide to actually put it in the API. > krb5_encrypt_data krb5_encrypt_data, krb5_decrypt_data, and krb5_random_confounder are "old APIs" which aren't actually prototyped in krb5.h (they are prototyped in k5-int.h). If we're going to rename them, we may as well delete them. I'm all in favor of deleting them, but maybe somebody knows some history about them to suggest that would be a bad idea. (Actually, we use krb5_encrypt_data in two places in the preauth framework, but we should stop that.) > krb5_derive_random Oddly, we don't seem to use this anywhere but in a test program. Does anyone know what it's for? Nico wrote: > How do you know this? There may be third party apps that do use these > symbols, even if that seems wrong. Some interfaces may be legacy; > some should never have been exported but were. Our policy has generally been that if a symbol isn't prototyped in krb5.h, it isn't a stable API even if it begins with "krb5_", although we should rename it if we change the symbol's API or ABI. (This is so that apps at least break cleanly if they used it, and so that configure-time tests don't find it in the library.) We've made use of this policy in the past, such as renaming krb5_send_tgs to krb5int_send_tgs for the FAST work in 1.7, and so far haven't received any negative feedback on it. If people have case-by-case reasons to believe that someone has used a particular symbol despite the lack of a prototype, then we should preserve compatibility, but I don't want to be paralyzed by the faint possibility that someone might have done so in every case. Nico specifically mentioned: > krb5_nfold > krb5_derive_key > krb5_derive_random [...] > any function that seems private, but > which actually implements an interface from RFC3961 should be public > since there may be krb5 applications and/or plugins that need them. If people agree that we should provide public APIs for all RFC 3961 operations we implement, then we can prototype these in krb5.hin, possibly under new names. (We don't actually use krb5_derive_random anywhere, so that would become the only use of that function.) I should note that as part of the enc-perf work I changed the signatures of krb5_derive_key and krb5_derive_random, and also krb5_hmac. So those should definitely be renamed; I will make a note to make sure that gets taken care of before 1.8. From Nicolas.Williams at sun.com Tue Oct 20 11:45:45 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 10:45:45 -0500 Subject: export list symbols In-Reply-To: <8DD7AD829AB61E499A433D6E558110A3144F14C9@EXPO7.exchange.mit.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <20091020150821.GS892@Sun.COM> <8DD7AD829AB61E499A433D6E558110A3144F14C9@EXPO7.exchange.mit.edu> Message-ID: <20091020154545.GB892@Sun.COM> On Tue, Oct 20, 2009 at 11:36:30AM -0400, Zhanna Tsitkova wrote: > The new libk5crypto.exports was generated based on the presence of the > APIs from the original libk5crypto.exports in the kerb public headers > and link requirements. What does "link requirements" mean though? It sounds like you looked for consumers and found none. But did you look hard enough? And are you sure that "no consumers" implies "not public"? IMO this requires more than automated static analysis. You have to look at each of the potentially-private interfaces and decide if it should be public in spite of there being no use for it that you can find. Conversely, just because you can find one application and/or plugin use of some symbol doesn't mean it should be exported -- that application's use of that symbol might be a bug, along with the symbol's being exported. If you can find no other such apps, and if you can fix that app, then you can make that symbol private, IF it really should be private. In both cases you need to do a fairly exhaustive search for consumers. In both cases you need to individualize the decision for each interface. Automated static analysis is not sufficient for making these kinds of decisions. Nico -- From Nicolas.Williams at sun.com Tue Oct 20 12:07:55 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 11:07:55 -0500 Subject: export list symbols In-Reply-To: <1256054226.23997.232.camel@ray> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> Message-ID: <20091020160755.GC892@Sun.COM> I think I missed that these were functions not listed in krb5.h. If a function is in a private header then I agree that automated static analysis is sufficient for deciding whether to make it not an exported symbol. Except for private-that-should-be-public symbols, of course, but that can be revisited later. On Tue, Oct 20, 2009 at 11:57:06AM -0400, Greg Hudson wrote: > > any function that seems private, but > > which actually implements an interface from RFC3961 should be public > > since there may be krb5 applications and/or plugins that need them. > > If people agree that we should provide public APIs for all RFC 3961 > operations we implement, then we can prototype these in krb5.hin, > possibly under new names. (We don't actually use krb5_derive_random > anywhere, so that would become the only use of that function.) Well, MIT krb5 has a plugin interface for preauth methods. Pre-auth methods may well (and PKINIT sure does) make use of RFC3961 interfaces. Ergo RFC3961 interfaces should really be exported, at least to plugins. It's hard to export to plugins but not to apps, but it can be done if you have the framework pass a set of function pointers to the plugin (and you can always segregate for-plugin vs. for-all declarations by header). But also, RFC3961 is not intended to be a mere detail of Kerberos protocol construction: "raw" krb5 apps that extract session keys and make use of krb5 enctypes directly are legitimate users of RFC3961. Think of TELNET and AFS, which, I know are not exactly good examples here (in large part because they pre-date RFC3961), but they are good examples of apps which, if they really had to avoid KRB-SAFE/PRIV or the GSS-API (e.g., because of per-token/message overhead), then really should have used _a_ cryptographic protocol framework, of which RFC3961 is a reasonable example. IMO Kerberos implementors SHOULD export RFC3961 interfaces. Nico -- From jhutz at cmu.edu Tue Oct 20 13:12:12 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 20 Oct 2009 13:12:12 -0400 Subject: export list symbols In-Reply-To: <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> Message-ID: <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> --On Tuesday, October 20, 2009 11:07:55 AM -0500 Nicolas Williams wrote: > I think I missed that these were functions not listed in krb5.h. If a > function is in a private header then I agree that automated static > analysis is sufficient for deciding whether to make it not an exported > symbol. Except for private-that-should-be-public symbols, of course, > but that can be revisited later. What about symbols which were previously removed from the public headers (or were never prototyped), but remain exported to maintain backward compatibility with existing users? -- Jeff From raeburn at MIT.EDU Tue Oct 20 13:19:15 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 20 Oct 2009 13:19:15 -0400 Subject: export list symbols In-Reply-To: <1256054226.23997.232.camel@ray> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> Message-ID: <04DF17E3-3800-44A8-9EEA-A474BDC2C359@mit.edu> On Oct 20, 2009, at 11:57, Greg Hudson wrote: >> krb5_derive_random > > Oddly, we don't seem to use this anywhere but in a test program. Does > anyone know what it's for? I think it's exported specifically for testing; see RFC 3961, A.3. It can probably be made internal and available through the accessor function. You could get rid of the test case, if you want, but I think it's better to be able to produce the intermediate values when debugging a problem. Ken From Nicolas.Williams at sun.com Tue Oct 20 13:12:16 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 12:12:16 -0500 Subject: export list symbols In-Reply-To: <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> Message-ID: <20091020171215.GE892@Sun.COM> On Tue, Oct 20, 2009 at 01:12:12PM -0400, Jeffrey Hutzelman wrote: > --On Tuesday, October 20, 2009 11:07:55 AM -0500 Nicolas Williams > wrote: > > >I think I missed that these were functions not listed in krb5.h. If a > >function is in a private header then I agree that automated static > >analysis is sufficient for deciding whether to make it not an exported > >symbol. Except for private-that-should-be-public symbols, of course, > >but that can be revisited later. > > What about symbols which were previously removed from the public headers > (or were never prototyped), but remain exported to maintain backward > compatibility with existing users? I'd forgotten that there were such symbols. From simon at sxw.org.uk Tue Oct 20 13:39:53 2009 From: simon at sxw.org.uk (Simon Wilkinson) Date: Tue, 20 Oct 2009 18:39:53 +0100 Subject: export list symbols In-Reply-To: <20091020160755.GC892@Sun.COM> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <20091020160755.GC892@Sun.COM> Message-ID: <44792A61-67F7-41F0-B704-A272B858B4C2@sxw.org.uk> > > Think of TELNET and AFS, which, I know are not exactly good examples > here (in large part because they pre-date RFC3961), but they are good > examples of apps which, if they really had to avoid KRB-SAFE/PRIV or > the > GSS-API (e.g., because of per-token/message overhead), then really > should have used _a_ cryptographic protocol framework, of which > RFC3961 > is a reasonable example. > > IMO Kerberos implementors SHOULD export RFC3961 interfaces. Just as a data point, the AFS community is currently considering a new security layer, rxgk, which makes use of RFC3961 for all of its bulk crypto needs. The more 3961 implementations available to choose between, the better! Cheers, Simon. From jhutz at cmu.edu Tue Oct 20 13:49:49 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 20 Oct 2009 13:49:49 -0400 Subject: export list symbols In-Reply-To: <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> Message-ID: --On Tuesday, October 20, 2009 11:07:55 AM -0500 Nicolas Williams wrote: > But also, RFC3961 is not intended to be a mere detail of Kerberos > protocol construction: "raw" krb5 apps that extract session keys and > make use of krb5 enctypes directly are legitimate users of RFC3961. > > Think of TELNET and AFS, which, I know are not exactly good examples > here (in large part because they pre-date RFC3961), but they are good > examples of apps which, if they really had to avoid KRB-SAFE/PRIV or the > GSS-API (e.g., because of per-token/message overhead), then really > should have used _a_ cryptographic protocol framework, of which RFC3961 > is a reasonable example. In fact, RFC3961 was designed with such users in mind. > IMO Kerberos implementors SHOULD export RFC3961 interfaces. Agree. From tsitkova at MIT.EDU Tue Oct 20 13:50:34 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Tue, 20 Oct 2009 13:50:34 -0400 Subject: export list symbols In-Reply-To: <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM>, <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> Message-ID: <8DD7AD829AB61E499A433D6E558110A3144F14CD@EXPO7.exchange.mit.edu> Sounds like a bad practice anyway, don't you think? Zhanna ________________________________________ From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of Jeffrey Hutzelman [jhutz at cmu.edu] Sent: Tuesday, October 20, 2009 1:12 PM To: Nicolas Williams; Greg Hudson Cc: krbdev at mit.edu; jhutz at cmu.edu Subject: Re: export list symbols --On Tuesday, October 20, 2009 11:07:55 AM -0500 Nicolas Williams wrote: > I think I missed that these were functions not listed in krb5.h. If a > function is in a private header then I agree that automated static > analysis is sufficient for deciding whether to make it not an exported > symbol. Except for private-that-should-be-public symbols, of course, > but that can be revisited later. What about symbols which were previously removed from the public headers (or were never prototyped), but remain exported to maintain backward compatibility with existing users? -- Jeff _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From Nicolas.Williams at sun.com Tue Oct 20 13:43:20 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 12:43:20 -0500 Subject: export list symbols In-Reply-To: <44792A61-67F7-41F0-B704-A272B858B4C2@sxw.org.uk> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <20091020160755.GC892@Sun.COM> <44792A61-67F7-41F0-B704-A272B858B4C2@sxw.org.uk> Message-ID: <20091020174320.GH892@Sun.COM> On Tue, Oct 20, 2009 at 06:39:53PM +0100, Simon Wilkinson wrote: > Just as a data point, the AFS community is currently considering a new > security layer, rxgk, which makes use of RFC3961 for all of its bulk > crypto needs. The more 3961 implementations available to choose > between, the better! Thanks for making that point (I was hoping someone would). The RFC3961 interfaces in MIT krb5 may not be mature enough. Some thought should go into public RFC3961 interfaces. From jhutz at cmu.edu Tue Oct 20 14:00:32 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 20 Oct 2009 14:00:32 -0400 Subject: export list symbols In-Reply-To: <28195_1256061199_n9KHrIJW019499_8DD7AD829AB61E499A433D6E558110A3144F14CD@EXPO7.exchange.mit.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> ,<220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> <28195_1256061199_n9KHrIJW019499_8DD7AD829AB61E499A433D6E558110A3144F14CD@EXPO7.exchange.mit.edu> Message-ID: --On Tuesday, October 20, 2009 01:50:34 PM -0400 Zhanna Tsitkova wrote: > Sounds like a bad practice anyway, don't you think? Maintaining backward compatibility? No. Deprecating interfaces? No. And, whether or not it's bad practice, if it's happened (and I don't know offhand whether it has for any of the symbols under discussion), it needs to be dealt with. Saying "Oh, we shouldn't have ever exported this, so anyone who used it now gets to lose" is not really OK. -- Jeff From Nicolas.Williams at sun.com Tue Oct 20 14:01:28 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 20 Oct 2009 13:01:28 -0500 Subject: export list symbols In-Reply-To: <8DD7AD829AB61E499A433D6E558110A3144F14CD@EXPO7.exchange.mit.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> <8DD7AD829AB61E499A433D6E558110A3144F14CD@EXPO7.exchange.mit.edu> Message-ID: <20091020180128.GI892@Sun.COM> On Tue, Oct 20, 2009 at 01:50:34PM -0400, Zhanna Tsitkova wrote: > On Tue, Oct 20, Jeff Hutzelman wrote: > > What about symbols which were previously removed from the public headers > > (or were never prototyped), but remain exported to maintain backward > > compatibility with existing users? > > Sounds like a bad practice anyway, don't you think? The _past_ practice of being careless with respect to public/private API status was definitely bad. Whether the _current_ practice of not breaking old apps [at run-time link-time] is good or bad is subject to debate. A decision to break such old apps may certainly be made (I wouldn't object), but it has to be made consciously. Nico -- From ghudson at MIT.EDU Tue Oct 20 15:02:59 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 20 Oct 2009 15:02:59 -0400 Subject: export list symbols In-Reply-To: <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> Message-ID: <1256065379.23997.269.camel@ray> On Tue, 2009-10-20 at 13:12 -0400, Jeffrey Hutzelman wrote: > What about symbols which were previously removed from the public headers > (or were never prototyped), but remain exported to maintain backward > compatibility with existing users? Of the symbols in Zhana's list, the following three were prototyped in past versions of krb5.h: krb5_random_confounder, krb5_encrypt_data, and krb5_decrypt_data. In r14320 (April 2002), Tom moved those symbols into an #if KRB5_PRIVATE block, and in r15798 (August 2003) Ken moved them to k5-int.h. Given that it hasn't been very many releases since 2002, I'd say we should keep those three symbols to maintain ABI compatibility. Assuming consensus on this point, I will move those symbols' prototypes from k5-int.h to old_api_glue.c and add appropriate comments. As for your "(or were never prototyped)" parenthetical: I'm all for not breaking things, but I don't want to be paralyzed by the mere speculation that someone might be using a non-prototyped symbol from one of our libraries. If we have specific evidence about specific symbols, we can make documented exceptions for those in the manner of the previous paragraph. From jhutz at cmu.edu Tue Oct 20 15:44:41 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 20 Oct 2009 15:44:41 -0400 Subject: export list symbols In-Reply-To: <12754_1256065439_n9KJ3wF3002418_1256065379.23997.269.camel@ray> References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> <12754_1256065439_n9KJ3wF3002418_1256065379.23997.269.camel@ray> Message-ID: --On Tuesday, October 20, 2009 03:02:59 PM -0400 Greg Hudson wrote: > As for your "(or were never prototyped)" parenthetical: I'm all for not > breaking things, but I don't want to be paralyzed by the mere > speculation that someone might be using a non-prototyped symbol from one > of our libraries. If we have specific evidence about specific symbols, > we can make documented exceptions for those in the manner of the > previous paragraph. I was particularly thinking about the case of a public interface becoming private, but long enough ago that there weren't yet prototypes for all public functions. I certainly agree that, if something was never public, it's reasonable not to worry about outside users unless there is specific evidence of an "interesting" use. -- Jeff From lukeh at padl.com Tue Oct 20 16:04:32 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 20 Oct 2009 16:04:32 -0400 Subject: export list symbols In-Reply-To: References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> <12754_1256065439_n9KJ3wF3002418_1256065379.23997.269.camel@ray> Message-ID: <954CFB3D-876C-4412-8B2E-2D04ACF2A75F@padl.com> > I was particularly thinking about the case of a public interface > becoming > private, but long enough ago that there weren't yet prototypes for all > public functions. I certainly agree that, if something was never > public, > it's reasonable not to worry about outside users unless there is > specific > evidence of an "interesting" use. Well, given everyone else in the room has chimed in :-) I think MIT can probably afford to be more aggressive in removing deprecating symbols than an OS vendor. -- Luke From sanribu at gmail.com Wed Oct 21 14:19:22 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Wed, 21 Oct 2009 20:19:22 +0200 Subject: Error calling function protocol status: 1312 In-Reply-To: <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> Message-ID: <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> After enabling debug mode, this is what I've got: Case 1: No principal is specified in jaas.conf *Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt fa lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is fal se principal is null tryFirstPass is false useFirstPass is false storePass is fa lse clearPass is false Acquire TGT from Cache Error calling function Protocol status: 1312 A specified logon session does not exist. It may already have been terminated Principal is null null credentials from Ticket Cache Username for Kerberos [santi]:* Case 2: Principal "santi" is specified in jaas.conf *Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt fa lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is fal se principal is **santi at zigia.org* * tryFirstPass is false useFirstPass is false stor ePass is false clearPass is false Acquire TGT from Cache Error calling function Protocol status: 1312 A specified logon session does not exist. It may already have been terminated Principal is **santi at zigia.org* *null credentials from Ticket Cache Kerberos password for **santi at zigia.org* *:* IMHO, it seems like JVM is not able to parse the credentials file generated by NIM. Referring to the credentials cache, is there any "known incompatibility" between NIM and JVM which I should be aware of? Thanks again! Regards, Santi 2009/10/19 Max (Weijun) Wang > Java first looks for cache from the file and then from LSA. If you see the > 1312 error it means there's no cache in the file. Maybe the principal name > is not the same with your JAAS conf setting? Or, NIM generates a file Java > cannot parse. > > Can you show the content of the cache with klist.exe in JDK (not the one > from Microsoft)? Also, add -Dsun.security.krb5.debug=true to your Java > program and see what debug output is saying. > > -- Max > > > On Oct 19, 2009, at 6:21 PM, Santiago Rivas wrote: > > It did help, Max! >> >> I started using kinit.exe from JDK and verified that credentials cache is >> stored, by default, in: >> >> "C:\Documents and Settings\santi\krb5cc_santi" <=> >> %HOMEPATH%\krb5cc_ >> >> Nothing new until here. But good news are that now JVM is able to read >> credentials and obtain TGT from that cache (which was my purpose). As you >> pointed out, my jaas.conf only specifies "useTicketCache=true", without any >> path to file, since I'm using the default settings. >> However, it's weird because if I set NIM to store credentials in the same >> location, the file is actually created, but then JVM throws the "1312 >> status" when it tries to read the cache. And this time the reason cannot be >> that "it's not finding the credentials cache" ... ?? >> >> Regards, >> Santi >> >> >> 2009/10/17 Max (Weijun) Wang >> Sorry I'm not an expert on NIM. >> >> >> On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote: >> >> By the moment, my purpose is to *generate a TGT (anyhow, using kinit or >> NIM) >> and configure the cache so those credentials are stored in a file*, >> >> Then you can use any kinit.exe, the one from JDK or MIT. To use a file >> cache, you don't need to care about the registry key mentioned by Douglas at >> all. >> >> In fact, I had thought you were trying to use the LSA cache (non-file >> in-memory Windows-specific cache). BTW, if you do want to use the LSA cache, >> please make sure that the file cache is not there, since Java always try to >> use the file cache first. You can check this out by calling the klist.exe >> command in JDK. >> >> >> where Java will read them from later. >> >> *Step 1: Configure credentials cache* >> >> Since you told me to "*update the Identity object to use a FILE: ccache*", >> I >> went to >> >> NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) >> >> On "Kerberos v5" folder, I set the "Credential cache" option to >> *FILE:ccache >> *. And now I can see that a file named ccache is created or deleted >> everytime I generate or destroy the TGT. So I think now I have credentials >> cache configured properly. Am I right? >> >> *Step 2: Configure JAAS so that TGT is read from file (in order to obtain >> a >> TGS)* >> >> Here is my *jaas.conf* file for the client: >> >> *Client {* >> * com.sun.security.auth.module.Krb5LoginModule required* >> * useTicketCache=true* >> * ticketCache="c:\docume~1\santi\ccache";* >> *}* >> >> But when I run the client I get the following exception: >> >> *java.lang.SecurityException: Configuration Error :* >> * Line 4: expected [option key], found [null]* >> * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* >> * ...* >> >> I think Java is complaining about the ticketCache value. It does not like >> Windows style "\" in path. You can try "\\" or "/". >> >> In fact, if you have not provided special argument to kinit, the cache >> file should be generated at the default location, and you don't need to >> specify ticketCache in the JAAS conf file at all. >> >> To debug, add "debug=true" into the JAAS conf file, *and* add >> -Dsun.security.krb5.debug=true into you Java command line, you will see a >> lot of things. >> >> Hope this helps >> >> Weijun (aka Max) >> >> >> I guess there some information missing about the credentials, but I don't >> know what. Any idea? >> >> I never tire for saying thank you! >> >> Regards, >> Santi >> >> 2009/10/16 Douglas E. Engert >> >> >> >> Santiago Rivas wrote: >> >> Ok, here is what I've done: >> I changed the JAAS config file, setting "useTicketCache=". That >> was enough to make de 1312 status error dissappear. But I'm still not able >> to configure the ticket caching properly. >> I forgot to mention that I have had already tried to set some file path >> under >> NIM: Options->Kerberos v5->Credential Cache ... with no results. >> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the >> text box and clicked the "Add" button, but it said something like "the >> credentials cache file was not found". If I only set the path to some >> folder >> (with no file name) there is no error message, but when I generate new >> tickets no file is created. I've reset the machine and verified that the >> user has privileges to access the path I'm typing son I don't known where >> I'm mistaking... ?? >> >> >> Did you make the registry setting change as suggested bu both NIM and >> Java? >> >> I don't think Java actually writes tickets to the cache. It just reads a >> TGT >> from the cache, then keeps tickets in memory. (I could be wrong) >> The Java kinit.exe will write the TGT but I have never needed to use it. >> Windows and NIM/KfW also have kinit.exe files so be careful which one you >> are using. >> >> Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. >> Regards, >> Santi >> 2009/10/14 Douglas E. Engert > >> >> >> >> >> P.S. The other responder to your note, Weijun Wang, is the >> author of the Sun web page I listed below. Small world! >> >> >> Douglas E. Engert wrote: >> >> >> Santiago Rivas wrote: >> >> So, if I didn't misunderstood your words, I basically have >> at least 2 >> alternatives to achieve ticket collection from cache under >> Windows XP >> environment: >> >> 1) Configure Network Identity Manager to store credentials >> into a file, in >> order to read them from Java. >> >> >> One of the other responder to your first e-mail, Jeff Altman, is >> the >> developer of Network Identity Manager, and said: >> " Network Identity Manager can be configured to store the user's >> credentials in a FILE:: cache which can then be >> accessed via Java." >> >> Start by looking under Options->Kerberos v5->Credential Cache >> >> 2) Set up the configuration so that logon session is >> authenticated with >> Kerberos, and then retrieve the TGT ticket from LSA querying >> via JAAS. >> >> >> Also see this: >> >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >> >> It talks about using the LSA, or the ticketCache=file options and >> the use of the "TGT accessibility" registry setting for >> allowtgtsessionkey. >> Network Identity Manager also uses this registry setting. >> >> (This registry setting may be you main issue!) >> >> Personally, I'm more interested on the second option, since >> the main target >> is to achieve single sign-on with kerberos. Anyway, I would >> appreciate to >> read some documentation on both tasks. Could you please tell >> me where I can >> find it? >> >> >> A third option is to use the Microsoft runas /netonly >> /user:user at realm program >> This will run the program with a new LSA. Program could be >> cmd.exe or even >> explorer.exe >> >> >> Thanks a lot, guys! >> >> Regards, >> Santi >> >> >> 2009/10/14 Douglas E. Engert > > >> >> >> Santiago Rivas wrote: >> >> Well, I do specify "useTicketCache=true" in the JAAS >> config file, but >> there >> is something I must be missing, cause I cannot get >> it working with cached >> tickets. In fact, I must provide username and >> password in the config file >> (or via command line). >> >> I can obtain TGT tickets with both Leash32 and >> Network Identity Manager >> tools, but I cannot see where they are stored, if >> cached (just the same as >> /tmp/krb5cc_1000 file in Linux...) ?? >> >> On Unix, with JXplorer, I can add >> -Duser.krb5ccname=$KRB5CCNAME >> to the command line, and the JXplorer gssapi.conf has: >> >> com.ca.commons.jndi.JNDIOps { >> com.sun.security.auth.module.Krb5LoginModule required >> client=TRUE >> ticketCache="${user.krb5ccname}" >> doNotPrompt=TRUE >> useTicketCache=TRUE; >> }; >> >> On Windows it does not have the ticketCache= line, >> but I think it could try it. >> >> If Leash32 or Network Identity Manager is storing them >> in a file, >> say \tmp\krb5cc_username >> you could try ticketCache=\tmp\krb5cc_username >> >> >> >> >> So may be the question should be: How do I configure >> the ticket cache in >> Windows? Is it mandatory to be configured through LSA? >> >> Thank you very much, Max! >> >> Regards, >> Santi >> >> 2009/10/14 Max (Weijun) Wang > > >> >> >> Java tries to get the credentials cache (ccache) >> from Windows LSA if you >> >> specify useTicketCache=true in the JAAS config >> file. In some cases, Java >> believes there's a ccache at the beginning, but >> finally it cannot get >> one. >> For example, you login as a AD account but then >> purge the TGT using klist >> or >> kerbtray. Then, you will see this error. >> >> Without the ccache, Java will try the Kerberos >> login itself, you'll need >> to >> provide username and password in your program. >> >> -- Max >> >> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >> >> Hi again, >> >> After some tough work, it seems I've got my >> test environment configured >> and >> working with DHCP server, DNS server, ldap >> and Domain Controller, >> running >> on >> a GNU Linux Debian platform. I've also >> configured KDC + AS services on >> that >> machine, and I'm glad to see that I'm able >> to create a secure context >> between the server and other GNU Linux >> machine. I'm using GSS-API in >> Java >> 1.6, and everything works fine. >> >> The problem comes when I run the same Java >> code on a Windows XP SP3 >> platform >> with jdk 1.5.0_21 version installed. Just >> before the context is created, >> I >> get the message: >> >> *Error calling function protocol status: >> 1312. A specified logon session >> does not exist. It may already have been >> terminated.* >> >> But the most curious thing is that execution >> continues and secure >> context >> is >> created indeed. I've also checked >> *krb5kdc.log* and verified that both >> TGT >> ans TGS tickets are generated and delivered >> correctly. >> >> I've searched the web and I've found many >> posible explanations, like: >> >> *"There is a problem with Windows API >> FormatMessage usage in a non >> English >> locale"* - forums.sun >> *"The identity associated with a >> **KerberosToken2*< >> >> >> >> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >> * security token is being used for >> constrained delegation, but >> constrained >> delegation is not configured correctly."* - >> msdn >> *"There is a bug in Java 1.5"* - other source >> >> ... but none of them convinces me. >> So the cuestion is: Why is that message >> appearing? Should I worry about >> it? >> How can I solve it? >> >> Thanks in advance! >> >> Regards, >> Santi >> _______________________________________________ >> krbdev mailing list >> krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> _______________________________________________ >> >> krbdev mailing list krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> >> -- >> >> Douglas E. Engert > > >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> >> >> -- >> Douglas E. Engert > >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> >> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> > From deengert at anl.gov Wed Oct 21 16:22:32 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 21 Oct 2009 15:22:32 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> Message-ID: <4ADF6D88.4020200@anl.gov> Santiago Rivas wrote: > After enabling debug mode, this is what I've got: > > Case 1: No principal is specified in jaas.conf > > *Debug is true storeKey false useTicketCache true useKeyTab false > doNotPrompt fa > lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is > fal > se principal is null tryFirstPass is false useFirstPass is false storePass > is fa > lse clearPass is false > Acquire TGT from Cache > Error calling function Protocol status: 1312 > A specified logon session does not exist. It may already have been > terminated > Principal is null > null credentials from Ticket Cache > Username for Kerberos [santi]:* > > Case 2: Principal "santi" is specified in jaas.conf > > *Debug is true storeKey false useTicketCache true useKeyTab false > doNotPrompt fa > lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is > fal > se principal is **santi at zigia.org* * tryFirstPass is false > useFirstPass is false stor > ePass is false clearPass is false > Acquire TGT from Cache > Error calling function Protocol status: 1312 > A specified logon session does not exist. It may already have been > terminated > Principal is **santi at zigia.org* > *null credentials from Ticket Cache > Kerberos password for **santi at zigia.org* *:* > IMHO, it seems like JVM is not able to parse the credentials file generated > by NIM. Referring to the credentials cache, is there any "known > incompatibility" between NIM and JVM which I should be aware of? > > Thanks again! > This could be an issue of the cache version. NIM looks like it is writing a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 is the version.) It could be Java only knows how to handle versions up to 3. In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom: ccache_type = 3 NIM will then write a type 3 cache. (This is not the only Kerberos feature that Java is way behind on either. Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one especially on Windows...) > Regards, > Santi > > > 2009/10/19 Max (Weijun) Wang > >> Java first looks for cache from the file and then from LSA. If you see the >> 1312 error it means there's no cache in the file. Maybe the principal name >> is not the same with your JAAS conf setting? Or, NIM generates a file Java >> cannot parse. >> >> Can you show the content of the cache with klist.exe in JDK (not the one >> from Microsoft)? Also, add -Dsun.security.krb5.debug=true to your Java >> program and see what debug output is saying. >> >> -- Max >> >> >> On Oct 19, 2009, at 6:21 PM, Santiago Rivas wrote: >> >> It did help, Max! >>> I started using kinit.exe from JDK and verified that credentials cache is >>> stored, by default, in: >>> >>> "C:\Documents and Settings\santi\krb5cc_santi" <=> >>> %HOMEPATH%\krb5cc_ >>> >>> Nothing new until here. But good news are that now JVM is able to read >>> credentials and obtain TGT from that cache (which was my purpose). As you >>> pointed out, my jaas.conf only specifies "useTicketCache=true", without any >>> path to file, since I'm using the default settings. >>> However, it's weird because if I set NIM to store credentials in the same >>> location, the file is actually created, but then JVM throws the "1312 >>> status" when it tries to read the cache. And this time the reason cannot be >>> that "it's not finding the credentials cache" ... ?? >>> >>> Regards, >>> Santi >>> >>> >>> 2009/10/17 Max (Weijun) Wang >>> Sorry I'm not an expert on NIM. >>> >>> >>> On Oct 17, 2009, at 1:56 AM, Santiago Rivas wrote: >>> >>> By the moment, my purpose is to *generate a TGT (anyhow, using kinit or >>> NIM) >>> and configure the cache so those credentials are stored in a file*, >>> >>> Then you can use any kinit.exe, the one from JDK or MIT. To use a file >>> cache, you don't need to care about the registry key mentioned by Douglas at >>> all. >>> >>> In fact, I had thought you were trying to use the LSA cache (non-file >>> in-memory Windows-specific cache). BTW, if you do want to use the LSA cache, >>> please make sure that the file cache is not there, since Java always try to >>> use the file cache first. You can check this out by calling the klist.exe >>> command in JDK. >>> >>> >>> where Java will read them from later. >>> >>> *Step 1: Configure credentials cache* >>> >>> Since you told me to "*update the Identity object to use a FILE: ccache*", >>> I >>> went to >>> >>> NIM: Options->Identities->santi at ZIGIA.ORG (which is my test principal) >>> >>> On "Kerberos v5" folder, I set the "Credential cache" option to >>> *FILE:ccache >>> *. And now I can see that a file named ccache is created or deleted >>> everytime I generate or destroy the TGT. So I think now I have credentials >>> cache configured properly. Am I right? >>> >>> *Step 2: Configure JAAS so that TGT is read from file (in order to obtain >>> a >>> TGS)* >>> >>> Here is my *jaas.conf* file for the client: >>> >>> *Client {* >>> * com.sun.security.auth.module.Krb5LoginModule required* >>> * useTicketCache=true* >>> * ticketCache="c:\docume~1\santi\ccache";* >>> *}* >>> >>> But when I run the client I get the following exception: >>> >>> *java.lang.SecurityException: Configuration Error :* >>> * Line 4: expected [option key], found [null]* >>> * at com.sun.security.auth.login.ConfigFile.(Unknown Source)* >>> * ...* >>> >>> I think Java is complaining about the ticketCache value. It does not like >>> Windows style "\" in path. You can try "\\" or "/". >>> >>> In fact, if you have not provided special argument to kinit, the cache >>> file should be generated at the default location, and you don't need to >>> specify ticketCache in the JAAS conf file at all. >>> >>> To debug, add "debug=true" into the JAAS conf file, *and* add >>> -Dsun.security.krb5.debug=true into you Java command line, you will see a >>> lot of things. >>> >>> Hope this helps >>> >>> Weijun (aka Max) >>> >>> >>> I guess there some information missing about the credentials, but I don't >>> know what. Any idea? >>> >>> I never tire for saying thank you! >>> >>> Regards, >>> Santi >>> >>> 2009/10/16 Douglas E. Engert >>> >>> >>> >>> Santiago Rivas wrote: >>> >>> Ok, here is what I've done: >>> I changed the JAAS config file, setting "useTicketCache=". That >>> was enough to make de 1312 status error dissappear. But I'm still not able >>> to configure the ticket caching properly. >>> I forgot to mention that I have had already tried to set some file path >>> under >>> NIM: Options->Kerberos v5->Credential Cache ... with no results. >>> I typed the path "C:\Documents and Settings\user\krb5cc_1000" into the >>> text box and clicked the "Add" button, but it said something like "the >>> credentials cache file was not found". If I only set the path to some >>> folder >>> (with no file name) there is no error message, but when I generate new >>> tickets no file is created. I've reset the machine and verified that the >>> user has privileges to access the path I'm typing son I don't known where >>> I'm mistaking... ?? >>> >>> >>> Did you make the registry setting change as suggested bu both NIM and >>> Java? >>> >>> I don't think Java actually writes tickets to the cache. It just reads a >>> TGT >>> from the cache, then keeps tickets in memory. (I could be wrong) >>> The Java kinit.exe will write the TGT but I have never needed to use it. >>> Windows and NIM/KfW also have kinit.exe files so be careful which one you >>> are using. >>> >>> Thanks, Douglas, for introducing Jeff Altman and Weijun Wang to me. >>> Regards, >>> Santi >>> 2009/10/14 Douglas E. Engert >> >>> >>> P.S. The other responder to your note, Weijun Wang, is the >>> author of the Sun web page I listed below. Small world! >>> >>> >>> Douglas E. Engert wrote: >>> >>> >>> Santiago Rivas wrote: >>> >>> So, if I didn't misunderstood your words, I basically have >>> at least 2 >>> alternatives to achieve ticket collection from cache under >>> Windows XP >>> environment: >>> >>> 1) Configure Network Identity Manager to store credentials >>> into a file, in >>> order to read them from Java. >>> >>> >>> One of the other responder to your first e-mail, Jeff Altman, is >>> the >>> developer of Network Identity Manager, and said: >>> " Network Identity Manager can be configured to store the user's >>> credentials in a FILE:: cache which can then be >>> accessed via Java." >>> >>> Start by looking under Options->Kerberos v5->Credential Cache >>> >>> 2) Set up the configuration so that logon session is >>> authenticated with >>> Kerberos, and then retrieve the TGT ticket from LSA querying >>> via JAAS. >>> >>> >>> Also see this: >>> >>> >>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>> >>> It talks about using the LSA, or the ticketCache=file options and >>> the use of the "TGT accessibility" registry setting for >>> allowtgtsessionkey. >>> Network Identity Manager also uses this registry setting. >>> >>> (This registry setting may be you main issue!) >>> >>> Personally, I'm more interested on the second option, since >>> the main target >>> is to achieve single sign-on with kerberos. Anyway, I would >>> appreciate to >>> read some documentation on both tasks. Could you please tell >>> me where I can >>> find it? >>> >>> >>> A third option is to use the Microsoft runas /netonly >>> /user:user at realm program >>> This will run the program with a new LSA. Program could be >>> cmd.exe or even >>> explorer.exe >>> >>> >>> Thanks a lot, guys! >>> >>> Regards, >>> Santi >>> >>> >>> 2009/10/14 Douglas E. Engert >> > >>> >>> >>> Santiago Rivas wrote: >>> >>> Well, I do specify "useTicketCache=true" in the JAAS >>> config file, but >>> there >>> is something I must be missing, cause I cannot get >>> it working with cached >>> tickets. In fact, I must provide username and >>> password in the config file >>> (or via command line). >>> >>> I can obtain TGT tickets with both Leash32 and >>> Network Identity Manager >>> tools, but I cannot see where they are stored, if >>> cached (just the same as >>> /tmp/krb5cc_1000 file in Linux...) ?? >>> >>> On Unix, with JXplorer, I can add >>> -Duser.krb5ccname=$KRB5CCNAME >>> to the command line, and the JXplorer gssapi.conf has: >>> >>> com.ca.commons.jndi.JNDIOps { >>> com.sun.security.auth.module.Krb5LoginModule required >>> client=TRUE >>> ticketCache="${user.krb5ccname}" >>> doNotPrompt=TRUE >>> useTicketCache=TRUE; >>> }; >>> >>> On Windows it does not have the ticketCache= line, >>> but I think it could try it. >>> >>> If Leash32 or Network Identity Manager is storing them >>> in a file, >>> say \tmp\krb5cc_username >>> you could try ticketCache=\tmp\krb5cc_username >>> >>> >>> >>> >>> So may be the question should be: How do I configure >>> the ticket cache in >>> Windows? Is it mandatory to be configured through LSA? >>> >>> Thank you very much, Max! >>> >>> Regards, >>> Santi >>> >>> 2009/10/14 Max (Weijun) Wang >> > >>> >>> >>> Java tries to get the credentials cache (ccache) >>> from Windows LSA if you >>> >>> specify useTicketCache=true in the JAAS config >>> file. In some cases, Java >>> believes there's a ccache at the beginning, but >>> finally it cannot get >>> one. >>> For example, you login as a AD account but then >>> purge the TGT using klist >>> or >>> kerbtray. Then, you will see this error. >>> >>> Without the ccache, Java will try the Kerberos >>> login itself, you'll need >>> to >>> provide username and password in your program. >>> >>> -- Max >>> >>> On Oct 14, 2009, at 6:55 PM, Santiago Rivas wrote: >>> >>> Hi again, >>> >>> After some tough work, it seems I've got my >>> test environment configured >>> and >>> working with DHCP server, DNS server, ldap >>> and Domain Controller, >>> running >>> on >>> a GNU Linux Debian platform. I've also >>> configured KDC + AS services on >>> that >>> machine, and I'm glad to see that I'm able >>> to create a secure context >>> between the server and other GNU Linux >>> machine. I'm using GSS-API in >>> Java >>> 1.6, and everything works fine. >>> >>> The problem comes when I run the same Java >>> code on a Windows XP SP3 >>> platform >>> with jdk 1.5.0_21 version installed. Just >>> before the context is created, >>> I >>> get the message: >>> >>> *Error calling function protocol status: >>> 1312. A specified logon session >>> does not exist. It may already have been >>> terminated.* >>> >>> But the most curious thing is that execution >>> continues and secure >>> context >>> is >>> created indeed. I've also checked >>> *krb5kdc.log* and verified that both >>> TGT >>> ans TGS tickets are generated and delivered >>> correctly. >>> >>> I've searched the web and I've found many >>> posible explanations, like: >>> >>> *"There is a problem with Windows API >>> FormatMessage usage in a non >>> English >>> locale"* - forums.sun >>> *"The identity associated with a >>> **KerberosToken2*< >>> >>> >>> >>> http://msdn.microsoft.com/en-us/library/microsoft.web.services2.security.tokens.kerberostoken2.aspx >>> * security token is being used for >>> constrained delegation, but >>> constrained >>> delegation is not configured correctly."* - >>> msdn >>> *"There is a bug in Java 1.5"* - other source >>> >>> ... but none of them convinces me. >>> So the cuestion is: Why is that message >>> appearing? Should I worry about >>> it? >>> How can I solve it? >>> >>> Thanks in advance! >>> >>> Regards, >>> Santi >>> _______________________________________________ >>> krbdev mailing list >>> krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> _______________________________________________ >>> >>> krbdev mailing list krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >>> -- >>> >>> Douglas E. Engert >> > >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >>> >>> -- >>> Douglas E. Engert > >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> >>> >>> -- >>> >>> Douglas E. Engert >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jhutz at cmu.edu Wed Oct 21 16:28:32 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Wed, 21 Oct 2009 16:28:32 -0400 Subject: Error calling function protocol status: 1312 In-Reply-To: <21605_1256156579_n9LKMwe3030347_4ADF6D88.4020200@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <21605_1256156579_n9LKMwe3030347_4ADF6D88.4020200@anl.gov> Message-ID: <6B4D7BF13A6AB50FB57192D8@atlantis.pc.cs.cmu.edu> --On Wednesday, October 21, 2009 03:22:32 PM -0500 "Douglas E. Engert" wrote: > This could be an issue of the cache version. NIM looks like it is writing > a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 is > the version.) It could be Java only knows how to handle versions up to 3. > > In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom: > ccache_type = 3 > > NIM will then write a type 3 cache. > > (This is not the only Kerberos feature that Java is way behind on either. > Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one > especially on Windows...) It also wouldn't be the first piece of software that was too ancient to handle version 4 file ccaches. From William.Fiveash at sun.com Wed Oct 21 19:46:33 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 21 Oct 2009 18:46:33 -0500 Subject: issue with preauth processing Message-ID: <20091021234632.GA1234@sun.com> I have an issue with the following behavior. I want to limit the preauths tried by libkrb to only PKINIT types. What I find is that libkrb5 will fall back to trying KRB5_PADATA_ENC_TIMESTAMP if the all the attempts to do PKINIT preauth fail. This doesn't seem like correct behavior if I've used krb5_get_init_creds_opt_set_preauth_list() to specify the preauths to try. Here's how I tried to limit the preauths tried: krb5_preauthtype pk_pa_list[] = { KRB5_PADATA_PK_AS_REP, KRB5_PADATA_PK_AS_REQ, KRB5_PADATA_PK_AS_REP_OLD, KRB5_PADATA_PK_AS_REQ_OLD }; /* limit Preauth types to just those for PKINIT */ krb5_get_init_creds_opt_set_preauth_list(&opts, pk_pa_list, 4); code = krb5_get_init_creds_password(kmd->kcontext, my_creds, me, NULL, /* clear text passwd */ pam_krb5_prompter, /* prompter */ pamh, /* prompter data */ 0, /* start time */ NULL, /* defaults to krbtgt at REALM */ &opts); I think the problem occurs here in krb5_get_init_creds() line 1512: if ((ret = krb5_do_preauth(context, &request, encoded_request_body, encoded_previous_request, local_as_reply->padata, &kdc_padata, ^^^^^^^^^^^^^^^^^^^^^^ &salt, &s2kparams, &etype, &as_key, prompter, prompter_data, gak_fct, gak_data, &get_data_rock, options))) { The logic ignores the krb5_gic_opt_ext *options that is passed in to krb5_get_init_creds(). Thoughts? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From Weijun.Wang at sun.com Wed Oct 21 20:05:35 2009 From: Weijun.Wang at sun.com (Max (Weijun) Wang) Date: Thu, 22 Oct 2009 08:05:35 +0800 Subject: Error calling function protocol status: 1312 In-Reply-To: <4ADF6D88.4020200@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910140946p7048544dx9d26ccfd5d6aa601@mail.gmail.com> <4AD61977.3070600@anl.gov> <4AD61E78.3080305@anl.gov> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> Message-ID: Hi Santiago Java is coded to support type 4 ccache, it just hasn't made use of the tags inside. Can you send me a copy of your ccache? It seems you've only specified debug=true in the JAAS config file. Please also add the system property sun.security.krb5.debug=true. I don't know how you launch the program. For the command line, it looks like --- java -Dsun.security.krb5.debug=true YourApp BTW, You mentioned the program works fine with kinit.exe from JDK. Can you show what the output in that case is? Thanks Max On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: > > > Santiago Rivas wrote: >> After enabling debug mode, this is what I've got: >> Case 1: No principal is specified in jaas.conf >> *Debug is true storeKey false useTicketCache true useKeyTab false >> doNotPrompt fa >> lse ticketCache is null isInitiator true KeyTab is null >> refreshKrb5Config is >> fal >> se principal is null tryFirstPass is false useFirstPass is false >> storePass >> is fa >> lse clearPass is false >> Acquire TGT from Cache >> Error calling function Protocol status: 1312 >> A specified logon session does not exist. It may already have been >> terminated >> Principal is null >> null credentials from Ticket Cache >> Username for Kerberos [santi]:* >> ... >> IMHO, it seems like JVM is not able to parse the credentials file >> generated >> by NIM. Referring to the credentials cache, is there any "known >> incompatibility" between NIM and JVM which I should be aware of? >> Thanks again! > This could be an issue of the cache version. NIM looks like it is > writing > a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 > is the > version.) It could be Java only knows how to handle versions up to 3. > > In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom: > ccache_type = 3 > > NIM will then write a type 3 cache. > > (This is not the only Kerberos feature that Java is way behind on > either. > Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one > especially on Windows...) From William.Fiveash at sun.com Wed Oct 21 20:01:37 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 21 Oct 2009 19:01:37 -0500 Subject: issue with preauth processing In-Reply-To: <20091021234632.GA1234@sun.com> References: <20091021234632.GA1234@sun.com> Message-ID: <20091022000136.GA1331@sun.com> On Wed, Oct 21, 2009 at 06:46:33PM -0500, Will Fiveash wrote: > I have an issue with the following behavior. I want to limit the > preauths tried by libkrb to only PKINIT types. What I find is that > libkrb5 will fall back to trying KRB5_PADATA_ENC_TIMESTAMP if the all > the attempts to do PKINIT preauth fail. This doesn't seem like correct > behavior if I've used krb5_get_init_creds_opt_set_preauth_list() to > specify the preauths to try. Here's how I tried to limit the preauths > tried: > > krb5_preauthtype pk_pa_list[] = { > KRB5_PADATA_PK_AS_REP, > KRB5_PADATA_PK_AS_REQ, > KRB5_PADATA_PK_AS_REP_OLD, > KRB5_PADATA_PK_AS_REQ_OLD > }; > > /* limit Preauth types to just those for PKINIT */ > krb5_get_init_creds_opt_set_preauth_list(&opts, pk_pa_list, 4); > > code = krb5_get_init_creds_password(kmd->kcontext, > my_creds, > me, > NULL, /* clear text passwd */ > pam_krb5_prompter, /* prompter */ > pamh, /* prompter data */ > 0, /* start time */ > NULL, /* defaults to krbtgt at REALM */ > &opts); > > I think the problem occurs here in krb5_get_init_creds() > > line 1512: > if ((ret = krb5_do_preauth(context, > &request, > encoded_request_body, encoded_previous_request, > local_as_reply->padata, &kdc_padata, > ^^^^^^^^^^^^^^^^^^^^^^ > &salt, &s2kparams, &etype, &as_key, prompter, > prompter_data, gak_fct, gak_data, > &get_data_rock, options))) { > > > The logic ignores the krb5_gic_opt_ext *options that is passed in to > krb5_get_init_creds(). Thoughts? Actually my analysis above is wrong. The issue is here where preauth_to_use is reset: if (should_continue_preauth(err_reply->error, loopcount) && retry) { /* reset the list of preauth types to try */ if (preauth_to_use) { krb5_free_pa_data(context, preauth_to_use); preauth_to_use = NULL; } preauth_to_use = out_padata; out_padata = NULL; krb5_free_error(context, err_reply); err_reply = NULL; ret = sort_krb5_padata_sequence(context, &request.server->realm, preauth_to_use); Perhaps somewhere there should be code to limit the preauth types to the intersection of options->preauth_list and out_padata? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From lukeh at padl.com Thu Oct 22 12:39:52 2009 From: lukeh at padl.com (Luke Howard) Date: Thu, 22 Oct 2009 12:39:52 -0400 Subject: Constrained delegation Message-ID: <89454E3C-1840-4CEA-8E70-A623810884DB@padl.com> I've created a new project for PAC-less constrained delegation in the MIT KDC: http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation Prior to this, the constrained delegation support we shipped in the 1.7 KDC was only useful with a backend that validated the Windows PAC, such as DSfW. -- Luke -- www.padl.com | www.fghr.net From Nicolas.Williams at sun.com Thu Oct 22 14:43:48 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 22 Oct 2009 13:43:48 -0500 Subject: issue with preauth processing In-Reply-To: <20091022000136.GA1331@sun.com> References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> Message-ID: <20091022184348.GS892@Sun.COM> On Wed, Oct 21, 2009 at 07:01:37PM -0500, Will Fiveash wrote: > > The logic ignores the krb5_gic_opt_ext *options that is passed in to > > krb5_get_init_creds(). Thoughts? > > Actually my analysis above is wrong. The issue is here where > preauth_to_use is reset: > > if (should_continue_preauth(err_reply->error, loopcount) && retry) { > /* reset the list of preauth types to try */ > if (preauth_to_use) { > krb5_free_pa_data(context, preauth_to_use); > preauth_to_use = NULL; > } > preauth_to_use = out_padata; > out_padata = NULL; > krb5_free_error(context, err_reply); > err_reply = NULL; > ret = sort_krb5_padata_sequence(context, > &request.server->realm, > preauth_to_use); > > Perhaps somewhere there should be code to limit the preauth types to the > intersection of options->preauth_list and out_padata? I've not looked at the code, but here's how I think this should work, pre-FAST: try the first app-requested pre-auth type, then, if that fails, remove from the app-requested pre-auth list any that don't appear in the KDC's PA-ETYPE-INFO*. FAST will change things somewhat in that it's possible that it won't be reasonable to expect apps (and/or admins, users!) to specify all acceptable FAST combinations. Instead apps/admins/users may wish to specify constraints such as "must protect PA-ENC-TIMESTAMP", "must authenticate KDC with certs", "must use client cert", and so on. A reasonable implementation strategy then may be to apply those constraints to the list of all pre-auths and FAST combinations to obtain a list that can then be used to as above. Nico -- From sanribu at gmail.com Fri Oct 23 03:58:13 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Fri, 23 Oct 2009 09:58:13 +0200 Subject: [WARNING - NOT VIRUS SCANNED] Re: Error calling function protocol status: 1312 In-Reply-To: References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910152333h2cb12ce7g4e23ae33f8fc12a1@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> Message-ID: <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> Hi, The application runs from the command line. Yesterday I ran it with the option you recommended (-Dsun.security.krb5.debug=true) and here you are the different outputs. *jvm.rar* includes both the credentials cache generated with JVM (kinit) and the output I get when I use them to run the Client. *nim.rar* includes both the credentials cache generated with NIM and the output I get when I use them to run the Client (one specifiyng the principal in the jaas.conf and another without doing it). Regards, Santi 2009/10/22 Max (Weijun) Wang > Hi Santiago > > Java is coded to support type 4 ccache, it just hasn't made use of the tags > inside. Can you send me a copy of your ccache? > > It seems you've only specified debug=true in the JAAS config file. Please > also add the system property sun.security.krb5.debug=true. I don't know how > you launch the program. For the command line, it looks like --- > > java -Dsun.security.krb5.debug=true YourApp > > BTW, You mentioned the program works fine with kinit.exe from JDK. Can you > show what the output in that case is? > > Thanks > Max > > On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: > > >> >> Santiago Rivas wrote: >> >>> After enabling debug mode, this is what I've got: >>> Case 1: No principal is specified in jaas.conf >>> *Debug is true storeKey false useTicketCache true useKeyTab false >>> doNotPrompt fa >>> lse ticketCache is null isInitiator true KeyTab is null refreshKrb5Config >>> is >>> fal >>> se principal is null tryFirstPass is false useFirstPass is false >>> storePass >>> is fa >>> lse clearPass is false >>> Acquire TGT from Cache >>> Error calling function Protocol status: 1312 >>> A specified logon session does not exist. It may already have been >>> terminated >>> Principal is null >>> null credentials from Ticket Cache >>> Username for Kerberos [santi]:* >>> >>> ... > > IMHO, it seems like JVM is not able to parse the credentials file >>> generated >>> by NIM. Referring to the credentials cache, is there any "known >>> incompatibility" between NIM and JVM which I should be aware of? >>> Thanks again! >>> >> This could be an issue of the cache version. NIM looks like it is writing >> a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 is >> the >> version.) It could be Java only knows how to handle versions up to 3. >> >> In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom: >> ccache_type = 3 >> >> NIM will then write a type 3 cache. >> >> (This is not the only Kerberos feature that Java is way behind on either. >> Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one >> especially on Windows...) >> > > From sanribu at gmail.com Fri Oct 23 04:01:04 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Fri, 23 Oct 2009 10:01:04 +0200 Subject: [WARNING - NOT VIRUS SCANNED] Re: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> Message-ID: <711a961b0910230101k78b9169s99fddba2156f9594@mail.gmail.com> Ooops, it seems that rar attachment didin't work. I re-send the txt files... 2009/10/23 Santiago Rivas > Hi, > > The application runs from the command line. Yesterday I ran it with the > option you recommended (-Dsun.security.krb5.debug=true) and here you are the > different outputs. > > *jvm.rar* includes both the credentials cache generated with JVM (kinit) > and the output I get when I use them to run the Client. > > *nim.rar* includes both the credentials cache generated with NIM and the > output I get when I use them to run the Client (one specifiyng the principal > in the jaas.conf and another without doing it). > > Regards, > Santi > > > 2009/10/22 Max (Weijun) Wang > > Hi Santiago >> >> Java is coded to support type 4 ccache, it just hasn't made use of the >> tags inside. Can you send me a copy of your ccache? >> >> It seems you've only specified debug=true in the JAAS config file. Please >> also add the system property sun.security.krb5.debug=true. I don't know how >> you launch the program. For the command line, it looks like --- >> >> java -Dsun.security.krb5.debug=true YourApp >> >> BTW, You mentioned the program works fine with kinit.exe from JDK. Can you >> show what the output in that case is? >> >> Thanks >> Max >> >> On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: >> >> >>> >>> Santiago Rivas wrote: >>> >>>> After enabling debug mode, this is what I've got: >>>> Case 1: No principal is specified in jaas.conf >>>> *Debug is true storeKey false useTicketCache true useKeyTab false >>>> doNotPrompt fa >>>> lse ticketCache is null isInitiator true KeyTab is null >>>> refreshKrb5Config is >>>> fal >>>> se principal is null tryFirstPass is false useFirstPass is false >>>> storePass >>>> is fa >>>> lse clearPass is false >>>> Acquire TGT from Cache >>>> Error calling function Protocol status: 1312 >>>> A specified logon session does not exist. It may already have been >>>> terminated >>>> Principal is null >>>> null credentials from Ticket Cache >>>> Username for Kerberos [santi]:* >>>> >>>> ... >> >> IMHO, it seems like JVM is not able to parse the credentials file >>>> generated >>>> by NIM. Referring to the credentials cache, is there any "known >>>> incompatibility" between NIM and JVM which I should be aware of? >>>> Thanks again! >>>> >>> This could be an issue of the cache version. NIM looks like it is writing >>> a type 4 cache. (First two bytes in the file are 0x05 0x04. The 0x04 is >>> the >>> version.) It could be Java only knows how to handle versions up to 3. >>> >>> In the MIT krb5.conf used by NIM, try adding to [libdefaults] sectiom: >>> ccache_type = 3 >>> >>> NIM will then write a type 3 cache. >>> >>> (This is not the only Kerberos feature that Java is way behind on either. >>> Using dns_lookup_kdc = 1 to use the DNS SRV records is a major one >>> especially on Windows...) >>> >> >> > -------------- next part -------------- Initializing for: username: null password: null servername: localhost realm: ZIGIA.ORG kdc: krb.zigia.org config: ./jaas.conf confName: Client Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false Acquire TGT from Cache >>>KinitOptions cache name is C:\Documents and Settings\santi\krb5cc_santi >>>DEBUG client principal is santi at ZIGIA.ORG >>>DEBUG server principal is krbtgt/ZIGIA.ORG at ZIGIA.ORG >>>DEBUG key type: 1 >>>DEBUG auth time: Fri Oct 23 03:38:19 CEST 2009 >>>DEBUG start time: Thu Jan 01 01:00:00 CET 1970 >>>DEBUG end time: Fri Oct 23 13:38:19 CEST 2009 >>>DEBUG renew_till time: Thu Jan 01 01:00:00 CET 1970 >>> CCacheInputStream: readFlags() INITIAL; PRE_AUTH; Host address is /192.168.2.205 >>>DEBUG >>> KrbCreds found the default ticket granting ticket in credential cache. >>> Obtained TGT from LSA: Credentials: client=santi at ZIGIA.ORG server=krbtgt/ZIGIA.ORG at ZIGIA.ORG authTime=20091023013819Z startTime=19700101000000Z endTime=20091023113819Z renewTill=19700101000000Z flags: INITIAL;PRE-AUTHENT EType (int): 1 Principal is santi at ZIGIA.ORG Commit Succeeded Subject: [santi at ZIGIA.ORG] Openning socket to localhost:2004 ...ok >>> GSSClient... Getting client credentials for santi at ZIGIA.ORG Found ticket for santi at ZIGIA.ORG to go to krbtgt/ZIGIA.ORG at ZIGIA.ORG expiring on Fri Oct 23 13:38:19 CEST 2009 >>> GSSClient... GSSManager creating security context >>> GSSClient... Sending token to server over secure context Entered Krb5Context.initSecContext with state=STATE_NEW Service ticket not found in the subject >>> Credentials acquireServiceCreds: same realm Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 3 1 23 16 17. >>> CksumType: sun.security.krb5.internal.crypto.RsaMd5CksumType >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType >>>crc32: c8d39274 >>>crc32: 11001000110100111001001001110100 >>> KrbKdcReq send: kdc=krb.zigia.org UDP:88, timeout=30000, number of retries =3, #bytes=541 >>> KDCCommunication: kdc=krb.zigia.org UDP:88, timeout=30000,Attempt =1, #bytes=541 >>> KrbKdcReq send: #bytes read=537 >>> KrbKdcReq send: #bytes read=537 >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType >>>crc32: cdfedbc7 >>>crc32: 11001101111111101101101111000111 >>> KrbApReq: APOptions are 00100000 00000000 00000000 00000000 >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType >>>crc32: 29332451 >>>crc32: 101001001100110010010001010001 Krb5Context setting mySeqNumber to: 403616947 Created InitSecContextToken: 0000: 01 00 6E 82 01 CD 30 82 01 C9 A0 03 02 01 05 A1 ..n...0......... 0010: 03 02 01 0E A2 07 03 05 00 20 00 00 00 A3 82 01 ......... ...... 0020: 09 61 82 01 05 30 82 01 01 A0 03 02 01 05 A1 0B .a...0.......... 0030: 1B 09 5A 49 47 49 41 2E 4F 52 47 A2 27 30 25 A0 ..ZIGIA.ORG.'0%. 0040: 03 02 01 00 A1 1E 30 1C 1B 09 6C 6F 63 61 6C 68 ......0...localh 0050: 6F 73 74 1B 0F 73 74 77 73 32 2E 7A 69 67 69 61 ost..stws2.zigia 0060: 2E 6F 72 67 A3 81 C3 30 81 C0 A0 03 02 01 01 A1 .org...0........ 0070: 03 02 01 01 A2 81 B3 04 81 B0 6A 35 CE 06 FD 97 ..........j5.... 0080: 9C 74 1C 38 D1 0B E6 BD F6 0F 10 A9 43 07 33 1F .t.8........C.3. 0090: 6A AD 64 D6 81 16 53 55 42 75 4E 05 6C 0D 7F 8F j.d...SUBuN.l... 00A0: A6 3D CB 83 CB BC 80 9F 02 C4 94 6E 82 50 E4 B7 .=.........n.P.. 00B0: 1D 12 AF B8 4A 4D 43 AA BC 14 09 B6 B5 FF EC 71 ....JMC........q 00C0: 1A 6C 56 D4 A0 D5 A3 C3 97 5D B7 5F FE 20 A3 09 .lV......]._. .. 00D0: B0 C8 14 40 57 1C F8 01 31 FF 62 5F 4F 30 83 78 ... at W...1.b_O0.x 00E0: C6 15 B0 43 21 9C 41 F5 CF B7 D4 C3 DC 2D E1 A6 ...C!.A......-.. 00F0: BB E8 38 B5 94 0A E8 C9 34 9B 64 19 FC 8A D5 8F ..8.....4.d..... 0100: 31 DA A7 F5 36 BB 36 4B 21 90 E7 58 6B E8 78 BD 1...6.6K!..Xk.x. 0110: 75 F5 25 95 5C 55 45 9C AF 95 A9 38 8F 8D 78 FC u.%.\UE....8..x. 0120: 0F 3B 00 3B 7B 6B BB 59 12 55 A4 81 A6 30 81 A3 .;.;.k.Y.U...0.. 0130: A0 03 02 01 01 A2 81 9B 04 81 98 D6 92 62 5C 61 .............b\a 0140: 33 E6 AF 61 0E 46 82 9A F6 0F 3E 13 5F F2 2A 24 3..a.F....>._.*$ 0150: 9B C7 02 CD FB 5E FD 33 E4 C2 DB 6B 2F 6C 9D 1B .....^.3...k/l.. 0160: 0A 99 8E B0 2C E0 A7 28 F7 AB 7B 9A F9 F8 0E B8 ....,..(........ 0170: 3C 07 7F F9 EB D7 A7 C7 24 F2 9F 70 30 5A 8A 30 <.......$..p0Z.0 0180: 97 01 6F 59 05 95 28 E4 4B EC FB 8B 97 EB 4F A7 ..oY..(.K.....O. 0190: A0 72 B6 AB 91 32 DC 86 E7 4B 32 40 77 84 D4 78 .r...2...K2 at w..x 01A0: BF 8A 88 68 48 09 9B ED 52 D5 D8 FB F9 10 06 AD ...hH...R....... 01B0: A7 59 F7 1B 2B BE B3 DA 83 12 BF 52 08 A6 3D 97 .Y..+......R..=. 01C0: CE 32 21 6A 08 D1 98 8D D7 32 22 62 A0 02 DC F5 .2!j.....2"b.... 01D0: 79 AC C2 y.. Entered Krb5Context.initSecContext with state=STATE_IN_PROCESS >>> EType: sun.security.krb5.internal.crypto.DesCbcCrcEType >>>crc32: 48992ba5 >>>crc32: 1001000100110010010101110100101 Krb5Context setting peerSeqNumber to: 823071632 >>> GSSClient... Client message is [A sample message from client] Krb5Context.wrap: data=[41 20 73 61 6d 70 6c 65 20 6d 65 73 73 61 67 65 20 66 72 6f 6d 20 63 6c 69 65 6e 74 ] Krb5Context.wrap: token=[60 4b 06 09 2a 86 48 86 f7 12 01 02 02 02 01 00 00 00 00 ff ff 6b d7 9e 3e f8 ce ff 25 b2 16 b4 a3 6e f8 4e 09 34 03 56 1a d1 34 2d a8 2f b6 5c 4f 38 25 62 5a 37 9f 1a a6 a9 b1 c2 f3 f4 e9 fe 94 57 59 7b f5 f2 c0 09 5a 37 98 66 88 ] Krb5Context.unwrap: token=[60 81 83 06 09 2a 86 48 86 f7 12 01 02 02 02 01 00 00 00 00 ff ff 3a 0d 5d 4f 36 de 64 33 aa af a2 d4 89 0e 7a ed 26 ed 5d 5b db 5e 2f e5 31 b0 11 9f 9d 76 e0 f4 6d 41 d1 41 3c 5b 4a 00 6f a8 21 f4 7c b8 e4 bd e2 51 3b 4a d7 a2 5a f2 41 7f 62 79 bb 5e 42 e7 79 cf f3 2a ce 23 e8 91 90 95 00 b4 8e 4e 7f 82 4f 77 05 b5 58 d3 da 93 67 71 7a e0 65 64 9c 48 16 17 44 bf 39 a4 f0 02 a8 c5 a4 6c b6 3c 31 ee ] Krb5Context.unwrap: data=[3e 3e 3e 20 47 53 53 53 65 72 76 65 72 3a 20 53 65 63 75 72 65 20 43 6f 6e 74 65 78 74 20 65 73 74 61 62 6c 69 73 68 20 62 65 74 77 65 65 6e 20 5b 6c 6f 63 61 6c 68 6f 73 74 5d 20 61 6e 64 20 5b 73 61 6e 74 69 40 5a 49 47 49 41 2e 4f 52 47 5d ] >>> GSSClient... Message recieved from Server [[B at 194df86] Server Response >>> GSSServer: Secure Context establish between [localhost] and [santi at ZIGIA.ORG] [Krb5LoginModule]: Entering logout [Krb5LoginModule]: logged out Subject -------------- next part -------------- Initializing for: username: null password: null servername: localhost realm: ZIGIA.ORG kdc: krb.zigia.org config: ./jaas.conf confName: Client Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is santi tryFirstPass is false useFirstPass is false storePass is false clearPass is false Acquire TGT from Cache >>>KinitOptions cache name is C:\Documents and Settings\santi\krb5cc_santi >>>DEBUG client principal is santi at ZIGIA.ORG >>>DEBUG server principal is krbtgt/ZIGIA.ORG at ZIGIA.ORG >>>DEBUG key type: 18 >>>DEBUG auth time: Fri Oct 23 03:41:49 CEST 2009 >>>DEBUG start time: Fri Oct 23 03:41:49 CEST 2009 >>>DEBUG end time: Fri Oct 23 13:41:49 CEST 2009 >>>DEBUG renew_till time: Fri Oct 30 02:41:49 CET 2009 >>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>DEBUG >>> KrbCreds found the default ticket granting ticket in credential cache. >>> unsupported key type found the default TGT: 18 >> Acquire default native Credentials >>> Found no TGT's in LSA Principal is santi at ZIGIA.ORG null credentials from Ticket Cache Error calling function Protocol status: 1312 Un inicio de sesi?n especificado no existe. Es posible que haya finalizado. -------------- next part -------------- Initializing for: username: null password: null servername: localhost realm: ZIGIA.ORG kdc: krb.zigia.org config: ./jaas.conf confName: Client Debug is true storeKey false useTicketCache true useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is false principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false Acquire TGT from Cache >>>KinitOptions cache name is C:\Documents and Settings\santi\krb5cc_santi >>>DEBUG client principal is santi at ZIGIA.ORG >>>DEBUG server principal is krbtgt/ZIGIA.ORG at ZIGIA.ORG >>>DEBUG key type: 18 >>>DEBUG auth time: Fri Oct 23 03:41:49 CEST 2009 >>>DEBUG start time: Fri Oct 23 03:41:49 CEST 2009 >>>DEBUG end time: Fri Oct 23 13:41:49 CEST 2009 >>>DEBUG renew_till time: Fri Oct 30 02:41:49 CET 2009 >>> CCacheInputStream: readFlags() FORWARDABLE; RENEWABLE; INITIAL; PRE_AUTH; >>>DEBUG >>> KrbCreds found the default ticket granting ticket in credential cache. >>> unsupported key type found the default TGT: 18 >> Acquire default native Credentials >>> Found no TGT's in LSA Principal is null null credentials from Ticket Cache Error calling function Protocol status: 1312 Un inicio de sesi?n especificado no existe. Es posible que haya finalizado. From deengert at anl.gov Fri Oct 23 10:04:50 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 23 Oct 2009 09:04:50 -0500 Subject: Error calling function protocol status: 1312 In-Reply-To: <711a961b0910230101k78b9169s99fddba2156f9594@mail.gmail.com> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> <711a961b0910230101k78b9169s99fddba2156f9594@mail.gmail.com> Message-ID: <4AE1B802.4030709@anl.gov> Looks like NIM is getting a TGT with AES256 (enctype 18). And your KDC supports it too. It looks like your java is version 5 See: http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html >>>DEBUG >>> KrbCreds found the default ticket granting ticket in credential cache. >>> unsupported key type found the default TGT: 18 >> Acquire default native Credentials >>> Found no TGT's in LSA Looks like the Java obtained TGT is using DES. >>>KinitOptions cache name is C:\Documents and Settings\santi\krb5cc_santi >>>DEBUG client principal is santi at ZIGIA.ORG >>>DEBUG server principal is krbtgt/ZIGIA.ORG at ZIGIA.ORG >>>DEBUG key type: 1 But the Java version you are running supports DES, DES, RC4, 3DES and 3DES >>> Credentials acquireServiceCreds: same realm Using builtin default etypes for default_tgs_enctypes default etypes for default_tgs_enctypes: 3 1 23 16 17. Santiago Rivas wrote: > Ooops, it seems that rar attachment didin't work. I re-send the txt files... > > 2009/10/23 Santiago Rivas > > > Hi, > > The application runs from the command line. Yesterday I ran it with > the option you recommended (-Dsun.security.krb5.debug=true) and here > you are the different outputs. > > /jvm.rar/ includes both the credentials cache generated with JVM > (kinit) and the output I get when I use them to run the Client. > > /nim.rar/ includes both the credentials cache generated with NIM and > the output I get when I use them to run the Client (one specifiyng > the principal in the jaas.conf and another without doing it). > > Regards, > Santi > > > 2009/10/22 Max (Weijun) Wang > > > Hi Santiago > > Java is coded to support type 4 ccache, it just hasn't made use > of the tags inside. Can you send me a copy of your ccache? > > It seems you've only specified debug=true in the JAAS config > file. Please also add the system property > sun.security.krb5.debug=true. I don't know how you launch the > program. For the command line, it looks like --- > > java -Dsun.security.krb5.debug=true YourApp > > BTW, You mentioned the program works fine with kinit.exe from > JDK. Can you show what the output in that case is? > > Thanks > Max > > > On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: > > > > Santiago Rivas wrote: > > After enabling debug mode, this is what I've got: > Case 1: No principal is specified in jaas.conf > *Debug is true storeKey false useTicketCache true > useKeyTab false > doNotPrompt fa > lse ticketCache is null isInitiator true KeyTab is null > refreshKrb5Config is > fal > se principal is null tryFirstPass is false useFirstPass > is false storePass > is fa > lse clearPass is false > Acquire TGT from Cache > Error calling function Protocol status: 1312 > A specified logon session does not exist. It may already > have been > terminated > Principal is null > null credentials from Ticket Cache > Username for Kerberos [santi]:* > > ... > > IMHO, it seems like JVM is not able to parse the > credentials file generated > by NIM. Referring to the credentials cache, is there any > "known > incompatibility" between NIM and JVM which I should be > aware of? > Thanks again! > > This could be an issue of the cache version. NIM looks like > it is writing > a type 4 cache. (First two bytes in the file are 0x05 0x04. > The 0x04 is the > version.) It could be Java only knows how to handle versions > up to 3. > > In the MIT krb5.conf used by NIM, try adding to > [libdefaults] sectiom: > ccache_type = 3 > > NIM will then write a type 3 cache. > > (This is not the only Kerberos feature that Java is way > behind on either. > Using dns_lookup_kdc = 1 to use the DNS SRV records is a > major one > especially on Windows...) > > > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From Weijun.Wang at sun.com Fri Oct 23 10:45:44 2009 From: Weijun.Wang at sun.com (Max (Weijun) Wang) Date: Fri, 23 Oct 2009 22:45:44 +0800 Subject: Error calling function protocol status: 1312 In-Reply-To: <4AE1B802.4030709@anl.gov> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <4AD8A2FD.2050006@anl.gov> <711a961b0910161056je2aa136paf3a5e5a4b3d4ec6@mail.gmail.com> <474CC5FE-179F-4646-AFFC-C3A4B4D90B32@sun.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> <711a961b0910230101k78b9169s99fddba2156f9594@mail.gmail.com> <4AE1B802.4030709@anl.gov> Message-ID: <30F05A76-8B7D-4518-B948-891A89160512@Sun.COM> Java does not support AES256 out of box due to some export control reasons. You need to apply the "Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy File". The file can be download from the following page: http://java.sun.com/javase/downloads/index.jsp Scroll down the page and it's the last download link. Thanks Max On Oct 23, 2009, at 10:04 PM, Douglas E. Engert wrote: > Looks like NIM is getting a TGT with AES256 (enctype 18). > And your KDC supports it too. > > It looks like your java is version 5 See: > http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html > > > >>>DEBUG > >>> KrbCreds found the default ticket granting ticket in credential > cache. > >>> unsupported key type found the default TGT: 18 > >> Acquire default native Credentials > >>> Found no TGT's in LSA > > > Looks like the Java obtained TGT is using DES. > >>>KinitOptions cache name is C:\Documents and Settings\santi > \krb5cc_santi > >>>DEBUG client principal is santi at ZIGIA.ORG > >>>DEBUG server principal is krbtgt/ZIGIA.ORG at ZIGIA.ORG > >>>DEBUG key type: 1 > > But the Java version you are running supports DES, DES, RC4, 3DES > and 3DES > >>> Credentials acquireServiceCreds: same realm > Using builtin default etypes for default_tgs_enctypes > default etypes for default_tgs_enctypes: 3 1 23 16 17. > > > Santiago Rivas wrote: >> Ooops, it seems that rar attachment didin't work. I re-send the txt >> files... >> 2009/10/23 Santiago Rivas > >> >> Hi, >> The application runs from the command line. Yesterday I ran >> it with >> the option you recommended (-Dsun.security.krb5.debug=true) and >> here >> you are the different outputs. >> /jvm.rar/ includes both the credentials cache generated >> with JVM >> (kinit) and the output I get when I use them to run the Client. >> /nim.rar/ includes both the credentials cache generated >> with NIM and >> the output I get when I use them to run the Client (one specifiyng >> the principal in the jaas.conf and another without doing it). >> Regards, >> Santi >> 2009/10/22 Max (Weijun) Wang > > >> Hi Santiago >> Java is coded to support type 4 ccache, it just hasn't made >> use >> of the tags inside. Can you send me a copy of your ccache? >> It seems you've only specified debug=true in the JAAS config >> file. Please also add the system property >> sun.security.krb5.debug=true. I don't know how you launch the >> program. For the command line, it looks like --- >> java -Dsun.security.krb5.debug=true YourApp >> BTW, You mentioned the program works fine with kinit.exe from >> JDK. Can you show what the output in that case is? >> Thanks >> Max >> On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: >> Santiago Rivas wrote: >> After enabling debug mode, this is what I've got: >> Case 1: No principal is specified in jaas.conf >> *Debug is true storeKey false useTicketCache true >> useKeyTab false >> doNotPrompt fa >> lse ticketCache is null isInitiator true KeyTab is >> null >> refreshKrb5Config is >> fal >> se principal is null tryFirstPass is false >> useFirstPass >> is false storePass >> is fa >> lse clearPass is false >> Acquire TGT from Cache >> Error calling function Protocol status: 1312 >> A specified logon session does not exist. It may >> already >> have been >> terminated >> Principal is null >> null credentials from Ticket Cache >> Username for Kerberos [santi]:* >> ... >> IMHO, it seems like JVM is not able to parse the >> credentials file generated >> by NIM. Referring to the credentials cache, is there >> any >> "known >> incompatibility" between NIM and JVM which I should be >> aware of? >> Thanks again! >> This could be an issue of the cache version. NIM looks >> like >> it is writing >> a type 4 cache. (First two bytes in the file are 0x05 >> 0x04. >> The 0x04 is the >> version.) It could be Java only knows how to handle >> versions >> up to 3. >> In the MIT krb5.conf used by NIM, try adding to >> [libdefaults] sectiom: >> ccache_type = 3 >> NIM will then write a type 3 cache. >> (This is not the only Kerberos feature that Java is way >> behind on either. >> Using dns_lookup_kdc = 1 to use the DNS SRV records is a >> major one >> especially on Windows...) > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 From hartmans at MIT.EDU Fri Oct 23 16:48:58 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 23 Oct 2009 16:48:58 -0400 Subject: issue with preauth processing In-Reply-To: <20091022184348.GS892@Sun.COM> (Nicolas Williams's message of "Thu\, 22 Oct 2009 13\:43\:48 -0500") References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> Message-ID: The preauth framework strongly encourages implementations to take optimistic pre-auth as a hint. If you try some pre-auth and get a PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as the KDC requesting you start over. Now, if that second round fails, you should probably give up. Basically, the question is whether we take that gic option call as an optimization or security constraint. Most people who have used it in the past have been looking for an optimization. From hartmans at MIT.EDU Fri Oct 23 16:54:06 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Fri, 23 Oct 2009 16:54:06 -0400 Subject: export list symbols In-Reply-To: <954CFB3D-876C-4412-8B2E-2D04ACF2A75F@padl.com> (Luke Howard's message of "Tue\, 20 Oct 2009 16\:04\:32 -0400") References: <42553961FD54AE41BF83834CB917221F031C7BA69E@w92expo2.exchange.mit.edu> <1256054226.23997.232.camel@ray> <13193_1256055583_n9KGJgAR031412_20091020160755.GC892@Sun.COM> <220CBCAACF326776BE020785@atlantis.pc.cs.cmu.edu> <12754_1256065439_n9KJ3wF3002418_1256065379.23997.269.camel@ray> <954CFB3D-876C-4412-8B2E-2D04ACF2A75F@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: Luke> I think MIT can probably afford to be more aggressive in Luke> removing deprecating symbols than an OS vendor. With my OS vendor hat on, please don't remove anything that has been part of your public ABI without changing the soname. More specifically, please change the soname whenever you remove/change a symbol prototyped in a header file for some library without KRB5_PRIVATE being required to get the symbol. I don't care much for cases where you don't install the header, but for things like kadmin, even though we're not committing to a stable ABI, we should at least change the sonames. From William.Fiveash at sun.com Fri Oct 23 17:50:35 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Fri, 23 Oct 2009 16:50:35 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> Message-ID: <20091023215035.GA4774@sun.com> On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > The preauth framework strongly encourages implementations to take > optimistic pre-auth as a hint. If you try some pre-auth and get a > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as > the KDC requesting you start over. Now, if that second round fails, > you should probably give up. But consider pam_krb5 and prompting. There may be situations where pam_krb5 wants to restrict libkrb and it's preauth plugins to only PKINIT and it's associated prompts. How can that be done? > Basically, the question is whether we take that gic option call as an > optimization or security constraint. Most people who have used it in > the past have been looking for an optimization. In the case of setting the preauth list why can't it be both? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From William.Fiveash at sun.com Fri Oct 23 18:04:57 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Fri, 23 Oct 2009 17:04:57 -0500 Subject: issue with preauth processing In-Reply-To: <20091023215035.GA4774@sun.com> References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> Message-ID: <20091023220457.GB4774@sun.com> On Fri, Oct 23, 2009 at 04:50:35PM -0500, Will Fiveash wrote: > On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > > The preauth framework strongly encourages implementations to take > > optimistic pre-auth as a hint. If you try some pre-auth and get a > > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as > > the KDC requesting you start over. Now, if that second round fails, > > you should probably give up. > > But consider pam_krb5 and prompting. There may be situations where > pam_krb5 wants to restrict libkrb and it's preauth plugins to only > PKINIT and it's associated prompts. How can that be done? In addition I notice that kpasswd is prompting for a PIN if the system is configured to do PKINIT. I notice in the source for kpasswd there is a call to: static void get_init_creds_opt_init( krb5_get_init_creds_opt *outOptions ) { krb5_preauthtype preauth[] = { KRB5_PADATA_ENC_TIMESTAMP }; krb5_enctype etypes[] = {ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC}; krb5_get_init_creds_opt_set_address_list(outOptions, NULL); krb5_get_init_creds_opt_set_etype_list( outOptions, etypes, sizeof(etypes)/sizeof(krb5_enctype) ); krb5_get_init_creds_opt_set_preauth_list(outOptions, preauth, sizeof(preauth)/sizeof(krb5_preauthtype) ); } Seems to me that the intention is to restrict the preauth to only KRB5_PADATA_ENC_TIMESTAMP. -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/ From William.Fiveash at sun.com Fri Oct 23 18:19:38 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Fri, 23 Oct 2009 17:19:38 -0500 Subject: issue with preauth processing In-Reply-To: <20091023220457.GB4774@sun.com> References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> <20091023220457.GB4774@sun.com> Message-ID: <20091023221938.GC4774@sun.com> On Fri, Oct 23, 2009 at 05:04:57PM -0500, Will Fiveash wrote: > On Fri, Oct 23, 2009 at 04:50:35PM -0500, Will Fiveash wrote: > > On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > > > The preauth framework strongly encourages implementations to take > > > optimistic pre-auth as a hint. If you try some pre-auth and get a > > > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as > > > the KDC requesting you start over. Now, if that second round fails, > > > you should probably give up. > > > > But consider pam_krb5 and prompting. There may be situations where > > pam_krb5 wants to restrict libkrb and it's preauth plugins to only > > PKINIT and it's associated prompts. How can that be done? > > In addition I notice that kpasswd is prompting for a PIN if the system > is configured to do PKINIT. I notice in the source for kpasswd there is > a call to: > > static void get_init_creds_opt_init( krb5_get_init_creds_opt *outOptions ) > { > krb5_preauthtype preauth[] = { KRB5_PADATA_ENC_TIMESTAMP }; > krb5_enctype etypes[] = {ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC}; > krb5_get_init_creds_opt_set_address_list(outOptions, NULL); > krb5_get_init_creds_opt_set_etype_list( outOptions, etypes, sizeof(etypes)/sizeof(krb5_enctype) ); > krb5_get_init_creds_opt_set_preauth_list(outOptions, preauth, sizeof(preauth)/sizeof(krb5_preauthtype) ); > } > > Seems to me that the intention is to restrict the preauth to only > KRB5_PADATA_ENC_TIMESTAMP. I also notice this in src/lib/krb5/krb/s4u_creds.c: krb5_get_init_creds_opt_set_preauth_list(opts, ptypes, 1); where ptypes is: krb5_preauthtype ptypes[1] = { KRB5_PADATA_S4U_X509_USER }; Isn't the point to restrict the preauth to just KRB5_PADATA_S4U_X509_USER? (Luke, I also think that code is buggy, shouldn't that be ptypes[0]?) -- Will Fiveash Sun Microsystems Office x64079/512-401-1079 Austin, TX, 78727 (TZ=CST6CDT), USA Internal Solaris Kerberos/GSS/SASL website: http://kerberos.sfbay.sun.com http://opensolaris.org/os/project/kerberos/ From lukeh at padl.com Fri Oct 23 18:34:54 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 23 Oct 2009 18:34:54 -0400 Subject: issue with preauth processing In-Reply-To: <20091023221938.GC4774@sun.com> References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> <20091023220457.GB4774@sun.com> <20091023221938.GC4774@sun.com> Message-ID: <3DB8AA1E-1D47-4513-8861-DBEBB2CED157@padl.com> > I also notice this in src/lib/krb5/krb/s4u_creds.c: > > krb5_get_init_creds_opt_set_preauth_list(opts, ptypes, 1); > > where ptypes is: > > krb5_preauthtype ptypes[1] = { KRB5_PADATA_S4U_X509_USER }; > > Isn't the point to restrict the preauth to just > KRB5_PADATA_S4U_X509_USER? Yep and from memory this works. > (Luke, I also think that code is buggy, shouldn't that be ptypes[0]?) No, we want enough space to hold one krb5_preauthtype. -- Luke From Nicolas.Williams at sun.com Fri Oct 23 18:24:25 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 23 Oct 2009 17:24:25 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> Message-ID: <20091023222425.GE892@Sun.COM> On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > The preauth framework strongly encourages implementations to take > optimistic pre-auth as a hint. If you try some pre-auth and get a > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you should take that as > the KDC requesting you start over. Now, if that second round fails, > you should probably give up. > > Basically, the question is whether we take that gic option call as an > optimization or security constraint. Most people who have used it in > the past have been looking for an optimization. First, I get that currently this is a not a "list of pre-auths to try" option, but with FAST in the picture we're likely going to need such a thing. In any case the KDC can return a list of pre-auth methods to try, so one way or another we'll have a loop over pre-auth methods to try. Second, I think it's fair for an application to want to avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP" methods, even if the KDC might allow it, in which case you'd want the system to try all other pre-auth methods available. I see this as a security constraint, since if a client just tries PA-ENC-TIMESTAMP there's harm done (if you worry about off-line dictionary attacks by eavesdroppers). And since a KDC's KRB-ERROR saying to try PA-ENC-TIMESTAMP could be spoofed... I really see this as a security constraint. I understand that changing the semantics of this gic option now is probably not acceptable, so maybe we should add a new option to indicate that the app's pre-auth choice(s) is(are) mandatory, not mere optimistic choices. Nico -- From William.Fiveash at sun.com Fri Oct 23 19:24:45 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Fri, 23 Oct 2009 18:24:45 -0500 Subject: issue with preauth processing In-Reply-To: <3DB8AA1E-1D47-4513-8861-DBEBB2CED157@padl.com> References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> <20091023220457.GB4774@sun.com> <20091023221938.GC4774@sun.com> <3DB8AA1E-1D47-4513-8861-DBEBB2CED157@padl.com> Message-ID: <20091023232444.GD4774@sun.com> On Fri, Oct 23, 2009 at 06:34:54PM -0400, Luke Howard wrote: > > > I also notice this in src/lib/krb5/krb/s4u_creds.c: > > > > krb5_get_init_creds_opt_set_preauth_list(opts, ptypes, 1); > > > > where ptypes is: > > > > krb5_preauthtype ptypes[1] = { KRB5_PADATA_S4U_X509_USER }; > > > > Isn't the point to restrict the preauth to just > > KRB5_PADATA_S4U_X509_USER? > > Yep and from memory this works. > > > (Luke, I also think that code is buggy, shouldn't that be ptypes[0]?) > > > No, we want enough space to hold one krb5_preauthtype. Yep, my mistake on that. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From lukeh at padl.com Sat Oct 24 19:06:12 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 24 Oct 2009 19:06:12 -0400 Subject: HDBBridge review Message-ID: <15178999-2198-4D27-AD67-48BA6882976D@padl.com> Hello, I am submitting the HDBBridge project up for review, ending 31 October 2009: http://k5wiki.kerberos.org/wiki/Projects/HDBBridge I have successfully used this to migrate a flat file Heimdal database to MIT. I anticipate this would also work with LDAP backends. With respect to the PAC glue layer, I have tested this with Heimdal's sample windc plugin, but am yet to test with Samba4, as this will require a dynamically built version of Samba4. regards, -- Luke -- www.padl.com | www.fghr.net From ghudson at MIT.EDU Sun Oct 25 13:06:33 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Sun, 25 Oct 2009 13:06:33 -0400 (EDT) Subject: Sanity check: kadm5 unit test organization change Message-ID: <200910251706.n9PH6XfD026317@outgoing.mit.edu> I'd like to reorganize the kadm5 unit tests slightly in order to reduce the amount of churn associated with bumping the kadmin API version. Right now we have directories api.1, api.2, and (recently added) api.3. This is good because it lets us test compatibility with older versions of the API, but bad because we have to copy or move all of the test cases every time we rev the API, no matter how minor the change to the API. What I'd like to do is have api.1, api.2, and api.current. The next time we bump the API version, we'll create api.3 and populate it with the specific test cases whose behavior changes between version 3 and version 4; the tests in api.current will remain in place and will just be updated for the new API version. From sanribu at gmail.com Sun Oct 25 15:16:14 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Sun, 25 Oct 2009 20:16:14 +0100 Subject: Error calling function protocol status: 1312 In-Reply-To: <30F05A76-8B7D-4518-B948-891A89160512@Sun.COM> References: <711a961b0910140355p360d3f05kb427c3e510e56552@mail.gmail.com> <711a961b0910190321h1a18a366p858cae9f45e75fb8@mail.gmail.com> <9CA14621-5BE8-4EB9-A941-DF5D83783006@Sun.COM> <711a961b0910211119k2bbffc78ya4f0ed4de403ae36@mail.gmail.com> <4ADF6D88.4020200@anl.gov> <711a961b0910230058x74297a93xdbdf615134743191@mail.gmail.com> <711a961b0910230101k78b9169s99fddba2156f9594@mail.gmail.com> <4AE1B802.4030709@anl.gov> <30F05A76-8B7D-4518-B948-891A89160512@Sun.COM> Message-ID: <711a961b0910251216h6b95cc4xc7872425fe371825@mail.gmail.com> Ok, thank you all! 2009/10/23 Max (Weijun) Wang > Java does not support AES256 out of box due to some export control reasons. > You need to apply the "Java Cryptography Extension (JCE) Unlimited Strength > Jurisdiction Policy File". The file can be download from the following page: > > http://java.sun.com/javase/downloads/index.jsp > > Scroll down the page and it's the last download link. > > Thanks > Max > > > On Oct 23, 2009, at 10:04 PM, Douglas E. Engert wrote: > > Looks like NIM is getting a TGT with AES256 (enctype 18). >> And your KDC supports it too. >> >> It looks like your java is version 5 See: >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/jgss/jgss-features.html >> >> >> >>>DEBUG >> >>> KrbCreds found the default ticket granting ticket in credential >> cache. >> >>> unsupported key type found the default TGT: 18 >> >> Acquire default native Credentials >> >>> Found no TGT's in LSA >> >> >> Looks like the Java obtained TGT is using DES. >> >>>KinitOptions cache name is C:\Documents and >> Settings\santi\krb5cc_santi >> >>>DEBUG client principal is santi at ZIGIA.ORG >> >>>DEBUG server principal is krbtgt/ZIGIA.ORG >> @ZIGIA.ORG >> >>>DEBUG key type: 1 >> >> But the Java version you are running supports DES, DES, RC4, 3DES and 3DES >> >>> Credentials acquireServiceCreds: same realm >> Using builtin default etypes for default_tgs_enctypes >> default etypes for default_tgs_enctypes: 3 1 23 16 17. >> >> >> Santiago Rivas wrote: >> >>> Ooops, it seems that rar attachment didin't work. I re-send the txt >>> files... >>> 2009/10/23 Santiago Rivas > >>> Hi, >>> The application runs from the command line. Yesterday I ran it >>> with >>> the option you recommended (-Dsun.security.krb5.debug=true) and here >>> you are the different outputs. >>> /jvm.rar/ includes both the credentials cache generated with JVM >>> (kinit) and the output I get when I use them to run the Client. >>> /nim.rar/ includes both the credentials cache generated with NIM >>> and >>> the output I get when I use them to run the Client (one specifiyng >>> the principal in the jaas.conf and another without doing it). >>> Regards, >>> Santi >>> 2009/10/22 Max (Weijun) Wang >> > >>> Hi Santiago >>> Java is coded to support type 4 ccache, it just hasn't made use >>> of the tags inside. Can you send me a copy of your ccache? >>> It seems you've only specified debug=true in the JAAS config >>> file. Please also add the system property >>> sun.security.krb5.debug=true. I don't know how you launch the >>> program. For the command line, it looks like --- >>> java -Dsun.security.krb5.debug=true YourApp >>> BTW, You mentioned the program works fine with kinit.exe from >>> JDK. Can you show what the output in that case is? >>> Thanks >>> Max >>> On Oct 22, 2009, at 4:22 AM, Douglas E. Engert wrote: >>> Santiago Rivas wrote: >>> After enabling debug mode, this is what I've got: >>> Case 1: No principal is specified in jaas.conf >>> *Debug is true storeKey false useTicketCache true >>> useKeyTab false >>> doNotPrompt fa >>> lse ticketCache is null isInitiator true KeyTab is null >>> refreshKrb5Config is >>> fal >>> se principal is null tryFirstPass is false useFirstPass >>> is false storePass >>> is fa >>> lse clearPass is false >>> Acquire TGT from Cache >>> Error calling function Protocol status: 1312 >>> A specified logon session does not exist. It may already >>> have been >>> terminated >>> Principal is null >>> null credentials from Ticket Cache >>> Username for Kerberos [santi]:* >>> ... >>> IMHO, it seems like JVM is not able to parse the >>> credentials file generated >>> by NIM. Referring to the credentials cache, is there any >>> "known >>> incompatibility" between NIM and JVM which I should be >>> aware of? >>> Thanks again! >>> This could be an issue of the cache version. NIM looks like >>> it is writing >>> a type 4 cache. (First two bytes in the file are 0x05 0x04. >>> The 0x04 is the >>> version.) It could be Java only knows how to handle versions >>> up to 3. >>> In the MIT krb5.conf used by NIM, try adding to >>> [libdefaults] sectiom: >>> ccache_type = 3 >>> NIM will then write a type 3 cache. >>> (This is not the only Kerberos feature that Java is way >>> behind on either. >>> Using dns_lookup_kdc = 1 to use the DNS SRV records is a >>> major one >>> especially on Windows...) >>> >> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> > > From sanribu at gmail.com Mon Oct 26 07:01:53 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Mon, 26 Oct 2009 12:01:53 +0100 Subject: Windows LSA under a non-Windows domain Message-ID: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> Hi everyone, I'm setting up Kerberos to work on Windows XP machines managed by a Samba as PDC. Thanks to your support, I know how to configure the credentials file cache on Windows platform. Next step is learn how to use Local Security Authority (LSA) in order to obtain TGT automatically from user logon. I've read several documents on the web ( http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html) and I get an idea, but still have some questions to ask: - Is it required to be under an Active Directory Windows Domain for LSA to gather the credentials? I ask it because most of the articles that I've read about LSA asume to be on that scenario, nevertheless I'm using openldap and Samba (as I mentioned before). - If it's possible to use LSA under a non-Windows domain, is there any extra configuration needed? (besides the *allowtgtsessionkey* registry change) Thanks in advance! From Weijun.Wang at sun.com Mon Oct 26 09:30:15 2009 From: Weijun.Wang at sun.com (Max (Weijun) Wang) Date: Mon, 26 Oct 2009 21:30:15 +0800 Subject: Windows LSA under a non-Windows domain In-Reply-To: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> Message-ID: http://www.ibm.com/developerworks/aix/library/au-unixothers/ Also, Googling "Samba as Windows Domain Controller" shows a lot of results. --Max On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: > Hi everyone, > > I'm setting up Kerberos to work on Windows XP machines managed by a > Samba as > PDC. > > Thanks to your support, I know how to configure the credentials file > cache > on Windows platform. Next step is learn how to use Local Security > Authority > (LSA) in order to obtain TGT automatically from user logon. > > I've read several documents on the web ( > http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html) > and I get an idea, but still have some questions to ask: > > - Is it required to be under an Active Directory Windows Domain for > LSA to > gather the credentials? I ask it because most of the articles that > I've read > about LSA asume to be on that scenario, nevertheless I'm using > openldap and > Samba (as I mentioned before). > > - If it's possible to use LSA under a non-Windows domain, is there > any extra > configuration needed? (besides the *allowtgtsessionkey* registry > change) > > Thanks in advance! > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From sanribu at gmail.com Mon Oct 26 11:08:08 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Mon, 26 Oct 2009 16:08:08 +0100 Subject: Windows LSA under a non-Windows domain In-Reply-To: References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> Message-ID: <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> Sorry Max, I'm afraid there must be a mistake, cause all the Samba configuration work is already done. I'm asking for information about LSA... Thanks! 2009/10/26 Max (Weijun) Wang > http://www.ibm.com/developerworks/aix/library/au-unixothers/ > > Also, Googling "Samba as Windows Domain Controller" shows a lot of results. > > --Max > > > On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: > > Hi everyone, >> >> I'm setting up Kerberos to work on Windows XP machines managed by a Samba >> as >> PDC. >> >> Thanks to your support, I know how to configure the credentials file cache >> on Windows platform. Next step is learn how to use Local Security >> Authority >> (LSA) in order to obtain TGT automatically from user logon. >> >> I've read several documents on the web ( >> >> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >> ) >> and I get an idea, but still have some questions to ask: >> >> - Is it required to be under an Active Directory Windows Domain for LSA to >> gather the credentials? I ask it because most of the articles that I've >> read >> about LSA asume to be on that scenario, nevertheless I'm using openldap >> and >> Samba (as I mentioned before). >> >> - If it's possible to use LSA under a non-Windows domain, is there any >> extra >> configuration needed? (besides the *allowtgtsessionkey* registry change) >> >> Thanks in advance! >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> > > From deengert at anl.gov Mon Oct 26 11:21:13 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 26 Oct 2009 10:21:13 -0500 Subject: Windows LSA under a non-Windows domain In-Reply-To: <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> Message-ID: <4AE5BE69.9070100@anl.gov> Santiago Rivas wrote: > Sorry Max, > > I'm afraid there must be a mistake, cause all the Samba configuration work > is already done. I'm asking for information about LSA... To see what is in the LSA, use the Microsoft kerbtray and/or klist commands, or the Network Identity Manager. runas with /user will run a command under a different user and will set the LSA. Also look at the /netonly option too. Also see the Microsoft ksetup command, useful with non-AD Kerberos realms. > > Thanks! > > 2009/10/26 Max (Weijun) Wang > >> http://www.ibm.com/developerworks/aix/library/au-unixothers/ >> >> Also, Googling "Samba as Windows Domain Controller" shows a lot of results. >> >> --Max >> >> >> On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: >> >> Hi everyone, >>> I'm setting up Kerberos to work on Windows XP machines managed by a Samba >>> as >>> PDC. >>> >>> Thanks to your support, I know how to configure the credentials file cache >>> on Windows platform. Next step is learn how to use Local Security >>> Authority >>> (LSA) in order to obtain TGT automatically from user logon. >>> >>> I've read several documents on the web ( >>> >>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>> ) >>> and I get an idea, but still have some questions to ask: >>> >>> - Is it required to be under an Active Directory Windows Domain for LSA to >>> gather the credentials? I ask it because most of the articles that I've >>> read >>> about LSA asume to be on that scenario, nevertheless I'm using openldap >>> and >>> Samba (as I mentioned before). >>> >>> - If it's possible to use LSA under a non-Windows domain, is there any >>> extra >>> configuration needed? (besides the *allowtgtsessionkey* registry change) >>> >>> Thanks in advance! >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >> > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From hartmans at MIT.EDU Mon Oct 26 14:33:45 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 26 Oct 2009 14:33:45 -0400 Subject: issue with preauth processing In-Reply-To: <20091023222425.GE892@Sun.COM> (Nicolas Williams's message of "Fri\, 23 Oct 2009 17\:24\:25 -0500") References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023222425.GE892@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> Second, I think it's fair for an application to want to Nicolas> avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP" Nicolas> methods, even if the KDC might allow it, in which case Nicolas> you'd want the system to try all other pre-auth methods Nicolas> available. I agree. I don't think that is what the current interface was intended to be though. At most you need three interfaces: * optimistic hint * list of mechanisms to avoid because they are constrained against * For cases like S4U a specific set of mechanisms we must use. From hartmans at MIT.EDU Mon Oct 26 14:38:06 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 26 Oct 2009 14:38:06 -0400 Subject: issue with preauth processing In-Reply-To: <20091023220457.GB4774@sun.com> (Will Fiveash's message of "Fri\, 23 Oct 2009 17\:04\:57 -0500") References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> <20091023220457.GB4774@sun.com> Message-ID: >>>>> "Will" == Will Fiveash writes: Will> On Fri, Oct 23, 2009 at 04:50:35PM -0500, Will Fiveash wrote: >> On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > > The preauth framework strongly encourages implementations to take >> > optimistic pre-auth as a hint. If you try some pre-auth and >> get a > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you >> should take that as > the KDC requesting you start over. Now, >> if that second round fails, > you should probably give up. >> >> But consider pam_krb5 and prompting. There may be situations >> where pam_krb5 wants to restrict libkrb and it's preauth >> plugins to only PKINIT and it's associated prompts. How can >> that be done? Will> In addition I notice that kpasswd is prompting for a PIN if Will> the system is configured to do PKINIT. I notice in the Will> source for kpasswd there is a call to: Will> static void get_init_creds_opt_init( krb5_get_init_creds_opt Will> *outOptions ) { krb5_preauthtype preauth[] = { Will> KRB5_PADATA_ENC_TIMESTAMP }; krb5_enctype etypes[] = Will> {ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC}; Will> krb5_get_init_creds_opt_set_address_list(outOptions, NULL); Will> krb5_get_init_creds_opt_set_etype_list( outOptions, etypes, Will> sizeof(etypes)/sizeof(krb5_enctype) ); Will> krb5_get_init_creds_opt_set_preauth_list(outOptions, Will> preauth, sizeof(preauth)/sizeof(krb5_preauthtype) ); Will> } Will> Seems to me that the intention is to restrict the preauth to only Will> KRB5_PADATA_ENC_TIMESTAMP. No, that sounds like optimistic pre-auth not a restriction. Our kpasswd doesn't seem to have those calls. The call to set the list of enctypes seems particularly unfortunate. From hartmans at MIT.EDU Mon Oct 26 14:39:26 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 26 Oct 2009 14:39:26 -0400 Subject: issue with preauth processing In-Reply-To: <20091023215035.GA4774@sun.com> (Will Fiveash's message of "Fri\, 23 Oct 2009 16\:50\:35 -0500") References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> Message-ID: >>>>> "Will" == Will Fiveash writes: Will> On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: >> The preauth framework strongly encourages implementations to >> take optimistic pre-auth as a hint. If you try some pre-auth >> and get a PREAUTH_REQUIRED or PREAUTH_FAILED error, then you >> should take that as the KDC requesting you start over. Now, if >> that second round fails, you should probably give up. Will> But consider pam_krb5 and prompting. There may be Will> situations where pam_krb5 wants to restrict libkrb and it's Will> preauth plugins to only PKINIT and it's associated prompts. Will> How can that be done? I don't think we have an API for that today. (I'm also not entirely convinced that libpam-krb5 should do this.) I do think such an API would be reasonable in some cases--for example the s4u case. From Nicolas.Williams at sun.com Mon Oct 26 14:34:56 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 13:34:56 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023222425.GE892@Sun.COM> Message-ID: <20091026183455.GP892@Sun.COM> On Mon, Oct 26, 2009 at 02:33:45PM -0400, Sam Hartman wrote: > Nicolas> Second, I think it's fair for an application to want to > Nicolas> avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP" > Nicolas> methods, even if the KDC might allow it, in which case > Nicolas> you'd want the system to try all other pre-auth methods > Nicolas> available. > > I agree. > I don't think that is what the current interface was intended to be though. I know. I'm not sure that changing this semantic now would break anything, but then, I also agree with this: > At most you need three interfaces: > * optimistic hint > * list of mechanisms to avoid because they are constrained against > * For cases like S4U a specific set of mechanisms we must use. Except that I'm not sure that there's a real need for an optimistic hint. Nico -- From Nicolas.Williams at sun.com Mon Oct 26 14:44:18 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 13:44:18 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> Message-ID: <20091026184418.GQ892@Sun.COM> On Mon, Oct 26, 2009 at 02:39:26PM -0400, Sam Hartman wrote: > >>>>> "Will" == Will Fiveash writes: > Will> But consider pam_krb5 and prompting. There may be > Will> situations where pam_krb5 wants to restrict libkrb and it's > Will> preauth plugins to only PKINIT and it's associated prompts. > Will> How can that be done? > > I don't think we have an API for that today. (I'm also not entirely > convinced that libpam-krb5 should do this.) I do think such an API > would be reasonable in some cases--for example the s4u case. Sam, I think pam_krb5 should be doing something else, yes, but, in Solaris we have other constraints that prevent us from doing something better. Nico -- From ghudson at MIT.EDU Mon Oct 26 15:44:58 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Mon, 26 Oct 2009 15:44:58 -0400 (EDT) Subject: How to extend kadmin Message-ID: <200910261944.n9QJiwin013887@outgoing.mit.edu> We've had some private discussions recently about how to best extend kadmin, prompted by the account lockout work. I'm bringing this to the larger community. There are three plausible ways to extend kadmin: 1. Bump the api_version, which is communicated to the server through the init_2 RPC when a connection is established. This has now been done three times: twice before the code was incorporated into the MIT tree in 1996, and once for the lockout code. The api_version is explicitly chosen by the caller. Support for API versions 0 and 1 was removed from the trunk (by me) in August 2009. 2. Bump the struct_version. This field's value is determined by admin.h, rather than the caller. Its value is passed to the kadm5_init functions but is never communicated to the server. The struct_version has never been bumped before; when the principal structure was changed prior to 1996, the OpenVision developers apparently chose to bump the api_version instead of the struct_version. Because the struct_version is not communicated to the server, protocol compatibility would demand that this mechanism be used in combination with (3) below. 3. Define new RPCs. This was done once in 1998 when keysalt support was added to chpass_principal, create_principal, setkey_principal, and randkey_principal. The client side of those functions choose whether to use the new or old RPCs depending on whether keysalts are specified. I do not currently know whether the GSSRPC encoding allows a client to try a newer RPC and then fall back to an old one--that is, I don't know if the server can try and fail to process an unknown RPC type and still keep the connection in sync. The api_version bumps from 1->2 (ancient history) and 2->3 (lockout) both correspond to structure changes. The encoding of a principal_ent_rec changed from 1->2 and the encoding of a policy_ent_rec changed from 2->3. To accomplish this, the output of rpcgen was hacked to pass the version number into the relevant encoding functions and conditionalize on the version. As a result, the MIT tree has never generated the kadmin RPC encoders at build or distro-preparation time; we have always stored modified rpcgen C output in the source tree. I am told that Sun uses rpcgen at build time instead (they removed api v1 support in order to do this), and that they may have trouble with the lockout code in its current form as a result. I don't personally have a strong opinion as to how this should work. I have never been a fan of the RPC model of network protocols, so for me this is a question of how to make the best of an architecture I wouldn't have chosen. From sanribu at gmail.com Mon Oct 26 15:53:49 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Mon, 26 Oct 2009 20:53:49 +0100 Subject: Windows LSA under a non-Windows domain In-Reply-To: <4AE5BE69.9070100@anl.gov> References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> <4AE5BE69.9070100@anl.gov> Message-ID: <711a961b0910261253w2b2ef74dmac21d6a1c1a59307@mail.gmail.com> After installing both "*Windows 2000/XP support tools" *and "*Windows 2000/XP Resource Kit" *I run kerbtray but no credentials are found (list is empty). Searching the web, I've found the link http://mailman.mit.edu/pipermail/krbdev/2003-December/002106.html where you give the steps to set MSLSA cache for a non-Microsoft KDC. But when I run ksetup.exe I get the errors described in the attached file (ksetup_error.txt) Could you please help me? Thank you very much indeed! 2009/10/26 Douglas E. Engert > > > Santiago Rivas wrote: > >> Sorry Max, >> >> I'm afraid there must be a mistake, cause all the Samba configuration work >> is already done. I'm asking for information about LSA... >> > > To see what is in the LSA, use the Microsoft kerbtray and/or klist > commands, > or the Network Identity Manager. > > runas with /user will run a command under a different user and will > set the LSA. Also look at the /netonly option too. > > Also see the Microsoft ksetup command, useful with non-AD Kerberos realms. > > > > >> Thanks! >> >> 2009/10/26 Max (Weijun) Wang >> >> http://www.ibm.com/developerworks/aix/library/au-unixothers/ >>> >>> Also, Googling "Samba as Windows Domain Controller" shows a lot of >>> results. >>> >>> --Max >>> >>> >>> On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: >>> >>> Hi everyone, >>> >>>> I'm setting up Kerberos to work on Windows XP machines managed by a >>>> Samba >>>> as >>>> PDC. >>>> >>>> Thanks to your support, I know how to configure the credentials file >>>> cache >>>> on Windows platform. Next step is learn how to use Local Security >>>> Authority >>>> (LSA) in order to obtain TGT automatically from user logon. >>>> >>>> I've read several documents on the web ( >>>> >>>> >>>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>>> ) >>>> and I get an idea, but still have some questions to ask: >>>> >>>> - Is it required to be under an Active Directory Windows Domain for LSA >>>> to >>>> gather the credentials? I ask it because most of the articles that I've >>>> read >>>> about LSA asume to be on that scenario, nevertheless I'm using openldap >>>> and >>>> Samba (as I mentioned before). >>>> >>>> - If it's possible to use LSA under a non-Windows domain, is there any >>>> extra >>>> configuration needed? (besides the *allowtgtsessionkey* registry change) >>>> >>>> Thanks in advance! >>>> _______________________________________________ >>>> krbdev mailing list krbdev at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev >> >> >> > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > -------------- next part -------------- Microsoft Windows XP [Versi?n 5.1.2600] (C) Copyright 1985-2001 Microsoft Corp. C:\Documents and Settings\santi>ksetup Machine is not configured to log on to an external KDC. Probably a workgroup member Failed to create Kerberos key: 5 (0x5) C:\Documents and Settings\santi>ksetup /addkdc ZIGIA.ORG Failed to create Kerberos key: 5 (0x5) Failed to open Kerberos Key: 0x5 NOTE: /AddKdc requires a reboot to take effect on pre-SP1 Win2000 computers C:\Documents and Settings\santi>ksetup /addkdc ZIGIA.ORG krb.zigia.org Failed to create Kerberos key: 5 (0x5) Failed to open Kerberos Key: 0x5 Failed /AddKdc : 0xc0000001 C:\Documents and Settings\santi>ksetup /setrealm ZIGIA.ORG Setting Dns Domain Failed to set dns domain info: 0xc0000022 Failed /SetRealm : 0xc0000022 From William.Fiveash at sun.com Mon Oct 26 15:54:28 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Mon, 26 Oct 2009 14:54:28 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023215035.GA4774@sun.com> <20091023220457.GB4774@sun.com> Message-ID: <20091026195428.GE4774@sun.com> On Mon, Oct 26, 2009 at 02:38:06PM -0400, Sam Hartman wrote: > >>>>> "Will" == Will Fiveash writes: > > Will> On Fri, Oct 23, 2009 at 04:50:35PM -0500, Will Fiveash wrote: > >> On Fri, Oct 23, 2009 at 04:48:58PM -0400, Sam Hartman wrote: > > > The preauth framework strongly encourages implementations to take > >> > optimistic pre-auth as a hint. If you try some pre-auth and > >> get a > PREAUTH_REQUIRED or PREAUTH_FAILED error, then you > >> should take that as > the KDC requesting you start over. Now, > >> if that second round fails, > you should probably give up. > >> > >> But consider pam_krb5 and prompting. There may be situations > >> where pam_krb5 wants to restrict libkrb and it's preauth > >> plugins to only PKINIT and it's associated prompts. How can > >> that be done? > > Will> In addition I notice that kpasswd is prompting for a PIN if > Will> the system is configured to do PKINIT. I notice in the > Will> source for kpasswd there is a call to: > > Will> static void get_init_creds_opt_init( krb5_get_init_creds_opt > Will> *outOptions ) { krb5_preauthtype preauth[] = { > Will> KRB5_PADATA_ENC_TIMESTAMP }; krb5_enctype etypes[] = > Will> {ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC}; > Will> krb5_get_init_creds_opt_set_address_list(outOptions, NULL); > Will> krb5_get_init_creds_opt_set_etype_list( outOptions, etypes, > Will> sizeof(etypes)/sizeof(krb5_enctype) ); > Will> krb5_get_init_creds_opt_set_preauth_list(outOptions, > Will> preauth, sizeof(preauth)/sizeof(krb5_preauthtype) ); > Will> } > > Will> Seems to me that the intention is to restrict the preauth to only > Will> KRB5_PADATA_ENC_TIMESTAMP. > > No, that sounds like optimistic pre-auth not a restriction. > Our kpasswd doesn't seem to have those calls. I'm looking at src/clients/kpasswd/ksetpwd.c in the krb5/trunk and I see: static void get_init_creds_opt_init( krb5_get_init_creds_opt *outOptions ) { krb5_preauthtype preauth[] = { KRB5_PADATA_ENC_TIMESTAMP }; krb5_enctype etypes[] = {ENCTYPE_DES_CBC_MD5, ENCTYPE_DES_CBC_CRC}; krb5_get_init_creds_opt_set_address_list(outOptions, NULL); krb5_get_init_creds_opt_set_etype_list( outOptions, etypes, sizeof(etypes)/sizeof(krb5_enctype) ); krb5_get_init_creds_opt_set_preauth_list(outOptions, preauth, sizeof(preauth)/sizeof(krb5_preauthtype) ); } and in userinitcontext(): if( kres != 0 || have_credentials == 0 ) { krb5_get_init_creds_opt *options = NULL; kres = krb5_get_init_creds_opt_alloc(kcontext, &options); if ( kres == 0 ) { get_init_creds_opt_init(options); /* ** no valid credentials - get new ones */ kres = krb5_get_init_creds_password( kcontext, &kcreds, kme, pPass, NULL /*prompter*/, NULL /*data*/, 0 /*starttime*/, 0 /*in_tkt_service*/, options /*options*/ ); } > The call to set the list of enctypes seems particularly unfortunate. Yep. -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From hartmans at MIT.EDU Mon Oct 26 16:03:01 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Mon, 26 Oct 2009 16:03:01 -0400 Subject: issue with preauth processing In-Reply-To: <20091026183455.GP892@Sun.COM> (Nicolas Williams's message of "Mon\, 26 Oct 2009 13\:34\:56 -0500") References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023222425.GE892@Sun.COM> <20091026183455.GP892@Sun.COM> Message-ID: >>>>> "Nicolas" == Nicolas Williams writes: Nicolas> On Mon, Oct 26, 2009 at 02:33:45PM -0400, Sam Hartman wrote: Nicolas> Second, I think it's fair for an application to want to Nicolas> avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP" Nicolas> methods, even if the KDC might allow it, in which case Nicolas> you'd want the system to try all other pre-auth methods Nicolas> available. >> >> I agree. I don't think that is what the current interface was >> intended to be though. Nicolas> I know. I'm not sure that changing this semantic now Nicolas> would break anything, but then, I also agree with this: It would for example break someone using enc-ts for optimistic pre-auth who upgrades to FAST and then sholud be using enc-challenge. From Nicolas.Williams at sun.com Mon Oct 26 16:26:57 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 15:26:57 -0500 Subject: issue with preauth processing In-Reply-To: References: <20091021234632.GA1234@sun.com> <20091022000136.GA1331@sun.com> <20091022184348.GS892@Sun.COM> <20091023222425.GE892@Sun.COM> <20091026183455.GP892@Sun.COM> Message-ID: <20091026202657.GW892@Sun.COM> On Mon, Oct 26, 2009 at 04:03:01PM -0400, Sam Hartman wrote: > >>>>> "Nicolas" == Nicolas Williams writes: > > Nicolas> On Mon, Oct 26, 2009 at 02:33:45PM -0400, Sam Hartman wrote: > Nicolas> Second, I think it's fair for an application to want to > Nicolas> avoid the "no pre-auth" and "plain PA-ENC-TIMESTAMP" > Nicolas> methods, even if the KDC might allow it, in which case > Nicolas> you'd want the system to try all other pre-auth methods > Nicolas> available. > >> > >> I agree. I don't think that is what the current interface was > >> intended to be though. > > Nicolas> I know. I'm not sure that changing this semantic now > Nicolas> would break anything, but then, I also agree with this: > > It would for example break someone using enc-ts for optimistic > pre-auth who upgrades to FAST and then sholud be using enc-challenge. It's not clear to me that this was intended to be for optimistic purposes. But yes, assuming it was, then the addition of new password-based pre-auth would, indeed, break apps that wanted plain PA-ENC-TIMESTAMP as an optimistic choice. Still, it doesn't matter, we should just add the additional options that we need and move on. Nico -- From Nicolas.Williams at sun.com Mon Oct 26 16:51:13 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 15:51:13 -0500 Subject: How to extend kadmin In-Reply-To: <200910261944.n9QJiwin013887@outgoing.mit.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> Message-ID: <20091026205113.GX892@Sun.COM> On Mon, Oct 26, 2009 at 03:44:58PM -0400, ghudson at MIT.EDU wrote: > We've had some private discussions recently about how to best extend > kadmin, prompted by the account lockout work. I'm bringing this to > the larger community. > > There are three plausible ways to extend kadmin: > > 1. Bump the api_version, which is communicated to the server through > the init_2 RPC when a connection is established. This has now been > done three times: twice before the code was incorporated into the MIT > tree in 1996, and once for the lockout code. The api_version is > explicitly chosen by the caller. Support for API versions 0 and 1 was > removed from the trunk (by me) in August 2009. This doesn't achieve much. You could not, for example, change the arguments/results of any RPCs this way. > 2. Bump the struct_version. This field's value is determined by > admin.h, rather than the caller. Its value is passed to the > kadm5_init functions but is never communicated to the server. The > struct_version has never been bumped before; when the principal > structure was changed prior to 1996, the OpenVision developers > apparently chose to bump the api_version instead of the > struct_version. Because the struct_version is not communicated to the > server, protocol compatibility would demand that this mechanism be > used in combination with (3) below. This also doesn't achieve much: at most it tells the implementation to expect the caller to call various extensions (new functions). > 3. Define new RPCs. This was done once in 1998 when keysalt support > was added to chpass_principal, create_principal, setkey_principal, and > randkey_principal. The client side of those functions choose whether > to use the new or old RPCs depending on whether keysalts are > specified. I do not currently know whether the GSSRPC encoding allows > a client to try a newer RPC and then fall back to an old one--that is, > I don't know if the server can try and fail to process an unknown RPC > type and still keep the connection in sync. This is fine, and a very reasonable way forward. Yes, if you call an undefined RPC you get an error (the server doesn't blow up; the client doesn't blow up). > The api_version bumps from 1->2 (ancient history) and 2->3 (lockout) > both correspond to structure changes. The encoding of a > principal_ent_rec changed from 1->2 and the encoding of a > policy_ent_rec changed from 2->3. To accomplish this, the output of > rpcgen was hacked to pass the version number into the relevant > encoding functions and conditionalize on the version. As a result, I know. That's... horrible. Well and truly horrible. > the MIT tree has never generated the kadmin RPC encoders at build or > distro-preparation time; we have always stored modified rpcgen C > output in the source tree. I am told that Sun uses rpcgen at build > time instead (they removed api v1 support in order to do this), and > that they may have trouble with the lockout code in its current form > as a result. No, we don't even have a .x for the kadmin protocol (as none can now be constructed). Incremental propagation does use a .x file and rpcgen- generated code. > I don't personally have a strong opinion as to how this should work. > I have never been a fan of the RPC model of network protocols, so for > me this is a question of how to make the best of an architecture I > wouldn't have chosen. There's also: 4. Bump the RPC program version number (and start fresh). Given the code you already have, more of the same (see (3)) is probably the most expedient way forward. If you could re-write that code I'd say go with (4), and this time have clean XDR and rpcgen-generated marshalling code. IMO there are few serious problems with ONC RPC, mostly: a) the fact that implementations tend to be _synchronous_, even though nothing about the protocol framework requires it, b) the RPCSEC_GSS API we have sucks. The rest is fine. Think of XDR-the-syntax as ASN.1-lite, and XDR-the-encoding as like a PER with four octet alignment for XDR-the-syntax-as-ASN.1-lite (that's actually very close to the mark, IMO). Now, what is wrong with that? Would you really prefer the full power of ASN.1? (In some cases I would, but not for kadmin.) Would you really prefer BER/DER/CER? (Same thing.) ONC RPC/XDR comes with a compiler that works and has worked for decades, though the compiler doesn't generate high-performance code (but for this it's just fine). The RPC framework has been contributed (dunno the exact terms, but you do, I'm sure) to MIT, so the implementation is free, including, I think, the compiler. You're going to need an encoding for any kadmin extensions. You get to choose whether to use an off-the-shelf encoding or a hand-crafted one. If the former you also get to choose whether to use a formal syntax or hand-craft the code. If you want to minimize security bugs you should use a formal syntax and a compiler and run-time. You don't have a whole lot of options in that department. ASN.1 is great, but until you have a compiler that you can use in MIT krb5, forget it -- it's bad enough that you have to hand- craft ASN.1/DER code for every Kerberos extension that comes along. In this case, I'm afraid that the most expedient option is (3): more of the same. That's unfortunate. Nico -- From deengert at anl.gov Mon Oct 26 17:08:38 2009 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 26 Oct 2009 16:08:38 -0500 Subject: Windows LSA under a non-Windows domain In-Reply-To: <711a961b0910261253w2b2ef74dmac21d6a1c1a59307@mail.gmail.com> References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> <4AE5BE69.9070100@anl.gov> <711a961b0910261253w2b2ef74dmac21d6a1c1a59307@mail.gmail.com> Message-ID: <4AE60FD6.5020904@anl.gov> Santiago Rivas wrote: > After installing both "*Windows 2000/XP support tools" *and "*Windows > 2000/XP Resource Kit" *I run kerbtray but no credentials are found (list is > empty). > > Searching the web, I've found the link > http://mailman.mit.edu/pipermail/krbdev/2003-December/002106.html where you > give the steps to set MSLSA cache for a non-Microsoft KDC. But when I run > ksetup.exe I get the errors described in the attached file > (ksetup_error.txt) > Could you please help me? That note was from 6 years ago. There is a ksetup for XP SP2 Google for: site:microsoft.com ksetup download The LSA would be empty unless you logged into XP using AD or Samba using Kerberos. (The Microsoft kinit or runas should also update the LSA.) Are you using NTLM by chance? If you are using Samba, you might be better off asking your questions on how to setup a Samba client to use Kerberos on that last. > > Thank you very much indeed! > > > 2009/10/26 Douglas E. Engert > >> >> Santiago Rivas wrote: >> >>> Sorry Max, >>> >>> I'm afraid there must be a mistake, cause all the Samba configuration work >>> is already done. I'm asking for information about LSA... >>> >> To see what is in the LSA, use the Microsoft kerbtray and/or klist >> commands, >> or the Network Identity Manager. >> >> runas with /user will run a command under a different user and will >> set the LSA. Also look at the /netonly option too. >> >> Also see the Microsoft ksetup command, useful with non-AD Kerberos realms. >> >> >> >> >>> Thanks! >>> >>> 2009/10/26 Max (Weijun) Wang >>> >>> http://www.ibm.com/developerworks/aix/library/au-unixothers/ >>>> Also, Googling "Samba as Windows Domain Controller" shows a lot of >>>> results. >>>> >>>> --Max >>>> >>>> >>>> On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: >>>> >>>> Hi everyone, >>>> >>>>> I'm setting up Kerberos to work on Windows XP machines managed by a >>>>> Samba >>>>> as >>>>> PDC. >>>>> >>>>> Thanks to your support, I know how to configure the credentials file >>>>> cache >>>>> on Windows platform. Next step is learn how to use Local Security >>>>> Authority >>>>> (LSA) in order to obtain TGT automatically from user logon. >>>>> >>>>> I've read several documents on the web ( >>>>> >>>>> >>>>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>>>> ) >>>>> and I get an idea, but still have some questions to ask: >>>>> >>>>> - Is it required to be under an Active Directory Windows Domain for LSA >>>>> to >>>>> gather the credentials? I ask it because most of the articles that I've >>>>> read >>>>> about LSA asume to be on that scenario, nevertheless I'm using openldap >>>>> and >>>>> Samba (as I mentioned before). >>>>> >>>>> - If it's possible to use LSA under a non-Windows domain, is there any >>>>> extra >>>>> configuration needed? (besides the *allowtgtsessionkey* registry change) >>>>> >>>>> Thanks in advance! >>>>> _______________________________________________ >>>>> krbdev mailing list krbdev at mit.edu >>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>> >>>>> >>>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >>> >>> >> -- >> >> Douglas E. Engert >> Argonne National Laboratory >> 9700 South Cass Avenue >> Argonne, Illinois 60439 >> (630) 252-5444 >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> krbdev mailing list krbdev at mit.edu >> https://mailman.mit.edu/mailman/listinfo/krbdev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From raeburn at MIT.EDU Mon Oct 26 17:08:21 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Mon, 26 Oct 2009 17:08:21 -0400 Subject: How to extend kadmin In-Reply-To: <200910261944.n9QJiwin013887@outgoing.mit.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> Message-ID: <2BB257B8-3914-42EE-8464-E76EB6B8BF53@mit.edu> On Oct 26, 2009, at 15:44, ghudson at MIT.EDU wrote: > To accomplish this, the output of > rpcgen was hacked to pass the version number into the relevant > encoding functions and conditionalize on the version. As a result, > the MIT tree has never generated the kadmin RPC encoders at build or > distro-preparation time; we have always stored modified rpcgen C > output in the source tree. I am told that Sun uses rpcgen at build > time instead (they removed api v1 support in order to do this), and > that they may have trouble with the lockout code in its current form > as a result. I tried to reverse-engineer an rpcgen input file a long time ago, but the v1/v2 combination was quite a pain. With v1 gone, it may be possible again. If it's at all possible, *please* do something compatible with the use of rpcgen to generate the files. Unless we switch to a new, non-RPC protocol, an eventual switch to rpcgen should help with maintenance and future changes. Even if you're not convinced of that, please don't do anything to close the door on that option. (Maybe I should dust off my rpcgen stuff and give it another look...) Ken From jhutz at cmu.edu Mon Oct 26 17:27:46 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 26 Oct 2009 17:27:46 -0400 Subject: How to extend kadmin In-Reply-To: <10563_1256591050_n9QL49X1014786_20091026205113.GX892@Sun.COM> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <10563_1256591050_n9QL49X1014786_20091026205113.GX892@Sun.COM> Message-ID: --On Monday, October 26, 2009 03:51:13 PM -0500 Nicolas Williams wrote: > 4. Bump the RPC program version number (and start fresh). Fine, but why do you then go on and spend four paragraphs extolling the virtues of ONC RPC in general and XDR in particular over ASN.1, when no one has proposed doing anything involving the latter? OTOH, I suppose someone should ask the question... Do we believe that we will eventually end up with a schema for an LDAP-based admin protocol, and if so, will it end up replacing the current kadmin protocol? If so, anything we do now is a stopgap. If not, we should be thinking about the long term. -- Jeff From lukeh at padl.com Mon Oct 26 17:31:11 2009 From: lukeh at padl.com (Luke Howard) Date: Mon, 26 Oct 2009 22:31:11 +0100 Subject: How to extend kadmin In-Reply-To: <20091026205113.GX892@Sun.COM> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <20091026205113.GX892@Sun.COM> Message-ID: > This doesn't achieve much. You could not, for example, change the > arguments/results of any RPCs this way. We can because the api_version is included in the relevant data structures. I prefer to avoid proliferation of RPCs for simply varying the data structures: look how horrible [MS-SAMR] looks because of this. static bool_t _xdr_kadm5_policy_ent_rec(XDR *xdrs, kadm5_policy_ent_rec *objp, int vers) { ... if (vers == KADM5_API_VERSION_3) { if (!xdr_krb5_kvno(xdrs, &objp->pw_max_fail)) return (FALSE); if (!xdr_krb5_deltat(xdrs, &objp->pw_failcnt_interval)) return (FALSE); if (!xdr_krb5_deltat(xdrs, &objp->pw_lockout_duration)) return (FALSE); } else if (xdrs->x_op == XDR_DECODE) { objp->pw_max_fail = 0; objp->pw_failcnt_interval = 0; objp->pw_lockout_duration = 0; } } bool_t xdr_gpol_ret(XDR *xdrs, gpol_ret *objp) { if (!xdr_ui_4(xdrs, &objp->api_version)) { return (FALSE); } if (!xdr_kadm5_ret_t(xdrs, &objp->code)) { return (FALSE); } if(objp->code == KADM5_OK) { if (!_xdr_kadm5_policy_ent_rec(xdrs, &objp->rec, objp->api_version)) return (FALSE); } return (TRUE); } -- Luke From Nicolas.Williams at sun.com Mon Oct 26 17:26:43 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 16:26:43 -0500 Subject: How to extend kadmin In-Reply-To: <2BB257B8-3914-42EE-8464-E76EB6B8BF53@mit.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <2BB257B8-3914-42EE-8464-E76EB6B8BF53@mit.edu> Message-ID: <20091026212643.GB892@Sun.COM> IIRC the kadmin principal name type cannot be described with XDR given how it's cobbled together on the wire. I should look again... From Nicolas.Williams at sun.com Mon Oct 26 17:35:09 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 16:35:09 -0500 Subject: How to extend kadmin In-Reply-To: References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <20091026205113.GX892@Sun.COM> Message-ID: <20091026213509.GD892@Sun.COM> On Mon, Oct 26, 2009 at 10:31:11PM +0100, Luke Howard wrote: > >This doesn't achieve much. You could not, for example, change the > >arguments/results of any RPCs this way. > > We can because the api_version is included in the relevant data > structures. I prefer to avoid proliferation of RPCs for simply varying > the data structures: look how horrible [MS-SAMR] looks because of this. With BER/DER/CER you can always reasonably turn a field of a SEQUENCE into a CHOICE and negotiate use of alternative CHOICEs. With PER-like encodings you have to think ahead and add extensibility in the right places, else you must add new procedures/operations/whatever you want to call them, or you must have truly fancy syntax that allows you to indicate alternatives which the encoders/decoders must receive indications of parametrically. As it is, if you try turning some field into a CHOICE then you can no longer use machine-generated code. XDR is a PER-like encoding. And XDR is not that fancy a syntax. But see my response to Jeff. I would, in fact, rather move to an LDAP-based solution. Nico -- From Nicolas.Williams at sun.com Mon Oct 26 17:30:00 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 16:30:00 -0500 Subject: How to extend kadmin In-Reply-To: References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <10563_1256591050_n9QL49X1014786_20091026205113.GX892@Sun.COM> Message-ID: <20091026212959.GC892@Sun.COM> On Mon, Oct 26, 2009 at 05:27:46PM -0400, Jeffrey Hutzelman wrote: > --On Monday, October 26, 2009 03:51:13 PM -0500 Nicolas Williams > wrote: > > >4. Bump the RPC program version number (and start fresh). > > Fine, but why do you then go on and spend four paragraphs extolling the > virtues of ONC RPC in general and XDR in particular over ASN.1, when no one > has proposed doing anything involving the latter? I was responding to "I have never been a fan of the RPC model of network protocols...". > OTOH, I suppose someone should ask the question... Do we believe that we > will eventually end up with a schema for an LDAP-based admin protocol, and > if so, will it end up replacing the current kadmin protocol? > > If so, anything we do now is a stopgap. > If not, we should be thinking about the long term. Darn, I forgot about this. I mostly agree, I'd rather see us move wholesale to LDAP. I happen to greatly dislike the LDAP schema that we all inheritted from Novell though. And also, for some things we absolutely need a protocol (think change/set password protocols), though it could always run as an LDAP extended operation. Nico -- From lukeh at padl.com Mon Oct 26 17:56:03 2009 From: lukeh at padl.com (Luke Howard) Date: Mon, 26 Oct 2009 22:56:03 +0100 Subject: How to extend kadmin In-Reply-To: <20091026213509.GD892@Sun.COM> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <20091026205113.GX892@Sun.COM> <20091026213509.GD892@Sun.COM> Message-ID: > But see my response to Jeff. I would, in fact, rather move to an > LDAP-based solution. Hey, it's 2009, we should be using SOAP. ;-) -- Luke From jhutz at cmu.edu Mon Oct 26 17:56:50 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Mon, 26 Oct 2009 17:56:50 -0400 Subject: How to extend kadmin In-Reply-To: <20091026212959.GC892@Sun.COM> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <10563_1256591050_n9QL49X1014786_20091026205113.GX892@Sun.COM> <20091026212959.GC892@Sun.COM> Message-ID: <6D03AB693DBBFE5F2393F83D@minbar.fac.cs.cmu.edu> --On Monday, October 26, 2009 04:30:00 PM -0500 Nicolas Williams wrote: > Darn, I forgot about this. I mostly agree, I'd rather see us move > wholesale to LDAP. I happen to greatly dislike the LDAP schema that we > all inheritted from Novell though. Well, but that's a schema for using LDAP as a KDB backend, which is a different beast. > And also, for some things we > absolutely need a protocol (think change/set password protocols) Yes. If only we had such a protocol, just waiting to be published. :-) -- Jeff From sanribu at gmail.com Mon Oct 26 17:58:37 2009 From: sanribu at gmail.com (Santiago Rivas) Date: Mon, 26 Oct 2009 22:58:37 +0100 Subject: Windows LSA under a non-Windows domain In-Reply-To: <4AE60FD6.5020904@anl.gov> References: <711a961b0910260401nd46ac78k678275e2f7a5cf1@mail.gmail.com> <711a961b0910260808o3bf32e40ia17d815cd1f17a4@mail.gmail.com> <4AE5BE69.9070100@anl.gov> <711a961b0910261253w2b2ef74dmac21d6a1c1a59307@mail.gmail.com> <4AE60FD6.5020904@anl.gov> Message-ID: <711a961b0910261458q2c186b71w85abd97c07692be9@mail.gmail.com> > That note was from 6 years ago. There is a ksetup for XP SP2 > Google for: site:microsoft.com ksetup download > > >> On the client side, I'm working with Windows XP Pro SP3 and the support tools where installed from CD/Support/Tools/Suptools.exe ... Do you think I should still install "ksetup for XP SP2"? << > The LSA would be empty unless you logged into XP using AD or Samba > using Kerberos. (The Microsoft kinit or runas should also update the LSA.) > Are you using NTLM by chance? > >> I don't think so, at least conciously. But how do I know it? << > > If you are using Samba, you might be better off asking your questions > on how to setup a Samba client to use Kerberos on that last. > > >> Now that you mention it, I've checked KDC log and I see that an error is generated when user logs on client WinXP machine. Hum... so I'm mistaking on Samba configuration (and I guess that's why Max told me to google for "Samba as Windows Domain Controller"). Thanks, Douglas, for pointing it out. << > > >> Thank you very much indeed! >> >> >> 2009/10/26 Douglas E. Engert >> >> >>> Santiago Rivas wrote: >>> >>> Sorry Max, >>>> >>>> I'm afraid there must be a mistake, cause all the Samba configuration >>>> work >>>> is already done. I'm asking for information about LSA... >>>> >>>> To see what is in the LSA, use the Microsoft kerbtray and/or klist >>> commands, >>> or the Network Identity Manager. >>> >>> runas with /user will run a command under a different user and will >>> set the LSA. Also look at the /netonly option too. >>> >>> Also see the Microsoft ksetup command, useful with non-AD Kerberos >>> realms. >>> >>> >>> >>> >>> Thanks! >>>> >>>> 2009/10/26 Max (Weijun) Wang >>>> >>>> http://www.ibm.com/developerworks/aix/library/au-unixothers/ >>>> >>>>> Also, Googling "Samba as Windows Domain Controller" shows a lot of >>>>> results. >>>>> >>>>> --Max >>>>> >>>>> >>>>> On Oct 26, 2009, at 7:01 PM, Santiago Rivas wrote: >>>>> >>>>> Hi everyone, >>>>> >>>>> I'm setting up Kerberos to work on Windows XP machines managed by a >>>>>> Samba >>>>>> as >>>>>> PDC. >>>>>> >>>>>> Thanks to your support, I know how to configure the credentials file >>>>>> cache >>>>>> on Windows platform. Next step is learn how to use Local Security >>>>>> Authority >>>>>> (LSA) in order to obtain TGT automatically from user logon. >>>>>> >>>>>> I've read several documents on the web ( >>>>>> >>>>>> >>>>>> >>>>>> http://java.sun.com/javase/6/docs/technotes/guides/security/kerberos/jgss-windows.html >>>>>> ) >>>>>> and I get an idea, but still have some questions to ask: >>>>>> >>>>>> - Is it required to be under an Active Directory Windows Domain for >>>>>> LSA >>>>>> to >>>>>> gather the credentials? I ask it because most of the articles that >>>>>> I've >>>>>> read >>>>>> about LSA asume to be on that scenario, nevertheless I'm using >>>>>> openldap >>>>>> and >>>>>> Samba (as I mentioned before). >>>>>> >>>>>> - If it's possible to use LSA under a non-Windows domain, is there any >>>>>> extra >>>>>> configuration needed? (besides the *allowtgtsessionkey* registry >>>>>> change) >>>>>> >>>>>> Thanks in advance! >>>>>> _______________________________________________ >>>>>> krbdev mailing list krbdev at mit.edu >>>>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>>>> >>>>>> >>>>>> _______________________________________________ >>>>> >>>> krbdev mailing list krbdev at mit.edu >>>> https://mailman.mit.edu/mailman/listinfo/krbdev >>>> >>>> >>>> >>>> -- >>> >>> Douglas E. Engert >>> Argonne National Laboratory >>> 9700 South Cass Avenue >>> Argonne, Illinois 60439 >>> (630) 252-5444 >>> >>> >>> ------------------------------------------------------------------------ >>> >>> >>> _______________________________________________ >>> krbdev mailing list krbdev at mit.edu >>> https://mailman.mit.edu/mailman/listinfo/krbdev >>> >> > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > From Nicolas.Williams at sun.com Mon Oct 26 17:53:29 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 16:53:29 -0500 Subject: How to extend kadmin In-Reply-To: References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <20091026205113.GX892@Sun.COM> <20091026213509.GD892@Sun.COM> Message-ID: <20091026215329.GG892@Sun.COM> On Mon, Oct 26, 2009 at 10:56:03PM +0100, Luke Howard wrote: > >But see my response to Jeff. I would, in fact, rather move to an > >LDAP-based solution. > > Hey, it's 2009, we should be using SOAP. ;-) SOAP is so 2006... ;) From Nicolas.Williams at sun.com Mon Oct 26 17:55:16 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 26 Oct 2009 16:55:16 -0500 Subject: How to extend kadmin In-Reply-To: <6D03AB693DBBFE5F2393F83D@minbar.fac.cs.cmu.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <10563_1256591050_n9QL49X1014786_20091026205113.GX892@Sun.COM> <20091026212959.GC892@Sun.COM> <6D03AB693DBBFE5F2393F83D@minbar.fac.cs.cmu.edu> Message-ID: <20091026215515.GI892@Sun.COM> On Mon, Oct 26, 2009 at 05:56:50PM -0400, Jeffrey Hutzelman wrote: > --On Monday, October 26, 2009 04:30:00 PM -0500 Nicolas Williams > wrote: > > >Darn, I forgot about this. I mostly agree, I'd rather see us move > >wholesale to LDAP. I happen to greatly dislike the LDAP schema that we > >all inheritted from Novell though. > > Well, but that's a schema for using LDAP as a KDB backend, which is a > different beast. Is it? I'd rather write an admin protocol than an LDAP bridge between one schema and another. > > > >And also, for some things we > >absolutely need a protocol (think change/set password protocols) > > Yes. If only we had such a protocol, just waiting to be published. :-) And better yet: implementations. From lukeh at padl.com Tue Oct 27 03:54:10 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 27 Oct 2009 08:54:10 +0100 Subject: ConstrainedDelegation review Message-ID: <5DF04B7F-2031-4C3C-BC38-5F30E1B4FE6F@padl.com> Hello, I am submitted the ConstrainedDelegation project for review, ending 30 October 2009 (not 31 October this time!). http://k5wiki.kerberos.org/wiki/Projects/ConstrainedDelegation The purpose of this project is twofold: first, to clean up the handling of KDC-issued authorisation data in the KDC itself, and the client library; and to support constrained delegation without requiring that supports the Windows PAC. More information is provided on the Wiki page. regards, -- Luke -- www.padl.com | www.fghr.net From lukeh at padl.com Tue Oct 27 05:42:41 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 27 Oct 2009 10:42:41 +0100 Subject: ConstrainedDelegation review In-Reply-To: <5DF04B7F-2031-4C3C-BC38-5F30E1B4FE6F@padl.com> References: <5DF04B7F-2031-4C3C-BC38-5F30E1B4FE6F@padl.com> Message-ID: <3D8E5DCD-2FF3-4E21-AC36-24769CD4D4FD@padl.com> > I am submitted the ConstrainedDelegation project for review, ending 30 > October 2009 (not 31 October this time!). Sorry, me thinking October had only 30 days in it was due to a bug in iCal. -- Luke From ghudson at MIT.EDU Tue Oct 27 11:36:24 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 27 Oct 2009 11:36:24 -0400 Subject: How to extend kadmin In-Reply-To: <200910261944.n9QJiwin013887@outgoing.mit.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> Message-ID: <1256657784.5933.132.camel@ray> Summary response: * Nico, Ken, and (in previous off-list conversation) Tom have expressed displeasure at an approach which requires more hand-editing of XDR code. So the way we've extended kadmin for lockout support on the trunk (the api 2->3 bump and conditionalization of xdr_kadm5_policy_ent_rec) is controversial. * However, Nico notes that the way we marshal krb5_principal is problematic for using rpcgen. I looked into this myself: we call krb5_unparse_name on encode and krb5_parse_name on decode. Does rpcgen support app-defined encoding functions for particular fields? If not, I am doubtful that we will ever be in the position of being able to use a .x file to define the kadmin protocol without starting over. * Personally, I don't think hand-editing XDR code is a big deal, as long as it wasn't my fault that we got into this position in the first place. For better or for worse, rpcgen generates pretty readable and hackable code. * There've been some ideas for the future of kadmin that don't involve ONC RPC, such as LDAP. Lacking specific plans and resources allocated to such a reboot, I have to assume that we'll be making evolutionary changes to the current kadmin architecture for an indefinite period. * I'm going to resist the temptation to get into a wide-ranging discussion of network protocol architecture at this juncture. Just pretend I didn't say anthing about my personal like or dislike of RPC-style network protocols. From Nicolas.Williams at sun.com Tue Oct 27 11:59:06 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 27 Oct 2009 10:59:06 -0500 Subject: How to extend kadmin In-Reply-To: <1256657784.5933.132.camel@ray> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> Message-ID: <20091027155906.GC1105@Sun.COM> On Tue, Oct 27, 2009 at 11:36:24AM -0400, Greg Hudson wrote: > Summary response: > > * Nico, Ken, and (in previous off-list conversation) Tom have expressed > displeasure at an approach which requires more hand-editing of XDR code. > So the way we've extended kadmin for lockout support on the trunk (the > api 2->3 bump and conditionalization of xdr_kadm5_policy_ent_rec) is > controversial. > > * However, Nico notes that the way we marshal krb5_principal is > problematic for using rpcgen. I looked into this myself: we call > krb5_unparse_name on encode and krb5_parse_name on decode. Does rpcgen > support app-defined encoding functions for particular fields? If not, I > am doubtful that we will ever be in the position of being able to use > a .x file to define the kadmin protocol without starting over. No, you can't, but what you could do is declare the kadm5 krb5 princ data type to be "opaque" and then do the parsing/unparsing at the application layer. Ah, so, yes, you can handle krb5 princ names the Right Way (tm). > * Personally, I don't think hand-editing XDR code is a big deal, as long > as it wasn't my fault that we got into this position in the first place. > For better or for worse, rpcgen generates pretty readable and hackable > code. I agreed with this already: more of the same is the expedient way to go. If you could bring yourself to rev the program, great, if not, oh well. > * There've been some ideas for the future of kadmin that don't involve > ONC RPC, such as LDAP. Lacking specific plans and resources allocated > to such a reboot, I have to assume that we'll be making evolutionary > changes to the current kadmin architecture for an indefinite period. I agree. > * I'm going to resist the temptation to get into a wide-ranging > discussion of network protocol architecture at this juncture. Just > pretend I didn't say anthing about my personal like or dislike of > RPC-style network protocols. Heh. Nico -- From jhutz at cmu.edu Tue Oct 27 12:20:38 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Tue, 27 Oct 2009 12:20:38 -0400 Subject: How to extend kadmin In-Reply-To: <9961_1256659884_n9RGBNs0013413_20091027155906.GC1105@Sun.COM> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> <9961_1256659884_n9RGBNs0013413_20091027155906.GC1105@Sun.COM> Message-ID: <33A526F575021907BCF4BC61@minbar.fac.cs.cmu.edu> --On Tuesday, October 27, 2009 10:59:06 AM -0500 Nicolas Williams wrote: >> * However, Nico notes that the way we marshal krb5_principal is >> problematic for using rpcgen. I looked into this myself: we call >> krb5_unparse_name on encode and krb5_parse_name on decode. Does rpcgen >> support app-defined encoding functions for particular fields? If not, I >> am doubtful that we will ever be in the position of being able to use >> a .x file to define the kadmin protocol without starting over. > > No, you can't, but what you could do is declare the kadm5 krb5 princ > data type to be "opaque" and then do the parsing/unparsing at the > application layer. > > Ah, so, yes, you can handle krb5 princ names the Right Way (tm). You could make it opaque, but given that it's the output of krb5_unparse_name(), IMHO it would be better to call a string<> a string<>. From Nicolas.Williams at sun.com Tue Oct 27 12:19:00 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 27 Oct 2009 11:19:00 -0500 Subject: How to extend kadmin In-Reply-To: <33A526F575021907BCF4BC61@minbar.fac.cs.cmu.edu> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> <9961_1256659884_n9RGBNs0013413_20091027155906.GC1105@Sun.COM> <33A526F575021907BCF4BC61@minbar.fac.cs.cmu.edu> Message-ID: <20091027161900.GD1105@Sun.COM> On Tue, Oct 27, 2009 at 12:20:38PM -0400, Jeffrey Hutzelman wrote: > --On Tuesday, October 27, 2009 10:59:06 AM -0500 Nicolas Williams > wrote: > > >>* However, Nico notes that the way we marshal krb5_principal is > >>problematic for using rpcgen. I looked into this myself: we call > >>krb5_unparse_name on encode and krb5_parse_name on decode. Does rpcgen > >>support app-defined encoding functions for particular fields? If not, I > >>am doubtful that we will ever be in the position of being able to use > >>a .x file to define the kadmin protocol without starting over. > > > >No, you can't, but what you could do is declare the kadm5 krb5 princ > >data type to be "opaque" and then do the parsing/unparsing at the > >application layer. > > > >Ah, so, yes, you can handle krb5 princ names the Right Way (tm). > > You could make it opaque, but given that it's the output of > krb5_unparse_name(), IMHO it would be better to call a string<> a string<>. Oh, true. application layer. I think you can leave the type undefined to rpcgen and use something like: #ifdef RPC_XDR %bool_t xdr_foo(XDR *xdrs, foo *fooptr) %{ % [...] %} #endif So you can supply an encoder/decoder (and typedef, etc) for an individual type, without having to preprocess it all at the application layer before calling into the RPC code. Ken From ghudson at MIT.EDU Tue Oct 27 14:03:10 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Tue, 27 Oct 2009 14:03:10 -0400 (EDT) Subject: issue with preauth processing In-Reply-To: Message-ID: <200910271803.n9RI3AUU003554@outgoing.mit.edu> > Basically, the question is whether we take that gic option call as > an optimization or security constraint. Most people who have used > it in the past have been looking for an optimization. When I first read this, I took it as reasonable, but on reconsideration I'm not sure. My understanding is that prior to 1.7, we never continued after PREAUTH_FAILED, so anyone calling krb5_get_init_creds_opt_set_preauth_list was getting both an optimization and a restriction. So, even if people were "looking for" an optimization, that's not what we were getting. I would say that 1.7 introduced an incompatible change to that API. If that's correct, then the most correct thing to do is (1) fix that in 1.7.1, and (2) add a new API for optimistic preauth. From tsitkova at MIT.EDU Wed Oct 28 11:33:08 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Wed, 28 Oct 2009 11:33:08 -0400 Subject: Code modularity Message-ID: Hello, This is the initial write-up for the Code Modularity proj. It's goal is to reorganize the code to simplify the construction of the code subsets (clients, servers, u2u etc for mobile devices, embedded systems etc) and, potentially, improve the quality of the code. After analyzing various approaches in the constructing of the subsets, we agreed that the best one is to have related functions in the separate files so that building these files would produce the minimal lib with the required functionality. It is somewhat one-function-per- file approach without going into extremes of literal "one function in one file", rather "file is a holder of the equivalent functions". Equivalence relation is defined in terms of reflexivity, symmetry and transitivity. We define two functions to be equivalent if they have the same parent. Let X1, X2, X3, ... Xn denote kerb API's and lets call them "parents". Example 1. Suppose that x-reference analyzer shows the following function call stack: X1 -> C1 -> B -> (A1, A2) ( i.e X1 calls C1 which calls B, which calls two functions A1 and A2) X2 -> C2 -> B -> (A1, A2) Then the parents are: X1 -----> X1 C1 -----> X1 X2-----> X2 C2 -----> X2 B -----> X1, X2 ( i.e. X1 and X2 are parents of B) A1-----> X1, X2 A2-----> X1, X2 This brings us to the conclusion that the following functions are equivalent and may live in three separate files: (X1,C1), (X2, C2), (B, A1, A2). Example 2. Let x-ref for X1 and X2 be the same as in example 1 and add a new API X3 which calls only A2. Now the parenthood is: X1 -----> X1 C1 -----> X1 X2-----> X2 C2 -----> X2 X3-----> X3 B -----> X1, X2 A1-----> X1, X2 A2-----> X1, X2, X3 resulting into five separate function holders (X1,C1), (X2, C2), (X3), (B, A1), (A2) We might consider the case when X2 and X3 are serving similar purpose. For example, they are client-only code. Then, we can define group, say G23: X1 -----> X1 C1 -----> X1 X2-----> X2 C2 -----> X2 X3-----> X3 B -----> X1, G23 A1-----> X1, G23 A2-----> X1, G23 so one needs four files to hold equivalent functions (X1,C1), (X2, C2), (X3), (B, A1, A2) Thanks, Zhanna From tlyu at MIT.EDU Wed Oct 28 12:27:10 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 28 Oct 2009 12:27:10 -0400 Subject: SVN server downtime today (10/28) 18:00-19:30 Message-ID: The server svn.mit.edu will be down from 18:00-19:30 today for a scheduled upgrade. This should only affect developers with commit access. As far as I know, the source browsers (FishEye and OpenGrok) and anonsvn.mit.edu will continue to function. -------------------- Start of forwarded message -------------------- From: Stephen M Landry Date: Wed, 28 Oct 2009 12:06:08 -0400 Subject: [ISDA] SVN Server Downtime, today, 10/28/2009 Dear Colleagues, For today's scheduled upgrades of several of IS&T's developer tools, the Subversion system updates will require downtime. This is new information and we apologize for the inconvenience. After speaking with several technical leads in IS&T, it seems to be acceptable to take SVN down from 6pm to 7:30pm tonight. For developers who use the SVN system at svn.mit.edu, it is best to do the following: - Check in your local changes to the repository prior to 6pm. - Refresh local project for which you might need access to source during the outage window. Contacts for SAIS: Ryan Jones, Kevin Mullins Contacts for ISDA: Andrew Boardman, Steve Landry Thanks for your patience, Steve Landry Team Leader, Application Management and Integration Team MIT > IS&T > ISDA > DSPS -------------------- End of forwarded message -------------------- From tlyu at MIT.EDU Wed Oct 28 16:28:20 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 28 Oct 2009 16:28:20 -0400 Subject: reindenting Message-ID: The "great reindent" that we have talked about from time to time will work as follows. New scripts and make targets, already committed to trunk, will support the reindentation effort. There are customizations that Emacs users should use to set up their editor to conform to our C coding style. At some point this Friday, I will run "make mark-cstyle" and "make reindent" on the source tree and commit to the trunk. Before then, I request input on what directories/files should be excluded from the automatic reindentation, and other adjustments to the procedure. I am reconsidering whether it's a good idea to reindent the bulk of the source tree at once. Even with the exception list that I have checked into the "make mark-cstyle" target, a lot of C files get reformatted in ways that reduce readability. Are there any objections to doing the reindent in stages, rather than in one huge commit? I realize it presents possible complications, but if developers who are maintaining branches batch-reindent according to changes in the trunk, it may be less painful. I am considering starting with chunks of lib/krb5, then progressing to all of lib/ and some of the KDC and kadmin directories. One example of problems with automated reindenting is lib/krb5/asn.1, which has some problems with comment formatting; the reindent process corrupts some of the positioning of things like itemized lists in the block comments. Other examples include the peculiar form of function prototypes in some of our headers, which have the opening parenthesis of the function declaration on a new line. Such files will need some amount of manual adjustment in order for the automated reindenting to minimize disruption. I have committed some changes to the trunk that allow for batch reindentation, and an Emacs C style definition. If you are an Emacs user, load src/util/krb5-c-style.el to get the new style defined. It won't become your default C style, so creating a new C file won't use the new style automatically. In that case, make sure you set a "-*-" line (such as below), then run "M-x normal-mode" to reinitialize the style settings correctly. At present, there is a "make reindent" target in the top-level Makefile, using some Emacs Lisp to use our Emacs C style to selectively reformat files that are marked as supposedly conforming to our coding style. At the moment, "make reindent" will unconditionally correct some whitespace nits such as: * whitespace at the ends of lines * lack of trailing newlines * spaces sandwiched between tabs It will untabify the file if the file-local variables indicate that the file should not have tabs. ('indent-tabs-mode: nil') If the file contains a marker indicating that it conforms to our coding style, signaled by a first line /* -*- mode: c; c-basic-offset: 4; indent-tabs-mode: nil -*- */ then it will reindent the entire file. (We don't use 'c-file-style: "krb5"' because that would cause errors for Emacs users who do not load our krb5-c-style.el file.) The "make mark-cstyle" target in the top-level Makefile is intended to insert markers for the files that we intend to conform to our C coding style, and will probably require adjustment as we determine what works best. -- Tom Yu Development Team Leader MIT Kerberos Consortium From Nicolas.Williams at sun.com Wed Oct 28 16:44:44 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Oct 2009 15:44:44 -0500 Subject: reindenting In-Reply-To: References: Message-ID: <20091028204444.GB1105@Sun.COM> Will re-indenting also re-wap long lines? Some kinds of whitespace changes have little impact on merging, while others have major impact on merging. Re-indenting is of the former kind, while re-wrapping is of the latter. (Of course, if Wyllys has agreed to re-indenting and re-wrapping then you can ignore my raising this issue, but I'm still curious as to whether you'll re-wrap.) Nico -- From epeisach at MIT.EDU Wed Oct 28 16:58:57 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Wed, 28 Oct 2009 16:58:57 -0400 Subject: svn rev #23080: libcrypto exports... Message-ID: <4AE8B091.8030609@mit.edu> make check will not run - some of the tests will no longer link: I suspect you did not configure the tree w/ --disable-rpath and are picking up an installed library which is working... crypto_tests/t_cksum.c: krb5int_keyhash_md5des undefined crypto_tests/t_crc.c: mit_crc32 undefined crypto_tests/t_cts.c: krb5int_aes_encrypt undefined crypto_tests/t_mddriver.c: krb5int_MD5_* undefined crypto_tests/aes-test.c: `krb5int_aes_encrypt Ezra From Wyllys.Ingersoll at sun.com Wed Oct 28 17:01:38 2009 From: Wyllys.Ingersoll at sun.com (Wyllys Ingersoll) Date: Wed, 28 Oct 2009 17:01:38 -0400 Subject: reindenting In-Reply-To: <20091028204444.GB1105@Sun.COM> References: <20091028204444.GB1105@Sun.COM> Message-ID: <4AE8B132.3060200@sun.com> Nicolas Williams wrote: > Will re-indenting also re-wap long lines? > > Some kinds of whitespace changes have little impact on merging, while > others have major impact on merging. Re-indenting is of the former > kind, while re-wrapping is of the latter. (Of course, if Wyllys has > agreed to re-indenting and re-wrapping then you can ignore my raising > this issue, but I'm still curious as to whether you'll re-wrap.) > > Nico I think you mean Will F. :) -Wyllys From tlyu at MIT.EDU Wed Oct 28 17:08:34 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 28 Oct 2009 17:08:34 -0400 Subject: reindenting In-Reply-To: <20091028204444.GB1105@Sun.COM> (Nicolas Williams's message of "Wed, 28 Oct 2009 16:44:44 -0400") References: <20091028204444.GB1105@Sun.COM> Message-ID: Nicolas Williams writes: > Will re-indenting also re-wap long lines? The automated procedures will not rewrap long lines. Doing so has the potential to render the code very unreadable, so I plan to leave this for future manual efforts. From ssorce at redhat.com Wed Oct 28 17:19:09 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 Oct 2009 17:19:09 -0400 Subject: reindenting In-Reply-To: References: Message-ID: <1256764749.2808.180.camel@willson> On Wed, 2009-10-28 at 16:28 -0400, Tom Yu wrote: > There are > customizations that Emacs users should use to set up their editor to > conform to our C coding style. Do you have a description of the indenting rules as a set of options to 'indent' (the program) for those that do not use emacs ? Alternatively a style guide where the rules are stated ? (sorry for the noise if this was already been published) Simo. -- Simo Sorce * Red Hat, Inc * New York From tlyu at MIT.EDU Wed Oct 28 17:31:47 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 28 Oct 2009 17:31:47 -0400 Subject: reindenting In-Reply-To: <1256764749.2808.180.camel@willson> (Simo Sorce's message of "Wed, 28 Oct 2009 17:19:09 -0400") References: <1256764749.2808.180.camel@willson> Message-ID: Simo Sorce writes: > On Wed, 2009-10-28 at 16:28 -0400, Tom Yu wrote: >> There are >> customizations that Emacs users should use to set up their editor to >> conform to our C coding style. > > Do you have a description of the indenting rules as a set of options to > 'indent' (the program) for those that do not use emacs ? > Alternatively a style guide where the rules are stated ? > (sorry for the noise if this was already been published) Please look at http://k5wiki.kerberos.org/wiki/Coding_style and its child pages (linked near the top of the page). The indent.pro settings are only a rough guideline; running GNU indent on the tree results in a great deal of carnage: much worse than doing the Emacs reindent. There are suggested vim/gvim settings as well. Feedback on these style guidelines is welcome. From Nicolas.Williams at sun.com Wed Oct 28 17:28:04 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 28 Oct 2009 16:28:04 -0500 Subject: reindenting In-Reply-To: References: <20091028204444.GB1105@Sun.COM> Message-ID: <20091028212804.GL1105@Sun.COM> On Wed, Oct 28, 2009 at 05:08:34PM -0400, Tom Yu wrote: > Nicolas Williams writes: > > > Will re-indenting also re-wap long lines? > > The automated procedures will not rewrap long lines. Doing so has the > potential to render the code very unreadable, so I plan to leave this > for future manual efforts. What indentation style will you use? Will you expand tabs? What will be the length of the longest line after re-indentation? You might not be able to answer the last question till you're almost done, of course :) Not that I mind line lengths past 80 columns, but I do mind line lengths past around 110-132 columns. (For me line length tolerance is a function of screen width and/or aspect ratio, resolution and font sizes. 110 columns is almost always something I can live with.) Nico -- From ssorce at redhat.com Wed Oct 28 17:54:02 2009 From: ssorce at redhat.com (Simo Sorce) Date: Wed, 28 Oct 2009 17:54:02 -0400 Subject: reindenting In-Reply-To: References: <1256764749.2808.180.camel@willson> Message-ID: <1256766842.2808.188.camel@willson> On Wed, 2009-10-28 at 17:31 -0400, Tom Yu wrote: > Simo Sorce writes: > > > On Wed, 2009-10-28 at 16:28 -0400, Tom Yu wrote: > >> There are > >> customizations that Emacs users should use to set up their editor to > >> conform to our C coding style. > > > > Do you have a description of the indenting rules as a set of options to > > 'indent' (the program) for those that do not use emacs ? > > Alternatively a style guide where the rules are stated ? > > (sorry for the noise if this was already been published) > > Please look at > > http://k5wiki.kerberos.org/wiki/Coding_style > > and its child pages (linked near the top of the page). Great, thanks! > The indent.pro settings are only a rough guideline; running GNU indent > on the tree results in a great deal of carnage: much worse than doing > the Emacs reindent. Yeah, I was in no way trying to suggest to use indent, I was just interested in knowing what style should be used "from now on". > There are suggested vim/gvim settings as well. > Feedback on these style guidelines is welcome. Style looks great, finally my eyes will not cross when I read the code once the big reindent goes through ;-) Seriously, thanks for doing this! Simo. -- Simo Sorce * Red Hat, Inc * New York From William.Fiveash at sun.com Wed Oct 28 19:06:47 2009 From: William.Fiveash at sun.com (Will Fiveash) Date: Wed, 28 Oct 2009 18:06:47 -0500 Subject: bug in pkinit preauth plugin? Message-ID: <20091028230646.GA932@sun.com> I notice that if "pkinit_identities = PKCS11:" is set in krb5.conf the pkint preauth plugin will prompt the user for a PIN even if the user has no certs in their token (I was testing using Solaris pkcs11_softtoken). I think the bug is here in src/plugins/preauth/pkinit/pkinit_crypto_openssl.c:pkinit_open_session(): /* Login if needed */ if (tinfo.flags & CKF_LOGIN_REQUIRED) r = pkinit_login(context, cctx, &tinfo); Given that certs are normally public objects in a token and should not require login to view I think the pkinit plugin should, by default, search for appropriate public certs and if there are none return failure without prompting the user for a PIN. If support for private certs is necessary then perhaps there should be a new config parameter that would cause pkinit to always prompt. Thoughts? -- Will Fiveash Sun Microsystems Inc. http://opensolaris.org/os/project/kerberos/ Sent from mutt, a sweet ASCII MUA From hotz at jpl.nasa.gov Wed Oct 28 20:43:32 2009 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Wed, 28 Oct 2009 17:43:32 -0700 Subject: How to extend kadmin In-Reply-To: References: Message-ID: <2D9BD8D9-B87C-4FEF-9090-C5156C970E33@jpl.nasa.gov> On Oct 27, 2009, at 9:05 AM, krbdev-request at mit.edu wrote: > * I'm going to resist the temptation to get into a wide-ranging > discussion of network protocol architecture at this juncture. Just > pretend I didn't say anthing about my personal like or dislike of > RPC-style network protocols. Aw, gee. Here I was looking forward to a good flame war. ------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From hartmans at MIT.EDU Thu Oct 29 10:40:19 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Oct 2009 10:40:19 -0400 Subject: issue with preauth processing In-Reply-To: <200910271803.n9RI3AUU003554@outgoing.mit.edu> (ghudson@mit.edu's message of "Tue\, 27 Oct 2009 14\:03\:10 -0400 \(EDT\)") References: <200910271803.n9RI3AUU003554@outgoing.mit.edu> Message-ID: >>>>> "ghudson" == ghudson writes: >> Basically, the question is whether we take that gic option call >> as an optimization or security constraint. Most people who >> have used it in the past have been looking for an optimization. ghudson> When I first read this, I took it as reasonable, but on ghudson> reconsideration I'm not sure. ghudson> My understanding is that prior to 1.7, we never continued ghudson> after PREAUTH_FAILED, so anyone calling ghudson> krb5_get_init_creds_opt_set_preauth_list was getting both ghudson> an optimization and a restriction. So, even if people ghudson> were "looking for" an optimization, that's not what we ghudson> were getting. I would say that 1.7 introduced an ghudson> incompatible change to that API. If that's correct, then ghudson> the most correct thing to do is (1) fix that in 1.7.1, ghudson> and (2) add a new API for optimistic preauth. Well, it's a bit more complicated than that. 1.6.3 will retry if it gets a PREAUTH_REQUIRED error. I think with the preauth methods shipped with 1.6.3 and most KDCs I'm familiar with, that tends not to happen. So, I think your description of what happened is more or less correct. I'm not sure I actually agree with you that the API change is incompatible. It depends on what the callers of that API thought the interface was. Certainly if we had API documentation and the API was documented as optimistic, then it would not be an incompatible change; if it was documented as a restriction then it would be. The 1.7 change breaks some code and makes some code work better. However I agree with your fix. From tlyu at MIT.EDU Thu Oct 29 10:57:00 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Oct 2009 10:57:00 -0400 Subject: reindenting In-Reply-To: <20091028212804.GL1105@Sun.COM> (Nicolas Williams's message of "Wed, 28 Oct 2009 17:28:04 -0400") References: <20091028204444.GB1105@Sun.COM> <20091028212804.GL1105@Sun.COM> Message-ID: Nicolas Williams writes: > What indentation style will you use? Will you expand tabs? What will > be the length of the longest line after re-indentation? > > You might not be able to answer the last question till you're almost > done, of course :) Not that I mind line lengths past 80 columns, but I > do mind line lengths past around 110-132 columns. I believe I have given answers to your first two questions already. (in my reply to Simo, and other places; please tell me if I missed something) As for the post-reindent maximum line length... I'm not sure either, but I think that 132 columns is a reasonable guess. If there are egregiously long lines remaining after reindenting, we can fix them manually. > (For me line length tolerance is a function of screen width and/or > aspect ratio, resolution and font sizes. 110 columns is almost always > something I can live with.) Yeah, these are factors that typographers take into account when designing printed pages. Baseline spacing also plays a role. From hartmans at MIT.EDU Thu Oct 29 13:40:52 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Thu, 29 Oct 2009 13:40:52 -0400 Subject: How to extend kadmin In-Reply-To: <1256657784.5933.132.camel@ray> (Greg Hudson's message of "Tue\, 27 Oct 2009 11\:36\:24 -0400") References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> Message-ID: >>>>> "Greg" == Greg Hudson writes: Greg> Summary response: * Nico, Ken, and (in previous off-list Greg> conversation) Tom have expressed displeasure at an approach Greg> which requires more hand-editing of XDR code. So the way Greg> we've extended kadmin for lockout support on the trunk (the Greg> api 2->3 bump and conditionalization of Greg> xdr_kadm5_policy_ent_rec) is controversial. Count me in the set of people who want to be able to use rpcgen. This is under the assumption that we can find some way of generating encoders for krb5_principal. Ken's solution seems fine to me. Nico's solution--asking the application to deal--does not. From ghudson at MIT.EDU Thu Oct 29 16:41:35 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 29 Oct 2009 16:41:35 -0400 Subject: How to extend kadmin In-Reply-To: References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> Message-ID: <1256848895.5933.230.camel@ray> On Thu, 2009-10-29 at 13:40 -0400, Sam Hartman wrote: > Count me in the set of people who want to be able to use rpcgen. This > is under the assumption that we can find some way of generating > encoders for krb5_principal. Ken's solution seems fine to me. Nico's > solution--asking the application to deal--does not. I've done a little more thinking about this today. 1. According to our current promises, we can change the C API of libkadm5 in any way we want (without necessarily bumping api_version or providing compatibility, though we do of course need to bump the soname). That means we can tamper with the principal_ent and policy_ent structures as long as we don't change their network encodings. 2. If we add an api_version field to the principal_ent and policy_ent structures, and custom encoding functions for those structures, then we can make those structure encodings dependent on the api_version while still using stock rpcgen for everything else. So, Luke's approach to lockout support isn't necessarily incompatible with using rpcgen--just with auto-generating xdr_kadm5_policy_ent_rec. From ghudson at MIT.EDU Thu Oct 29 16:56:21 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 29 Oct 2009 16:56:21 -0400 Subject: reindenting In-Reply-To: References: Message-ID: <1256849781.5933.232.camel@ray> On Wed, 2009-10-28 at 16:28 -0400, Tom Yu wrote: > I am considering starting with chunks of lib/krb5, then progressing to > all of lib/ and some of the KDC and kadmin directories. I'll be happy to take on some of the manual work of reindenting/reviewing parts of the tree, once you've declared the transition window open. This should be pretty easy to parallelize. From tlyu at MIT.EDU Thu Oct 29 23:32:50 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Thu, 29 Oct 2009 23:32:50 -0400 Subject: prefer Python for new scripts? Message-ID: I propose that we move toward preferring Python for new scripts in the source tree. Scripts in our tree are written in many languages, including Python, Perl, Tcl/Expect, Bourne shell, and others. Anecdotal evidence suggests that it is easier to write maintainable Python code than maintainable Perl code, and that newcomers find Python an easier language to learn than Perl. I'm not suggesting that we rewrite all our scripts in Python, just that we prefer it in the future. Reasons to not choose Python for new work would include extending existing scripts, etc. that are written in another language. For example, the Tcl/Expect/Dejagnu testing frameworks we have are somewhat cumbersome, and I plan to replace them with something more consolidated, but any modifications or extensions to them should still be written in the currently used Tcl/Expect language. I have looked at a Python-based testing framework called QMTest, which appears somewhat promising, as a replacement for Dejagnu. It hasn't had a release since 2007, but this is not inherently a bad thing. Please provide feedback on these suggestions. Thanks. -- Tom Yu Development Team Leader MIT Kerberos Consortium From tsitkova at MIT.EDU Fri Oct 30 01:47:10 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Fri, 30 Oct 2009 01:47:10 -0400 Subject: prefer Python for new scripts? In-Reply-To: References: Message-ID: <8DD7AD829AB61E499A433D6E558110A31577DC80@EXPO7.exchange.mit.edu> You have my vote, of course. Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5. Any strong preferences with regard to version choice? Thanks, Zhanna ________________________________________ From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of Tom Yu [tlyu at MIT.EDU] Sent: Thursday, October 29, 2009 11:32 PM To: krbdev at mit.edu Subject: prefer Python for new scripts? I propose that we move toward preferring Python for new scripts in the source tree. Scripts in our tree are written in many languages, including Python, Perl, Tcl/Expect, Bourne shell, and others. Anecdotal evidence suggests that it is easier to write maintainable Python code than maintainable Perl code, and that newcomers find Python an easier language to learn than Perl. I'm not suggesting that we rewrite all our scripts in Python, just that we prefer it in the future. Reasons to not choose Python for new work would include extending existing scripts, etc. that are written in another language. For example, the Tcl/Expect/Dejagnu testing frameworks we have are somewhat cumbersome, and I plan to replace them with something more consolidated, but any modifications or extensions to them should still be written in the currently used Tcl/Expect language. I have looked at a Python-based testing framework called QMTest, which appears somewhat promising, as a replacement for Dejagnu. It hasn't had a release since 2007, but this is not inherently a bad thing. Please provide feedback on these suggestions. Thanks. -- Tom Yu Development Team Leader MIT Kerberos Consortium _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From ghudson at MIT.EDU Fri Oct 30 06:51:24 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 30 Oct 2009 06:51:24 -0400 Subject: How to extend kadmin In-Reply-To: <1256848895.5933.230.camel@ray> References: <200910261944.n9QJiwin013887@outgoing.mit.edu> <1256657784.5933.132.camel@ray> <1256848895.5933.230.camel@ray> Message-ID: <1256899884.5933.273.camel@ray> On Thu, 2009-10-29 at 16:41 -0400, Greg Hudson wrote: > 2. If we add an api_version field to the principal_ent and policy_ent > structures, and custom encoding functions for those structures, then we > can make those structure encodings dependent on the api_version while > still using stock rpcgen for everything else. I tried this approach and it doesn't quite work, unfortunately. Without marshalling the api_version of policy_ent_rec across the wire (which would be wire-incompatible with krb5 1.7), we would still need custom encoding functions for xdr_cpol_arg and friends in order to fill in the api_version of the policy_ent_rec before decoding it. Also, I uncovered another apparent obstacle to using stock rpcgen encoders: many of our result encoders, like xdr_gpols_ret and xdr_chrand_ret, conditionalize the encoding of result data on whether the result code was success or not. So, to summarize where we are: * Lockout support on the trunk was done by revving the api_version field from 2 to 3 and making the encoding of a policy_ent_rec conditional on the api version. (This is similar to how principal_ent_rec was extended between api_version 1 and 2, but since we shed support for api_version 1 a while back, we aren't constrained by that.) * If this code ships in 1.8, we will be committed to using custom encoders for xdr_kadm5_policy_ent_rec, xdr_cpol_arg, xdr_mpol_arg, and xdr_gpol_ret essentially forever. This commitment likely already exists for xdr_gpol_ret because of result-code conditionalization. * Personally, I see a lot of obstacles to using rpcgen-generated encoding functions for much of kadm5, and I don't see a lot of harm in the current regime where we hand-edit code that was once created by rpcgen in ages past. So I don't plan to devote any more time "on the margin" to forwarding this goal. It may still be possible to use rpcgen-generated client/or and server stubs; the lockout support doesn't make that any easier or harder. From tlyu at MIT.EDU Fri Oct 30 09:05:18 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 30 Oct 2009 09:05:18 -0400 Subject: prefer Python for new scripts? In-Reply-To: <8DD7AD829AB61E499A433D6E558110A31577DC80@EXPO7.exchange.mit.edu> (Zhanna Tsitkova's message of "Fri, 30 Oct 2009 01:47:10 -0400") References: <8DD7AD829AB61E499A433D6E558110A31577DC80@EXPO7.exchange.mit.edu> Message-ID: Zhanna Tsitkova writes: > You have my vote, of course. > Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5. > Any strong preferences with regard to version choice? I think our minimum Python version requirement should be based on whatever versions ship with operating systems we care about. For example, Mac OS 10.5 ships with 2.5.1; Debian-stable ships 2.5.2; RHEL 4 ships 2.3, I think, which has been problematic in the past (Linux-Athena 9.4 was based on RHEL 4, but that is quite ancient at this point.); RHEL 5 ships 2.4.x: not sure how much people still care about that. I'm not sure what ships on modern releases of Solaris, but the Solaris 10 (3/05?) box I'm using has Python 2.3.3. Scripts that are required in the build process but not in the test suite should require lower versions of Python, to be friendlier to non-developer users and sysadmins who are building from source. (Note that we currently already require Perl for the build process.) Given that much of my current work environment is on Mac OS 10.5, I would be biased toward using Python 2.5 as a minimum, but may update my opinion based on additional information about what Python versions various operating systems ship. From jaltman at secure-endpoints.com Fri Oct 30 09:52:24 2009 From: jaltman at secure-endpoints.com (Jeffrey Altman) Date: Fri, 30 Oct 2009 09:52:24 -0400 Subject: prefer Python for new scripts? In-Reply-To: <8DD7AD829AB61E499A433D6E558110A31577DC80@EXPO7.exchange.mit.edu> References: <8DD7AD829AB61E499A433D6E558110A31577DC80@EXPO7.exchange.mit.edu> Message-ID: <4AEAEF98.8070907@secure-endpoints.com> Using python permits you to use buildbot. One of the challenges of using python is finding a version that works on all of the platforms and applications that you require. If you care about Windows you have 32-bit support for just about any version from 2.4 through 3.0. 64-bit support on the other hand is only available for 2.6 and 3.0. If I remember correctly some of the buildbot dependencies require 2.5. Jeffrey Altman Zhanna Tsitkova wrote: > You have my vote, of course. > Also, back in February, when I initially proposed Python for our testing framework, we discussed what version of Python should be used - 2.3, 2.5 2.6 or 3.0 - and the question is still open. I prefer 2.6+ and would not go below 2.5. > Any strong preferences with regard to version choice? > > Thanks, > Zhanna > > > ________________________________________ > From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of Tom Yu [tlyu at MIT.EDU] > Sent: Thursday, October 29, 2009 11:32 PM > To: krbdev at mit.edu > Subject: prefer Python for new scripts? > > I propose that we move toward preferring Python for new scripts in the > source tree. Scripts in our tree are written in many languages, > including Python, Perl, Tcl/Expect, Bourne shell, and others. > > Anecdotal evidence suggests that it is easier to write maintainable > Python code than maintainable Perl code, and that newcomers find > Python an easier language to learn than Perl. > > I'm not suggesting that we rewrite all our scripts in Python, just > that we prefer it in the future. Reasons to not choose Python for new > work would include extending existing scripts, etc. that are written > in another language. For example, the Tcl/Expect/Dejagnu testing > frameworks we have are somewhat cumbersome, and I plan to replace them > with something more consolidated, but any modifications or extensions > to them should still be written in the currently used Tcl/Expect > language. > > I have looked at a Python-based testing framework called QMTest, which > appears somewhat promising, as a replacement for Dejagnu. It hasn't > had a release since 2007, but this is not inherently a bad thing. > > Please provide feedback on these suggestions. Thanks. > > -- > Tom Yu > Development Team Leader > MIT Kerberos Consortium > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/x-pkcs7-signature Size: 3368 bytes Desc: S/MIME Cryptographic Signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20091030/36f8e5b8/smime-0001.bin From ssorce at redhat.com Fri Oct 30 10:28:59 2009 From: ssorce at redhat.com (Simo Sorce) Date: Fri, 30 Oct 2009 10:28:59 -0400 Subject: prefer Python for new scripts? In-Reply-To: References: Message-ID: <1256912939.2808.257.camel@willson> On Thu, 2009-10-29 at 23:32 -0400, Tom Yu wrote: > I propose that we move toward preferring Python for new scripts in the > source tree. Scripts in our tree are written in many languages, > including Python, Perl, Tcl/Expect, Bourne shell, and others. > > Anecdotal evidence suggests that it is easier to write maintainable > Python code than maintainable Perl code, and that newcomers find > Python an easier language to learn than Perl. > > I'm not suggesting that we rewrite all our scripts in Python, just > that we prefer it in the future. Reasons to not choose Python for new > work would include extending existing scripts, etc. that are written > in another language. For example, the Tcl/Expect/Dejagnu testing > frameworks we have are somewhat cumbersome, and I plan to replace them > with something more consolidated, but any modifications or extensions > to them should still be written in the currently used Tcl/Expect > language. > > I have looked at a Python-based testing framework called QMTest, which > appears somewhat promising, as a replacement for Dejagnu. It hasn't > had a release since 2007, but this is not inherently a bad thing. > > Please provide feedback on these suggestions. Thanks. Unfortunately right now python is going through a transition phase. In theory using 2.6 carefully should allow you to use the code with 3.0 later with minimal or no changes. Using anything below 2.6 may require to migrate scripts later on. I guess what will really drive your choice is going to be dependencies anyway. Btw if someone would go and contribute to enhance krb5 python bindings that would be awesome :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From ghudson at MIT.EDU Fri Oct 30 12:21:36 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 30 Oct 2009 12:21:36 -0400 Subject: prefer Python for new scripts? In-Reply-To: References: Message-ID: <1256919696.5933.315.camel@ray> I like Python. I may set up Buildbot at some point to replace the ad hoc nightly test framework Ken set up. Time permitting, I may also work on Python support for system tests (similar to what we have in tcl--the ability to easily set up and tear down Kerberos environments to run test cases in). I don't think there's a Python equivalent of "expect", so in a few cases we might need to beef up programs to accept passwords from sources other than the controlling terminal, if we don't have support for that already. I am not too worried about the 3.0 transition. I suspect Python 2 will be with us for a number of years. However, I would suggest we avoid runing Python scripts during the build unless we can be very minimal about the version requirements. For developer scripts (run during distro-prep, or the test suite, or by hand) I'm tentatively okay with using Python 2.5 as a minimum, although I'd like to know if we have any developers who regularly use an OS which ships Python 2.4. Some of the Python 2.5 features look fairly nice (like conditional expressions) but none of them look like must-haves. From jhutz at cmu.edu Fri Oct 30 14:25:27 2009 From: jhutz at cmu.edu (Jeffrey Hutzelman) Date: Fri, 30 Oct 2009 14:25:27 -0400 Subject: prefer Python for new scripts? In-Reply-To: <26802_1256919748_n9UGMR1l002653_1256919696.5933.315.camel@ray> References: <26802_1256919748_n9UGMR1l002653_1256919696.5933.315.camel@ray> Message-ID: --On Friday, October 30, 2009 12:21:36 PM -0400 Greg Hudson wrote: > However, I would suggest we avoid > runing Python scripts during the build unless we can be very minimal > about the version requirements Or preferably, not at all. Perl is _probably_ sufficiently widely deployed that requiring it for the build is OK, and apparently it hasn't been a problem for Kerberos, but my preference in the long run is to avoid even that. If something is too complicated to be done in sh, then chances are it doesn't need to be done as part of the build, and if it does, maybe it's a candidate for a C program. For tests, I'd relax that a bit. It ought to be possible for anyone building Kerberos to run the tests (modulo cross-compiling), but I think it's OK to require them to have a reasonably new perl and/or python first. From epeisach at MIT.EDU Fri Oct 30 18:54:32 2009 From: epeisach at MIT.EDU (Ezra Peisach) Date: Fri, 30 Oct 2009 18:54:32 -0400 Subject: prefer Python for new scripts? In-Reply-To: <1256919696.5933.315.camel@ray> References: <1256919696.5933.315.camel@ray> Message-ID: <4AEB6EA8.2020501@mit.edu> Greg Hudson wrote: > I like Python. > > I may set up Buildbot at some point to replace the ad hoc nightly test > framework Ken set up. Time permitting, I may also work on Python > support for system tests (similar to what we have in tcl--the ability to > easily set up and tear down Kerberos environments to run test cases in). > I don't think there's a Python equivalent of "expect", so in a few cases > we might need to beef up programs to accept passwords from sources other > than the controlling terminal, if we don't have support for that > already. > > I found pexpect ( http://pexpect.sf.net or http://www.noah.org/wiki/Pexpect ) - is a pure python version of expect interface... According to the FAQ: Q: Isn't there already a Python Expect? A: Yes, there are several of them. They usually require you to compile C. I wanted something that was pure Python and preferably a single module that was simple to install. I also wanted something that was easy to use. This pure Python expect only recently became possible with the introduction of the pty module in the standard Python library. Previously C extensions were required. So - we could distribute Pexpect... (like krb5 use to distribute autoconf)... The pty module appears to exist as far back as python 2.3.3.. Although I cannot say how buggy the older implementations are.... Pexpect is written and tested w/ Python 2.5. Licensing of pexpect looks ok... (but someone else should check)... Ezra