On 2/24/2012 9:32 AM, Jean-Christophe Gay wrote: > Hi, > > I'm configuring a Kerberos installation. I've got two KDC running. The > first one is in charge of the realm EXAMPLE.COM and the second one is > in charge of ETUD.EXAMPLE.COM. > > In order to test this installation I add two ssh-servers to my two > KDCs, one for each realm. They are working. I can obtain a ticket from > one KDC and then ssh the ssh-server of the correct realm without any > difficulty. > > To this I add a workstation. My workstation is configured so I can > obtain an EXAMPLE.COM ticket or an ETUD.EXAMPLE.COM one. I can use > these tickets to succesfully connect via ssh on my ssh-servers. > > Now I'd like to achive cross-realm authentication. I want that someone > with an EXAMPLE.COM ticket can connect to the ETUD.EXAMPLE.COM > ssh-server. To be sure of what principal to add I tried to connect to > my ssh-server : > debug1: Unspecified GSS failure. Minor code may provide more > information Server krbtgt/etud.example....@example.com not found in > Kerberos database > > So I added this principal to both KDCs : > kadmin.local -e "des3-hmac-sha1:normal des-cbc-crc:v4" > kadmin: add_principal -kvno 1 -requires_preauth > krbtgt/etud.example....@example.com > > both with the same password. Then this should be working but here is > the error returned by: > $ kinit -p myuser > Password for myu...@example.com: > $ klist > Ticket cache: FILE:/tmp/krb5cc_1000 > Default principal: myu...@example.com > > Valid starting Expires Service principal > 02/24/12 15:50:12 02/24/12 21:50:12 krbtgt/example....@example.com > renew until 02/25/12 03:50:12 > $ ssh -vv myu...@ssh-serv.etud.example.com > [...] > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password debug1: Next authentication method: > gssapi-with-mic debug2: we sent a gssapi-with-mic packet, wait for reply > debug1: Delegating credentials > debug1: Delegating credentials > debug1: Authentications that can continue: > publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic > packet, wait for reply debug1: Authentications that can continue: > publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic > packet, wait for reply debug1: Authentications that can continue: > publickey,gssapi-with-mic,password debug2: we sent a gssapi-with-mic > packet, wait for reply debug1: Authentications that can continue: > publickey,gssapi-with-mic,password debug2: we did not send a packet, > disable method > debug1: Next authentication method: password > myu...@ssh-serv.etud.example.com's password: > ^C > $ klist > Ticket cache: FILE:/tmp/krb5cc_1000 > Default principal: myu...@example.com > > Valid starting Expires Service principal > 02/24/12 15:50:12 02/24/12 21:50:12 krbtgt/example....@example.com > renew until 02/25/12 03:50:12 > 02/24/12 16:16:38 02/24/12 21:50:12 > krbtgt/etud.example....@example.com > renew until 02/25/12 03:50:12 > 02/24/12 16:16:38 02/24/12 21:50:12 > host/ssh-server.etud.example....@etud.example.com > renew until 02/25/12 03:50:12 > > So I can obtain the correct tickets, but can't log into the ssh-server > using the SSO functions of Kerberos. Is there anything I did wrong or > missed about my configuration of theses services ? any help would be > appreciated.
Did you add the line: myu...@example.com to the .k5login file for myuser on ssh-serv.etud.example.com? The assumption is foreign principals are not allowed to login by default. i.e. a local user in one realm is not the same as a local user in another realm. Also see the auth_to_local options in the krb5.conf file. > > Jean-Christophe > ________________________________________________ > Kerberos mailing list Kerberos@mit.edu > https://mailman.mit.edu/mailman/listinfo/kerberos > > -- Douglas E. Engert <deeng...@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