[30480] in Kerberos
Re: Trouble with service principal missing its realm
daemon@ATHENA.MIT.EDU (Rich McDonough)
Thu Nov 27 06:48:29 2008
Message-Id: <3936275F-8F3E-4115-A593-42E833B65BA7@worldgaming.com>
From: Rich McDonough <rich.mcdonough@worldgaming.com>
To: Tim Alsop <Tim.Alsop@CyberSafe.com>
In-Reply-To: <1A136DCE57F98F4B8BAB5FFC69C8E6DA21E4902A10@exchange.cybersafe.local>
Mime-Version: 1.0 (Apple Message framework v929.2)
Date: Thu, 27 Nov 2008 06:47:30 -0500
Cc: "kerberos@mit.edu" <kerberos@mit.edu>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu
That's an excellent question. Jeffery is right though - adding this to
my krb5.conf fixed the realm issue:
[domain_realm]
.staging.wg = STAGING.WG
staging.wg = STAGING.WG
.wg = STAGING.WG
wg = STAGING.WG
staging [joe@nms ~]$ klist
Ticket cache: FILE:/tmp/krb5cc_10000
Default principal: joe@STAGING.WG
Valid starting Expires Service principal
11/27/08 11:41:29 11/28/08 11:40:46 krbtgt/STAGING.WG@STAGING.WG
11/27/08 11:41:41 11/28/08 11:40:46 ldap/db.wg@STAGING.WG
On 27-Nov-08, at 4:26 AM, Tim Alsop wrote:
> Jeffrey,
>
> Regarding:
>
>> A service ticket in the credential cache without a realm name
>> is a service ticket that was obtained using server side referrals.
>> The actual realm name was not specified by the client when
>> requesting the service ticket.
>
> [Tim Alsop] Is the fact that there is no realm, a bug, or is the
> cache supposed to contain tickets without a realm in this scenario ?
> Surely if actual realm was not specified, when the actual realm is
> determined by KDC, and ticket issued, this realm should be used when
> putting the ticket in the client cache ? if not, why not ?
>
> Thanks,
> Tim
Rich McDonough
System Adminstrator
Worldgaming
rich.mcdonough@worldgaming.com
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
