In regard to: Re: Cross-realm trust, Sam Hartman said (at 1:24pm on Feb 15,...:

>>>>>> "Philippe" == Philippe Perrin <[EMAIL PROTECTED]> writes:
>
>    Philippe> Hello
>    Philippe> I'm now willing to allow users authenticated in REALM1 to use services 
>of
>    Philippe> REALM2. I configured everything as I think I should have, and then I 
>made a
>    Philippe> user authenticate in REALM1, and used a telnet server in REALM2. The 
>only
>    Philippe> way I found to make it work was to add a ~/.k5login file containing
>    Philippe> "user@REALM1" on the server.
>    Philippe> How could I avoid writing such files for every user ? Can I make this 
>server
>
>That's how it should work.  Cross realm keys only enable
>authentication between the two realms; they say nothing about
>authorization.

I asked basically this same question (why does cross realm require
.k5login for each user) back in mid-September of 2000.  A fairly long
thread evolved out of the question, with some great information by
Ken Hornstein and others.

Philippe, the reason this is required is that Kerberos doesn't assume that
the local account for bob (on a machine in REALM1) is the same person
as bob@REALM2.  With cross realm, it could easily be the case that
`bob@REALM2' should really map to `jimbob' on the local machine.
That's why the .k5login is required.

In my case (and apparently in yours) I *can* guarantee that usernames
on machines always exactly match the principal, no matter what realm
they're in (so bob@REALM2 should be able to log into the `bob' account
on a machine that's in REALM1).

Ken Hornstein suggested looking into the k5userok() function.  See
the thread in September of 2000 for more info.

Tim
-- 
Tim Mooney                              [EMAIL PROTECTED]
Information Technology Services         (701) 231-1076 (Voice)
Room 242-J6, IACC Building              (701) 231-8541 (Fax)
North Dakota State University, Fargo, ND 58105-5164

_______________________________________________
Kerberos mailing list
[EMAIL PROTECTED]
http://mailman.mit.edu/mailman/listinfo/kerberos

Reply via email to