[this is largely a kerberos question, but I am cross posting in case
anyone on the openafs mailing list may have had a similar experience]
We are having two problems with larger krb5 afs/service tickets.
Specifically when krb5_creds.ticket.length exceeds order of about 350
bytes we run into these
clearly sets auth_context with
KRB5_AUTH_CONTEXT_DO_SEQUENCE.
What am I missing?
>>>>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
>>>>> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes:
Cesar> wrt to gssapi and 1.3.1 ...
Cesa
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes:
>> It is also worth noting, that, while Heimdal is not thread safe (at least there
>> are no guarantees), it has proven to be much more thread-robust than MIT.
>> OpenLDAP page and a couple of users have expirienced problems with MIT and
Are you building your own app or is this from one of the stock
applications?
Can you provide a stack trace and other relevent details that you can
obtain from your debugger?
Which version of the kerberos libraries does this application use, did
you build your own are you using libraries provided
You can also inspect for which principal a service ticket was
acquired, on the client side via klist. Make sure there is a
corresponding keytab entry for this principal on the target host
(klist -k).
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes:
>>> GSSAPI accepted as authentication ty
This is really impractical, since most applications attempt to use
tickets for the default principal named in the ticket. Unless [all of]
your applications intend explicitly acquire credentials for a named
[client] principal, a single credential's cache is going to be
difficult.
My personal recomm
short:
There does not appear to be use of file locks when reading/writing to
replay cache files.
long:
We are implementing gss authentication via client and server side
security exits invoked by a vendor application. The application is
both multi-processed and multi-threaded. We have applied var
Hi,
I'm am trying to change the behavior of a functioning GSS-enabled
application server such that the server principal and corresponding
keytab entry used by gss_accept_sec_context is determined dynamically
based on the server principal named in the client's ticket (implicitly
specified by the in
Understood, I've just been delaying for no good reason.
I'll find time one of these weekends to submit various patches.
Thanks.
>>>>> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
>>>>> "Cesar" == Cesar Garcia <[EMAIL PR
in it's form was not compiled or tested, I just forged it
from actual working changes, but it looks correct. (it also includes a
one line fix for a memory leak).
>>>>> "Matthew" == Matthew Mauzy <[EMAIL PROTECTED]> writes:
Matthew> I found the following p
this bug. But with your
Klaas> patch, the krb524d works good together with openafs?
Klaas> Thanks Klaas - Original Message - From: "Cesar Garcia"
Klaas> <[EMAIL PROTECTED]> To: "Ken Hornstein"
Klaas> <[EMAIL PROTECTED]> Cc: "Cesar Garci
Not sure - I'm not exactly an AFS subject matter expert and I haven't
seen the AFS code that implements the key retrieval (from KeyFile)
and token validation.
When I first started looking at MIT's krb524, this was the first problem
we saw. [the 524 client setting the lifetimes incorrectly was the
There is also a bug in krb524d that does not set the kvno on the
returned V4 ticket. Here's a patch:
$ diff -c krb524d.c.orig krb524d.c
*** krb524d.c.orig Thu Oct 17 13:37:30 2002
--- krb524d.c Thu Oct 17 13:39:55 2002
***
*** 412,418
memset (key, 0, sizeof (*
We'll try this.
Thanks.
> "Sam" == Sam Hartman <[EMAIL PROTECTED]> writes:
Sam> The krb5 library is not thread safe. IN practice you may be able to
Sam> simply put a mutex around context setup (gss_init_sec_context and
Sam> gss_accept_sec_context) calls and be OK, but this is not guarantee
Hi,
I was wondering what the thread safety situation is with ligss and
underlying libraries.
We intend to use these apps in heavily threaded applications
(including middle tier servers that act as both security context
initiators and acceptors).
We seem to be running in to KRB5_FCC_INTERNAL "In
Part of our migration from NT to active directory involves cloning
NT user accounts to initialize the AD account (including the
password). This allows a user to log in to XP (a member of an
AD domain) using the cloned password, at least initially.
It's not clear whether the cloning mechanism all
> "Marcio" == Marcio d'Avila Scheibler <[EMAIL PROTECTED]> writes:
Marcio> Since we have a multi-realm KDC and in real life the same
Marcio> people will manage those realms, I'd like to give permissions
Marcio> to the same principal and if possible I wouldn't like
Marcio> create user/admin@RE
vno;
return 0;
} else if (use_master) {
return kdc_get_server_key(context, p, key, kvnop, ktype, kvno);
>>>>> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes:
Cesar> OK. I may have figured the error.
Cesar> Although the the ke
of 0.
>>>>> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes:
Cesar> This is not exactly a Kerberos specific issue, but perhaps
Cesar> the folks on this mailing list might have some insight.
Cesar> I decided for now to go with Ken's suggestion that
is machines, openafs 1.2.2 on our linux boxes.
AFS servers are solaris.
Before I go digging into this problem some more, I was wondering
if anyone might have some insight on this one.
Thanks in advance.
>>>>> "Cesar" == Cesar Garcia <[EMAIL PROTECTED]> writes:
Ce
> "Ken" == Ken Hornstein <[EMAIL PROTECTED]> writes:
>> Since we use NIS as the primary source for hostname
>> resolution, all host lookups render a single IP address,
>> even for multihomed machines. Moving to DNS is not an
>> option at the moment.
Ken> I have to ask ... you're STILL using
I've been working with 1.2.2 for a some months now, and only
recently have attempted to get the rcmds working, mainly in
an effort to better understand how ticket forwarding works,
since we have a need to do this in a homegrown application.
The behavior that I see is that when I invoke ticket
f
e kerberos libs are referencing the
global errno, instead of the thread specific errno which stat is
actually using. Hence your problem.
>>>>> "Christopher" == Christopher Burke <[EMAIL PROTECTED]> writes:
Christopher> [EMAIL PROTECTED] (Cesar Garcia) wrote in
I gather your application is multithreaded, or at least built
with threads in mind ...
You should build your kerberos libs with -D_REENTRANT.
At least in 1.2.2, the problem begins in src/util/profile/prof_file.c in the
profile_update_file method, where a stat is done to look for the
krb5.conf f
Actually they are sharing the details, but only for review/
analysis.
The Microsoft PAC specification is available at Microsoft's
web site, but subject to a rather prohibitive license.
http://www.microsoft.com/Downloads/Release.asp?ReleaseID=20597
Unfortunately, at least from my interpretation
Does anyone know if user to user is supported in
the MIT implementation of GSSAPI? or if there
are any plans for it.
Thanks.
smime.p7s
Description: S/MIME Cryptographic Signature
Hi,
I was just wondering if it was possible for an application
to specify an alternate keytab when obtaining credentials
(gss_acquire_cred) that will be used to accept a security
context (gss_accept_sec_context). If not, should I bother
to make changes to gssapi_krb5, or is expected to be in
the
27 matches
Mail list logo
