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-sssd(a)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: bro(a)SUB1.EXAMPLE.COM
> > > >
> > > > Valid starting Expires Service principal
> > > > 04/06/2018 16:09:54 04/07/2018 02:09:54
> > > > krbtgt/SUB1.EXAMPLE.COM(a)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.client(a)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 'bro(a)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(a)lists.fedorahosted.org
> > To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org
> _______________________________________________
> sssd-users mailing list -- sssd-users(a)lists.fedorahosted.org
> To unsubscribe send an email to sssd-users-leave(a)lists.fedorahosted.org