On Tue, Apr 10, 2018 at 06:57:15PM +0200, Bastian Rosner wrote:
> Hi,
> 
> I think I found the solution. After I realized that putting a .k5login file
> into $HOME results in a working cross-domain Kerberos authentication, a
> search on this ML revealed the following:
> 
> Add this to krb5.conf:
> [plugins]
> localauth = {
> module=sssd:/usr/lib/x86_64-linux-gnu/sssd/modules/sssd_krb5_localauth_plugin.so
> enable_only = sssd
> }

Glad to hear that it is working for you now. I would suggest to remove
'enable_only = sssd' so that other schemes like .k5login files can be
used as well.

SSSD should automatically create a config snippet for this in
/var/lib/sss/pubconf/krb5.include.d/localauth_plugin and in Fedora/RHEL
/etc/krb5.conf starts with 

    includedir /var/lib/sss/pubconf/krb5.include.d/

to automatically include the snippet.

HTH

bye,
Sumit

> 
> 
> 
> Cheers, Bastian
> 
> 
> Am 2018-04-09 16:49, schrieb Bastian Rosner:
> > 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.
> > 
> > 
> > > 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
_______________________________________________
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