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 <[email protected]> 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: [email protected] > > Valid starting Expires Service principal > 04/06/2018 16:09:54 04/07/2018 02:09:54 > krbtgt/[email protected] > 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/[email protected]' (if the client is joined to SUB2.EXAMPLE.COM). 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 '[email protected]' on the SSH client? HTH bye, Sumit > _______________________________________________ > sssd-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ sssd-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
