cross-realm authentication works only with .k5login

Markus Moeller huaraz at moeller.plus.com
Fri Mar 21 13:45:10 EDT 2008


Andrea,

can you provide the output of

1) klist -ek on both systems
2) a tcpdump on port 88 when you try to connect from one system to the 
other.
    e.g. on Server1
   a) kinit andrea at SOLARIS; ssh andrea at server2
   b) kinit andrea at SOLARIS2; ssh andrea at server2
       on Server2
   a) kinit andrea at SOLARIS; ssh andrea at server1
   b) kinit andrea at SOLARIS2; ssh andrea at server1
3) a klist -e after the attempted connection on both servers

Markus

----- Original Message ----- 
From: "Andrea" <acirulli at gmail.com>
To: "Markus Moeller" <huaraz at moeller.plus.com>
Sent: Friday, March 21, 2008 9:59 AM
Subject: Re: cross-realm authentication works only with .k5login


> Hi Markus (thanks a lot for your suggestions),
> it is exactly how I setted up the two machine master and slave.
>
> The problem is that on the same machine I can SSO with both REALM. But
> if I try to SSO from one machine, let's say MASTER to the SLAVE, i can
> SSO only with the default REALM of the target machine (i.e. from
> MASTER (default REALM SOLARIS) to the SLAVE (default REALM SOLARIS2) I
> can SSO only with a valid ticket from REALM SOLARIS2, and with a
> ticket from SOLARIS the SSO doesn't work).
>
> I can't figured out why and this problem it is driving me nuts,
>
>
> Best Regards,
> Andrea
>
> On 20 Mar, 21:01, "Markus Moeller" <hua... at moeller.plus.com> wrote:
>> Andrea,
>>
>> if I understand your setup right then you have:
>>
>> 1) Server1.solaris member of REALM SOLARIS
>> 2) Server2.solaris2 member of REALM SOLARIS2
>> 3) user andrea at SOLARIS and andrea at SOLARIS2
>>
>> Now your krb5.conf on Server1 should be:
>>
>> [libdefaults]
>>        default_realm =SOLARIS
>>         ...
>> [realms]
>>   SOLARIS = {
>>                kdc = colcascms
>>                admin_server = colcascms
>>                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS2$)s/@.*//
>>                auth_to_local = DEFAULT
>>
>>         }
>>         SOLARIS2 = {
>>                 kdc = colcascms2
>>                 admin_server = colcascms2
>>         }
>> [domain_realm]
>>      .solaris = SOLARIS
>>      .solaris2 = SOLARIS2
>>
>> and on Server2:
>>
>> [libdefaults]
>>        default_realm =SOLARIS2
>>         ...
>> [realms]
>>   SOLARIS2 = {
>>                kdc = colcascms2
>>                admin_server = colcascms2
>>                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS$)s/@.*//
>>                auth_to_local = DEFAULT
>>
>>         }
>>         SOLARIS = {
>>                 kdc = colcascms
>>                 admin_server = colcascms
>>         }
>> [domain_realm]
>>      .solaris = SOLARIS
>>      .solaris2 = SOLARIS2
>>
>> This would allow andrea at SOLARIS and andrea at SOLARIS2 to login to Server1 
>> and
>> Server2 as local user andrea.
>>
>> Or do I misunderstand your terminology of Master and Slave ?
>>
>> Markus
>>
>> "Andrea" <aciru... at gmail.com> wrote in message
>>
>> news:a83c3a25-2b33-4e15-9dae-aa3486e6249a at t54g2000hsg.googlegroups.com...
>>
>> > Hi, i inserted the regular expression as you suggested, and on that
>> > machine (let's say this machine as MASTER) I can Single Sign On with
>> > both REALMS.
>>
>> > However if  I use the same krb5.conf on an another machine (let's say
>> > SLAVE) setting the realm SOLARIS2 as default I can't Single Sign On on
>> > MASTER machine which is setted up for SOLARIS REALM as default. The
>> > strange thing lies in the fact that if on the SLAVE i use as default
>> > REALM SOLARIS then everything works fine, that is i can SSO with both
>> > REALMS.
>>
>> > Any idea or suggestions?
>>
>> > The krb5.conf of the master is the following:
>> > [libdefaults]
>> >        default_realm =SOLARIS
>> >        dns_lookup_kdc = false
>> >        dns_fallback  =  false
>> > # The following krb5.conf variables are only for MIT Kerberos.
>> >        krb4_config = /etc/krb.conf
>> >        krb4_realms = /etc/krb.realms
>> >        kdc_timesync = 1
>> >        ccache_type = 4
>> >        renewable = true
>> >        forwardable = true
>> >        proxiable = true
>>
>> > [realms]
>> >        SOLARIS = {
>> >                kdc = colcascms
>> >                admin_server = colcascms
>> >                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS2$)s/@.*//
>> >               auth_to_local = DEFAULT
>>
>> >        }
>> >        SOLARIS2 = {
>> >                kdc = colcascms
>> >                admin_server = colcascms
>> >        }
>>
>> > And the krb5.conf of the SLAVE is:
>>
>> > [libdefaults]
>> >        default_realm =SOLARIS
>> >        dns_lookup_kdc = false
>> >        dns_fallback  =  false
>> > # The following krb5.conf variables are only for MIT Kerberos.
>> >        krb4_config = /etc/krb.conf
>> >        krb4_realms = /etc/krb.realms
>> >        kdc_timesync = 1
>> >        ccache_type = 4
>> >        renewable = true
>> >        forwardable = true
>> >        proxiable = true
>>
>> > [realms]
>> >        SOLARIS = {
>> >                kdc = colcascms
>> >                admin_server = colcascms
>> >                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS2$)s/@.*//
>> >                auth_to_local = DEFAULT
>>
>> >        }
>> >        SOLARIS2 = {
>> >                kdc = colcascms
>> >                admin_server = colcascms
>> >                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS$)s/@.*//
>> >                auth_to_local = DEFAULT
>> >        }
>>
>> > On 17 Mar, 21:44, "Markus Moeller" <hua... at moeller.plus.com> wrote:
>> >> Hi Andrea,
>>
>> >> a user andrea at SOLARIS in not the same as a user andrea at SOLARIS2. You 
>> >> need
>> >> to
>> >> tell a server in domain SOLARIS that user andrea at SOLARIS2 is the same 
>> >> as
>> >> andrea at SOLARIS by either using .k5login or use auth_to_local in 
>> >> krb5.conf
>> >> e.g.
>>
>> >> ..
>> >> [realms]
>> >>        SOLARIS = {
>> >>                kdc = ..
>> >> #
>> >> # map xxx at SOLARIS2 to local user xxx
>> >> #
>> >>                auth_to_local = RULE:[1:$1@$0](.*@SOLARIS2$)s/@.*//
>> >>                auth_to_local = DEFAULT
>> >>        }
>> >> ..
>>
>> >> This means you trust both domains using unique ids.
>>
>> >> Markus
>>
>> >> "Andrea" <aciru... at gmail.com> wrote in message
>>
>> >>news:b66de008-26d7-48b7-9bc1-0f5e4756b71b at z38g2000hsc.googlegroups.com...
>>
>> >> > Hi all,
>> >> > I just setted up a multi realm KDC on a linux machine.
>> >> > The 2 REALMS are named SOLARIS and SOLARIS2.
>> >> > I want to put a trust relationship between the two REALMS, so I did
>> >> > the following on each KDC:
>>
>> >> > addprinc -pw krbtgt/SOLARIS2 krbtgt/SOLARIS2 at SOLARIS
>> >> > addprinc -pw krbtgt/SOLARIS krbtgt/SOLARIS at SOLARIS2
>>
>> >> > In order to test cross realm authentication I tryed to single sign 
>> >> > on
>> >> > into a machine based on SOLARIS realm, with a ticket of SOLARIS2. 
>> >> > The
>> >> > SSO doesn't work, however if I run klist after trying   SSO, it
>> >> > yields:
>> >> > [root at localhost ~]# klist
>> >> > Ticket cache: FILE:/tmp/krb5cc_0
>> >> > Default principal: andrea at SOLARIS2
>>
>> >> > Valid starting     Expires            Service principal
>> >> > 03/17/08 04:09:13  03/17/08 15:49:13  krbtgt/SOLARIS2 at SOLARIS2
>> >> >        renew until 03/17/08 04:09:13
>> >> > 03/17/08 04:09:19  03/17/08 15:49:13  krbtgt/SOLARIS at SOLARIS2
>> >> >        renew until 03/17/08 04:09:13
>> >> > 03/17/08 04:09:19  03/17/08 15:49:13  host/andrea at SOLARIS
>> >> >        renew until 03/17/08 04:09:13
>>
>> >> > It seems that the cross realm authentication works, but the SSO no.
>>
>> >> > I can make the system successfully works inserting the .k5login file
>> >> > into the home directory of the user who is attempting to SSO on the
>> >> > machine with a ticket of SOLARIS2 REALM.
>>
>> >> > I want to ask to you:
>>
>> >> > Am I missing something on the configuration?
>> >> > Is necessary to set up for each user on the system a .k5login?
>> >> > Is it possible to avoid using the .k5login?
>>
>> >> > Thanks in advance!
>>
>> >> > best regards,
>> >> > Andrea
>> >> > ________________________________________________
>> >> > Kerberos mailing list           Kerbe... at mit.edu
>> >> >https://mailman.mit.edu/mailman/listinfo/kerberos
>>
>> > ________________________________________________
>> > Kerberos mailing list           Kerbe... at mit.edu
>> >https://mailman.mit.edu/mailman/listinfo/kerberos
>
> 





More information about the Kerberos mailing list