Re: Getting two service principals, one of them with an empty realm

[Rahul Amaram]

Thanks for the response.

Regards,
Rahul.

On Wednesday 09 June 2010 07:27 AM, Tom Yu wrote:
> Rahul Amaram  writes:
>
>> Hi,
>> I did not get any response for this query. If nobody has an idea, I was
>> planning to submit this a bug report. Looking forward to a response.
>>
>> Thanks,
>> Rahul.
>>
>> On Wednesday 02 June 2010 11:59 AM, Rahul Amaram wrote:
>>> Hi,
>>> I am strangely getting two service principals for every service I use
>>> and one of them has an empty realm. Below is a sample output.
>>>
>>> $ klist
>>> Ticket cache: FILE:/tmp/krb5cc_1001_Xc3DVv
>>> Default principal: xxx...@synovel.com
>>>
>>> Valid starting ExpiresService principal
>>> 06/02/10 11:45:07  06/02/10 21:45:07  krbtgt/synovel@synovel.com
>>>renew until 06/03/10 11:44:57
>>> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel.com@
>>>renew until 06/03/10 11:44:57
>>> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel@synovel.com
>>>renew until 06/03/10 11:44:57
>
> This is expected behavior that is a side effect of the way that
> service principal realm referrals work.  The empty realm name
> indicates that the realm of the principal is unknown.  A copy of the
> ticket is present in the cache under its actual service principal name
> and realm to allow both referral and non-referral lookups to work.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Getting two service principals, one of them with an empty realm

[Tom Yu]

Rahul Amaram  writes:

> Hi,
> I did not get any response for this query. If nobody has an idea, I was 
> planning to submit this a bug report. Looking forward to a response.
>
> Thanks,
> Rahul.
>
> On Wednesday 02 June 2010 11:59 AM, Rahul Amaram wrote:
>> Hi,
>> I am strangely getting two service principals for every service I use
>> and one of them has an empty realm. Below is a sample output.
>>
>> $ klist
>> Ticket cache: FILE:/tmp/krb5cc_1001_Xc3DVv
>> Default principal: xxx...@synovel.com
>>
>> Valid starting ExpiresService principal
>> 06/02/10 11:45:07  06/02/10 21:45:07  krbtgt/synovel@synovel.com
>>   renew until 06/03/10 11:44:57
>> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel.com@
>>   renew until 06/03/10 11:44:57
>> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel@synovel.com
>>   renew until 06/03/10 11:44:57

This is expected behavior that is a side effect of the way that
service principal realm referrals work.  The empty realm name
indicates that the realm of the principal is unknown.  A copy of the
ticket is present in the cache under its actual service principal name
and realm to allow both referral and non-referral lookups to work.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Tom Yu]

Russ Allbery  writes:

> Adam Megacz  writes:
>> Russ Allbery  writes:
>
>>> Check the host/* principal on the system to which you were
>>> authenticating.  I bet that the REQUIRES_PRE_AUTH flag was set for it,
>>> which means that only tickets that are pre-authenticated can
>>> authenticate to that service principal.
>
>> Indeed, that was it!  Russ saves the day again.
>
> The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
> one authenticates rather than principals one authenticates as always
> strikes me as surprising, unexpected, and unintuitive.

We are open to suggestions about how to remedy this behavior.  I think
it stems from the KDB flag REQUIRES_PRE_AUTH being overloaded with two
mostly unrelated meanings: (1) require preauthentication when the
specified client obtains initial tickets; (2) require that any
client's service ticket have the "preauthenticated" flag set when
presented to a specified service.

How many people have a security policy that requires behavior (2)
above?  If so, is it necessary to conflate that behavior with behavior
(1)?

>> Curious: I assume that the failure mode here is some variation on the
>> sshd machine asking the KDC for a delegation and the KDC refusing.
>
> I believe it fails even if you're not doing delegation.  I believe the KDC
> refuses to issue you a service ticket for a principal with
> REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated.  But
> I don't remember the details of the research that I did when I ran into
> this.  (We just cleared that flag from principals like host/* principals
> and moved on with our lives; given that they're randomly generated keys,
> hopefully brute force attacks are difficult anyway.)

That matches my recollection, but I haven't examined the relevant code
recently.

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Simon Wilkinson]

On 8 Jun 2010, at 22:05, Russ Allbery wrote:
>> In general I find that sshd really does a very poor job explaining the
>> reason why things went wrong when it comes to Kerberos/GSSAPI.  I've got
>> some free cycles this summer that I can put towards fixing that if it's
>> something that can be fixed.
> 
> I haven't looked at the code personally, but what I recall from what other
> people have said is that the code is structured so that doing proper error
> reporting is fairly difficult.

There's a few factors at play here.

Firstly, the client only reports GSSAPI errors if it's run with the -v flag. 
This was a requirement when the code was originally pulled into OpenSSH, as 
they wanted to avoid alarming users who knew nothing about Kerberos/GSSAPI with 
the opaque error messages produced by GSSAPI at the time. Fixing this would be 
fairly straightforwards - getting those fixes into OpenSSH, less so.

Secondly, GSSAPI libraries have historically produced pretty poor error 
messages "See etext for details" being a great example of this. The only way to 
solve this is to improve the information that comes out of your library. I 
think MIT have done some recent work on this.

Thirdly, there's no communication of server errors back to the client. This is 
partly deliberate, as telling the client why an operation failed can, in some 
environments, be an information leak. My original GSSAPI patch had support for 
sending this information, based on configuration settings. When I was trying to 
get the GSSAPI code into OpenSSH, this was one of the things that got dropped 
in order to reduce code complexity.

>  It can also quite hard to get OpenSSH upstream to take GSSAPI-related 
> patches, depending on how those patches strike them.

Unless you have the patience and perseverance of Sisyphus, I wouldn't even 
consider trying to get GSSAPI code into OpenSSH. Success in getting even small, 
platform compatibility based changes into the upstream distribution has been 
geologically slow at best.

Cheers,

Simon.



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Russ Allbery]

Adam Megacz  writes:
> Russ Allbery  writes:

>> Check the host/* principal on the system to which you were
>> authenticating.  I bet that the REQUIRES_PRE_AUTH flag was set for it,
>> which means that only tickets that are pre-authenticated can
>> authenticate to that service principal.

> Indeed, that was it!  Russ saves the day again.

The behavior caused by setting REQUIRES_PRE_AUTH on principals to which
one authenticates rather than principals one authenticates as always
strikes me as surprising, unexpected, and unintuitive.

> Curious: I assume that the failure mode here is some variation on the
> sshd machine asking the KDC for a delegation and the KDC refusing.

I believe it fails even if you're not doing delegation.  I believe the KDC
refuses to issue you a service ticket for a principal with
REQUIRES_PRE_AUTH set if your TGT is not tagged as preauthenticated.  But
I don't remember the details of the research that I did when I ran into
this.  (We just cleared that flag from principals like host/* principals
and moved on with our lives; given that they're randomly generated keys,
hopefully brute force attacks are difficult anyway.)

> Does the refusal include enough information to produce an error message
> (either in the sshd log or elsewhere) mentioning this as the reason for
> the failure?

ssh (well, OpenSSH) never reports useful error messages by default for
anything related to GSSAPI.

> In general I find that sshd really does a very poor job explaining the
> reason why things went wrong when it comes to Kerberos/GSSAPI.  I've got
> some free cycles this summer that I can put towards fixing that if it's
> something that can be fixed.

I haven't looked at the code personally, but what I recall from what other
people have said is that the code is structured so that doing proper error
reporting is fairly difficult.  It can also quite hard to get OpenSSH
upstream to take GSSAPI-related patches, depending on how those patches
strike them.

-- 
Russ Allbery (r...@stanford.edu) 

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: GSSAPIDelegateCredentials only works for REQUIRES_PRE_AUTH principals?

[Adam Megacz]

Russ Allbery  writes:
> Check the host/* principal on the system to which you were authenticating.
> I bet that the REQUIRES_PRE_AUTH flag was set for it, which means that
> only tickets that are pre-authenticated can authenticate to that service
> principal.

Indeed, that was it!  Russ saves the day again.

Curious: I assume that the failure mode here is some variation on the
sshd machine asking the KDC for a delegation and the KDC refusing.  Does
the refusal include enough information to produce an error message
(either in the sshd log or elsewhere) mentioning this as the reason for
the failure?

In general I find that sshd really does a very poor job explaining the
reason why things went wrong when it comes to Kerberos/GSSAPI.  I've got
some free cycles this summer that I can put towards fixing that if it's
something that can be fixed.

  - a


Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Getting two service principals, one of them with an empty realm

[Marcus Watts]

> Date:Tue, 08 Jun 2010 13:20:17 +0530
> To:  kerberos@MIT.EDU
> From:Rahul Amaram 
> Subject: Re: Getting two service principals, one of them with an empty realm
> 
> Hi,
> I did not get any response for this query. If nobody has an idea, I was 
> planning to submit this a bug report. Looking forward to a response.
> 
> Thanks,
> Rahul.
> 
> On Wednesday 02 June 2010 11:59 AM, Rahul Amaram wrote:
> > Hi,
> > I am strangely getting two service principals for every service I use
> > and one of them has an empty realm. Below is a sample output.
> >
> > $ klist
> > Ticket cache: FILE:/tmp/krb5cc_1001_Xc3DVv
> > Default principal: xxx...@synovel.com
> >
> > Valid starting ExpiresService principal
> > 06/02/10 11:45:07  06/02/10 21:45:07  krbtgt/synovel@synovel.com
> >   renew until 06/03/10 11:44:57
> > 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel.com@
> >   renew until 06/03/10 11:44:57
> > 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel@synovel.com
> >   renew until 06/03/10 11:44:57
> >
> >
> > Kerberos 4 ticket cache: /tmp/tkt1001
> > klist: You have no tickets cached
> >
> >
> > The hostname to realm mapping and realm kdc details are obtained
> > completely through DNS (using TXT and SRV records).
> >
> > Any help in this regard would be appreciated.
> >
> >
> > Regards,
> > Rahul.
> > 
> > Kerberos mailing list   Kerberos@mit.edu
> > https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Ok.  I have some suggestions, but I was really hoping somebody else could
give you a better answer.  Here's how I would go about investigating this,

/1/ collect together all relevant krb5.conf and dns information.  That is,
*everything* your client sees should be in one concise report.
So, contents of krb5.conf
dns SRV records for {_kerberos,_kerberos-master}.{_tcp,_udp}.SYNOVEL.COM

/2/ verify this happens with "kvno" too, not just applications.
You report "every service"--what's important here is
the library that application is calling.  Since "kvno" does no
application stuff whatsoever, it's the purest way to reproduce this problem.

/3/ do one, or better yet, both of the following:
strace (or truss, or ktrace, or ... depending on your OS).
tcpdump (or snoop, or ...)
For tcpdump, use -tt -p -s 2000 -X -v

do this for both kinit and kvno.

Look at:
/a/ what krb5.conf(s) did it *really* open?
Most libraries will try several places.
/b/ k5 traffic.  What kdcs did it try to talk to?
What did it get back?
/c/ DNS traffic - what did it really try to lookup?

The k5 stuff is wire encoded as ASN.1.  It is possible to decode
this using some perl glop and "openssl asn1parse".
See ``/afs/umich.edu/user/m/d/mdw/bin/tcp2pem.pl'' for an out-dated
and badly documented example of how to do this.  (you might have to use
tcpdump -x not -X if you use this script without changes.)

/4/ Now look at the logs on each kdc it talked to.  What's recorded there?

The entry with an '@' and no domain looks like a weird referal record.
Points to consider:
is windows involved here?
do you have "domain_realm" records in krb5.conf?
is there something consistently weird about the service host
to realm mapping?

/4a/ kdb and kdc data
does the service principal with no realm actually exist in your kdb?

What's in krb5.conf and kdc.conf on the kdc?

/5/ experiment with crafting a krb5.conf file with "dns_fallback" false,
and seeing if varying the contents can reproduce the behavior,
or suppress the behavior.  Both cases are of interest.

/6/ At this point, if the answer is not somehow obvious to me,
I'd be resorting to "gdb" on whichever part(s) were doing something
I didn't understand.  I'd be hoping that something in krb5.conf
dns, tcpdump, or strace would be looking "weird" and would give me a
clue about where to look.  The results of varying krb5.conf
should certainly give me a starting point: the dns logic at the very
least if I can't cause the behavior to appear.

In your case - if you are not a C programmer, well, I told you my
answer might suck.

/8/ when reporting problems, for klist, do "klist -fea".
Also consider doing:
getprinc on client principal
getprinc on service principal(s).

/9/ when reporting problems, include: exact client software version and
architecture.  Ie, if an rpm, what rpm.  If building from source, which
version of MIT source.  Also host operating sytem version and cpu architecture.

/10/ when reporting problems, include: exact server software version and
architecture.  Ie, if an rpm, what rpm.  If building from source, which
version of MIT source.  Also host operating sytem version and cpu architecture.

/11/ when reporting *bugs*, you should include sufficient details
that somebody else can reproduce your problem.

/12/

Help Needed for Kerberos token retrieval using GSS API

[Aditya]

Hello Sir,

I am not sure whether this is correct forum or not but..

Can you please let me know that how can I write JDK 1.6 program to retrieve 
Kerberos token of the logged in user? I am very new to this technology. 
After reading few articles I am not able to understand, how I can do it at my 
machine(stand alone Windows XP machine).

Your inputs can help me a lot.


Regards,
Aditya

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: bug?: erroneous start time for max renewable life check

[Jeffrey Altman]

On 5/17/2010 7:37 PM, Richard Johnson wrote:
>
> The misbehavior:
>
> When a TGT with the Renewable flag set is used to obtain an ftp or host ticket
> on an MIT Kerberos client, that ftp or host service ticket also has the
> Renewable flag set.  I call this misbehavior as it seems nonsensical.  If an
> ftp or host service ticket is expired, a new one will be obtained; there's no
> need to make them renewable.

It would only be nonsensical if the assumption that the obtained service
ticket would never be used
without possession of the TGT.A renewable service ticket permits
that ticket to be handed off
to a process which is meant to do a specific task (local or remote)
without the dangers inherent in
delegating a TGT.

Jeffrey Altman



Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

Re: Getting two service principals, one of them with an empty realm

[Rahul Amaram]

Hi,
I did not get any response for this query. If nobody has an idea, I was 
planning to submit this a bug report. Looking forward to a response.

Thanks,
Rahul.

On Wednesday 02 June 2010 11:59 AM, Rahul Amaram wrote:
> Hi,
> I am strangely getting two service principals for every service I use
> and one of them has an empty realm. Below is a sample output.
>
> $ klist
> Ticket cache: FILE:/tmp/krb5cc_1001_Xc3DVv
> Default principal: xxx...@synovel.com
>
> Valid starting ExpiresService principal
> 06/02/10 11:45:07  06/02/10 21:45:07  krbtgt/synovel@synovel.com
>   renew until 06/03/10 11:44:57
> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel.com@
>   renew until 06/03/10 11:44:57
> 06/02/10 11:45:27  06/02/10 21:45:07  imap/scs.synovel@synovel.com
>   renew until 06/03/10 11:44:57
>
>
> Kerberos 4 ticket cache: /tmp/tkt1001
> klist: You have no tickets cached
>
>
> The hostname to realm mapping and realm kdc details are obtained
> completely through DNS (using TXT and SRV records).
>
> Any help in this regard would be appreciated.
>
>
> Regards,
> Rahul.
> 
> Kerberos mailing list   Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos

Kerberos mailing list   Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos