Cross Realm MIT <-> Active Directory

Miguel Sanders miguelsanders at telenet.be
Sun Nov 5 09:33:44 EST 2006


1) You should use rc4-hmac. des is week and shouldn't be used.

Can that be used in combination with Active Directory? Which stanza's/
configuration items should be used in kdc.conf and krb5.conf?

2) Now why can't user XYZ at UNIX.COM login successfully with his Windows
password?

I meant on the Unix box, not on the Windows box, so sorry on that.


Markus Moeller wrote:
> "Miguel Sanders" <miguelsanders at telenet.be> wrote in message
> news:1162725045.392694.47100 at i42g2000cwa.googlegroups.com...
> > Hi
> > I have been through many documents for several times but I just can't
> > seem to find the problem.
> > Here is the idea.
> > Users are defined in Active Directory (domain/realm WINDOWS.COM)
> > Host and service principals are defined in MIT Kerberos (realm
> > UNIX.COM).
> > Now I want the Windows users to be able to login to the Unix machines(
> > and thus the UNIX.COM realm).
> > Since users and host/service principals are in separated realms, cross
> > realm authentication should be set up, right?
> > So the point is that users XYZ (Windows Domain User) should be able to
> > logon to the Unix Machines.
> > 1) Does the Windows user XYZ need to be defined in MIT Kerberos? I
> > presume that this is the case (although set with a random password).
>
> You don't need the user in the MIT kdc. You either need a mapping like
>                 auth_to_local = RULE:[1:$1@$0](.*@.WINDOWS.COM$)s/@.*//
>                 auth_to_local = DEFAULT
> as part of the realms UNIX.COM section or use a .k5login file.
>
> > 2) Is something wrong with the given krb5.conf ?
> > [libdefaults]
> >        default_realm = UNIX.COM
> >        default_keytab_name = FILE:/etc/krb5/krb5.keytab
> >        default_tkt_enctypes = des-cbc-md5 des-cbc-crc
> >        default_tgs_enctypes = des-cbc-md5 des-cbc-crc
> >
> > [realms]
> >        UNIX.COM= {
> >                kdc = server1.unix.com:88
> >                admin_server = server1.unix.com:749
> >                default_domain = unix.com
> >        }
> >
> >       WINDOWS.COM= {
> >                kdc = server1.windows.com:88
> >                admin_server = server1.windows.com:749
> >                default_domain = unix.com
> >        }
> >
> > [domain_realm]
> >        .windows.com = WINDOWS.COM
> >        windows.com = WINDOWS.COM
> >        .unix.com = UNIX.COM
> >        unix.com = UNIX.COM
> >
> > [capaths]
> >        WINDOWS.COM = {
> >                UNIX.COM = .
> >        }
> >
> >        UNIX.COM = {
> >                WINDOWS.COM = .
> >        }
> >
> > 3) In kdc.conf I edited the following
> > master_key_type = des-cbc-md5
> > supported_enctypes = des-cbc-md5:normal des-cbc-crc:normal
>
>
>
> >
> > 4) In MIT Kerberos I defined krbtgt/WINDOWS.COM at UNIX.COM and
> > krbtgt/UNIX.COM at WINDOWS.COM principals with password ABC
> >
> > 5) In Active Directory I defined the MIT realm and MIT kerberos master
> > with ksetup
> >>ksetup
> > default realm = windows.com (NT Domain)
> > UNIX.COM:
> >        kdc = server1.unix.com
> >        Realm Flags = 0x0 none
> > Mapping XYZ at UNIX.COM to XYZ
>
> The mapping is only needed when you login from Unix to Windows.
>
> >
> > 6) In Active Directory I defined the realm trust (one way, incoming)
> > with the password ABC
> > 7) In Active Directory Users and Computers I created the name mapping
> > for user XYZ to XYZ at UNIX.COM (since the mapping set up by ksetup wasn't
> > visible here, did this just to be sure)
>
> I don't think you need this.
>
> >
> > Now why can't user XYZ at UNIX.COM login successfully with his Windows
> > password?
> > I am quite desperate on this one. What am I missing?
> > Any help would be greatly appreciated.
> >
>
> You have to tell the Windows clients where to find the service principals
> for the unix.com domain. This will be done with
> trust WINDOWS.COM/ domain:UNIX.COM /addtln:unix.com
> on Active Directory.
> 
> > Kind regards
> >
> > Miguel
> >
> 
> Regards
> Markus




More information about the Kerberos mailing list