AD Domain Authentication to MIT Kerb V

[Douglas E. Engert]

Matt Joyce wrote:

> Douglas E. Engert wrote:
> 
>>
>>
>> Matt Joyce wrote:
>>
>>>>
>>>>
>>>> So when you login, do you type user at realm or just user?
>>>>
>>> just user.  The @ seemingly specifies a domain to login to. 
>>
>>
>>
>> No its the realm of the user. This machine knows what domain it is in.
>> So the first step it to authenticate to the user's realm, then
>> the libs will get cross realm tickets and finals a service ticket
>> for the machine from the machine's realm.
>>
> So it is still within the DOMAIN.COM domain not a seperate 
> REALM.DOMAIN.COM domain.  Okay That clears something up.
> If this is the case do I need to add host principles to the MIT Kerb V 
> kdc for the machines in the domain wishing to auth to the 
> REALM.FXSERVER.COM principles?  

No. The machine need only to be in one or the other.  But where
it gets a little tricky is that the client has to figure out
what realm the server is in so it can ask the correct realm for tickets.
That is where the referrals comes in. The Windows libs know how to
user referrals. The MIT libs can use the [realm_domain] section
of the krb5.ini file. But since you are using the Windows libs
and the hosts are in the domain, May be I should not have mentioned this.

> Do I need to join the REALM on the client boxes?  

Not sure what you mean.

You have three choices. The machine can be part of the domain,
in which case the admin has joined it to the domain. This
will cause it to have a kerberos host principal in the domain.
This is used to authenticate an login attempts to the machine
by a user using either Kerberos or the domain.
 From what I think you are trying to do this is the case.

The machine can have a kerberos principal in some realm
(or domain) but it is not a full domain. i.e. you used the
ksetup /setcomputerpassword as spelled out in the MS doc.
You can then user Windows login to login to the machine
as a local user, yet still have kerberos credentials.

The machine is not registerd at all. You can login as
a local user only. But you can use leach or runas to
get some tickets.


>Should I be seeing the REALM option in the domain list?  =(

What?

> Is there anything special I need to do to those client machines?

Assuming it is a domain workstaiton already, you may have to
run the ksetup /addkdc for the REALM.DOMAIN.COM  But if the MS
code can use the SRV records, you would not need this. Try it.


> 
> currently I am unable to login to user at REALM.DOMAIN.COM on anything but 
> the AD box.  Any suggestions as to why that might be?

When you say AD box, do you mean the ad server box or a box
in the domain?

The machine may need the mapuser but not sure, or the /addkdc

> 
>>> I cannot login to a Domain with a complete realm prinicpal without 
>>> inadvertental telling windows to login to som alternate domain... 
>>
>>
>>
>> *BUT thats the point* the user is in one realm the machine in another.
>> They can trust each other because you setup the cross realm, and with AD,
>> the AD of the machine spotted that your user has an AD account, and so it
>> added PAC information so the machine would accept the user as domain 
>> user.
>>
>> > possibly a trusted kerb5 realm domain created by AD?
>>
>> Not sure what you mean. AD does not create realms. Although domains in
>> a forest are using Kerberos cross realm.
>>
> This cleared up all sorts of misunderstandings I had.  =)  Well I am 
> seeing lots of DOMAIN.COM tickets but no REALM.DOMAIN.COM tickets.  But 
> that's probably because I've been thinking i need to login to the AD 
> domain not the REALM.  =/
> 
>>>>
>>> When i login to the Domain as a regular user MIT leash shows me a wad 
>>> of @DOMAIN.COM tickets.  Can I assume these tickets will be honored 
>>> by services  in the MIT Kerb V realm REALM.DOMAIN.COM?
>>
>>
>>
>> Yes and no. The tickets are for selected services in what ever realm
>> the service is in. Since the user is in DOMAIN.COM one of the tickets
>> is krbtgt/DOMAIN.COM at DOMAIN.COM this is the ticket granting ticket used
>> to get more tickets from DOMAIN.COM for services in that realm.
>>
>> There may also be a krbtgt/REALM.DOMAIN.COM at DOMAIN.COM This is the cross
>> realm ticket issued by DOMAIN.COM used to get tickets from 
>> REALM.DOMAIN.COM
>> But you would only see this if the user attempted to use a service in
>> REALM.DOMAIN.COM.
>>
>> When you get this working you using the user in REALM.DOMAIN.COM
>> you should see these tickets:
>>
>>    krbtgt/REALM.DOMAIN.COM at REALM.DOMAIN.COM   (initial ticket)
> 
> 
> Don't have that.
> 
>>    krbtgt/DOMAIN.COM at REALM.DOMAIN.COM         (cross realm ticket)
> 
> 
> or that
> 
>>    host/theworkstaiton at DOMAIN.COM             (service ticket for host)
>>
>>>
>>> This line of discussion is really really helpful thanks a ton.
>>
>>
> Still is =P
> 
> -Matt Joyce
> 
> 

Its 5:00PM, I am out of here.

> 

-- 

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