[23418] in Kerberos
Re: AD Domain Authentication to MIT Kerb V
daemon@ATHENA.MIT.EDU (Matt Joyce)
Fri Feb 18 16:18:10 2005
Message-ID: <42165B60.6010804@vtsystems.com>
Date: Fri, 18 Feb 2005 16:17:20 -0500
From: Matt Joyce <syslists@vtsystems.com>
MIME-Version: 1.0
To: "Douglas E. Engert" <deengert@anl.gov>, kerberos@mit.edu
In-Reply-To: <4216565B.6030705@anl.gov>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: syslists@vtsystems.com
Errors-To: kerberos-bounces@mit.edu
Douglas E. Engert wrote:
> Something else to try is to login to the workstation as a local user,
> run Ethereal to trace network activity, then use the runas command
> in a cmd window and watch what happens. The Microsoft klist in the
> 2003 resouces or support tools (forgot which) can be helpfull too.
>
> runas /user:user cmd
>
> runas /user:user@DOMAIN cmd
>
> runas /user:user@REALM cmd
>
> This might give you some insite as to what MS is doing and how the
> local mappings and mapping in AD effect this. Ethereal can show
> you DNS requests, and Kerberos trafic. It even can format
> most of the kerberos packets.
>
> We have all our user's in AD, and don't have AD trusting any Kerberos
> realm at least not today, so I am interested in seeing if you get this
> working.
> .
>
I have been using ethereal extensively. Helped me trouble shoot some
stuff already.
>
> There are two mappings talked about in the doc. THe mapping in AD
> and the mappings on the local machine.
>
> You will need to set in AD that an AD account is willing to trust
> the Kerberos authentication from the Kerberos realm. Your AD admin
> needs to do this. (We don't use it this way here so I can't tell you
> exactly what to do.)
>
> The step by step guide talkes about:
>
> Creating Account Mappings
> Account mappings are used to map a foreign Kerberos identity (in a
> trusted MIT Kerberos realm) to a local account identity in the domain.
> These account mappings are managed through the Active Directory
> Management tool.
>
> These account mappings will allow the Kerberos realm to act as an
> account domain. Users with Kerberos principals that have mappings to
> domain accounts, can logon to a workstation that is joined to a
> trusted domain using the Kerberos principal and password from the
> Kerberos realm
>
Mappings are set. on the 2003 AD box in the domain lists I see a
DOMAIN.COM domain which is the AD domain, and a "REALM.DOMAIN.COM (Krb V
Realm)" which is the KRB5 Realm name. I can choose that domain, or type
my name as user@REALM.DOMAIN.COM and login to my mapped account on the
AD box. Which makes me think all the docs in the MIT kerb interop
guide have been followed correctly.
*REALM.DOMAIN.COM is the correct complete name of the Kerb V realm. It
has the DOMAIN.COM suffix only because I felt that that would be a sane
realm name.
Now on a machine i join to the DOMAIN.COM domain I only see the
DOMAIN.COM domain as a login option. Should I be adding a
REALM.DOMAIN.COM domain as well? And trying to authenticate to that?
>
>> My Kerb V realm name is indeed different from my domain name. So I
>> am well aware of which is which when referenced.
>>
>
> OK, it was not clear.
>
Sorry bout that.
>> I am only seeing tickets from my AD domain realm. I am not seeing
>> any tickets seemingly issued by my Kerb V realm.
>
>
> So when you login, do you type user@realm or just user?
>
just user. The @ seemingly specifies a domain to login to. I cannot
login to a Domain with a complete realm prinicpal without inadvertental
telling windows to login to som alternate domain... possibly a trusted
kerb5 realm domain created by AD?
>> Do I need to configure the client machines on the domain to be aware
>> of the Kerb5 trusted realm?
>
>
> Not sure, as we have all our users in the Domain to start with.
> We do have a few windows machines, and a lot of UNIX machines that
> are registered in the MIT realm. I can use my domain principal
> to login at a unix console.
>
So theoretically i can kinit on unix using my domain accounts from AD?
because I am using my AD ticket in a two way trusted cross realm
authentication setup?
>> Are they aware of it through SRV records? Or is NTLM auth to the AD
>> domain supposed to automagically grab tickets from my trusted kerb5
>> realm? When I log into NTLM I am not seeing any queries in
>> krb5kdc.log =(.
>
>
> NTLM does not use Kerberos at all.
>
Yes I would rather not have to enter each user machine into the KDC. I
would like for AD to delegate tickets to the user machines that the Kerb
V kdc will honor. Assuming I am in a cross realm two way trust, when I
authenticate directly to the AD domain will my AD given @DOMAIN.COM
tickets be honored via SPNEGO / GSSAPI by MIT kerb V?
Is there any benefit to allowing a user to login to the Realm as opposed
to using ntlm to login to the domain?
>>
>> Am I missing some added step in providing cross realm authentication
>> that's not mentition in the interoperability guide?
>>
>
>
> When loging into Windows, Windows will stash the user and password in
> case
> it is needed later for NTLM. If you really still need NTLM, you would
> have
> to keep your passwrods in sync. The main idea of Kerberos it to get away
> from NTLM.
>
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?
This line of discussion is really really helpful thanks a ton.
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
