[23633] in Kerberos
Re: Solaris 9 Cross Realm Authentication Problems
daemon@ATHENA.MIT.EDU (Douglas E. Engert)
Mon Apr 4 10:12:45 2005
Message-ID: <42514A72.7060408@anl.gov>
Date: Mon, 04 Apr 2005 09:08:50 -0500
From: "Douglas E. Engert" <deengert@anl.gov>
MIME-Version: 1.0
To: Markus Moeller <huaraz@moeller.plus.com>
In-Reply-To: <d2ojih$psb$1@sea.gmane.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
cc: kerberos@mit.edu
Errors-To: kerberos-bounces@mit.edu
Markus Moeller wrote:
> Has anybody tried to centralise the .k5login by storing this information in
> ldap ?
Not, sure, but a good idea. A related way to do this is to use
the auth_to_local = option in the [realms] secion of the krb5.conf
If all your users from one realm SAMPLE1.COM) are trusted as local
in realm (SAMPLE2.COM), then you could so something like:
[realms]
SAMPLE1.COM = {
kdc= ...
}
SAMPLE2.COM = {
kdc = ...
auth_to_local = RULE:[1:$1@$0](^.*@SAMPLE1.COM$)s/@SAMPLE1.COM//
auth_to_local = default
}
This tells sample2 servers to treat any User@SAMPLE1.COM principals
as User.
>
> Thanks
> Markus
>
> "Jeffrey Hutzelman" <jhutz@cmu.edu> wrote in message
> news:7B1894BF811333D1C3B83881@sirius.fac.cs.cmu.edu...
>
>>
>>On Friday, April 01, 2005 11:33:08 PM -0800 Darren Hoch
>><darren.hoch@litemail.org> wrote:
>>
>>
>>>Hello All,
>>>
>>>Thanks Jeffery. I deleted the old krbtgt principals and added the
>>>following on each host:
>>>
>>>krbtgt/EXAMPLE.COM@EXAMPLE1.COM
>>>krbtgt/EXAMPLE1.COM@EXAMPLE.COM
>>>
>>>I am almost there. When user darren now tries to telnet (kerberized) from
>>>a host in realm EXAMPLE.COM to a host in EXAMPLE1.COM, the credentials
>>>and encryption are accepted, however, I am still prompted for a password
>>>for the user darren in realm EXAMPLE1.COM. Shoud I be prompted, or should
>>>I be able to do single sign on?
>>
>>It sounds like now you are successfully authenticating to the telnet
>>server, and the authorization check is failing. This is not surprising,
>>since the default policy only allows you to log in as user 'foo' if you
>>are authenticated as the principal 'foo@LOCAL.REALM'. You can override
>>the local policy for a given user by giving that user a .k5login file
>>listing the principals who are allowed to log in as him. For example, you
>>could give 'darren' a .k5login file containing the following two lines:
>>
>>darren@EXAMPLE.COM
>>darren@EXAMPLE1.COM
>>
>>
>>-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
>> Sr. Research Systems Programmer
>> School of Computer Science - Research Computing Facility
>> Carnegie Mellon University - Pittsburgh, PA
>>
>>________________________________________________
>>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
>
>
>
--
Douglas E. Engert <DEEngert@anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
________________________________________________
Kerberos mailing list Kerberos@mit.edu
https://mailman.mit.edu/mailman/listinfo/kerberos
