On Mon, Apr 09, 2018 at 04:49:02PM +0200, Bastian Rosner wrote:
> Am 2018-04-09 16:35, schrieb Sumit Bose:
> > On Fri, Apr 06, 2018 at 10:21:11PM +0200, Bastian Rosner wrote:
> > > On 04/06/2018 09:59 PM, Jakub Hrozek wrote:
> > > >
> > > >
> > > > > On 6 Apr 2018, at 17:54, Bastian Rosner <bro-s...@d00m.org> wrote:
> > > > >
> > > > > Unfortunately, users from other domains can't use their Kerberos 
> > > > > ticket, only password works. These users are specifying their domain 
> > > > > on login.
> > > >
> > > > This all sounds like the issue is not on the SSSD level, but either the 
> > > > krb5.conf configuration might be perhaps missing the domain-realm 
> > > > mappings, but what you said next was interesting:
> > > This is the krb5.conf for a host in one of the other domains. My
> > > client
> > > (both computer and user) is in sub1 and logs in to a host in sub2.
> > > $ cat /etc/krb5.conf
> > > [logging]
> > >  default = FILE:/var/log/krb5libs.log
> > > 
> > > [libdefaults]
> > >  default_realm = SUB2.EXAMPLE.COM
> > >  dns_lookup_realm = true
> > >  dns_lookup_kdc = true
> > >  ticket_lifetime = 24h
> > >  renew_lifetime = 7d
> > >  forwardable = true
> > >  rdns = false
> > > 
> > > Do I have to specify all domains in here? I thought the site/forest
> > > discovery of sssd-ad should take care of all the other trusted
> > > subdomains.
> > > 
> > > > > Surprisingly, once logged in after authenticating with a password, 
> > > > > foreign-domain users are able to issue a Kerberos ticket with kinit 
> > > > > if they specify username@FQDN
> > > >
> > > > Hmm, are you saying that if you log in with a password you don’t get a 
> > > > TGT?
> > > 
> > > Actually I do get a ticket after a logging in using password:
> > > $ klist
> > > Ticket cache: FILE:/tmp/krb5cc_94821677_hr943p
> > > Default principal: b...@sub1.example.com
> > > 
> > > Valid starting       Expires              Service principal
> > > 04/06/2018 16:09:54  04/07/2018 02:09:54
> > > krbtgt/sub1.example....@sub1.example.com
> > >   renew until 04/13/2018 16:09:54
> > > 
> > > This ticket does not work on sub2 hosts but can be used for
> > > gssapi-with-mic
> > > based authentication in sub1.
> > 
> > The authentication part is completely handled on the SSH level here. I
> > would first check on the client (I guess it is a Windows workstation) if
> > you got a service ticket for the Linux host after trying to authenticate
> > with the SSH client (putty?). You can check this by calling 'klist.exe'
> > in the command shell or power shell. You should see a principal like
> > 'host/fqdn.of.the.linux.cli...@sub2.example.com' (if the client is
> > joined to SUB2.EXAMPLE.COM).
> 
> Clients are Linux and users can receive tickets for the local domain and can
> also use these tickets for authentication on the local domain.
> On the same domain, Kerberos-auth works.
> Cross-domain, Kerberos-auth does not work.

What does 'klist' on the client show after trying ssh to the server?

Do you have a '[domain_realm]' section in krb5.conf on the client where
the DNS domain of the server is mapped to the SUB2.EXAMPLE.COM realm?

What is returned if you call

    kvno host/fqdn.of.the.linux.server

on the client?

bye,
Sumit

> 
> 
> > If the host/... principal is shown by klist there might be a user name
> > to principal mapping issue on the client. Have you tried to use the
> > fully-qualified user name 'b...@sub1.example.com' on the SSH client?
> 
> That was the first thing we checked since it is so obvious.
> Without using the @domain part, not even password-based authentication works
> across domains.
> _______________________________________________
> sssd-users mailing list -- sssd-users@lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org
_______________________________________________
sssd-users mailing list -- sssd-users@lists.fedorahosted.org
To unsubscribe send an email to sssd-users-le...@lists.fedorahosted.org

Reply via email to