Kerberos AS-REQ

[Yang Li]

Thanks Douglas For your clarification.

I am using MIT Kerberos for window http://web.mit.edu/kerberos/dist/#kfw-3.2

is there a way to enforce a specific KDC in windows?

Thanks, -Yang



-----Original Message-----
From: Douglas E. Engert [mailto:deengert at anl.gov] 
Sent: Friday, May 14, 2010 3:09 PM
To: Yang Li
Cc: 'mark'; kerberos at mit.edu
Subject: Re: Kerberos AS-REQ



Yang Li wrote:
> Thanks Mark!
> 
> I didn't realize it is case sensitive, but I try with HTTP, the same
error. 
>

Kerberos is case sensitive, Windows AD KDC are case insensitive, but will
try an preserve the case.

> one follow-up question, in our environment, we have multiple KDC, is there
a
> way to specify which KDC Kvno or Kinit can connect to? The odd thing is,
> although I can't get the HTTP service ticket by kinit or kvno,
browser(IE)
> can get it when doing http request ( verified by using klist after
browsing
> in IE), but IE hits a different KDC. So i want a way to enforce them to
hit
> the same KDC. Any suggestions?
> 

Sounds like you are using Windows. What version of the Kerberos programs
are you using? Microsoft has Klist and Kinit program and so does Java.
You might be using one of these.

If you where on Unix, copy your krb5.conf file, and edit it to list only
the specific KDC. export KRB5_CONFIG=edited.krb5.conf





> 
> Thanks, -Yang
> 
> 
> 
> 
> -----Original Message-----
> From: mark [mailto:mark at mproehl.net] 
> Sent: Friday, May 14, 2010 11:19 AM
> To: kerberos at mit.edu; sharepointlink at hotmail.com
> Subject: Re: Kerberos AS-REQ
> 
> Hi,
> 
> you can get tickets for any service principal by sending a AS-REQ with
> kinit. By default kinit requests TGTs (i.e. service tickets for
> krbtgt/REALM at REALM). -S overides this behaviour. So "kinit -S 
> HTTP/server.domain at REALM"
> should just get you an initial service ticket for the HTTP service on
> server.domain instead of a TGT.
> 
> If you just want to check if the KDC can issue service tickets for
> HTTP/server.domain by TGS-REQ, you can use "kvno HTTP/server.domain"
> after doing a kinit.
> 
> I wonder why the server name in your wireshark is written lowercase
> (http/server.domain instead of  HTTP/server.domain). Could that be the
> reason for PRINCIPAL_UNKNOWN error?
> 
> Regards,
> 
> Mark Pröhl
> 
> On 05/14/2010 04:38 PM, Yang Li wrote:
>> When I run Kinit -S HTTP/server.domain.  KDC returns with
> PRINCIAPL_UNKNOWN
>> error.
>>
>>
>> >From WireShark, I can see client makes a (KRB 5 )AS-REQ to KDC, but its
>> KDC_REQ_BODY has the server name (principal) as http/server.domain. is
> this
>> the right behavior? should client sends krbtgt/domain in its request to
> KDC
>> instead? My understanding is the purpose of AS-REQ is only to get TGT?
can
>> someone help me understand this?
>>
>> Thanks, -Yang
>>
>>
>>
>> -----Original Message-----
>> From: Tom Parker [mailto:tparker at cbnco.com] 
>> Sent: Wednesday, May 12, 2010 1:40 PM
>> To: Yang Li
>> Cc: 'Russ Allbery'; kerberos at mit.edu
>> Subject: Re: error message after kdestroy
>>
>> klist should always fail after a kdestroy
>>
>> kinit should work fine to get you a new TGT
>>
>> On 05/12/2010 01:32 PM, Yang Li wrote:
>>   
>>> Thanks Russ for your response.
>>>
>>> What puzzle me is, this behavior is not consistent. Most of time, after
>>> kdestroy, either klist or kinit can still get TGT ticket, but i did get
>>>     
>> the
>>   
>>> error message sometimes after kdestroy, is that odd?
>>>
>>> Thanks, -Yang
>>>
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: kerberos-bounces at mit.edu [mailto:kerberos-bounces at mit.edu] On
> Behalf
>>> Of Russ Allbery
>>> Sent: Wednesday, May 12, 2010 12:43 PM
>>> To: kerberos at mit.edu
>>> Subject: Re: error message after kdestroy
>>>
>>> "Yang Li" <sharepointlink at hotmail.com> writes:
>>>
>>>   
>>>     
>>>> after kdestroy command, i get the following error message on any other
>>>> commands such as klist or kinit. Any idea?
>>>>     
>>>>       
>>>   
>>>     
>>>> No credentials cache found while getting default ccache
>>>>     
>>>>       
>>> Well... yes.  kdestroy destroys the credential cache, so the other
>>> commands now no longer have a credential cache to work with.  That's the
>>> whole point of kdestroy.
>>>
>>>   
>>>     
>> ________________________________________________
>> Kerberos mailing list           Kerberos at mit.edu
>> https://mailman.mit.edu/mailman/listinfo/kerberos
>>   
> 
> 
> 
> ________________________________________________
> Kerberos mailing list           Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 
> 

-- 

  Douglas E. Engert  <DEEngert at anl.gov>
  Argonne National Laboratory
  9700 South Cass Avenue
  Argonne, Illinois  60439
  (630) 252-5444