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
}
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
