Nothing wrong with what you suggest, but in theory the conf-
>krb_save_credentials value doesn't need to be checked.
In practice, who knows? Lots of bugs out there.
On Jul 26, 2007, at 1:38 PM, Achim Grolms wrote:
> On Thursday 26 July 2007 21:54, Douglas E. Engert wrote:
>> Achim Grolms wrot
Miguel Sanders wrote:
> Dear all
>
> I managed to do cross realm authentication between AD realm A and MIT
> realm B.
> However this only works if, hosts in realm B, have "default_realm =A"
> in their krb5.conf. I have some problems with this since there are
> quit a lot of other principals in r
On Thursday 26 July 2007 21:54, Douglas E. Engert wrote:
> Achim Grolms wrote:
> > On Thursday 26 July 2007 20:40, Henry B. Hotz wrote:
> >>> If I understand RFC2744 correct GSS_C_DELEG_FLAG
> >>> would not be set in that case?
> >>>
> >>> Achim
> >>
> >> Agreed. That flag shouldn't be set AFAIK,
On Jul 26, 2007, at 8:22 AM, Douglas E. Engert wrote:
> Attached is the Wireshark print output of the GET request showing
> the SPNEGO and GSSAPI
>
> In original trace, the client does request a ticket to delegate
> but it looks like it is not delegating it.
>
> It looks like it is:
> User-Agent:
On Thursday 26 July 2007 20:40, Henry B. Hotz wrote:
> > If I understand RFC2744 correct GSS_C_DELEG_FLAG
> > would not be set in that case?
> >
> > Achim
>
> Agreed. That flag shouldn't be set AFAIK, though the value isn't
> valid until negotiation is complete.
That means before trying to store
Miguel Sanders <[EMAIL PROTECTED]> writes:
> I managed to do cross realm authentication between AD realm A and MIT
> realm B. However this only works if, hosts in realm B, have
> "default_realm =A" in their krb5.conf. I have some problems with this
> since there are quit a lot of other principals
Dear all
I managed to do cross realm authentication between AD realm A and MIT
realm B.
However this only works if, hosts in realm B, have "default_realm =A"
in their krb5.conf. I have some problems with this since there are
quit a lot of other principals in realm B...
Perhaps a setting in krb5.c
Achim Grolms wrote:
> On Thursday 26 July 2007 20:40, Henry B. Hotz wrote:
>
>>> If I understand RFC2744 correct GSS_C_DELEG_FLAG
>>> would not be set in that case?
>>>
>>> Achim
>> Agreed. That flag shouldn't be set AFAIK, though the value isn't
>> valid until negotiation is complete.
>
> Tha
On Jul 26, 2007, at 11:28 AM, Achim Grolms wrote:
> On Thursday 26 July 2007 20:16, Douglas E. Engert wrote:
>> Achim Grolms wrote:
>
>>> From my point of view that means we can exclude the item
>>> "Client sends nothing as delegated credeatials" because from
>>> my point of view the logging mean
Mikkel Kruse Johnsen wrote:
> Hi Douglas
>
> I have already done all these steps.
It still looks like the client is not delegating. and I am out of ideas.
>
> I'm currently on linux only to eliminate trust relations and the windows
> factor :)
>
> I'm on Fedora 7 getting a ticket from MIT k
On Thursday 26 July 2007 20:16, Douglas E. Engert wrote:
> Achim Grolms wrote:
> > From my point of view that means we can exclude the item
> > "Client sends nothing as delegated credeatials" because from
> > my point of view the logging means *something* is received.
>
> No, the trace showed tha
On Thursday 26 July 2007 19:41, Douglas E. Engert wrote:
> Mikkel Kruse Johnsen wrote:
> > Hi Douglas
> >
> > I have already done all these steps.
>
> It still looks like the client is not delegating.
I am not sure if this idea works
but maybe you (Mikkel) can give it a try?
>From my point of vi
One more idea...
Achim Grolms wrote:
> On Thursday 26 July 2007 19:41, Douglas E. Engert wrote:
>> Mikkel Kruse Johnsen wrote:
>>> Hi Douglas
>>>
>>> I have already done all these steps.
>> It still looks like the client is not delegating.
>
> I am not sure if this idea works
> but maybe you (Mi
Hi Douglas
I have already done all these steps.
I'm currently on linux only to eliminate trust relations and the windows
factor :)
I'm on Fedora 7 getting a ticket from MIT kerberos and accessing a web
site using the same MIT kerberos.
I regularly try on windows, It don't work either (have done
Attached is the Wireshark print output of the GET request showing
the SPNEGO and GSSAPI
In original trace, the client does request a ticket to delegate
but it looks like it is not delegating it.
It looks like it is:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.5) Gecko/20070718
Hi Douglas
Im not sure what to look for, but here is the dump. If you are able to
see anything. Done with wireshark.
/Mikkel
On Wed, 2007-07-25 at 09:36 -0500, Douglas E. Engert wrote:
> Looks like it should have worked.
>
> A wireshark trace of the packets would show a lot, as long as
> the s
Hi Achim
With the patch applied:
[Thu Jul 26 16:05:21 2007] [debug] src/mod_auth_kerb.c(1451): [client
130.226.36.170] kerb_authenticate_user entered with user (NULL) and
auth_type Kerberos
[Thu Jul 26 16:05:21 2007] [debug] src/mod_auth_kerb.c(1451): [client
130.226.36.170] kerb_authenticate_use
Hello all,
Im trying to compile krb5-1.6.2 on AIX 5.3 with gcc 4. Everything
works well up until it hits the rpc/unit-test and then the make crashes.
It gives
Target "all" is up to date.
gcc -L../../../lib -Wl,-blibpath:/opt/krb5/lib::/usr/lib:/lib -g
-O2 -Wall -Wmissing-prototypes -Wca
18 matches
Mail list logo
