From lukeh at padl.com Tue Sep 1 13:45:12 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 1 Sep 2009 19:45:12 +0200 Subject: KDB and referrals/aliases In-Reply-To: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> Message-ID: <62DDF208-E7F1-4B05-A633-7AF310415925@padl.com> > The problem here (as Sam has noted) is that this behaviour leaves no > opportunity for an administrative interface to disable aliases. So, > if this is important, then we should potentially introduce another > flag. Although this would probably be better done with a separate interface for managing aliases -- Luke From hartmans at MIT.EDU Tue Sep 1 14:40:45 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 01 Sep 2009 14:40:45 -0400 Subject: [krbdev.mit.edu #6206] storing configuration data in credentials caches Message-ID: I'd like to start a discussion of a patch Love filed a while back. He proposed to add the following APIs: + +krb5_error_code KRB5_CALLCONV +krb5_cc_get_config(krb5_context, krb5_ccache, + krb5_const_principal, + const char *, krb5_data *); + +krb5_error_code KRB5_CALLCONV +krb5_cc_set_config(krb5_context, krb5_ccache, + krb5_const_principal, + const char *, krb5_data *); +krb5_boolean KRB5_CALLCONV +krb5_is_config_principal(krb5_context, + krb5_const_principal); The implementation of these APIs stores extra data as tickets with fake principal names in the cache. Jeff Altman complained that this approach seems problematic and that especially for CCAPI caches, we can do better. Jeff would rather us have a mechanism where we have types of data including v4 tickets, v5 tickets, and config data in a cache, and where there is some registration procedure for these types. I'd really like to see these or similar APIs exist and be exposed in the MIT interface. I agree with Jeff that the implementation is kind of ugly. However I don't want to see us get into a situation where perfect is the enemy of progress. In particular, Jeff's proposal seems difficult to implement for file based ccaches. I'd like to collect input on this. --Sam From lukeh at padl.com Tue Sep 1 13:42:11 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 1 Sep 2009 19:42:11 +0200 Subject: KDB and referrals/aliases Message-ID: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> So, we need to distinguish between aliases OK and referrals OK, when requesting an entry from the KDB. We also need to be conscious that an administrative interface might not want to see aliases. This is how it works in 1.7. Apologies in advance for any confusion! * KRB5_KDB_FLAG_CANONICALIZE means both to look up aliases and return referrals (notwithstanding the exception below) * KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY means that referrals should be returned with naming information only (as skeletal principals), rather than as cross-realm TGS entries There are three interesting cases in the KDC path (I'm leaving S4U out for now, that is similar to the AS-REQ client path): * AS-REQ client lookup * AS-REQ server lookup * TGS-REQ server lookup In the AS-REQ client lookup case, we set KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY always, and optionally KRB5_KDB_FLAG_CANONICALIZE (depending on the setting of the canonicalize KDC option). For both server lookup cases, we set KRB5_KDB_FLAG_CANONICALIZE depending on the setting of the canonicalize KDC option. Novell's DSfW backend always returned aliases in the TGS-REQ server lookup path, and used KRB5_KDB_FLAG_CANONICALIZE to determine whether to return referrals or not. The MIT LDAP backend patch I proposed earlier matched this behaviour. Another way of looking at this is: only if KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY is set should KRB5_KDB_FLAG_CANONICALIZE determine whether aliases are returned; otherwise, they should always be returned. If KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY is not set, then KRB5_KDB_FLAG_CANONICALIZE governs only whether referrals should be returned; aliases should always be. The problem here (as Sam has noted) is that this behaviour leaves no opportunity for an administrative interface to disable aliases. So, if this is important, then we should potentially introduce another flag. On the point of always setting KRB5_KDB_FLAG_CANONICALIZE in the TGS- REQ server lookup path, I suspect we don't want to that, because the backend should have the opportunity to not generate referrals. (Referral generation may be expensive: for example, in the AD information model, this requires running string2key on the cross-realm secret.) Were I doing this again, it would be cleaner to have separate LOOKUP_ALIASES and LOOKUP_REFERRALS flags. AS-REQ client would set LOOKUP_ALIASES (if the canonicalize KDC option was set), and TGS-REQ server would always set LOOKUP_ALIASES. LOOKUP_REFERRALS would be set only in the TGS-REQ server path, and then only if the KDC canonicalize option was set. However, I'd prefer to not change the existing interface if at all possible, out of courtesy to Novell. Finally, note that for ease of implementation, the backend can always return the canonical principal name: the KDC will determine which name to return to the client based on its own policy and the setting of the canonicalize KDC option. -- Luke From manojm at us.ibm.com Tue Sep 1 16:08:40 2009 From: manojm at us.ibm.com (Manoj Mohan) Date: Tue, 1 Sep 2009 15:08:40 -0500 Subject: gss_import_name() fails on HPUX .. need help In-Reply-To: References: Message-ID: Hi Tom, Sorry I was on vacation for few days.. so could not get you the required information.. I changed the mech_type from GSS_C_NULL_OID to GSS_C_NT_USER_NAME and gss_import_name worked on HP.. don't know if that is the right thing to do or not. My server principal is in servername/fullyqualified_hostname at domain format. However, gss_acquire_cred is mem-faulting when I am calling it like shown below :( Here is the code snippet: ....................... OM_uint32 maj_stat=0, min_stat=0; gss_cred_id_t claimant_cred_handle = GSS_C_NO_CREDENTIAL; gss_buffer_desc name_buffer; char server_name[CSMGSSMAXSTRLEN]; ...................... name_buffer.length = strlen(server_name); name_buffer.value = server_name; /* Here the server_name is a Fully Qualified Name */ maj_stat = gss_import_name(&min_stat, &name_buffer, mech_type, &target_name); ............. /* Here is the gss_acquire_cred which is mem faulting for me on HP */ maj_stat = gss_acquire_cred(&min_stat, GSS_C_NO_NAME, 0, GSS_C_NO_OID_SET, GSS_C_INITIATE, &claimant_cred_handle, NULL, NULL ); ........................... Thanks in advance, Manoj From: Tom Yu To: Manoj Mohan/Lenexa/IBM at IBMUS Cc: "krbdev at MIT.EDU" Date: 08/25/2009 07:40 AM Subject: Re: gss_import_name() fails on HPUX .. need help Manoj Mohan writes: > Hi, > > I was able to setup my client server programs successfully when > KDC/client/server were on same host (linux). > However, when I am trying to keep KDC on linux, and client/server on HP.. > its failing in gss_import_name on the > client side with error or GSS_S_CALL_INACCESSIBLE_READ. > > I tried to google this, but most of the links were indicating the patch > could be an issue.. but apparently that seems to > be okay. > Do I need to install something special on HP-UX. I can see that patches > look good.. > > $ swlist -lproduct | grep -i gss > GSS-API B.11.11 GSS-API Version 1.0 > PHSS_29487 1.0 GSS-API Version 1.0 Cumulative patch > > ........ > name_buffer.length = strlen("ol_vardhan_al/neto.abcdef.abc.com"); > name_buffer.value = server_name; > maj_stat = gss_import_name(&min_stat, &name_buffer, mech_type, > &target_name); > .................. > > On KDC, I can see that ol_vardhan_al/neto.abcdef.abc.com entry is there > (via list_principals) > > Any idea.. what I am missing? You do not appear to have quoted the source code that sets the "server_name" variable. It is difficult to tell what the problem may be without having this information. From Nicolas.Williams at sun.com Tue Sep 1 17:15:10 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 1 Sep 2009 16:15:10 -0500 Subject: Solaris C-style links fixed (Re: Services4User review) In-Reply-To: <20090826191058.GI1033@Sun.COM> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM> <1251216150.2171.18.camel@equal-rites.mit.edu> <20090826191058.GI1033@Sun.COM> Message-ID: <20090901211510.GX1033@Sun.COM> > > The broken URLs above are actually present as broken links some other > > OpenSolaris pages. Has there been some rearrangement of the site? Is > > there a more authoritative location for SunOS cstyle? > > Yes. They're being fixed. I'll post an update when the links are fixed > or replaced. Fixed: http://opensolaris.org/os/community/on/ http://opensolaris.org/os/community/on/cstyle.ms.pdf http://opensolaris.org/os/community/on/cstyle.ms From tlyu at MIT.EDU Tue Sep 1 17:50:01 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Tue, 01 Sep 2009 17:50:01 -0400 Subject: Solaris C-style links fixed (Re: Services4User review) In-Reply-To: <20090901211510.GX1033@Sun.COM> (Nicolas Williams's message of "Tue, 1 Sep 2009 17:15:10 -0400") References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1251146991.20047.133.camel@ray> <20090824211425.GD1033@Sun.COM> <1251216150.2171.18.camel@equal-rites.mit.edu> <20090826191058.GI1033@Sun.COM> <20090901211510.GX1033@Sun.COM> Message-ID: Nicolas Williams writes: >> > The broken URLs above are actually present as broken links some other >> > OpenSolaris pages. Has there been some rearrangement of the site? Is >> > there a more authoritative location for SunOS cstyle? >> >> Yes. They're being fixed. I'll post an update when the links are fixed >> or replaced. > > Fixed: > > http://opensolaris.org/os/community/on/ > http://opensolaris.org/os/community/on/cstyle.ms.pdf > http://opensolaris.org/os/community/on/cstyle.ms Thanks; I updated the wiki. From ghudson at MIT.EDU Wed Sep 2 11:26:30 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 02 Sep 2009 11:26:30 -0400 Subject: [krbdev.mit.edu #6206] storing configuration data in credentials caches In-Reply-To: References: Message-ID: <1251905190.18351.11.camel@ray> On Tue, 2009-09-01 at 14:40 -0400, Sam Hartman wrote: > I agree with Jeff that the implementation is kind of ugly. However I > don't want to see us get into a situation where perfect is the enemy > of progress. In particular, Jeff's proposal seems difficult to > implement for file based ccaches. Love's implementation operates at the generic ccache layer. A way to address Jeff's concerns is to push the decision into the ccache provider. Then, file ccaches can continue to work the way they do in Love's patch, CCAPI ccaches can use the existing type field, and memory ccaches can grow a new type field to properly isolate configuration from ticket entries. However, when we discussed this option at a recent meeting, we were not sure the benefit outweighs the cost, which is twofold: (1) it's noticeably more work, and (2) it's incompatible with CCAPI-using deployments of Love's implementation under OSX, assuming those exist. The major practical downside to using magic service principals is that old code might try to display configuration entries to users, which would be confusing (the entries should display okay since the configuration data is stored in the normally-opaque key field, but would still be unwanted gunk in the list). This is probably more likely in a CCAPI world than a Unix file-based ccache world since Unix ccache access is usually funneled through the system libkrb5. I do not have strong objections to either approach. From hartmans at MIT.EDU Wed Sep 2 12:07:22 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 02 Sep 2009 12:07:22 -0400 Subject: [krbdev.mit.edu #6206] storing configuration data in credentials caches In-Reply-To: <1251905190.18351.11.camel@ray> (Greg Hudson's message of "Wed\, 02 Sep 2009 11\:26\:30 -0400") References: <1251905190.18351.11.camel@ray> Message-ID: I don't have strong objections to either approach but would prefer Love's original patch unless someone steps forward to do the work of putting this at the ccache provider layer. --Sam From lha at kth.se Wed Sep 2 12:20:53 2009 From: lha at kth.se (=?iso-8859-1?Q?Love_H=F6rnquist_=C5strand?=) Date: Wed, 2 Sep 2009 09:20:53 -0700 Subject: [krbdev.mit.edu #6206] storing configuration data in credentials caches In-Reply-To: References: Message-ID: <78E6EC75-9D73-4F27-BEF1-11AB653740F7@kth.se> 1 sep 2009 kl. 11:40 skrev Sam Hartman: > I'd like to collect input on this. - the configuration data only lives as long as the credentials cache, this have the unfortunate site-effect that renewals remove the configuration, its also good since it removes configuration that becomes stale at renewal time - the backend implementation can be migrated to storing the data differently in the future. Love From ghudson at MIT.EDU Wed Sep 2 13:36:10 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 02 Sep 2009 13:36:10 -0400 Subject: KDB and referrals/aliases In-Reply-To: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> Message-ID: <1251912970.18351.26.camel@ray> On Tue, 2009-09-01 at 13:42 -0400, Luke Howard wrote: > Finally, note that for ease of implementation, the backend can always > return the canonical principal name: the KDC will determine which name > to return to the client based on its own policy and the setting of the > canonicalize KDC option. I'm not sure in what sense this is true. If I remove the KRB5_KDB_FLAG_CANONICALIZE check from our LDAP back end, then the behavior of the as-req path changes noticeably: 1. kinit realname --> tickets 2. kinit aliasname --> working tickets as aliasname 3. kinit -C aliasname --> tickets as realname In current 1.7, case 2 results in a lookup failure. From lukeh at padl.com Wed Sep 2 13:46:53 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 2 Sep 2009 19:46:53 +0200 Subject: KDB and referrals/aliases In-Reply-To: <1251912970.18351.26.camel@ray> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251912970.18351.26.camel@ray> Message-ID: <334FF40A-8C20-467D-934C-9A861338AEAA@padl.com> On 02/09/2009, at 7:36 PM, Greg Hudson wrote: > On Tue, 2009-09-01 at 13:42 -0400, Luke Howard wrote: >> Finally, note that for ease of implementation, the backend can always >> return the canonical principal name: the KDC will determine which >> name >> to return to the client based on its own policy and the setting of >> the >> canonicalize KDC option. > > I'm not sure in what sense this is true. If I remove the > KRB5_KDB_FLAG_CANONICALIZE check from our LDAP back end, then the > behavior of the as-req path changes noticeably: > > 1. kinit realname --> tickets > 2. kinit aliasname --> working tickets as aliasname > 3. kinit -C aliasname --> tickets as realname > > In current 1.7, case 2 results in a lookup failure. What I meant was, when returning an alias, there is no need to set entry.princ to the alias name. -- Luke From ghudson at MIT.EDU Wed Sep 2 14:44:19 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 02 Sep 2009 14:44:19 -0400 Subject: KDB and referrals/aliases In-Reply-To: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> Message-ID: <1251917059.18351.54.camel@ray> Okay. To re-summarize Luke's message: 1. Currently we are not returning aliases in server lookups unless the client understands referrals (i.e. it set the canonicalize protocol flag). This is unnecessarily limiting. 2. The easiest way to change this is to abuse the KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY flag as an indication that the lookup is for a client principal. 3. The above change would have the side effect of making kadmin's "getprinc" see aliases. I'm not sure if this is a real concern. If it is, it could be addressed by adding new DAL interfaces for administrative operations. 4. We could restructure the flags to make things clearer, but at a penalty to Novell (and theoretically to anyone else who has made a custom 1.7 back end). I am okay with using comments to address the lack of clarity of (2), although it's disappointing. I am okay with leaving (3) unsolved since I'm not sure it's any better for getprinc to fail on an alias name. From Nicolas.Williams at sun.com Wed Sep 2 15:12:36 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 2 Sep 2009 14:12:36 -0500 Subject: KDB and referrals/aliases In-Reply-To: <1251917059.18351.54.camel@ray> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> Message-ID: <20090902191236.GQ1033@Sun.COM> On Wed, Sep 02, 2009 at 02:44:19PM -0400, Greg Hudson wrote: > Okay. To re-summarize Luke's message: > > 1. Currently we are not returning aliases in server lookups unless the > client understands referrals (i.e. it set the canonicalize protocol > flag). This is unnecessarily limiting. Yes, it is limiting. Aliases should not require any protocol extensions beyond RFC4120 to use. > 2. The easiest way to change this is to abuse the > KRB5_KDB_FLAG_CLIENT_REFERRALS_ONLY flag as an indication that the > lookup is for a client principal. > > 3. The above change would have the side effect of making kadmin's > "getprinc" see aliases. I'm not sure if this is a real concern. If it I think it's a legitimate concern that kadmin clients be able to distinguish aliases from non-aliases. Not that getprinc(alias) should fail, but that it should tell you its canonical name; listprincs should probably list only canonical names. I think it'd be OK if old clients can't distinguish aliases, as long as new ones can. Preferably old clients should be able to distinguish aliases. > is, it could be addressed by adding new DAL interfaces for > administrative operations. Yes. > 4. We could restructure the flags to make things clearer, but at a > penalty to Novell (and theoretically to anyone else who has made a > custom 1.7 back end). Are there other solutions? Can the KDC and kadmind remain compatible with existing DBs (and not distinguish aliases in that case)? What is the interface stability of the DAL? Would an incompatible change justify a 1.8 release? > I am okay with using comments to address the lack of clarity of (2), > although it's disappointing. I am okay with leaving (3) unsolved since > I'm not sure it's any better for getprinc to fail on an alias name. I don't think getprinc(alias) should fail in any case. See above. Nico -- From lukeh at padl.com Wed Sep 2 15:29:30 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 2 Sep 2009 21:29:30 +0200 Subject: KDB and referrals/aliases In-Reply-To: <20090902191236.GQ1033@Sun.COM> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> Message-ID: <18CBE1E0-BBC4-4AA2-9120-B1BC35B05C1B@padl.com> > I think it's a legitimate concern that kadmin clients be able to > distinguish aliases from non-aliases. Not that getprinc(alias) should > fail, but that it should tell you its canonical name; listprincs > should > probably list only canonical names. Right, but that is the current behaviour. >> 4. We could restructure the flags to make things clearer, but at a >> penalty to Novell (and theoretically to anyone else who has made a >> custom 1.7 back end). > > Are there other solutions? Can the KDC and kadmind remain compatible > with existing DBs (and not distinguish aliases in that case)? What is > the interface stability of the DAL? Would an incompatible change > justify a 1.8 release? The interface is private, but my two cents is that I'd prefer to keep it as stable as possible (also so we can still test against the Novell KDC backend). -- Luke From lukeh at padl.com Wed Sep 2 15:54:45 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 2 Sep 2009 21:54:45 +0200 Subject: KDB and referrals/aliases In-Reply-To: <18CBE1E0-BBC4-4AA2-9120-B1BC35B05C1B@padl.com> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <18CBE1E0-BBC4-4AA2-9120-B1BC35B05C1B@padl.com> Message-ID: > The interface is private, but my two cents is that I'd prefer to keep > it as stable as possible (also so we can still test against the Novell > KDC backend). But I'm not super-fussed. Another thing we could do is provide some helper macros for the backend that mirror what we'd like the flag to be. -- Luke From ghudson at MIT.EDU Wed Sep 2 16:22:40 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 02 Sep 2009 16:22:40 -0400 Subject: KDB and referrals/aliases In-Reply-To: <20090902191236.GQ1033@Sun.COM> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> Message-ID: <1251922960.18351.58.camel@ray> On Wed, 2009-09-02 at 15:12 -0400, Nicolas Williams wrote: > I think it's a legitimate concern that kadmin clients be able to > distinguish aliases from non-aliases. Not that getprinc(alias) should > fail, but that it should tell you its canonical name; listprincs should > probably list only canonical names. In that case, there is no problem: kadmin.local: getprinc user2 Principal: user at DIRECTORATE.ORG Expiration date: [never] [...] "user2" is an alias name and "user" is the canonical name. That's with the LDAP back end hacked to return aliases (a la Luke's patch) but no other changes. From Nicolas.Williams at sun.com Wed Sep 2 16:28:32 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 2 Sep 2009 15:28:32 -0500 Subject: KDB and referrals/aliases In-Reply-To: <1251922960.18351.58.camel@ray> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <1251922960.18351.58.camel@ray> Message-ID: <20090902202832.GS1033@Sun.COM> On Wed, Sep 02, 2009 at 04:22:40PM -0400, Greg Hudson wrote: > On Wed, 2009-09-02 at 15:12 -0400, Nicolas Williams wrote: > > I think it's a legitimate concern that kadmin clients be able to > > distinguish aliases from non-aliases. Not that getprinc(alias) should > > fail, but that it should tell you its canonical name; listprincs should > > probably list only canonical names. > > In that case, there is no problem: > > kadmin.local: getprinc user2 > Principal: user at DIRECTORATE.ORG > [...] > > "user2" is an alias name and "user" is the canonical name. That's with > the LDAP back end hacked to return aliases (a la Luke's patch) but no > other changes. Great. Is there a way to list canonical names only though? That'd be nice. I'm not sure it'd be "required", but if listing only canon names meant listing all names then doing a getprinc on each, then yes, IMO it'd be a required feature. Conversely, being able to list all names, alias and canonical, in one step is a "requirement", IMO. From ghudson at MIT.EDU Wed Sep 2 17:04:54 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 02 Sep 2009 17:04:54 -0400 Subject: KDB and referrals/aliases In-Reply-To: <20090902202832.GS1033@Sun.COM> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <1251922960.18351.58.camel@ray> <20090902202832.GS1033@Sun.COM> Message-ID: <1251925494.18351.63.camel@ray> On Wed, 2009-09-02 at 16:28 -0400, Nicolas Williams wrote: > Is there a way to list canonical names only though? That'd be nice. > I'm not sure it'd be "required", but if listing only canon names meant > listing all names then doing a getprinc on each, then yes, IMO it'd be a > required feature. Conversely, being able to list all names, alias and > canonical, in one step is a "requirement", IMO. Now that I look, iteration is pretty broken in the presence of aliases. krb5_ldap_iterate will stop at the first krbPrincipalName value which is in the specified realm, so you get one name listed per principal entry, and it's not even necessarily the canonical name. The DAL interface for iteration is: krb5_error_code krb5_db_iterate ( krb5_context kcontext, char *match_entry, int (*func) (krb5_pointer, krb5_db_entry *), krb5_pointer func_arg ); I believe that interface would have to be extended to do something sensical with aliases. Luke, what does the DSfW back end do about iteration? From lukeh at padl.com Thu Sep 3 01:52:52 2009 From: lukeh at padl.com (Luke Howard) Date: Thu, 3 Sep 2009 07:52:52 +0200 Subject: KDB and referrals/aliases In-Reply-To: <1251925494.18351.63.camel@ray> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <1251922960.18351.58.camel@ray> <20090902202832.GS1033@Sun.COM> <1251925494.18351.63.camel@ray> Message-ID: <4345C43B-90E0-4375-8F81-25D17C634483@padl.com> On 02/09/2009, at 11:04 PM, Greg Hudson wrote: > On Wed, 2009-09-02 at 16:28 -0400, Nicolas Williams wrote: >> Is there a way to list canonical names only though? That'd be nice. >> I'm not sure it'd be "required", but if listing only canon names >> meant >> listing all names then doing a getprinc on each, then yes, IMO it'd >> be a >> required feature. Conversely, being able to list all names, alias >> and >> canonical, in one step is a "requirement", IMO. > > Now that I look, iteration is pretty broken in the presence of > aliases. > krb5_ldap_iterate will stop at the first krbPrincipalName value > which is > in the specified realm, so you get one name listed per principal > entry, > and it's not even necessarily the canonical name. > > The DAL interface for iteration is: > > krb5_error_code krb5_db_iterate ( krb5_context kcontext, > char *match_entry, > int (*func) (krb5_pointer, > krb5_db_entry *), > krb5_pointer func_arg ); > > I believe that interface would have to be extended to do something > sensical with aliases. Luke, what does the DSfW back end do about > iteration? It always returns the canonical name. For DSfW, the primary administration interface is LDAP (in fact, I don't think Novell even shipped kadmin). -- Luke From ghudson at MIT.EDU Thu Sep 3 12:17:07 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Thu, 03 Sep 2009 12:17:07 -0400 Subject: KDB and referrals/aliases In-Reply-To: <4345C43B-90E0-4375-8F81-25D17C634483@padl.com> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <1251922960.18351.58.camel@ray> <20090902202832.GS1033@Sun.COM> <1251925494.18351.63.camel@ray> <4345C43B-90E0-4375-8F81-25D17C634483@padl.com> Message-ID: <1251994627.18351.73.camel@ray> On Thu, 2009-09-03 at 01:52 -0400, Luke Howard wrote: > It always returns the canonical name. For DSfW, the primary > administration interface is LDAP (in fact, I don't think Novell even > shipped kadmin). Alright. When I added alias support to LDAP for 1.7, time constraints led me to relegate administration of aliases (such as adding them at all) to external LDAP tools. So for the moment it makes sense to just fix the iteration code to supply the canonical name. That means: * With Luke's suggested change to krb5_ldap_get_principal(), "getprinc aliasname" will start working, and will report the canonical name. That will be the only way to see aliases in the admin interface. * With the (not yet coded) fix to krb5_ldap_iterate(), "listprincs" will display only a list of canonical names. From Nicolas.Williams at sun.com Thu Sep 3 12:47:50 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 3 Sep 2009 11:47:50 -0500 Subject: KDB and referrals/aliases In-Reply-To: <1251994627.18351.73.camel@ray> References: <15920B0D-3035-4138-9FBF-7E0D80995105@padl.com> <1251917059.18351.54.camel@ray> <20090902191236.GQ1033@Sun.COM> <1251922960.18351.58.camel@ray> <20090902202832.GS1033@Sun.COM> <1251925494.18351.63.camel@ray> <4345C43B-90E0-4375-8F81-25D17C634483@padl.com> <1251994627.18351.73.camel@ray> Message-ID: <20090903164750.GO1033@Sun.COM> On Thu, Sep 03, 2009 at 12:17:07PM -0400, Greg Hudson wrote: > On Thu, 2009-09-03 at 01:52 -0400, Luke Howard wrote: > > It always returns the canonical name. For DSfW, the primary > > administration interface is LDAP (in fact, I don't think Novell even > > shipped kadmin). > > Alright. When I added alias support to LDAP for 1.7, time constraints > led me to relegate administration of aliases (such as adding them at > all) to external LDAP tools. So for the moment it makes sense to just > fix the iteration code to supply the canonical name. That means: > > * With Luke's suggested change to krb5_ldap_get_principal(), "getprinc > aliasname" will start working, and will report the canonical name. That > will be the only way to see aliases in the admin interface. > > * With the (not yet coded) fix to krb5_ldap_iterate(), "listprincs" > will display only a list of canonical names. Excellent. A TL_DATA to list the known aliases of a princ, and getprinc support for that, would round this out. From ghudson at MIT.EDU Fri Sep 4 12:35:41 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 04 Sep 2009 12:35:41 -0400 Subject: Services4User review In-Reply-To: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> Message-ID: <1252082141.18351.109.camel@ray> Two questions about the API design: * Whereas the krb5 gss_acquire_cred only fetches existing credentials from a cache, the krb5 gss_acquire_cred_impersonate_cred actually goes out and fetches credentials from the KDC, right? * Under what circumstances would an application need to use the gss_acquire_cred_impersonate_cred interface, instead of just calling gss_init_sec_context with the appropriate proxy credential? Is there an actual reason to provide that API? (And similarly for the corresponding add_ API, of course.) From lukeh at padl.com Fri Sep 4 13:03:26 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 4 Sep 2009 19:03:26 +0200 Subject: Services4User review In-Reply-To: <1252082141.18351.109.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> Message-ID: On 04/09/2009, at 6:35 PM, Greg Hudson wrote: > Two questions about the API design: > > * Whereas the krb5 gss_acquire_cred only fetches existing credentials > from a cache, the krb5 gss_acquire_cred_impersonate_cred actually goes > out and fetches credentials from the KDC, right? krb5_gss_acquire_cred_impersonate_cred() does not (this is deferred until gss_init_sec_context(), as it would be with normal credentials). krb5_gss_acquire_cred_impersonate_name() does, but I think this can be considered an implementation detail. > * Under what circumstances would an application need to use the > gss_acquire_cred_impersonate_cred interface, instead of just calling > gss_init_sec_context with the appropriate proxy credential? Is > there an > actual reason to provide that API? (And similarly for the > corresponding > add_ API, of course.) I believe this was proposed principally for other mechanisms (perhaps you can chime in here, Nico). You could use gss_acquire_cred_impersonate_cred() if you wished to impersonate a credential handle you acquired explicitly with gss_acquire_cred(). -- Luke From Nicolas.Williams at sun.com Fri Sep 4 13:23:37 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 12:23:37 -0500 Subject: Services4User review In-Reply-To: References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> Message-ID: <20090904172336.GM1033@Sun.COM> On Fri, Sep 04, 2009 at 07:03:26PM +0200, Luke Howard wrote: > On 04/09/2009, at 6:35 PM, Greg Hudson wrote: > >* Under what circumstances would an application need to use the > >gss_acquire_cred_impersonate_cred interface, instead of just calling > >gss_init_sec_context with the appropriate proxy credential? Is > >there an actual reason to provide that API? (And similarly for the > >corresponding add_ API, of course.) > > I believe this was proposed principally for other mechanisms (perhaps > you can chime in here, Nico). You could use > gss_acquire_cred_impersonate_cred() if you wished to impersonate a > credential handle you acquired explicitly with gss_acquire_cred(). Indeed, this is just for completeness. Without gss_acquire/add_cred_impersonate_cred() you can only do the S4U2SELF thing when you're the acceptor of a context, but with it you can also do the S4U2SELF thing when you just happen to have creds for two principals around. I could see this being useful to someone, though I have no use for it at all. Nico -- From ghudson at MIT.EDU Fri Sep 4 14:13:42 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 04 Sep 2009 14:13:42 -0400 Subject: Services4User review In-Reply-To: <20090904172336.GM1033@Sun.COM> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> Message-ID: <1252088022.18351.119.camel@ray> On Fri, 2009-09-04 at 13:23 -0400, Nicolas Williams wrote: > Without gss_acquire/add_cred_impersonate_cred() you can only do the > S4U2SELF thing when you're the acceptor of a context, but with it you > can also do the S4U2SELF thing when you just happen to have creds for > two principals around. I could see this being useful to someone, though > I have no use for it at all. I thought S4U2Self was done with gss_acquire/add_cred_impersonate_name, not _cred? Did you mean S4U2Proxy there? I'm not really happy with adding an unstandardized GSS extension for "completeness" or for the sake of unspecified mechanisms we don't have. Code which isn't tested doesn't work. If a future need arises for this interface, it may turn out that the interface isn't quite right, and what we provide will only get in the way. So, I'm happy with gss_acquire/add_cred_impersonate_name, which is needed for S4U2Self with Kerberos, but not with gss_acquire/add_cred_impersonate_cred. From lukeh at padl.com Fri Sep 4 14:24:42 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 4 Sep 2009 20:24:42 +0200 Subject: Services4User review In-Reply-To: <1252088022.18351.119.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> Message-ID: On 04/09/2009, at 8:13 PM, Greg Hudson wrote: > On Fri, 2009-09-04 at 13:23 -0400, Nicolas Williams wrote: >> Without gss_acquire/add_cred_impersonate_cred() you can only do the >> S4U2SELF thing when you're the acceptor of a context, but with it you >> can also do the S4U2SELF thing when you just happen to have creds for >> two principals around. I could see this being useful to someone, >> though >> I have no use for it at all. > > I thought S4U2Self was done with gss_acquire/ > add_cred_impersonate_name, > not _cred? Did you mean S4U2Proxy there? Yes, he did. > I'm not really happy with adding an unstandardized GSS extension for > "completeness" or for the sake of unspecified mechanisms we don't > have. > Code which isn't tested doesn't work. If a future need arises for > this > interface, it may turn out that the interface isn't quite right, and > what we provide will only get in the way. I didn't say it wasn't tested. :-) > So, I'm happy with gss_acquire/add_cred_impersonate_name, which is > needed for S4U2Self with Kerberos, but not with > gss_acquire/add_cred_impersonate_cred. How do others feel about this? -- Luke From Nicolas.Williams at sun.com Fri Sep 4 14:56:21 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 13:56:21 -0500 Subject: Services4User review In-Reply-To: References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> Message-ID: <20090904185621.GN1033@Sun.COM> On Fri, Sep 04, 2009 at 08:24:42PM +0200, Luke Howard wrote: > On 04/09/2009, at 8:13 PM, Greg Hudson wrote: > >I thought S4U2Self was done with gss_acquire/ > >add_cred_impersonate_name, > >not _cred? Did you mean S4U2Proxy there? > > Yes, he did. Indeed. > >I'm not really happy with adding an unstandardized GSS extension for > >"completeness" or for the sake of unspecified mechanisms we don't > >have. Code which isn't tested doesn't work. If a future need arises > >for this interface, it may turn out that the interface isn't quite > >right, and what we provide will only get in the way. MIT has already added non-standard GSS-API extensions. So has Sun. So has Heimdal. We're working towards having an IANA registry for GSS-API extensions. That should be good enough. > >So, I'm happy with gss_acquire/add_cred_impersonate_name, which is > >needed for S4U2Self with Kerberos, but not with > >gss_acquire/add_cred_impersonate_cred. > > How do others feel about this? I don't care that much. But this is the sort of thing where actual experience helps. So I'd rather it ship, preferably with a warning that it's subject to change/removal/... (That's what we did with gss_store_cred(), for example.) Nico -- From lukeh at padl.com Fri Sep 4 15:17:03 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 4 Sep 2009 21:17:03 +0200 Subject: Services4User review In-Reply-To: <20090904185621.GN1033@Sun.COM> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> Message-ID: > I don't care that much. But this is the sort of thing where actual > experience helps. So I'd rather it ship, preferably with a warning > that > it's subject to change/removal/... (That's what we did with > gss_store_cred(), for example.) Or we should write up an I-D. -- Luke From Nicolas.Williams at sun.com Fri Sep 4 15:21:47 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 14:21:47 -0500 Subject: Services4User review In-Reply-To: References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> Message-ID: <20090904192147.GO1033@Sun.COM> On Fri, Sep 04, 2009 at 09:17:03PM +0200, Luke Howard wrote: > >I don't care that much. But this is the sort of thing where actual > >experience helps. So I'd rather it ship, preferably with a warning > >that > >it's subject to change/removal/... (That's what we did with > >gss_store_cred(), for example.) > > Or we should write up an I-D. Definitely. My intention was certainly to do that (though with the registry we shouldn't need to submit an I-D). From ghudson at MIT.EDU Fri Sep 4 17:17:59 2009 From: ghudson at MIT.EDU (ghudson@MIT.EDU) Date: Fri, 4 Sep 2009 17:17:59 -0400 (EDT) Subject: Trace logging project Message-ID: <200909042118.n84LHx1Y027719@outgoing.mit.edu> Based on recent feedback from krb5 users, I've written up an early project page on trace logging: http://k5wiki.kerberos.org/wiki/Projects/Trace_logging I'm currently at the rough design stage, and am interested in feedback on: * How trace logging information should be selected, particularly from people who have used trace logging facilities in other projects. * Whether it's better for tracing calls to require a krb5 context for better isolation and thread safety, or not to require a context for better code penetration. There's a bit more on both bullet points in the project page. From ghudson at MIT.EDU Fri Sep 4 17:30:21 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 04 Sep 2009 17:30:21 -0400 Subject: Services4User review In-Reply-To: <20090904185621.GN1033@Sun.COM> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> Message-ID: <1252099821.18351.130.camel@ray> On Fri, 2009-09-04 at 14:56 -0400, Nicolas Williams wrote: > MIT has already added non-standard GSS-API extensions. So has Sun. So > has Heimdal. We're working towards having an IANA registry for GSS-API > extensions. That should be good enough. I should clarify my position: * I am fine with adding unstandardized GSSAPI extensions which have a well-defined purpose. (Thus, gss_acquire/add_cred_impersonate_name is okay because that's how we do S4U.) * I am fine with adding standardized GSSAPI extensions which we don't have an identified need for, if resources are available to do so. For example, I don't know if we have a current use for gss_store_cred, but I wouldn't think to raise any objection on principle if someone wanted to implement it in our tree. * I see no benefit in adding unstandardized APIs for no particular reason, nor do I see any benefit in standardizing gss_acquire/add_cred_impersonate_cred. * When I said "code that isn't tested doesn't work," I meant that code without an identifiable need is likely to bitrot or simply be non-useful in the first place, even if it's covered by a regression test suite. > I don't care that much. But this is the sort of thing where actual > experience helps. So I'd rather it ship, preferably with a warning > that it's subject to change/removal/... (That's what we did with > gss_store_cred(), for example.) I would much rather apply the YAGNI principle, since it is easier to add interfaces than remove or change them. From Nicolas.Williams at sun.com Fri Sep 4 17:49:17 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 4 Sep 2009 16:49:17 -0500 Subject: Services4User review In-Reply-To: <1252099821.18351.130.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> <1252099821.18351.130.camel@ray> Message-ID: <20090904214917.GU1033@Sun.COM> On Fri, Sep 04, 2009 at 05:30:21PM -0400, Greg Hudson wrote: > I should clarify my position: > > * I am fine with adding unstandardized GSSAPI extensions which have a > well-defined purpose. (Thus, gss_acquire/add_cred_impersonate_name is > okay because that's how we do S4U.) Actually, S4U2Self and Proxy *both* are in the same boat: they can be used without new gss_*cred*() extentions because in both cases they can be used solely through the delegated credentials returned by gss_accept_sec_context(). > * I am fine with adding standardized GSSAPI extensions which we don't > have an identified need for, if resources are available to do so. For > example, I don't know if we have a current use for gss_store_cred, but I > wouldn't think to raise any objection on principle if someone wanted to > implement it in our tree. Login daemons like sshd and ftpd can use it (in Solaris sshd uses it). > * I see no benefit in adding unstandardized APIs for no particular > reason, nor do I see any benefit in standardizing > gss_acquire/add_cred_impersonate_cred. What's the difference between "for no particular reason" and "[for] which we don't have an identified need"? It must be subtle :) I don't have a current use for these extensions, therefore I won't mind if they go. But I can imagine uses for these (think of a PAM module that uses host and user creds to impersonate the user to other services). Typically one has no need for such a thing because the PAM module will be running with all privileges and it can assert any ID to any other service on the same host. But suppose now that you want to be able to convey KDC-issued authz-data for that user to those other services; suddenly these APIs become useful! Sometimes no use will materialize for an API if no one knows about it. That's where the utility of "experimental" interface classifications comes. Experimental C interfaces are best segregated into a separate shared object, so that their use is easy to identify. This might be a good time to figure out how experimental interfaces should be dealt with by MIT krb5, if at all. > * When I said "code that isn't tested doesn't work," I meant that code > without an identifiable need is likely to bitrot or simply be non-useful > in the first place, even if it's covered by a regression test suite. I think one can build tests for these interfaces that prevent bitrot. In this case you'd build two services: one to get delegated S4U2* creds and use them to call to the second service. To test the new credentials functions you'd use a test utility that calls that second service. If the second service can tell the difference, then you have bitrot. Like I said, the interfaces were there for completeness. It was possible that someone might come up with a use for them in review, for example. They need not be committed. They should be written up somewhere, in case someone would have a use for them if only they knew about them. Nico -- From ghudson at MIT.EDU Fri Sep 4 23:10:15 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 04 Sep 2009 23:10:15 -0400 Subject: Services4User review In-Reply-To: <20090904214917.GU1033@Sun.COM> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> <1252099821.18351.130.camel@ray> <20090904214917.GU1033@Sun.COM> Message-ID: <1252120215.18351.205.camel@ray> On Fri, 2009-09-04 at 17:49 -0400, Nicolas Williams wrote: > Actually, S4U2Self and Proxy *both* are in the same boat: they can be > used without new gss_*cred*() extentions because in both cases they can > be used solely through the delegated credentials returned by > gss_accept_sec_context(). That doesn't match my understanding. As I understand it, the general use case of S4U2Self is that you've authenticated a user by some other means (like an X.509 certificate or a password over TLS) and you want to get a ticket as that user to examine the PAC information or for use with S4U2Proxy. You never accepted a GSS security context. So you need gss_acquire_cred_impersonate_name to do S4U2Self, but you can then pass the resulting credentials to gss_init_sec_context to do S4U2Proxy, without needing a second extension. > > * I see no benefit in adding unstandardized APIs for no particular > > reason, nor do I see any benefit in standardizing > > gss_acquire/add_cred_impersonate_cred. > > What's the difference between "for no particular reason" and "[for] > which we don't have an identified need"? It must be subtle :) In one bullet point I said "standardized" and in the next I said "unstandardized". Basically, I'm saying that stuff coming out of the IETF gets a presumption of usefulness, but extensions we dream up do not. > I don't have a current use for these extensions, therefore I won't mind > if they go. But I can imagine uses for these (think of a PAM module > that uses host and user creds to impersonate the user to other > services). > Typically one has no need for such a thing because the PAM > module will be running with all privileges and it can assert any ID to > any other service on the same host. But suppose now that you want to be > able to convey KDC-issued authz-data for that user to those other > services; suddenly these APIs become useful! If the PAM module has user creds on hand for some reason, it can use those directly. If the PAM module doesn't have user creds on hand, it can use S4U2Self (via the extension API) to get them, and can pass the result to gss_init_sec_context to do S4U2Proxy. From lukeh at padl.com Sat Sep 5 02:46:36 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 5 Sep 2009 08:46:36 +0200 Subject: Services4User review In-Reply-To: <1252120215.18351.205.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> <1252099821.18351.130.camel@ray> <20090904214917.GU1033@Sun.COM> <1252120215.18351.205.camel@ray> Message-ID: <60648571-246A-497B-9B9D-8EB358089A24@padl.com> On 05/09/2009, at 5:10 AM, Greg Hudson wrote: > On Fri, 2009-09-04 at 17:49 -0400, Nicolas Williams wrote: >> Actually, S4U2Self and Proxy *both* are in the same boat: they can be >> used without new gss_*cred*() extentions because in both cases they >> can >> be used solely through the delegated credentials returned by >> gss_accept_sec_context(). > > That doesn't match my understanding. As I understand it, the general > use case of S4U2Self is that you've authenticated a user by some other > means (like an X.509 certificate or a password over TLS) and you > want to > get a ticket as that user to examine the PAC information or for use > with > S4U2Proxy. You never accepted a GSS security context. So you need > gss_acquire_cred_impersonate_name to do S4U2Self, but you can then > pass > the resulting credentials to gss_init_sec_context to do S4U2Proxy, > without needing a second extension. Yes, that is my understanding too. -- Luke From Nicolas.Williams at sun.com Sat Sep 5 03:12:46 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Sat, 5 Sep 2009 02:12:46 -0500 Subject: Services4User review In-Reply-To: <60648571-246A-497B-9B9D-8EB358089A24@padl.com> References: <1252082141.18351.109.camel@ray> <20090904172336.GM1033@Sun.COM> <1252088022.18351.119.camel@ray> <20090904185621.GN1033@Sun.COM> <1252099821.18351.130.camel@ray> <20090904214917.GU1033@Sun.COM> <1252120215.18351.205.camel@ray> <60648571-246A-497B-9B9D-8EB358089A24@padl.com> Message-ID: <20090905071246.GV1033@Sun.COM> On Sat, Sep 05, 2009 at 08:46:36AM +0200, Luke Howard wrote: > On 05/09/2009, at 5:10 AM, Greg Hudson wrote: > >On Fri, 2009-09-04 at 17:49 -0400, Nicolas Williams wrote: > >>Actually, S4U2Self and Proxy *both* are in the same boat: they can > >>be used without new gss_*cred*() extentions because in both cases > >>they can be used solely through the delegated credentials returned > >>by gss_accept_sec_context(). > > > >That doesn't match my understanding. As I understand it, the general > >use case of S4U2Self is that you've authenticated a user by some > >other means (like an X.509 certificate or a password over TLS) and > >you want to get a ticket as that user to examine the PAC information > >or for use with S4U2Proxy. You never accepted a GSS security > >context. So you need gss_acquire_cred_impersonate_name to do > >S4U2Self, but you can then pass the resulting credentials to > >gss_init_sec_context to do S4U2Proxy, without needing a second > >extension. > > Yes, that is my understanding too. Your page says: " Readers are referred to [MS-SFU] for protocol details, but the premise behind S4U2Self is that a service requests a ticket from itself, to itself, presenting some additional preauthentication data containing the name of the user it has presumably authenticated. The KDC, after making any access checks, returns a ticket with the client-name rewritten to that in the preauthentication data. The server name is unchanged. " It follows that one could use the initiator name from an established security context. Yes, that's twisting things around a bit. Nico -- From mso at medical-insight.com Tue Sep 8 07:11:29 2009 From: mso at medical-insight.com (Morten Sylvest Olsen) Date: Tue, 08 Sep 2009 13:11:29 +0200 Subject: resource leak in gss_krb5_copy_ccache Message-ID: <4AA63BE1.5010700@medical-insight.com> Hi, I keep getting valgrind leaks reported when I use gss_krb5_copy_ccache. Looking at the code, it seems there is a krb5_free_cred_contents missing. Or I may be completely off the mark? krb5-1.7/src/lib/gssapi/krb5: .. code = krb5_cc_start_seq_get(context, k5creds->ccache, &cursor); if (code) { k5_mutex_unlock(&k5creds->lock); *minor_status = code; save_error_info(*minor_status, context); krb5_free_context(context); return(GSS_S_FAILURE); } while (!code && !krb5_cc_next_cred(context, k5creds->ccache, &cursor, &creds)) code = krb5_cc_store_cred(context, out_ccache, &creds); krb5_cc_end_seq_get(context, k5creds->ccache, &cursor); -- Morten Sylvest Olsen, System Developer Medical Insight A/S, Krumtappen 4,3.th,2500 Valby, Denmark Phone:+4546550444, Mobile:+4551573092,Mail: mso at medical-insight.com From ghudson at MIT.EDU Tue Sep 8 12:32:38 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 08 Sep 2009 12:32:38 -0400 Subject: resource leak in gss_krb5_copy_ccache In-Reply-To: <4AA63BE1.5010700@medical-insight.com> References: <4AA63BE1.5010700@medical-insight.com> Message-ID: <1252427558.18351.227.camel@ray> On Tue, 2009-09-08 at 07:11 -0400, Morten Sylvest Olsen wrote: > I keep getting valgrind leaks reported when I use gss_krb5_copy_ccache. > Looking at the code, it seems there is a krb5_free_cred_contents > missing. Or I may be completely off the mark? I believe you are correct. Can you please test out the attached patch and see if it closes the memory leaks you're seeing without causing other issues? -------------- next part -------------- Index: copy_ccache.c =================================================================== --- copy_ccache.c (revision 22715) +++ copy_ccache.c (working copy) @@ -50,8 +50,10 @@ krb5_free_context(context); return(GSS_S_FAILURE); } - while (!code && !krb5_cc_next_cred(context, k5creds->ccache, &cursor, &creds)) + while (!code && !krb5_cc_next_cred(context, k5creds->ccache, &cursor, &creds)) { code = krb5_cc_store_cred(context, out_ccache, &creds); + krb5_free_cred_contents(context, &creds); + } krb5_cc_end_seq_get(context, k5creds->ccache, &cursor); k5_mutex_unlock(&k5creds->lock); *minor_status = code; From mso at medical-insight.com Wed Sep 9 06:49:23 2009 From: mso at medical-insight.com (Morten Sylvest Olsen) Date: Wed, 09 Sep 2009 12:49:23 +0200 Subject: resource leak in gss_krb5_copy_ccache In-Reply-To: <1252427558.18351.227.camel@ray> References: <4AA63BE1.5010700@medical-insight.com> <1252427558.18351.227.camel@ray> Message-ID: <4AA78833.8000308@medical-insight.com> Greg Hudson wrote: > On Tue, 2009-09-08 at 07:11 -0400, Morten Sylvest Olsen wrote: >> I keep getting valgrind leaks reported when I use gss_krb5_copy_ccache. >> Looking at the code, it seems there is a krb5_free_cred_contents >> missing. Or I may be completely off the mark? > > I believe you are correct. Can you please test out the attached patch > and see if it closes the memory leaks you're seeing without causing > other issues? That seemed to do the trick. Our normal build environment is rhel 5.3, which provides mit krb5 1.6.1. The gssapi code is basically the same as in 1.7, I tried your fix in both, and it fixes the leak without ill effects. Saw another leak in 1.7, though I didn't investigate it further: ==4937== 184 bytes in 8 blocks are definitely lost in loss record 126 of 185 ==4937== at 0x40053C0: malloc (vg_replace_malloc.c:149) ==4937== by 0x4E46DF: strdup (in /lib/libc-2.5.so) ==4937== by 0x52B726: gaih_inet (in /lib/libc-2.5.so) ==4937== by 0x52D9F2: getaddrinfo (in /lib/libc-2.5.so) ==4937== by 0x5813BC6: krb5int_getaddrinfo (fake-addrinfo.c:315) ==4937== by 0x552817E: krb5_sname_to_principal (sn2princ.c:112) ==4937== by 0x57BC963: krb5_gss_import_name (import_name.c:99) ==4937== by 0x57B18EB: gssint_import_internal_name (g_glue.c:306) ==4937== by 0x57AF8BA: gss_add_cred (g_acquire_cred.c:383) ==4937== by 0x57AFBC9: gss_acquire_cred (g_acquire_cred.c:198) ==4937== by 0x797CCCA: (within /usr/lib/sasl2/libgssapiv2.so.2.0.22) ==4937== by 0x33CD4F5: sasl_server_step (in /usr/lib/libsasl2.so.2.0.22) /Morten -- Morten Sylvest Olsen, System Developer Medical Insight A/S, Krumtappen 4,3.th,2500 Valby, Denmark Phone:+4546550444, Mobile:+4551573092,Mail: mso at medical-insight.com From ghudson at MIT.EDU Wed Sep 9 11:15:11 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Wed, 09 Sep 2009 11:15:11 -0400 Subject: resource leak in gss_krb5_copy_ccache In-Reply-To: <4AA78833.8000308@medical-insight.com> References: <4AA63BE1.5010700@medical-insight.com> <1252427558.18351.227.camel@ray> <4AA78833.8000308@medical-insight.com> Message-ID: <1252509311.18351.254.camel@ray> On Wed, 2009-09-09 at 06:49 -0400, Morten Sylvest Olsen wrote: > Saw another leak in 1.7, though I didn't investigate it further: That's #6534 in our RT database and has been fixed (more or less) on the trunk. Thanks for the testing work. From Qiang.Xu at fujixerox.com Thu Sep 10 23:42:02 2009 From: Qiang.Xu at fujixerox.com (Xu, Qiang (FXSGSC)) Date: Fri, 11 Sep 2009 11:42:02 +0800 Subject: bugzilla URL Message-ID: Hi, Just want to know whether there is place report any bug for MIT Kerberos distribution? From http://web.mit.edu/Kerberos/, I can't find a place to report bugs. Thanks, Xu Qiang From ghudson at MIT.EDU Fri Sep 11 00:27:03 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 11 Sep 2009 00:27:03 -0400 Subject: Services4User review In-Reply-To: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> Message-ID: <1252643223.18351.356.camel@ray> Here are my comments from my (hopefully) final review of the S4U code. Please address the following and then merge with the latest rev of the trunk: * add_pa_data_element appears to leave out_padata in an invalid state when the if (copy) block fails to allocate memory. While you are there, please rename "out_padata" since it is an in/out parameter, not an output parameter. * kvno should check for -P without -k after parsing all of the options, so that option order is not important. * kvno.c:226 should use &server instead of &in_creds.server, I believe (that is, you missed a case when altering the logic). * The new kvno options should be documented in the man page. * s4u_gss.glue.c:kg_get_evidence_ticket is unused; it should be removed unless there's a reason for it that I couldn't see. * The kfree.c changes to krb5_free_checksum_contents and krb5_free_unparsed_name are unnecessary and undesirable; please revert them (or explain them if I am misunderstanding). I have some other notes, which I am not going to require changes for: * I wasn't sure what the get_in_tkt.c changes were for. They relate to changing the server name for referrals in an as-req, which seems only peripherally related to S4U at most. * I wasn't able to intuit what "gcvt" was supposed to stand for, even after you added the comment to krb5int_send_tgs. * There's some mech logic in s4u_gss_glue.c (conversion between OID membership in a list and prerfc_mech/rfc_mech flags) which appears to be common with acquire_cred.c and should be factored out. * Going forward, the preferred pattern for handling output parameters is to (1) initialize them to NULL (or something appropriate for non-pointer types), and (2) not touch them after that until a successful return is guaranteed. This facilitates static analysis tools like Coverity in determining the correspondence between return values and allocation of return pointers. * In future work, please briefly document the purpose of new internal functions with a comment above the function definition. * I got slightly lost in the mechglue changes, so I wasn't able to review those as carefully as the rest of the code. From ghudson at MIT.EDU Fri Sep 11 00:29:41 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 11 Sep 2009 00:29:41 -0400 Subject: Services4User review In-Reply-To: <1252643223.18351.356.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> Message-ID: <1252643381.18351.358.camel@ray> One more thing I meant to mention: since your S4U tests are not integrated into "make check" (except for the ASN.1 encoder/decoder tests), you're on the hook to document how to run them manually in http://k5wiki.kerberos.org/wiki/Manual_Testing after this code is merged into the trunk. From lukeh at padl.com Fri Sep 11 02:00:29 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 11 Sep 2009 08:00:29 +0200 Subject: Services4User review In-Reply-To: <1252643223.18351.356.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> Message-ID: <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> > * The kfree.c changes to krb5_free_checksum_contents and > krb5_free_unparsed_name are unnecessary and undesirable; please revert > them (or explain them if I am misunderstanding). You said: * Do not check for nullity before calling free or krb5_free functions. (I don't think this is in the coding practices document but is what we're moving towards.) Examples: However, if the caller does not check for nullity, the krb5_free functions must. Which is it to be? > I have some other notes, which I am not going to require changes for: > > * I wasn't sure what the get_in_tkt.c changes were for. They relate > to changing the server name for referrals in an as-req, which seems > only > peripherally related to S4U at most. Right, however this fixes a bug where the server realm was not being rewritten when chasing referrals. It affects S4U but you probably want it for 1.7.1 too. > * I wasn't able to intuit what "gcvt" was supposed to stand for, even > after you added the comment to krb5int_send_tgs. I will try and think of something more sensible. > * I got slightly lost in the mechglue changes, so I wasn't able to > review those as carefully as the rest of the code. Nico? cheers, -- Luke From lukeh at padl.com Fri Sep 11 08:47:38 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 11 Sep 2009 14:47:38 +0200 Subject: Services4User review In-Reply-To: <1252643223.18351.356.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> Message-ID: > * I wasn't sure what the get_in_tkt.c changes were for. They relate > to changing the server name for referrals in an as-req, which seems > only > peripherally related to S4U at most. s4u_identify_user() will fail to chase referrals without this change. > * I wasn't able to intuit what "gcvt" was supposed to stand for, even > after you added the comment to krb5int_send_tgs. Fixed. > * There's some mech logic in s4u_gss_glue.c (conversion between OID > membership in a list and prerfc_mech/rfc_mech flags) which appears > to be > common with acquire_cred.c and should be factored out. Presently not fixed. > * Going forward, the preferred pattern for handling output parameters > is to (1) initialize them to NULL (or something appropriate for > non-pointer types), and (2) not touch them after that until a > successful > return is guaranteed. This facilitates static analysis tools like > Coverity in determining the correspondence between return values and > allocation of return pointers. Noted. > * In future work, please briefly document the purpose of new internal > functions with a comment above the function definition. Noted. -- Luke From tlyu at MIT.EDU Fri Sep 11 09:07:38 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 11 Sep 2009 09:07:38 -0400 Subject: bugzilla URL In-Reply-To: (Qiang Xu's message of "Thu, 10 Sep 2009 23:42:02 -0400") References: Message-ID: "Xu, Qiang (FXSGSC)" writes: > Hi, > > Just want to know whether there is place report any bug for MIT Kerberos distribution? From http://web.mit.edu/Kerberos/, I can't find a place to report bugs. Generally, bug reports go to krb5-bugs at mit.edu, which is the input to our Request Tracker bug database. We prefer that potential security issues be reported to krbcore-security at mit.edu by PGP-encrypted e-mail. http://krbdev.mit.edu/rt/ is the web interface to our bug tracking system, but it is read-only to the general public for spam prevention reasons. http://web.mit.edu/kerberos/contact.html lists our contact information. From ghudson at MIT.EDU Fri Sep 11 10:35:21 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Fri, 11 Sep 2009 10:35:21 -0400 Subject: Services4User review In-Reply-To: <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> Message-ID: <1252679721.18351.381.camel@ray> On Fri, 2009-09-11 at 02:00 -0400, Luke Howard wrote: > However, if the caller does not check for nullity, the krb5_free > functions must. Which is it to be? krb5_free functions must check for nullity before dereferencing pointers. However, we've made the decision to rely on free(NULL) being a no-op in our code base. So: * In krb5_free_checksum_contents, val->contents can be freed and set to NULL even if it is NULL to begin with, so the check you added for non-nullity of val->contents is unnecessary. (val itself is already checked for nullity.) * In krb5_free_unparsed_name, val can be freed even if it is NULL. From sbuckley at MIT.EDU Fri Sep 11 14:47:21 2009 From: sbuckley at MIT.EDU (Stephen C Buckley) Date: Fri, 11 Sep 2009 14:47:21 -0400 Subject: bugzilla URL In-Reply-To: Message-ID: ________________________________ From: Tom Yu Date: Fri, 11 Sep 2009 09:07:38 -0400 To: "Xu, Qiang (FXSGSC)" Cc: Subject: Re: bugzilla URL "Xu, Qiang (FXSGSC)" writes: > Hi, > > Just want to know whether there is place report any bug for MIT Kerberos distribution? From http://web.mit.edu/Kerberos/, I can't find a place to report bugs. Many of these "how to's" are also on our wiki at http://k5wiki.kerberos.org/ From lukeh at padl.com Fri Sep 11 14:54:59 2009 From: lukeh at padl.com (Luke Howard) Date: Fri, 11 Sep 2009 20:54:59 +0200 Subject: TKT_FLG_TRANSIT_POLICY_CHECKED Message-ID: <9AF43311-8749-449D-B7B6-D2A99D96A00B@padl.com> Is there a reason we don't support the use of TKT_FLG_TRANSIT_POLICY_CHECKED to bypass client-side transited policy checking? (Or do we and I haven't looked closely enough?) -- Luke -- www.padl.com | www.fghr.net From lukeh at padl.com Fri Sep 11 18:28:03 2009 From: lukeh at padl.com (Luke Howard) Date: Sat, 12 Sep 2009 00:28:03 +0200 Subject: Services4User review In-Reply-To: <1252679721.18351.381.camel@ray> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> <1252679721.18351.381.camel@ray> Message-ID: <8F2B7F70-F766-4DF2-9A9B-05A722478E01@padl.com> Fixed (although personally I would always check for NULL; call it habit). A couple of other changes were checked in today, after we discovered some issues in interop testing. Other than that, have synced trunk into the s4u branch. Thanks for the feedback. -- Luke On 11/09/2009, at 4:35 PM, Greg Hudson wrote: > On Fri, 2009-09-11 at 02:00 -0400, Luke Howard wrote: >> However, if the caller does not check for nullity, the krb5_free >> functions must. Which is it to be? > > krb5_free functions must check for nullity before dereferencing > pointers. However, we've made the decision to rely on free(NULL) > being > a no-op in our code base. So: > > * In krb5_free_checksum_contents, val->contents can be freed and set > to NULL even if it is NULL to begin with, so the check you added for > non-nullity of val->contents is unnecessary. (val itself is already > checked for nullity.) > > * In krb5_free_unparsed_name, val can be freed even if it is NULL. > > > -- www.padl.com | www.fghr.net From Nicolas.Williams at sun.com Fri Sep 11 18:35:30 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 11 Sep 2009 17:35:30 -0500 Subject: Services4User review In-Reply-To: <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> References: <96BBEC87-8806-4AF4-8CDB-F260985F2C1A@padl.com> <1252643223.18351.356.camel@ray> <294F1AE6-7B85-4067-BB7E-2B1329B79976@padl.com> Message-ID: <20090911223530.GV1033@Sun.COM> On Fri, Sep 11, 2009 at 08:00:29AM +0200, Luke Howard wrote: > > * I got slightly lost in the mechglue changes, so I wasn't able to > > review those as carefully as the rest of the code. > > Nico? I can do a code review, probably next week. I'll try for this weekend. Nico -- From ghudson at MIT.EDU Sat Sep 12 00:14:06 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Sat, 12 Sep 2009 00:14:06 -0400 Subject: Trace logging project In-Reply-To: <200909042118.n84LHx1Y027719@outgoing.mit.edu> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> Message-ID: <1252728846.18351.401.camel@ray> On Fri, 2009-09-04 at 17:17 -0400, ghudson at MIT.EDU wrote: > Based on recent feedback from krb5 users, I've written up an early > project page on trace logging: It sounds like no one has strong opinions about this, which is fine; it's not going to be very intricate. I'm going to start with a simple binary switch: you turn on tracing (by specifying a filename in KRB5_TRACE) and you get everything. If there turns out to be a need for pre-filtering, that can be added later, although it will of course mean marking up all of the existing trace calls. Trace calls will require a context. I don't think there's any important code to trace with no access to a context, and it makes it simple to avoid tracing for secure contexts. When I went to add my first tracing call, I realized that we'll need a custom formatter to deal with principal names and krb5_data structures and the like. Fortunately, there already is one in lib/krb5/os/sendto_kdc.c, which was easy to adapt. I've adjusted the project page and kicked into review status, with an end date of September 18th (one week). I have the plumbing written now, and can commence the work of littering the code base with tracing calls. From Akos.Frohner at cern.ch Mon Sep 14 09:01:17 2009 From: Akos.Frohner at cern.ch (FROHNER Akos) Date: Mon, 14 Sep 2009 15:01:17 +0200 Subject: Trace logging project In-Reply-To: <20090914125848.GN14195@pcitgm06.cern.ch> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914125848.GN14195@pcitgm06.cern.ch> Message-ID: <20090914130117.GA23621@pcitgm06.cern.ch> Greg, Only one comment: I think it is worth adding a timestamp to the trace message, preferably in RFC 3393 format. -- FROHNER ?kos From ghudson at MIT.EDU Mon Sep 14 12:38:37 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 14 Sep 2009 12:38:37 -0400 Subject: Trace logging project In-Reply-To: <03CAA2C09532074C985C6D8D9EBAC89C209F473C@lwlexch02.olympus.f5net.com> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <03CAA2C09532074C985C6D8D9EBAC89C209F473C@lwlexch02.olympus.f5net.com> Message-ID: <1252946317.18351.487.camel@ray> Thanks for the feedback. I have a little follow-up on one of your requirements: On Sat, 2009-09-12 at 19:23 -0400, JC Ferguson wrote: > - The trace logging must be able to be enabled and disable without > restarting a program that calls MIT KRB5. We have long-running > programs and it would be disruptive to restart the program to enable > logging, then restart it again to disable logging. I've been thinking about how we might support dynamic enabling/disabling of tracing without impacting performance. As a library, we have limited choices for dynamic interaction with the outside environment (we can't commandeer signals, for instance), so the basic question is whether we can consult the filesystem at a regular enough interval to enable tracing promptly, but not too often. On the wiki discussion page, you suggested using krb5.conf accesses as an integration point. I'm not sure that's quite a proper fit. As things are now, we can't be sure that krb5.conf would be accessed frequently enough to turn tracing on and off promptly; also, in the future, performance considerations may lead us to access krb5.conf less frequently than we currently do. (Heimdal, for instance, only reads in krb5.conf at context initialization, and is generally more parsimonious with its internal use of krb5 contexts than we are.) One option is to tie into a subset of APIs which might serve as a heartbeat. For applications which regularly establish security contexts, the combination of krb5_mk_req and krb5_rd_req might serve; they usually have to do filesystem accesses to retrieve keys anyway. For applications which use a single security context for a long time (such as ssh), I'm not sure if there are any good options--adding a filesystem access to every sign/seal operation might be too much. My other thought is that one might have to explicitly turn on dynamic enablement/disablement of tracing in krb5.conf, such that the filesystem access penalty would only be paid for in environments which need it. As you noted, we always have the option of punting this problem to the application. Applications have a better range of choices when it comes to IPC, as well as more information about what performance tradeoffs are reasonable. But of course this places more of a burden on the application, and it is also not useful in situations where someone wants to dynamically enable tracing in an application they didn't write. From jc at F5.com Sat Sep 12 19:23:47 2009 From: jc at F5.com (JC Ferguson) Date: Sat, 12 Sep 2009 19:23:47 -0400 Subject: Trace logging project In-Reply-To: <1252728846.18351.401.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> Message-ID: <03CAA2C09532074C985C6D8D9EBAC89C209F473C@lwlexch02.olympus.f5net.com> Greg, I replied on the Wiki with my thoughts. Here are some additional thoughts: - The trace logging must be able to be enabled and disable without restarting a program that calls MIT KRB5. We have long-running programs and it would be disruptive to restart the program to enable logging, then restart it again to disable logging. - also, we may have many processes running on one operating system instance, each calling MIT KRB5. Ideally, we'd want to enable logging for one process, but not all. - Need different logging levels; i.e., 1=little bit, 2=more, 3=even more, 99=fill the disk up :). Alternatively, if you did it per facility in the library, that may work also. There should be an option to write keys out the trace log, with all the normal caveats about security. Sometimes, we have bizarre issues with changing session/long-term keys in the environments we interoperate in. - May want to consider limiting the size of the log to avoid the "oops, I forgot to disable logging" problem that may turn up. What I have done that works well in commercial production applications is maintain two log files - Kerberos.log and Kerberos.log.1. kerberos.log, when filled to some pre-specified size, get renamed to Kerberos.log.1, then it restarts. - regarding the context requirement, so long as that is buried under the covers and the interfaces to the API don't change, I'm good with it. - the format of the log should include the time, pid, some sort of facility identifier, then the text - this'll help with finding the needed in the haystack as you can eliminate things you don't care about using 'grep -v' when doing post-mortem analysis. I'll check the Wiki also. 2 cents -jc > -----Original Message----- > From: krbdev-bounces at mit.edu [mailto:krbdev-bounces at mit.edu] On Behalf Of Greg > Hudson > Sent: Saturday, September 12, 2009 0:14 > To: krbdev at mit.edu > Subject: Re: Trace logging project > > On Fri, 2009-09-04 at 17:17 -0400, ghudson at MIT.EDU wrote: > > Based on recent feedback from krb5 users, I've written up an early > > project page on trace logging: > > It sounds like no one has strong opinions about this, which is fine; > it's not going to be very intricate. > > I'm going to start with a simple binary switch: you turn on tracing (by > specifying a filename in KRB5_TRACE) and you get everything. If there > turns out to be a need for pre-filtering, that can be added later, > although it will of course mean marking up all of the existing trace > calls. > > Trace calls will require a context. I don't think there's any important > code to trace with no access to a context, and it makes it simple to > avoid tracing for secure contexts. > > When I went to add my first tracing call, I realized that we'll need a > custom formatter to deal with principal names and krb5_data structures > and the like. Fortunately, there already is one in > lib/krb5/os/sendto_kdc.c, which was easy to adapt. > > I've adjusted the project page and kicked into review status, with an > end date of September 18th (one week). I have the plumbing written now, > and can commence the work of littering the code base with tracing calls. > > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev From Nicolas.Williams at sun.com Mon Sep 14 13:13:46 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Sep 2009 12:13:46 -0500 Subject: Trace logging project In-Reply-To: <1252728846.18351.401.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> Message-ID: <20090914171346.GB1033@Sun.COM> On Sat, Sep 12, 2009 at 12:14:06AM -0400, Greg Hudson wrote: > On Fri, 2009-09-04 at 17:17 -0400, ghudson at MIT.EDU wrote: > > Based on recent feedback from krb5 users, I've written up an early > > project page on trace logging: > > It sounds like no one has strong opinions about this, which is fine; > it's not going to be very intricate. Well, I'd just missed this that's all :) I would like this to see this requirement: - zero cost when tracing is disabled at build time - only interesting events should be traceable, for a definition of interesting (function entry/exit tracing is not interesting to me) Also, I think you should consider a DTrace USDT provider. If at all possible you should have a single set of macros that can expand into USDT provider points or calls to an MIT krb5-specific trace framework. (DTrace runs on MacOS X, FreeBSD, and, of course, Solaris.) > I'm going to start with a simple binary switch: you turn on tracing (by > specifying a filename in KRB5_TRACE) and you get everything. If there > turns out to be a need for pre-filtering, that can be added later, > although it will of course mean marking up all of the existing trace > calls. One of the nice things about DTrace is that you don't have to add filtering features to the victim code. > Trace calls will require a context. I don't think there's any important > code to trace with no access to a context, and it makes it simple to > avoid tracing for secure contexts. Context initialization is interesting, and should be traceable without a context, for obvious reasons. > When I went to add my first tracing call, I realized that we'll need a > custom formatter to deal with principal names and krb5_data structures > and the like. Fortunately, there already is one in > lib/krb5/os/sendto_kdc.c, which was easy to adapt. That could be useful for a DTrace USDT provider, actually (with if-enabled probes). > I've adjusted the project page and kicked into review status, with an > end date of September 18th (one week). I have the plumbing written now, > and can commence the work of littering the code base with tracing calls. Ugh. I think we should trace *interesting* events, not all function entry/exit (since plenty of tools can do _that_). I'd hate to see the code littered with trace macros/function calls in all function entries, before gotos, before returns. You should aim to have relatively few traces, compared to the number of actual functions (and function entries/exits). Nico -- From ghudson at MIT.EDU Mon Sep 14 15:32:51 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 14 Sep 2009 15:32:51 -0400 Subject: Trace logging project In-Reply-To: <20090914171346.GB1033@Sun.COM> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914171346.GB1033@Sun.COM> Message-ID: <1252956771.18351.503.camel@ray> On Mon, 2009-09-14 at 13:13 -0400, Nicolas Williams wrote: > I would like this to see this requirement: > > - zero cost when tracing is disabled at build time > - only interesting events should be traceable, for a definition of > interesting (function entry/exit tracing is not interesting to me) We agree. As noted in the project page, the primary use case here is to help experienced users (such as support staff) diagnose configuration problems, not to aid programmers in debugging. So, for instance, it's important to know what preauth systems kinit tried to use or what KDC was contacted for a TGS request. Information at the level of function calls is not important to this use case. > Also, I think you should consider a DTrace USDT provider. I will have to read up on this. > Context initialization is interesting, and should be traceable without a > context, for obvious reasons. If the simple fact of context initialization is interesting, then that can be traced just before krb5_init_context returns. A more interesting question is whether we should trace profile reads, since those are done with a profile handle instead of a krb5 context. I'm not sure if those count as interesting events, though. > > [...] littering the code base with tracing calls. > > Ugh. [...] I'd hate to see the > code littered with trace macros/function calls in all function entries, > before gotos, before returns. I think my use of the word "littering" connoted more than I really meant. From Nicolas.Williams at sun.com Mon Sep 14 16:03:28 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Sep 2009 15:03:28 -0500 Subject: Trace logging project In-Reply-To: <1252956771.18351.503.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914171346.GB1033@Sun.COM> <1252956771.18351.503.camel@ray> Message-ID: <20090914200328.GJ1033@Sun.COM> On Mon, Sep 14, 2009 at 03:32:51PM -0400, Greg Hudson wrote: > As noted in the project page, the primary use case here is to help > experienced users (such as support staff) diagnose configuration > problems, not to aid programmers in debugging. So, for instance, it's > important to know what preauth systems kinit tried to use or what KDC > was contacted for a TGS request. Information at the level of function > calls is not important to this use case. Good. > > Also, I think you should consider a DTrace USDT provider. > > I will have to read up on this. Please do. I think it's likely that you could have one set of macros that uses your trace facility in the [build-time] absence of DTrace, or which expand into DTrace USDT probe sites in the presence of DTrace. (I bet we'd be interested in a krb5 DTrace USDT provider, and perhaps so would Apple engineers. But if the macros are sufficiently general I think Linux and others could benefit as well. I've not looked recently at USDT provider construction, so I don't know whether this is feasible.) > > Context initialization is interesting, and should be traceable without a > > context, for obvious reasons. > > If the simple fact of context initialization is interesting, then that > can be traced just before krb5_init_context returns. > > A more interesting question is whether we should trace profile reads, > since those are done with a profile handle instead of a krb5 context. > I'm not sure if those count as interesting events, though. Context initialization _failures_ are interesting. Context init success is utterly uninteresting, though as you say, what config files are read is potentially interesting. > > > [...] littering the code base with tracing calls. > > > > Ugh. [...] I'd hate to see the > > code littered with trace macros/function calls in all function entries, > > before gotos, before returns. > > I think my use of the word "littering" connoted more than I really > meant. I hope so. Solaris Kerberos used to be so-littered, and it was an eye sore. Incidentally, I've built DTrace scripts, using the PID provider, to get at cleartext from deep in libkrb5 that normally there's no way to get at. It's certainly feasible to do this, and perhaps we ought to keep an archive of useful scripts for tracing MIT Kerberos. Nico -- From Nicolas.Williams at sun.com Mon Sep 14 17:00:06 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Sep 2009 16:00:06 -0500 Subject: Trace logging project In-Reply-To: <200909042118.n84LHx1Y027719@outgoing.mit.edu> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> Message-ID: <20090914210006.GM1033@Sun.COM> Also, anything that is of diagnostic use should really be stored in the context and made available to apps for display to users. What, then, needs tracing? I think aspects of the protocol do, particularly where ciphertext is involved (therefore packet captures are not so useful, not without keys made available to the to the packet dissector). Of course, the GSS-API has no interface by which to get non-error information, and the gss_display_status() interface is lame for dynamic error/diagnostic data. Plus existing apps. Thus the desire for a tracing facility driven by environment variables. I think we need new APIs. We have applications that could really use having detailed descriptions of errors passed all the way up the stack from low-level crypto, up through Kerberos, the GSS-API, SASL, LDAP, etcetera, to the application. It's the application that interacts with users, and needs to give them advice when things break. Building a diagnostic tool on top of a KRB5_TRACE env var-driven trace tool would be challenging, if not outright a bad idea (the same would apply to using the DTrace PID provider, though not to the USDT provider). So what is the real goal? Nico -- From ghudson at MIT.EDU Mon Sep 14 18:14:52 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Mon, 14 Sep 2009 18:14:52 -0400 Subject: Trace logging project In-Reply-To: <20090914210006.GM1033@Sun.COM> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <20090914210006.GM1033@Sun.COM> Message-ID: <1252966492.18351.550.camel@ray> On Mon, 2009-09-14 at 17:00 -0400, Nicolas Williams wrote: > So what is the real goal? We received two independent requests in the course of one week, from different angles. I'll present them as use cases: 1. You market an application which uses Kerberos as a core component. You are experiencing rare, inexplicable failures in customer deployments. You want to be able to collect more information about failures in order to reproduce and debug them. 2. You market a server product with Kerberos support. Your customers are having trouble properly configuring clients to talk to a KDC and your server product. When they experience failures, they typically can't tell if the problem is arising because of the client configuration, the server configuration, the KDC configuration, or the communication path between two of those components. You want to be able to collect more information about failed operations in order to identify the configuration error. Use case #1 arguably wants a facility oriented towards code debugging, not configuration debugging, and it's possible that it's better fodder for a generic tool--though I'm not sure the right tools exist in most runtime environments, especially when you don't get to ship specially-compiled debugging code to the customer as part of the support process. At any rate, a trace logging tool suitable for use case #2 could still be of assistance for #1, even if it's not a perfect fit. In use case #2, the client failure is typically coming from a program you didn't write, which may not have a rich interface for displaying errors. >From elsewhere in the thread: > Context initialization _failures_ are interesting. It seems like context initialization failures are about the simplest type of possible krb5 failure, and can easily be captured in the text of a simple error message. Regardless, the point is likely moot; context initialization failures can likely be traced using the half-constructed context. From Nicolas.Williams at sun.com Mon Sep 14 18:37:57 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Sep 2009 17:37:57 -0500 Subject: Trace logging project In-Reply-To: <1252966492.18351.550.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <20090914210006.GM1033@Sun.COM> <1252966492.18351.550.camel@ray> Message-ID: <20090914223756.GN1033@Sun.COM> On Mon, Sep 14, 2009 at 06:14:52PM -0400, Greg Hudson wrote: > On Mon, 2009-09-14 at 17:00 -0400, Nicolas Williams wrote: > > So what is the real goal? > > We received two independent requests in the course of one week, from > different angles. I'll present them as use cases: > > 1. You market an application which uses Kerberos as a core component. > You are experiencing rare, inexplicable failures in customer > deployments. You want to be able to collect more information about > failures in order to reproduce and debug them. Indeed, but once you're done you want to modify the application so that it recognizes the error condition and gives the user advice. Otherwise you keep getting the same calls over and over. Updating documentation helps, but not enough -- the UIs really need to be able to tell the user useful information. I know this because I've been there. The Solaris smbd and idmapd daemons have no access to Kerberos error data in LDAP contexts because our libldap aliases all SASL errors as "local error" (error 80), which has given rise to many calls. But even if it didn't, making sure that we convey all of the relevant errors and ancilliary data up the stack (krb5->gss->sasl gss plug-in->sasl->ldap->app) is tricky. Having trace data is a _lot_ better than nothing: these apps could just point the user at the trace data, or at analysis of it (assuming the trace output is stable enough and machine parseable). But it'd be nicer if these apps could just say "synchronize your clock" or "re-join your domain", and so on. Without improved error reporting, tracing is a band-aid. A very welcome band-aid, no doubt (particularly if you don't have dynamic tracing facilities). > In use case #2, the client failure is typically coming from a program > you didn't write, which may not have a rich interface for displaying > errors. In the case of interop problems, you may really need to see a capture of all PDUs (including cleartext of any EncryptedData). I've had to build DTrace scripts to get at such cleartext as I had no other way to get it. In the case of interaction with other components on the same system (e.g., NTP) I'd say what you really have is a variant of case #1. > >From elsewhere in the thread: > > Context initialization _failures_ are interesting. > > It seems like context initialization failures are about the simplest > type of possible krb5 failure, and can easily be captured in the text of > a simple error message. True. > Regardless, the point is likely moot; context initialization failures > can likely be traced using the half-constructed context. Yes. What do you need the context for? I'd say: to give the app direct control over whether to enable tracing, and where to output the traces, which information should be conveyed via the context argument. Nico -- From Nicolas.Williams at sun.com Mon Sep 14 19:15:03 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 14 Sep 2009 18:15:03 -0500 Subject: Trace logging project In-Reply-To: <1252956771.18351.503.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914171346.GB1033@Sun.COM> <1252956771.18351.503.camel@ray> Message-ID: <20090914231502.GP1033@Sun.COM> On Mon, Sep 14, 2009 at 03:32:51PM -0400, Greg Hudson wrote: > On Mon, 2009-09-14 at 13:13 -0400, Nicolas Williams wrote: > > Also, I think you should consider a DTrace USDT provider. > > I will have to read up on this. Ok, so, looking at the docs, it looks like it ought to be possible to build krb5 trace macros that devolve into DTrace USDT probes when that is available. Defining a USDT provider and its probes is easy enough: - you need a .d file listing provider attributes and defining the probes and their arguments; - DTRACE_PROBEn() _() and __ENABLED() macros (the last two generated by dtrace(1M) from the .d file) must be littered in the code to define the actual probe points. The 'n' is the number of arguments. These macros take a provider name argument, a probe name argument, and any arguments to the probe; - an extra build step to use dtrace(1M) to generate a header file to include (defines the _*() macros) and an object to link in. ISTM that you could define macros with the same signatures as the ones that DTrace would generated for you. Which means you could have a single set of trace/probe points to litter through the code. I think it'd be great if you did define trace points as macros that could be generated by dtrace(1M). Someone else could do the work of writing the .d file, autoconf and makefile code to use DTrace. Useful links: http://www.solarisinternals.com/wiki/index.php/DTrace_Topics_USDT (and links at the bottom of that) http://wikis.sun.com/display/DTrace/Statically+Defined+Tracing+for+User+Applications http://www.opensolaris.org/jive/thread.jspa?messageID=31314 Cheers, Nico -- From tlyu at MIT.EDU Mon Sep 14 21:37:09 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Mon, 14 Sep 2009 21:37:09 -0400 Subject: kerberos.org (including k5wiki and blog) migration 09/16 Message-ID: At some point on 2009-09-16, I plan to migrate kerberos.org, including k5wiki and the blog, to a new server host. The web server will be down while I create a snapshot and migrate it to the new host. If you happen to be editing the wiki on Wednesday, please take care to make a local save of wiki changes that you might need a lot of effort to recreate. While there should be no data loss, I am uncertain of whether you will lose your edits if you submit a wiki change while the web server is down; this may depend on your web browser. The duration of the web server outage should be less than 30 minutes. This new host is a virtual machine on a VMware ESX infrastructure supported and managed by MIT's IS&T operations staff, as opposed to the existing host, which is a self-supported virtual machine on a Xen hypervisor originally intended for testing purposes. We will shut down this hypervisor at some point in the future and replace it with some sort of VMware hypervisor. I will coordinate DNS changes and TCP forwarders to minimize the disruption of the keberos.org web server migration. If you care to test the new host prior to the migration, it is in the test.kerberos.org subdomain (www.test.kerberos.org, k5wiki.test.kerberos.org, blog.test.kerberos.org). Any changes you make here will not persist beyond the migration, as the migration procedure will overwrite them. Some functionality may not work correctly on the test subdomain due to domain name discrepancies. Please let me know if you have concerns with or encounter problems with the migration. At some point in the future, a similar migration will occur for krbdev.mit.edu, which is also a self-supported virtual machine on the Xen hypervisor. -- Tom Yu Development Team Leader MIT Kerberos Consortium From ghudson at MIT.EDU Tue Sep 15 09:25:10 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 15 Sep 2009 09:25:10 -0400 Subject: svn rev #22761: trunk/src/include/ In-Reply-To: <200909150617.n8F6HIAZ030945@drugstore.mit.edu> References: <200909150617.n8F6HIAZ030945@drugstore.mit.edu> Message-ID: <1253021110.18351.565.camel@ray> On Tue, 2009-09-15 at 02:17 -0400, raeburn at MIT.EDU wrote: > +#elif defined(__BIG_ENDIAN__) || !defined(__LITTLE_ENDIAN__) > +# define K5_BE > +#elif defined(__LITTLE_ENDIAN__) || !defined(__BIG_ENDIAN__) > +# define K5_LE Did you mean && instead of || here? On a compiler which doesn't define these macros or anything preceding, you're going to wind up assuming K5_BE with no evidence. From lukeh at padl.com Tue Sep 15 13:25:49 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 15 Sep 2009 19:25:49 +0200 Subject: Naming extensions Message-ID: For review: http://k5wiki.kerberos.org/wiki/Projects/VerifyAuthData -- Luke -- www.padl.com | www.fghr.net From ghudson at MIT.EDU Tue Sep 15 13:38:55 2009 From: ghudson at MIT.EDU (Greg Hudson) Date: Tue, 15 Sep 2009 13:38:55 -0400 Subject: Trace logging project In-Reply-To: <20090914231502.GP1033@Sun.COM> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914171346.GB1033@Sun.COM> <1252956771.18351.503.camel@ray> <20090914231502.GP1033@Sun.COM> Message-ID: <1253036335.18351.709.camel@ray> On Mon, 2009-09-14 at 19:15 -0400, Nicolas Williams wrote: > I think it'd be great if you did define trace points as macros that > could be generated by dtrace(1M). Someone else could do the work of > writing the .d file, autoconf and makefile code to use DTrace. [Some out of band conversation ensues.] Because the internal mechanism requires a context, there is an impedance mismatch between USDT-style macros and what is needed for the internal mechanism. Also, we don't want our tracing calls to be mucking around with converting data structures like krb5_principals into strings; that needs to happen behind the covers (or perhaps not at all, for a USDT provider). As you noted, the most important thing is that there be some kind of symbolic identification of the trace point. That would come at the cost of a big header file full of trace macro definitions, but it turns out that Tom likes this idea anyway. So I think the tracing calls will look like: TRACE_GET_CREDS(context, in_creds->client, in_creds->server, options); and then the basic macro in the big header file would read something like: #define TRACE_GET_CREDS(c, client, server, flags) \ k5trace(c, "Getting credentials for %P -> %P with flags %F", client, server, flags) To add a USDT provider, one could add in a call to DTRACE_PROBE3 or to an automatically-generated macro, perhaps after converting the arguments to strings. The changes might be a bit ugly if stringification is included, but would be confined to a single header file. From hartmans at MIT.EDU Tue Sep 15 14:49:08 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Tue, 15 Sep 2009 14:49:08 -0400 Subject: TKT_FLG_TRANSIT_POLICY_CHECKED In-Reply-To: <9AF43311-8749-449D-B7B6-D2A99D96A00B@padl.com> (Luke Howard's message of "Fri\, 11 Sep 2009 20\:54\:59 +0200") References: <9AF43311-8749-449D-B7B6-D2A99D96A00B@padl.com> Message-ID: >>>>> "Luke" == Luke Howard writes: 8 Luke> Is there a reason we don't support the use of Luke> TKT_FLG_TRANSIT_POLICY_CHECKED to bypass client-side Luke> transited policy checking? (Or do we and I haven't looked Luke> closely enough?) You mean app-server-side. No, just never implemented. From lukeh at padl.com Tue Sep 15 14:55:00 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 15 Sep 2009 20:55:00 +0200 Subject: TKT_FLG_TRANSIT_POLICY_CHECKED In-Reply-To: References: <9AF43311-8749-449D-B7B6-D2A99D96A00B@padl.com> Message-ID: On 15/09/2009, at 8:49 PM, Sam Hartman wrote: >>>>>> "Luke" == Luke Howard writes: > 8 > Luke> Is there a reason we don't support the use of > Luke> TKT_FLG_TRANSIT_POLICY_CHECKED to bypass client-side > Luke> transited policy checking? (Or do we and I haven't looked > Luke> closely enough?) > > You mean app-server-side. No, just never implemented. Yes, I struggle with the use of the word "client". Sometimes I use it to mean "not KDC". -- Luke From lukeh at padl.com Tue Sep 15 14:56:47 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 15 Sep 2009 20:56:47 +0200 Subject: Lockout Message-ID: For review: http://k5wiki.kerberos.org/wiki/Projects/Lockout Note: code is not well tested (in case of LDAP, untested). -- Luke From Nicolas.Williams at sun.com Tue Sep 15 15:04:56 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Tue, 15 Sep 2009 14:04:56 -0500 Subject: Trace logging project In-Reply-To: <1253036335.18351.709.camel@ray> References: <200909042118.n84LHx1Y027719@outgoing.mit.edu> <1252728846.18351.401.camel@ray> <20090914171346.GB1033@Sun.COM> <1252956771.18351.503.camel@ray> <20090914231502.GP1033@Sun.COM> <1253036335.18351.709.camel@ray> Message-ID: <20090915190455.GC1033@Sun.COM> On Tue, Sep 15, 2009 at 01:38:55PM -0400, Greg Hudson wrote: > [Some out of band conversation ensues.] > > Because the internal mechanism requires a context, there is an impedance > mismatch between USDT-style macros and what is needed for the internal > mechanism. Also, we don't want our tracing calls to be mucking around > with converting data structures like krb5_principals into strings; that > needs to happen behind the covers (or perhaps not at all, for a USDT > provider). The macros can take the context argument. When one goes to turn those marcos into a USDT provider one would #define then to ignore the krb5_context argument. See examples below. > As you noted, the most important thing is that there be some kind of > symbolic identification of the trace point. That would come at the cost > of a big header file full of trace macro definitions, but it turns out > that Tom likes this idea anyway. So I think the tracing calls will look > like: I like that idea as well. It gives you and others a lot more control over what actually happens at each trace-point. See below. The other constraint that you mentioned is that the DTrace USDT macros are not variadic. > TRACE_GET_CREDS(context, in_creds->client, in_creds->server, options); > > and then the basic macro in the big header file would read something > like: > > #define TRACE_GET_CREDS(c, client, server, flags) \ > k5trace(c, "Getting credentials for %P -> %P with flags %F", > client, server, flags) Yes. > To add a USDT provider, one could add in a call to DTRACE_PROBE3 or to > an automatically-generated macro, perhaps after converting the arguments > to strings. The changes might be a bit ugly if stringification is > included, but would be confined to a single header file. It's easier, actually: dtrace(1M) will actually generate macros called PROVIDER_PROBE_ENABLED (for "is-enabled" probing) and PROVIDER_PROBE. Suppose you call your macros TRACE_ and that we want the provider to be called "krb5", then the definitions that turns those macros into USDT probe points would look like this: #define TRACE_GET_CREDS(c, client, server, flags) \ if (KRB5_GET_CREDS_ENABLED()) { variable decls; \ stringification code; \ KRB5_GET_CREDS(stringified_client, stringified_server, \ flags); \ free stringified args; \ } or #define TRACE_GET_CREDS(c, client, server, flags) \ KRB5_GET_CREDS(client, server, flags); The first form is for when you want the probe arguments to be stringified state, which otherwise a DTrace script writer would have to use copyin() and additional script and other code to get at. Note that the "if (..._ENABLED())" idiom can be used in your version of these macros too, which nets you fine-grained trace-point enable/disable control. This way you can have a poor man's DTrace, the real thing, or other dynamic tracing facilities, all with zero changes to any of the main krb5 code -- just minor changes to the build system and the addition of a .d file. A win-win all around, IMO. Thanks! Nico -- From raeburn at MIT.EDU Tue Sep 15 15:25:43 2009 From: raeburn at MIT.EDU (Ken Raeburn) Date: Tue, 15 Sep 2009 15:25:43 -0400 Subject: svn rev #22761: trunk/src/include/ In-Reply-To: <1253021110.18351.565.camel@ray> References: <200909150617.n8F6HIAZ030945@drugstore.mit.edu> <1253021110.18351.565.camel@ray> Message-ID: <4EF78D8D-1549-4471-87D8-519201EB55A5@mit.edu> On Sep 15, 2009, at 09:25, Greg Hudson wrote: > Did you mean && instead of || here? On a compiler which doesn't > define > these macros or anything preceding, you're going to wind up assuming > K5_BE with no evidence. Ugh! Yes, I'll fix it, thanks. Ken From ssorce at redhat.com Tue Sep 15 16:49:51 2009 From: ssorce at redhat.com (Simo Sorce) Date: Tue, 15 Sep 2009 16:49:51 -0400 Subject: Lockout In-Reply-To: References: Message-ID: <1253047791.15736.30.camel@localhost.localdomain> On Tue, 2009-09-15 at 20:56 +0200, Luke Howard wrote: > For review: > > http://k5wiki.kerberos.org/wiki/Projects/Lockout > > Note: code is not well tested (in case of LDAP, untested). I think there is some discussion about lockout policies (probably in the password policy discussion) for LDAP in the ldap workgroup. Instead of having only the last failed and a count of failed authentication attempts it would be probably better to have a list of authentication failures/success with a timestamp. This would be not only multimaster friendly (when using LDAP as a backend) but would allow for better reporting if needed. It also allows to change policies on the fly because you have all the data available to recalculate the status an account "should" be. Simo. -- Simo Sorce * Red Hat, Inc * New York From tsitkova at MIT.EDU Tue Sep 15 17:24:38 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Tue, 15 Sep 2009 17:24:38 -0400 Subject: Lockout In-Reply-To: <1253047791.15736.30.camel@localhost.localdomain> References: , <1253047791.15736.30.camel@localhost.localdomain> Message-ID: <42553961FD54AE41BF83834CB917221F0313454592@w92expo2.exchange.mit.edu> Something in lines of "Password Policy for LDAP Directories" draft? http://www.ietf.org/id/draft-behera-ldap-password-policy-10.txt Zhanna ________________________________________ From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of Simo Sorce [ssorce at redhat.com] Sent: Tuesday, September 15, 2009 4:49 PM To: Luke Howard Cc: MIT Kerberos Dev List Subject: Re: Lockout On Tue, 2009-09-15 at 20:56 +0200, Luke Howard wrote: > For review: > > http://k5wiki.kerberos.org/wiki/Projects/Lockout > > Note: code is not well tested (in case of LDAP, untested). I think there is some discussion about lockout policies (probably in the password policy discussion) for LDAP in the ldap workgroup. Instead of having only the last failed and a count of failed authentication attempts it would be probably better to have a list of authentication failures/success with a timestamp. This would be not only multimaster friendly (when using LDAP as a backend) but would allow for better reporting if needed. It also allows to change policies on the fly because you have all the data available to recalculate the status an account "should" be. Simo. -- Simo Sorce * Red Hat, Inc * New York _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From lukeh at padl.com Tue Sep 15 17:30:01 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 15 Sep 2009 23:30:01 +0200 Subject: Lockout In-Reply-To: <42553961FD54AE41BF83834CB917221F0313454592@w92expo2.exchange.mit.edu> References: , <1253047791.15736.30.camel@localhost.localdomain> <42553961FD54AE41BF83834CB917221F0313454592@w92expo2.exchange.mit.edu> Message-ID: <9F9B7EF8-49CB-4FCD-BC0A-33F3A9B54DA6@padl.com> Right, I did look at this; however, for now I chose the path that was the least intrusive to the existing kadm5 information model. I did this on the presumption that eventually we will want to harmonise the KDB LDAP backend with the password policy draft, and that this will be best done in one fell swoop rather than piecemeal. (Now, doing that is out of scope for this project.) -- Luke On 15/09/2009, at 11:24 PM, Zhanna Tsitkova wrote: > Something in lines of "Password Policy for LDAP Directories" draft? > http://www.ietf.org/id/draft-behera-ldap-password-policy-10.txt > > Zhanna > ________________________________________ > From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of > Simo Sorce [ssorce at redhat.com] > Sent: Tuesday, September 15, 2009 4:49 PM > To: Luke Howard > Cc: MIT Kerberos Dev List > Subject: Re: Lockout > > On Tue, 2009-09-15 at 20:56 +0200, Luke Howard wrote: >> For review: >> >> http://k5wiki.kerberos.org/wiki/Projects/Lockout >> >> Note: code is not well tested (in case of LDAP, untested). > > I think there is some discussion about lockout policies (probably in > the > password policy discussion) for LDAP in the ldap workgroup. > > Instead of having only the last failed and a count of failed > authentication attempts it would be probably better to have a list of > authentication failures/success with a timestamp. > This would be not only multimaster friendly (when using LDAP as a > backend) but would allow for better reporting if needed. > > It also allows to change policies on the fly because you have all the > data available to recalculate the status an account "should" be. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev > -- www.padl.com | www.fghr.net From hartmans at MIT.EDU Wed Sep 16 08:38:52 2009 From: hartmans at MIT.EDU (Sam Hartman) Date: Wed, 16 Sep 2009 08:38:52 -0400 Subject: Naming extensions In-Reply-To: (Luke Howard's message of "Tue\, 15 Sep 2009 19\:25\:49 +0200") References: Message-ID: I'm very interested in this project. If you get good enough review before then, definitely do not block on me. However my time is going to be tight until first week in October. If you are having trouble getting sufficient review before then I will be available at that point. --Sam From lukeh at padl.com Wed Sep 16 08:45:52 2009 From: lukeh at padl.com (Luke Howard) Date: Wed, 16 Sep 2009 14:45:52 +0200 Subject: Naming extensions In-Reply-To: References: Message-ID: On 16/09/2009, at 2:38 PM, Sam Hartman wrote: > I'm very interested in this project. If you get good enough review > before then, definitely do not block on me. However my time is going > to be tight until first week in October. If you are having trouble > getting sufficient review before then I will be available at that > point. That's fine with me, I'm mostly busy with other (non-Kerberos) projects until the end of the month. -- Luke From tlyu at MIT.EDU Wed Sep 16 12:39:58 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 16 Sep 2009 12:39:58 -0400 Subject: kerberos.org migrated (Re: kerberos.org (including k5wiki and blog) migration 09/16) In-Reply-To: (Tom Yu's message of "Mon, 14 Sep 2009 21:37:09 -0400") References: Message-ID: I completed the migration of the kerberos.org web server earlier this morning. Please let me know if you experience problems that might have resulted from this migration. A TCP forwarder will remain in place on the old IP address for at least a few more days, though the new DNS record should have fully propagated by now. From Peter.Shoults at Sun.COM Wed Sep 16 14:21:27 2009 From: Peter.Shoults at Sun.COM (Peter Shoults) Date: Wed, 16 Sep 2009 14:21:27 -0400 Subject: [Fwd: LDAP & Kerberos interaction & SIGPIPE] Message-ID: <4AB12CA7.9040708@sun.com> Hi, Was told to forward this along to this alias as well.... pete -------- Original Message -------- Subject: LDAP & Kerberos interaction & SIGPIPE Date: Wed, 16 Sep 2009 10:48:06 -0400 From: Peter Shoults To: kerberos-discuss Hi, Customer has brought forward an issue they were having with Kerberos and LDAP, where LDAP is being used to store the database information for Kerberos. The issue is that if the LDAP server is restarted for any reason, then Kerberos does not automatically resync back with the LDAP server when the LDAP server is back up and running. Specifically, one can run and login into kadmin, but any commands that are run will fail with the error: "Communication failure with server while retrieving list." It turns out if the user exits from kadmin and logs back in a second time, then the command do work fine. I have determined that the cause of this problem is that when the LDAP server is restarted, all the connections we have on port 636 to the LDAP server go into a CLOSE_WAIT/FIN_WAIT_2 state. When we log into kadmin, we attempt to contact the LDAP server on these connections, and we received SIGPIPE in response to our writes. Here is a snippet from truss: 3200/1: 57.2401 write(14, 0x0010B810, 23) Err#32 EPIPE 3200/1: 150301\012941A 60F Y P87A7BE9318B6 c8C |0F v 3200/1: 57.2404 Received signal #13, SIGPIPE [caught] This is fine - the sig_pipe handler is invoked and we do print out the syslog message. However, we never reset the signal disposition for SIGPIPE. kadmind process immediately proceeds to try the next connection to the LDAP server, and again gets SIGPIPE. This time though, the default handler is invoked, which terminates kadmind. At this point, SMF realizes kadmind has died and restarts it, which re-establishes all our connections to the LDAP server and that explains why a subsequent login to kadmin will work. I have two questions about this. The first why do we have a handler for SIGPIPE in the kadmin code, unlike the krb5kdc code, which sets SIGPIPE disposition to SIG_IGNORE. This handler in the kadmin code has not changed in a long long time. I tested setting SIGPIPE to SIG_IGN and this does allow a user to enter commands into kadmin after LDAP server restarts and run commands without issue. Assuming we have the SIGPIPE handler specifically to output the syslog message, then I propose that we have in the handler a resetting of the signal disposition to sig_pipe. I have also tested this fix and verified that this also resolves the problem and allows the user to enter kadmin commands after LDAP server restarts. Here is my change: file modified is ovsec_kadmd.c void sig_pipe(int unused) { + signal(SIGPIPE, sig_pipe); krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " "probably a client aborted. Continuing.")); } Pete From thomas.harning at trustbearer.com Wed Sep 16 14:47:39 2009 From: thomas.harning at trustbearer.com (Thomas Harning Jr.) Date: Wed, 16 Sep 2009 14:47:39 -0400 Subject: MIT Kerberos - FIPS Validation Message-ID: Just wondering, has there been any work to make a FIPS-validated MIT Kerberos client implementation? I'm guessing that there is some built-in crypto in MIT Kerberos, or do I have that wrong? If the crypto is not built-into MIT Kerberos client, is it implemented by OpenSSL or some other cryptography library? -- Thomas Harning Jr. From tsitkova at MIT.EDU Wed Sep 16 22:57:14 2009 From: tsitkova at MIT.EDU (Zhanna Tsitkova) Date: Wed, 16 Sep 2009 22:57:14 -0400 Subject: MIT Kerberos - FIPS Validation In-Reply-To: References: Message-ID: <42553961FD54AE41BF83834CB917221F0313454598@w92expo2.exchange.mit.edu> It is work in progress. Please, see Crypto Modularity proj @ http://k5wiki.kerberos.org/wiki/Projects/Crypto_modularity Zhanna ________________________________________ From: krbdev-bounces at MIT.EDU [krbdev-bounces at MIT.EDU] On Behalf Of Thomas Harning Jr. [thomas.harning at trustbearer.com] Sent: Wednesday, September 16, 2009 2:47 PM To: krbdev at mit.edu Subject: MIT Kerberos - FIPS Validation Just wondering, has there been any work to make a FIPS-validated MIT Kerberos client implementation? I'm guessing that there is some built-in crypto in MIT Kerberos, or do I have that wrong? If the crypto is not built-into MIT Kerberos client, is it implemented by OpenSSL or some other cryptography library? -- Thomas Harning Jr. _______________________________________________ krbdev mailing list krbdev at mit.edu https://mailman.mit.edu/mailman/listinfo/krbdev From Nicolas.Williams at sun.com Mon Sep 21 11:21:14 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 21 Sep 2009 10:21:14 -0500 Subject: Lockout In-Reply-To: References: Message-ID: <20090921152114.GH1033@Sun.COM> On Tue, Sep 15, 2009 at 08:56:47PM +0200, Luke Howard wrote: > For review: > > http://k5wiki.kerberos.org/wiki/Projects/Lockout - Comment #1 " Replication ... For LDAP backends, we always attempt to update the lockout count; we assume the LDAP client library can chase referrals, or that it is multi-master. Ideally the administrator should be able to configure some attributes on the LDAP server as non-replicated, but doing so is vendor-specific. " I don't know about OpenLDAP, but Mozilla libldap does not automatically chase referrals. Also, it's the DS that has to be multi-master, no? In any case, I think it's simpler to just say that in the LDAP case you assume that the server is smart enough to ensure replication and atomicity. (Note that LDAP does provide for some degree of atomicity.) - Comment #2 What's really desired here is a way to slow down password guessing attacks. Account "lockout" is just what this technique evolved from. If we look at "account lockout" from this p.o.v. then we see that we don't really need to replicate any of the account lockout principal record fields -- replication would only add to the infrastructure's burden and would only marginally help in the real goal. But we must not forget about the other kind of password guessing attack: where the attacker is trying to guess usernames and passwords, or has a list of usernames and is trying to guess passwords for any one of them. Detecting password guessing attempts per-principal is easy because we already have a record to base it on (in the KDB). Detecting password guessing attempts spread across multiple principals is clearly harder (and the available responses more limited), but probably worth doing as a follow on. Which brings me to: - Comment #3 Do we really need to write the account lockout fields to the KDB? It seems like a waste of time, literally -- assuming that KDB writes involve fsync()s, doing any such writes will surely increase latency, quite likely significantly so. Of course, keeping account lockout state in memory is not necessarily the right answer either, not without a fixed size to the in-core account lockout DB and LRU/LFU eviction. The necessary code infrastructure is missing from the KDC, so the KDB approach is clearly the most expedient. Can you characterize the impact on KDC performance of account lockout? Yes, flash devices can be used to accelerate synchronous writes, so one shouldn't mind any extra fsync()s here. But it seems worth noting. Nico -- From rra at stanford.edu Mon Sep 21 14:12:04 2009 From: rra at stanford.edu (Russ Allbery) Date: Mon, 21 Sep 2009 11:12:04 -0700 Subject: Lockout In-Reply-To: <20090921152114.GH1033@Sun.COM> (Nicolas Williams's message of "Mon, 21 Sep 2009 10:21:14 -0500") References: <20090921152114.GH1033@Sun.COM> Message-ID: <87my4ob217.fsf@windlord.stanford.edu> Nicolas Williams writes: > What's really desired here is a way to slow down password guessing > attacks. Account "lockout" is just what this technique evolved from. This is partly out of context and I suspect the end solution will work for this regardless, but to mention: I don't know about others who are looking at this feature, but what Stanford would need is account lockout, even if it's not effective at slowing down password guessing attacks. That's because the requirement is regulatory, not technical. The security standards with which we have to comply (specifically PCI) names account lockout specifically, not just techniques to slow down password guessing. -- Russ Allbery (rra at stanford.edu) From Nicolas.Williams at sun.com Mon Sep 21 14:16:27 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Mon, 21 Sep 2009 13:16:27 -0500 Subject: Lockout In-Reply-To: <87my4ob217.fsf@windlord.stanford.edu> References: <20090921152114.GH1033@Sun.COM> <87my4ob217.fsf@windlord.stanford.edu> Message-ID: <20090921181627.GJ1033@Sun.COM> On Mon, Sep 21, 2009 at 11:12:04AM -0700, Russ Allbery wrote: > Nicolas Williams writes: > > > What's really desired here is a way to slow down password guessing > > attacks. Account "lockout" is just what this technique evolved from. > > This is partly out of context and I suspect the end solution will work for > this regardless, but to mention: I don't know about others who are looking > at this feature, but what Stanford would need is account lockout, even if > it's not effective at slowing down password guessing attacks. That's > because the requirement is regulatory, not technical. The security > standards with which we have to comply (specifically PCI) names account > lockout specifically, not just techniques to slow down password guessing. I'm quite aware of the regulatory nature of the requirement. But from a real security point of view the correct requirement should be to detect and mitigate password guessing attacks. Nico -- From lukeh at padl.com Mon Sep 21 18:11:13 2009 From: lukeh at padl.com (Luke Howard) Date: Tue, 22 Sep 2009 00:11:13 +0200 Subject: Lockout In-Reply-To: <20090921152114.GH1033@Sun.COM> References: <20090921152114.GH1033@Sun.COM> Message-ID: > I don't know about OpenLDAP, but Mozilla libldap does not > automatically > chase referrals. Also, it's the DS that has to be multi-master, > no? In > any case, I think it's simpler to just say that in the LDAP case you > assume that the server is smart enough to ensure replication and > atomicity. (Note that LDAP does provide for some degree of > atomicity.) Right. Chasing referrals with authentication requires you to provide a rebind callback. I'm not sure whether the default is to chase them anonymously or not (in OpenLDAP I expect this can be set in ldap.conf), but that's pretty irrelevant to a KDC which will likely authenticate to the LDAP server. -- Luke From Nicolas.Williams at sun.com Thu Sep 24 13:05:09 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 24 Sep 2009 12:05:09 -0500 Subject: Delegated creds and SPNEGO In-Reply-To: <20090924140353.GA8310@twisp.few.eur.nl> References: <20090924140353.GA8310@twisp.few.eur.nl> Message-ID: <20090924170509.GW1033@Sun.COM> On Thu, Sep 24, 2009 at 04:03:53PM +0200, pk wrote: > > So, I'm wondering: was this fixed correctly? Is the expectation that, > > when using pseudo-mechanisms, you will acquire credentials for the > > pseudo-mechanism or for the concrete mechanism? If it's the former, > > well, it doesn't work right now. I ask because it impacts some other > > work. > > Given `src_name' is mechanism specific and `mech_type' also contains > the actually chosen mechanism, returning a mechanism specific delegated > credential would be by far the most sensible thing to do. > > > See also my post to the krbdev list from May 22, 2007 for an alternative > fix, which is cleaner, IMHO, because it avoids hard-coding the > SPNEGO OID and allows the composite/stacked mechamism implementation > to decide what to return. Please see the rest of this thread. The simplest thing to do w.r.t. delegated credential in the mechglue is this: if the mechanism returned an actual_mech other than the mechanism's OID, then assume that the delegated credential is already a mechglue object. In other words: assume that pseudo-mechanisms re-enter the _same_ mechglue [as the one calling the pseudo-mechanisms] in order to call other mechanisms, and that pseudo-mechanisms will return a mechglue gss_cred_id_t object when the actual_mech != the OID from the initial context token. The same need not apply to src_name; it could be made to apply, but it's not necessary. In the case of src_name, as with all other mechanism- specific objects, the mechglue will assume that the object returned by the mechanism is allocated by the mechanism itself and therefore must be wrapped by the mechglue. (There's a slight change to the above to account for stackable mechanisms. See the rest of this thread.) This approach does not result in hardcoding of mechanism OIDs in the mechglue. It is a heuristic based on what you might call an ABI requirement imposed by a system's mechglue, specifically: that pseudo-mechanisms must re-enter the same mechglue that is calling them in order to invoke other mechanisms from inside a pseudo-mechanism. This is a very reasonable requirement to impose, though it implies a requirement that pseudo-mechanisms be able to find the mechglue to re-enter. If one wishes to have pseudo-mechanisms be mechglue-like and call directly into other mechanisms then one can adjust the above scheme accordingly ("deleg cred is a mechanism-level object for the actual_mech, not for the pseudo-mechanism"), with a similar requirement resulting: the mechglue and pseudo-mechanisms must use the same mechanism providers. Nico -- From kranenburg at ese.eur.nl Thu Sep 24 10:03:53 2009 From: kranenburg at ese.eur.nl (pk) Date: Thu, 24 Sep 2009 16:03:53 +0200 Subject: Delegated creds and SPNEGO Message-ID: <20090924140353.GA8310@twisp.few.eur.nl> > So, I'm wondering: was this fixed correctly? Is the expectation that, > when using pseudo-mechanisms, you will acquire credentials for the > pseudo-mechanism or for the concrete mechanism? If it's the former, > well, it doesn't work right now. I ask because it impacts some other > work. Given `src_name' is mechanism specific and `mech_type' also contains the actually chosen mechanism, returning a mechanism specific delegated credential would be by far the most sensible thing to do. See also my post to the krbdev list from May 22, 2007 for an alternative fix, which is cleaner, IMHO, because it avoids hard-coding the SPNEGO OID and allows the composite/stacked mechamism implementation to decide what to return. --pk From Peter.Shoults at Sun.COM Fri Sep 25 08:59:31 2009 From: Peter.Shoults at Sun.COM (Peter Shoults) Date: Fri, 25 Sep 2009 08:59:31 -0400 Subject: LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <4AB0FAA6.1090408@sun.com> References: <4AB0FAA6.1090408@sun.com> Message-ID: <4ABCBEB3.10703@sun.com> I am sending this out again as the customer has tested a fix I provided and determined that it does resolve their issue. I would like to move forward with a fix, and the one I am using now is the one mentioned below with the addition of signal(). If I can get some comments, I would appreciate it. Otherwise - I guess I will just proceed to put this into Solaris code. Pete On 09/16/09 10:48, Peter Shoults wrote: > Hi, > > Customer has brought forward an issue they were having with Kerberos and > LDAP, where LDAP is being used to store the database information for > Kerberos. The issue is that if the LDAP server is restarted for any > reason, then Kerberos does not automatically resync back with the LDAP > server when the LDAP server is back up and running. Specifically, one > can run and login into kadmin, but any commands that are run will fail > with the error: > > "Communication failure with server while retrieving list." > > It turns out if the user exits from kadmin and logs back in a second > time, then the command do work fine. > > I have determined that the cause of this problem is that when the LDAP > server is restarted, all the connections we have on port 636 to the LDAP > server go into a CLOSE_WAIT/FIN_WAIT_2 state. When we log into kadmin, > we attempt to contact the LDAP server on these connections, and we > received SIGPIPE in response to our writes. Here is a snippet from truss: > > 3200/1: 57.2401 write(14, 0x0010B810, 23) > Err#32 EPIPE > 3200/1: 150301\012941A 60F Y P87A7BE9318B6 > c8C |0F v > 3200/1: 57.2404 Received signal #13, SIGPIPE [caught] > > This is fine - the sig_pipe handler is invoked and we do print out the > syslog message. However, we never reset the signal disposition for > SIGPIPE. kadmind process immediately proceeds to try the next > connection to the LDAP server, and again gets SIGPIPE. This time > though, the default handler is invoked, which terminates kadmind. At > this point, SMF realizes kadmind has died and restarts it, which > re-establishes all our connections to the LDAP server and that explains > why a subsequent login to kadmin will work. > > I have two questions about this. The first why do we have a handler for > SIGPIPE in the kadmin code, unlike the krb5kdc code, which sets SIGPIPE > disposition to SIG_IGNORE. This handler in the kadmin code has not > changed in a long long time. I tested setting SIGPIPE to SIG_IGN and > this does allow a user to enter commands into kadmin after LDAP server > restarts and run commands without issue. > > Assuming we have the SIGPIPE handler specifically to output the syslog > message, then I propose that we have in the handler a resetting of the > signal disposition to sig_pipe. I have also tested this fix and > verified that this also resolves the problem and allows the user to > enter kadmin commands after LDAP server restarts. Here is my change: > > file modified is ovsec_kadmd.c > > void > sig_pipe(int unused) > { > + signal(SIGPIPE, sig_pipe); > krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " > "probably a client aborted. Continuing.")); > } > > > Pete > > From tlyu at MIT.EDU Fri Sep 25 12:50:38 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 25 Sep 2009 12:50:38 -0400 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <4ABCBEB3.10703@sun.com> (Peter Shoults's message of "Fri, 25 Sep 2009 08:59:31 -0400") References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> Message-ID: Peter Shoults writes: > I am sending this out again as the customer has tested a fix I provided > and determined that it does resolve their issue. I would like to move > forward with a fix, and the one I am using now is the one mentioned > below with the addition of signal(). If I can get some comments, I > would appreciate it. Otherwise - I guess I will just proceed to put > this into Solaris code. > > Pete Is there a reason to not use sigaction() here if possible? That should make things more portable than calling signal(). > On 09/16/09 10:48, Peter Shoults wrote: >> Hi, >> >> Customer has brought forward an issue they were having with Kerberos and >> LDAP, where LDAP is being used to store the database information for >> Kerberos. The issue is that if the LDAP server is restarted for any >> reason, then Kerberos does not automatically resync back with the LDAP >> server when the LDAP server is back up and running. Specifically, one >> can run and login into kadmin, but any commands that are run will fail >> with the error: >> >> "Communication failure with server while retrieving list." >> >> It turns out if the user exits from kadmin and logs back in a second >> time, then the command do work fine. >> >> I have determined that the cause of this problem is that when the LDAP >> server is restarted, all the connections we have on port 636 to the LDAP >> server go into a CLOSE_WAIT/FIN_WAIT_2 state. When we log into kadmin, >> we attempt to contact the LDAP server on these connections, and we >> received SIGPIPE in response to our writes. Here is a snippet from truss: >> >> 3200/1: 57.2401 write(14, 0x0010B810, 23) >> Err#32 EPIPE >> 3200/1: 150301\012941A 60F Y P87A7BE9318B6 >> c8C |0F v >> 3200/1: 57.2404 Received signal #13, SIGPIPE [caught] >> >> This is fine - the sig_pipe handler is invoked and we do print out the >> syslog message. However, we never reset the signal disposition for >> SIGPIPE. kadmind process immediately proceeds to try the next >> connection to the LDAP server, and again gets SIGPIPE. This time >> though, the default handler is invoked, which terminates kadmind. At >> this point, SMF realizes kadmind has died and restarts it, which >> re-establishes all our connections to the LDAP server and that explains >> why a subsequent login to kadmin will work. >> >> I have two questions about this. The first why do we have a handler for >> SIGPIPE in the kadmin code, unlike the krb5kdc code, which sets SIGPIPE >> disposition to SIG_IGNORE. This handler in the kadmin code has not >> changed in a long long time. I tested setting SIGPIPE to SIG_IGN and >> this does allow a user to enter commands into kadmin after LDAP server >> restarts and run commands without issue. >> >> Assuming we have the SIGPIPE handler specifically to output the syslog >> message, then I propose that we have in the handler a resetting of the >> signal disposition to sig_pipe. I have also tested this fix and >> verified that this also resolves the problem and allows the user to >> enter kadmin commands after LDAP server restarts. Here is my change: >> >> file modified is ovsec_kadmd.c >> >> void >> sig_pipe(int unused) >> { >> + signal(SIGPIPE, sig_pipe); >> krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " >> "probably a client aborted. Continuing.")); >> } >> >> >> Pete >> >> > > _______________________________________________ > kerberos-discuss mailing list > kerberos-discuss at opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss From Nicolas.Williams at sun.com Fri Sep 25 12:44:30 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 25 Sep 2009 11:44:30 -0500 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <4ABCBEB3.10703@sun.com> References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> Message-ID: <20090925164430.GI1033@Sun.COM> On Fri, Sep 25, 2009 at 08:59:31AM -0400, Peter Shoults wrote: > > Assuming we have the SIGPIPE handler specifically to output the syslog > > message, then I propose that we have in the handler a resetting of the > > signal disposition to sig_pipe. I have also tested this fix and > > verified that this also resolves the problem and allows the user to > > enter kadmin commands after LDAP server restarts. Here is my change: > > > > file modified is ovsec_kadmd.c > > > > void > > sig_pipe(int unused) > > { > > + signal(SIGPIPE, sig_pipe); > > krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " > > "probably a client aborted. Continuing.")); > > } That's not reliable. Use reliable signals instead (i.e., use sigaction(2) and clear the SA_RESETHAND flag). Nico -- From tlyu at MIT.EDU Fri Sep 25 13:17:00 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 25 Sep 2009 13:17:00 -0400 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <20090925164430.GI1033@Sun.COM> (Nicolas Williams's message of "Fri, 25 Sep 2009 12:44:30 -0400") References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> <20090925164430.GI1033@Sun.COM> Message-ID: Nicolas Williams writes: > On Fri, Sep 25, 2009 at 08:59:31AM -0400, Peter Shoults wrote: >> > Assuming we have the SIGPIPE handler specifically to output the syslog >> > message, then I propose that we have in the handler a resetting of the >> > signal disposition to sig_pipe. I have also tested this fix and >> > verified that this also resolves the problem and allows the user to >> > enter kadmin commands after LDAP server restarts. Here is my change: >> > >> > file modified is ovsec_kadmd.c >> > >> > void >> > sig_pipe(int unused) >> > { >> > + signal(SIGPIPE, sig_pipe); >> > krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " >> > "probably a client aborted. Continuing.")); >> > } > > That's not reliable. Use reliable signals instead (i.e., use > sigaction(2) and clear the SA_RESETHAND flag). I was puzzled at why sigaction() was not being used to set up the SIGPIPE handler, and it looks like the MIT code is using sigaction(), but OpenSolaris is not, for some reason. From Nicolas.Williams at sun.com Fri Sep 25 13:16:19 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 25 Sep 2009 12:16:19 -0500 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <4ABCFA2D.1090907@sun.com> References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> <4ABCFA2D.1090907@sun.com> Message-ID: <20090925171618.GK1033@Sun.COM> On Fri, Sep 25, 2009 at 01:13:17PM -0400, Peter Shoults wrote: > I used signal() because that is what is being used in this file as it > exists now, so I did it to maintain a standard look/feel. That the existing code uses signal() instead of sigaction() should be considered a bug. I say: just fix it :) From Nicolas.Williams at sun.com Fri Sep 25 13:17:18 2009 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Fri, 25 Sep 2009 12:17:18 -0500 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> <20090925164430.GI1033@Sun.COM> Message-ID: <20090925171718.GL1033@Sun.COM> On Fri, Sep 25, 2009 at 01:17:00PM -0400, Tom Yu wrote: > I was puzzled at why sigaction() was not being used to set up the > SIGPIPE handler, and it looks like the MIT code is using sigaction(), > but OpenSolaris is not, for some reason. My guess: MIT fixed this eons ago and we didn't. The fork of this particular bit of code may go back to the late 90s. Nico -- From Peter.Shoults at Sun.COM Fri Sep 25 13:13:17 2009 From: Peter.Shoults at Sun.COM (Peter Shoults) Date: Fri, 25 Sep 2009 13:13:17 -0400 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> Message-ID: <4ABCFA2D.1090907@sun.com> On 09/25/09 12:50, Tom Yu wrote: > Peter Shoults writes: > > >> I am sending this out again as the customer has tested a fix I provided >> and determined that it does resolve their issue. I would like to move >> forward with a fix, and the one I am using now is the one mentioned >> below with the addition of signal(). If I can get some comments, I >> would appreciate it. Otherwise - I guess I will just proceed to put >> this into Solaris code. >> >> Pete >> > > Is there a reason to not use sigaction() here if possible? That > should make things more portable than calling signal(). > > I used signal() because that is what is being used in this file as it exists now, so I did it to maintain a standard look/feel. >> On 09/16/09 10:48, Peter Shoults wrote: >> >>> Hi, >>> >>> Customer has brought forward an issue they were having with Kerberos and >>> LDAP, where LDAP is being used to store the database information for >>> Kerberos. The issue is that if the LDAP server is restarted for any >>> reason, then Kerberos does not automatically resync back with the LDAP >>> server when the LDAP server is back up and running. Specifically, one >>> can run and login into kadmin, but any commands that are run will fail >>> with the error: >>> >>> "Communication failure with server while retrieving list." >>> >>> It turns out if the user exits from kadmin and logs back in a second >>> time, then the command do work fine. >>> >>> I have determined that the cause of this problem is that when the LDAP >>> server is restarted, all the connections we have on port 636 to the LDAP >>> server go into a CLOSE_WAIT/FIN_WAIT_2 state. When we log into kadmin, >>> we attempt to contact the LDAP server on these connections, and we >>> received SIGPIPE in response to our writes. Here is a snippet from truss: >>> >>> 3200/1: 57.2401 write(14, 0x0010B810, 23) >>> Err#32 EPIPE >>> 3200/1: 150301\012941A 60F Y P87A7BE9318B6 >>> c8C |0F v >>> 3200/1: 57.2404 Received signal #13, SIGPIPE [caught] >>> >>> This is fine - the sig_pipe handler is invoked and we do print out the >>> syslog message. However, we never reset the signal disposition for >>> SIGPIPE. kadmind process immediately proceeds to try the next >>> connection to the LDAP server, and again gets SIGPIPE. This time >>> though, the default handler is invoked, which terminates kadmind. At >>> this point, SMF realizes kadmind has died and restarts it, which >>> re-establishes all our connections to the LDAP server and that explains >>> why a subsequent login to kadmin will work. >>> >>> I have two questions about this. The first why do we have a handler for >>> SIGPIPE in the kadmin code, unlike the krb5kdc code, which sets SIGPIPE >>> disposition to SIG_IGNORE. This handler in the kadmin code has not >>> changed in a long long time. I tested setting SIGPIPE to SIG_IGN and >>> this does allow a user to enter commands into kadmin after LDAP server >>> restarts and run commands without issue. >>> >>> Assuming we have the SIGPIPE handler specifically to output the syslog >>> message, then I propose that we have in the handler a resetting of the >>> signal disposition to sig_pipe. I have also tested this fix and >>> verified that this also resolves the problem and allows the user to >>> enter kadmin commands after LDAP server restarts. Here is my change: >>> >>> file modified is ovsec_kadmd.c >>> >>> void >>> sig_pipe(int unused) >>> { >>> + signal(SIGPIPE, sig_pipe); >>> krb5_klog_syslog(LOG_NOTICE, gettext("Warning: Received a SIGPIPE; " >>> "probably a client aborted. Continuing.")); >>> } >>> >>> >>> Pete >>> >>> >>> >> _______________________________________________ >> kerberos-discuss mailing list >> kerberos-discuss at opensolaris.org >> http://mail.opensolaris.org/mailman/listinfo/kerberos-discuss >> From Peter.Shoults at Sun.COM Fri Sep 25 13:40:18 2009 From: Peter.Shoults at Sun.COM (Peter Shoults) Date: Fri, 25 Sep 2009 13:40:18 -0400 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <20090925171718.GL1033@Sun.COM> References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> <20090925164430.GI1033@Sun.COM> <20090925171718.GL1033@Sun.COM> Message-ID: <4ABD0082.7090303@sun.com> On 09/25/09 13:17, Nicolas Williams wrote: > On Fri, Sep 25, 2009 at 01:17:00PM -0400, Tom Yu wrote: > >> I was puzzled at why sigaction() was not being used to set up the >> SIGPIPE handler, and it looks like the MIT code is using sigaction(), >> but OpenSolaris is not, for some reason. >> > > My guess: MIT fixed this eons ago and we didn't. The fork of this > particular bit of code may go back to the late 90s. > > Nico > That did not get picked up on the re-syncs? OK - fine - I will open a new CR about the signal() to sigaction(). If I change to sigaction() are we all good with the fix as proposed? From tlyu at MIT.EDU Fri Sep 25 14:00:57 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Fri, 25 Sep 2009 14:00:57 -0400 Subject: [kerberos-discuss] LDAP & Kerberos interaction & SIGPIPE In-Reply-To: <4ABD0082.7090303@sun.com> (Peter Shoults's message of "Fri, 25 Sep 2009 13:40:18 -0400") References: <4AB0FAA6.1090408@sun.com> <4ABCBEB3.10703@sun.com> <20090925164430.GI1033@Sun.COM> <20090925171718.GL1033@Sun.COM> <4ABD0082.7090303@sun.com> Message-ID: Peter Shoults writes: > On 09/25/09 13:17, Nicolas Williams wrote: > > On Fri, Sep 25, 2009 at 01:17:00PM -0400, Tom Yu wrote: > > > I was puzzled at why sigaction() was not being used to set up the > SIGPIPE handler, and it looks like the MIT code is using sigaction(), > but OpenSolaris is not, for some reason. > > > > My guess: MIT fixed this eons ago and we didn't. The fork of this > particular bit of code may go back to the late 90s. > > Nico > > > > That did not get picked up on the re-syncs? > > OK - fine - I will open a new CR about the signal() to sigaction(). If I > change to sigaction() are we all good with the fix as proposed? Correctly using sigaction() for establishing the handlers will obviate the need to call signal() from inside the handlers. From remi.ferrand at cc.in2p3.fr Tue Sep 29 04:31:16 2009 From: remi.ferrand at cc.in2p3.fr (Remi Ferrand) Date: Tue, 29 Sep 2009 10:31:16 +0200 Subject: Hack Kerberos / AFS Message-ID: <4AC1C5D4.8040903@cc.in2p3.fr> Hye, I need help to create a little hack on Kerberos / AFS. My final aim is to forge Tokens (Ticket Granting Server for AFS (Andrew File System)) without any passwords from the users (directly with the Master Key). Our production system works as follow : - the client SSH onto a machine and is granted an AFS Token obtained with aklog. At this very step, the user have the Ticket Granting Ticket krbtgt/REALM at REALM ticket and the afs/cell at REALM Ticket Granting Service. It also have an AFS Token obtained with aklog. - the user will then submit a job to our Batch system. - the job will be processed X hours/minutes later and could last a long time. Our problem is that some jobs could last more than the AFS token lifetime. Once this lifetime is expired, jobs could not access AFS filesystems anymore and will abort. My idea is to implement a new functionnality to our Batch system: the capacity of "Token regeneration". My first idea was to : * store the Master Key K/M at REALM in a KeyTab. * store the TGT somewhere once the user has been granted the TGT (on the client side). * once the Token is going to expire, I would like to read the K/M from the KeyTab and use it to decrypt the user TGT stored at the previous step. * once the user TGT has been decrypted with the K/M I will then be able to modify expiration time and other fields. I still have many questions about details: * the stash file is used to decrypt the DataBase, isn't it ? * Every DataBase entry is crypted with the Master Key, isn't it ? * On the KDC side, the TGT is decrypted with the Master Key in the DataBase (is this the K/M at REALM entry ?) * when the TGT is in the client cache, the TGT is encrypted with the user password, isn't it ? * If I have my K/M in a KeyTab, am I able to decrypt the TGT stored in the client cache ? Is this possible ? Any other is accepted... Thanks in advance for your help :) -- 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/20090929/78202e3f/smime.bin From simon at sxw.org.uk Tue Sep 29 05:00:00 2009 From: simon at sxw.org.uk (Simon Wilkinson) Date: Tue, 29 Sep 2009 11:00:00 +0200 Subject: Hack Kerberos / AFS In-Reply-To: <4AC1C5D4.8040903@cc.in2p3.fr> References: <4AC1C5D4.8040903@cc.in2p3.fr> Message-ID: On 29 Sep 2009, at 10:31, Remi Ferrand wrote: > Hye, > > I need help to create a little hack on Kerberos / AFS. You'd be much better off asking this question on the openafs-devel list, to which I've directed follows. This is definitely off-topic for krb-devel, and is actually not particularly Kerberos dependent at all. > My final aim is to forge Tokens (Ticket Granting Server for AFS > (Andrew File System)) without any passwords from the users (directly > with the Master Key). You don't need to use the Kerberos master key for this - you can forge AFS tokens using just the afs/@ key that's stored in your servers keyfiles. The daemon that lives behind gssklog already forges AFS tokens - that's probably a good location to look for code. Hope that helps, Simon. > Our production system works as follow : > - the client SSH onto a machine and is granted an AFS Token obtained > with aklog. > At this very step, the user have the Ticket Granting Ticket krbtgt/ > REALM at REALM ticket and the afs/cell at REALM Ticket Granting Service. > It also have an AFS Token obtained with aklog. > - the user will then submit a job to our Batch system. > - the job will be processed X hours/minutes later and could last a > long time. > > Our problem is that some jobs could last more than the AFS token > lifetime. > Once this lifetime is expired, jobs could not access AFS filesystems > anymore and will abort. > > My idea is to implement a new functionnality to our Batch system: > the capacity of "Token regeneration". > My first idea was to : > * store the Master Key K/M at REALM in a KeyTab. > * store the TGT somewhere once the user has been granted the TGT (on > the client side). > * once the Token is going to expire, I would like to read the K/M > from the KeyTab and use it to decrypt the user TGT stored at the > previous step. > * once the user TGT has been decrypted with the K/M I will then be > able to modify expiration time and other fields. > > I still have many questions about details: > * the stash file is used to decrypt the DataBase, isn't it ? > * Every DataBase entry is crypted with the Master Key, isn't it ? > * On the KDC side, the TGT is decrypted with the Master Key in the > DataBase (is this the K/M at REALM entry ?) > * when the TGT is in the client cache, the TGT is encrypted with the > user password, isn't it ? > * If I have my K/M in a KeyTab, am I able to decrypt the TGT stored > in the client cache ? > > Is this possible ? > Any other is accepted... > > Thanks in advance for your help :) > > > -- > > 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/ > > ________________________________________________ > Kerberos mailing list Kerberos at mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos From Volker.Lendecke at SerNet.DE Tue Sep 29 04:40:19 2009 From: Volker.Lendecke at SerNet.DE (Volker Lendecke) Date: Tue, 29 Sep 2009 10:40:19 +0200 Subject: Hack Kerberos / AFS In-Reply-To: <4AC1C5D4.8040903@cc.in2p3.fr> References: <4AC1C5D4.8040903@cc.in2p3.fr> Message-ID: On Tue, Sep 29, 2009 at 10:31:16AM +0200, Remi Ferrand wrote: > Is this possible ? > Any other is accepted... You might want to install Samba with the fake-kaserver option and look at the net afs key and net afs impersonate commands. Volker -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 197 bytes Desc: Digital signature Url : http://mailman.mit.edu/pipermail/krbdev/attachments/20090929/0a76fa47/attachment.bin From shadow at gmail.com Tue Sep 29 05:04:44 2009 From: shadow at gmail.com (Derrick Brashear) Date: Tue, 29 Sep 2009 05:04:44 -0400 Subject: [OpenAFS-devel] Re: Hack Kerberos / AFS In-Reply-To: References: <4AC1C5D4.8040903@cc.in2p3.fr> Message-ID: On Tue, Sep 29, 2009 at 5:00 AM, Simon Wilkinson wrote: > > On 29 Sep 2009, at 10:31, Remi Ferrand wrote: > >> Hye, >> >> I need help to create a little hack on Kerberos / AFS. > > You'd be much better off asking this question on the openafs-devel list, to > which I've directed follows. This is definitely off-topic for krb-devel, and > is actually not particularly Kerberos dependent at all. > >> My final aim is to forge Tokens (Ticket Granting Server for AFS (Andrew >> File System)) without any passwords from the users (directly with the Master >> Key). > > You don't need to use the Kerberos master key for this - you can forge AFS > tokens using just the afs/@ key that's stored in your servers > keyfiles. The daemon that lives behind gssklog already forges AFS tokens - > that's probably a good location to look for code. aklog includes such a thing based on heimdal kimpersonate From jmontmartin at gmail.com Wed Sep 30 09:38:34 2009 From: jmontmartin at gmail.com (Julien Montmartin) Date: Wed, 30 Sep 2009 15:38:34 +0200 Subject: Kerberos for Windows (kfw) and GSS-API in native 64 bit Message-ID: Hi List, I'm working on an application server which will run on various flavour of Windows and Unix OS, and need to support Integrated Windows Authentication (IWA) to do SSO with Windows domain clients. I've written some code that works on Linux, using GSS-API. Now I'm porting this code on the Windows plateform. My first attempt was to get 'Kerberos for Windows' kfw-3.2.2 sdk, and compile/link with it. It works well... in 32 bit mode ! 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 : "Kerberos for Windows 3.2 is designed for 32-bit versions of Windows 2000, XP, 2003, 2003 R2, Vista and WOW64 environments. Native 64-bit Windows XP, 2003, and Vista applications are not being distributed as part of this release." As expected, WOW64 doesn't do the job for me, I really need native 64 bit. - Are there any known issues with kfw in native 64 bit mode (which would explain why it's not officially supported) ? Are there any plans to support it in the near future ? - Did any one manage to get it works in 64 bit by recompiling the sources ? - Are there other solutions to get GSS-API on windows 64 bit plateform ? And if not, any pointer to help me to port my GSS-API code to Microsoft SSPI ? Thanks, Julien From tlyu at MIT.EDU Wed Sep 30 16:00:41 2009 From: tlyu at MIT.EDU (Tom Yu) Date: Wed, 30 Sep 2009 16:00:41 -0400 Subject: Kerberos for Windows (kfw) and GSS-API in native 64 bit In-Reply-To: (Julien Montmartin's message of "Wed, 30 Sep 2009 09:38:34 -0400") References: Message-ID: Julien Montmartin writes: > Hi List, > > I'm working on an application server which will run on various flavour of > Windows and Unix OS, and need to support Integrated Windows Authentication > (IWA) to do SSO with Windows domain clients. > > I've written some code that works on Linux, using GSS-API. Now I'm porting > this code on the Windows plateform. My first attempt was to get 'Kerberos > for Windows' kfw-3.2.2 sdk, and compile/link with it. It works well... in 32 > bit mode ! > > 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 > : > > "Kerberos for Windows 3.2 is designed for 32-bit versions of Windows 2000, > XP, 2003, 2003 R2, Vista and WOW64 environments. Native 64-bit Windows XP, > 2003, and Vista applications are not being distributed as part of this > release." > > As expected, WOW64 doesn't do the job for me, I really need native 64 bit. > > - Are there any known issues with kfw in native 64 bit mode (which would > explain why it's not officially supported) ? Are there any plans to support > it in the near future ? 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 > - Did any one manage to get it works in 64 bit by recompiling the sources ? > > - Are there other solutions to get GSS-API on windows 64 bit plateform ? And > if not, any pointer to help me to port my GSS-API code to Microsoft SSPI ? > > Thanks, > > Julien > _______________________________________________ > krbdev mailing list krbdev at mit.edu > https://mailman.mit.edu/mailman/listinfo/krbdev