All good suggestions.
Apparently the packets were going back to the KDC (I assume AS) not
some other registry or service, so I'm thinking maybe it wasn't
another service. I'm leaning towards a broken implementation as the
explanation.
I'll try to have a look at the sniffed packets to see what it's
Thanks for your help Luke.
Cheers,
Tc.
Tony Cowan - IBM SWG Services. ([EMAIL PROTECTED])
Phone: (206) 675 0095 Cell: (206) 280 6942
There is no tomorrow. Only a succession of todays. Don't wait too long to
figure tha
Thanks.
Tony Cowan - IBM SWG Services. ([EMAIL PROTECTED])
Phone: (206) 675 0095 Cell: (206) 280 6942
There is no tomorrow. Only a succession of todays. Don't wait too long to
figure that out.
|-+>
| | &q
Hi Jacques,
Thanks for this info.
I'm not familiar with the releases ... is the Heimdal GSSAPI library
something from which many others were derived?
I'm using a java JGSS implementation.
Thanks for your time.
Tc.
Tony Cowan - IBM SWG Services. ([EMAIL PROTECTED])
Phone: (206) 675
ervice key, and also why it would make sense that only some
priveleged service have access to the one key. I don't quite get why the
LSA has to visit the KDC if it has the service key
Thanks for the tip.
As an aside, I'm working with a java JGSS-API implementation.
Thanks,
Tc.
Tony
> No, that's the beauty of Kerberos.
Thanks Luke.
Someone tells me they've been sniffing and found that one particular
implementation does in fact hit the KDC to validate the ticket.
I wonder if it's actually hitting the KDC for some other purpose.
Getting further information perhaps .. I guess th
Sorry if this is a bit newbie ..
This is my hypothetical scenario:
I have a client process that authenticates to the KDC.
I get a TGT as part of that transaction I think.
I go back to the TGS with my TGT and get a ticket to access some service.
Now that service ticket should be encrypted with a k
