[27801] in Kerberos

home help back first fref pref prev next nref lref last post

Re: Joining a multiple realm AD environment

daemon@ATHENA.MIT.EDU (Markus Moeller)
Sun May 20 22:02:04 2007

To: kerberos@mit.edu
From: "Markus Moeller" <huaraz@moeller.plus.com>
Date: Sun, 20 May 2007 19:57:59 +0100
Message-ID: <f2q5pg$ieg$1@sea.gmane.org>
X-Complaints-To: usenet@sea.gmane.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Errors-To: kerberos-bounces@mit.edu

Chris,

Using PAM for Kerberos authentication is in reality against the way Keberos 
works. If you use a keberised client like SecureCRT on Windows or a patched 
putty for ssh you won't have the problems.

Trying the different domains is only a hack as most applications can not 
deal with a username like user@LOC1.


Regards
Markus


"Chris Penney" <penney@msu.edu> wrote in message 
news:111aefd0705190626h6c952d1ap12f9348c69876f91@mail.gmail.com...
> On 5/18/07, Douglas E. Engert <deengert@anl.gov> wrote:
>>
>> Chris Penney wrote:
>> >
>> > Ah!  I see.  I used the pam_krb5 that Douglas noted and the pam config
>> > lines you noted and it works basically as intended.
>> >
>> > Do you still have to do this even if you add the system to AD via a
>> > "User" account?
>>
>> Microsoft used a mis-leading term when they said to add the machine as
>> a "user".  You are adding a service principal for the machine into a
>> realm. With AD that also means it needs an account, which looks like
>> a "user" account, but in Kerberos terms has nothing to do with the user.
>>
>> So each user must be registered with a principal and (AD account), and
>> each service must be registered with a principal and its own AD account).
>>
>> If you have cross realm setup then each user only needs to be in one 
>> realm,
>> and each service only needs to be in one realm.
>>
>> You did not indicate that you have cross realm set up. i.e. the ADs have
>> some cross domain trust.  But if it works as intended, then it must.
>> A klist would show an extra TGT like krbtgt/LOC1.DOM.COM@LOC2.DOM.COM
>
> Yes, LOC1 and LOC2 trust each other, though I'm not clear that I'm
> leveraging that.  When I say working as intended it's probably
> incorrect.  I just mean that if I have an entry in the pam config file
> for each realm all users can login simply because pam trys user@LOC1
> then user@LOC2, etc.
>
> Is this a normal way of handing this?  Is setting up .k5login with
> user@LOCx the best way to avoid iterating through all the realms?
>
>    Chris
> ________________________________________________
> Kerberos mailing list           Kerberos@mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
> 



________________________________________________
Kerberos mailing list           Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos

home help back first fref pref prev next nref lref last post