Simon Wilkinson writes:
> On 3 Mar 2010, at 21:16, Russ Allbery wrote:
>> Well, bear in mind that one of the goals of rxgk is to have per-server
>> credentials, so that someone can set up an AFS file server without
>> getting the keys to the entire cell. This means that a client may have
>> to a
On 3 Mar 2010, at 21:16, Russ Allbery wrote:
Well, bear in mind that one of the goals of rxgk is to have per-server
credentials, so that someone can set up an AFS file server without
getting
the keys to the entire cell. This means that a client may have to
authenticate separately with each
Andrew Deason writes:
> Jeffrey Altman wrote:
>> As with any Kerberos based GSSAPI mechanism there needs to be a
>> credential cache. Even klog.krb5 uses a credential cache. It just
>> destroys the contents of the cache it creates after it is finished.
> This is what I didn't know. That seems
On Wed, 03 Mar 2010 15:53:24 -0500
Jeffrey Altman wrote:
> rxgk is not Kerberos based. Kerberos happens to be one of the
> authentication mechanisms that can be used via a GSSAPI mechanism to
> produce rxgk tokens. The others that will be available will include
> the GSI GSSAPI mechanism which
Jeffrey Altman writes:
> As with any Kerberos based GSSAPI mechanism there needs to be a
> credential cache. Even klog.krb5 uses a credential cache. It just
> destroys the contents of the cache it creates after it is finished. The
> difference is that klog.krb5 is capable of directly requestin
On 3/3/2010 3:32 PM, Andrew Deason wrote:
> On Wed, 3 Mar 2010 18:36:25 +
> Simon Wilkinson wrote:
>
>> On 3 Mar 2010, at 18:28, Russ Allbery wrote:
>>
>>> Why wouldn't klog.krb5 be applicable to rxgk, at least in the
>>> abstract (doing the work is another matter)? It's just the
>>> combina
Andrew Deason writes:
> I'm not familiar with this area of the code at all, but are you saying
> you cannot acquire krb5 creds within an application, and (through some
> GSS hoops) pass it on to rxgk? That we must have a ticket cache (e.g.
> pointed to by KRB5CCNAME) available?
> I believe I am
On Wed, 3 Mar 2010 18:36:25 +
Simon Wilkinson wrote:
> On 3 Mar 2010, at 18:28, Russ Allbery wrote:
>
> > Why wouldn't klog.krb5 be applicable to rxgk, at least in the
> > abstract (doing the work is another matter)? It's just the
> > combination of a kinit and aklog without storing the cr
Simon Wilkinson writes:
> Actually, I'm not sure that GSSAPI will let us do this. A
> GSS_C_NT_HOSTBASED_SERVICE is defined as being "serv...@hostname", with
> no provision for specifying a realm.
> We could define the acceptor identity as a GSS_KRB5_NT_PRINCIPAL_NAME,
> but that completely ties
On 3 Mar 2010, at 19:13, Russ Allbery wrote:
Er, many OpenAFS users do not have simple control over their Kerberos
configuration without duplicating it and setting environment
variables.
And for debugging purposes, it's obnoxious to have to make a
separate copy
of krb5.conf and mess around
Simon Wilkinson writes:
> aklog will work in exactly the same way as aklog always has. We don't
> need any explicit Kerberos knowledge there, because we're just another
> GSSAPI application at that point. If something breaks us, then it will
> also break every other GSSAPI application under the s
On 3 Mar 2010, at 18:46, Russ Allbery wrote:
In practice, at least 95% of our users are going to be using Kerberos.
Making the common case go more smoothly is a good idea, and that
includes
at least documenting things like how you make aklog use a different
ticket
cache and possibly some Ke
Simon Wilkinson writes:
> Because rxgk doesn't care what GSSAPI mechanism is being used to get the
> initial credentials. The tools that AFS provides assume that a set of
> credentials are available (from Kerberos, from GSI, from a local smart
> card ...), and simply does GSSAPI calls from then o
On 3 Mar 2010, at 18:28, Russ Allbery wrote:
Simon Wilkinson writes:
It might be, but I think documenting multiple ways of doing things is
likely to be confusing to a novice user. We should pick one mechanism
and stick to it, and aklog is probably the best one to choose. In
addition, klog.kr
Simon Wilkinson writes:
> It might be, but I think documenting multiple ways of doing things is
> likely to be confusing to a novice user. We should pick one mechanism
> and stick to it, and aklog is probably the best one to choose. In
> addition, klog.krb5 won't be applicable to rxgk, but aklog
On 3 Mar 2010, at 18:12, Andrew Deason wrote:
On Wed, 3 Mar 2010 09:31:26 -0800 (PST)
Booker Bense wrote:
1. Replace references to klog, with the kinit and aklog pair of
commands.
klog.krb5 may be worth mentioning, as it avoids having a
possibly-undesirable ticket cache lying around.
It
On Wed, 3 Mar 2010 09:31:26 -0800 (PST)
Booker Bense wrote:
> 1. Replace references to klog, with the kinit and aklog pair of
> commands.
klog.krb5 may be worth mentioning, as it avoids having a
possibly-undesirable ticket cache lying around.
--
Andrew Deason
adea...@sinenomine.net
_
17 matches
Mail list logo
