Hi,
we are looking for a detailed configuration example to join an AD forest with working Kerberos authentication.
Our AD infrastructure consists of a single forest with multiple (sub-)domains in two-way trust. No FreeIPA, just Windows 2012 AD servers and SSSD clients using version 1.11 and 1.15 on Debian. We can successfully join with sssd-ad using the "net ads join" command and users from the same domain can authenticate using a Kerberos ticket or password. Also mounting CIFS shares via pam-mount works fine in the same domain. Unfortunately, users from other domains can't use their Kerberos ticket, only password works. These users are specifying their domain on login. 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 (with capital letters). Also lookup up group membership of users from another domain works fine, so presumably the LDAP part is working correctly.
This is our current config, are we missing something in order to get Kerberos cross-domain authentication working?
$ cat /etc/sssd/sssd.conf [sssd] domains = sub1.example.com services = nss, pam, pac config_file_version = 2
[nss] filter_groups = root filter_users = root
[pam]
[domain/sub1.example.com] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad cache_credentials = true ldap_referrals = false ldap_force_upper_case_realm = true ad_gpo_access_control = disabled override_homedir = /home/%u default_shell = /bin/bash
Thanks and kind regards, Bastian
On 6 Apr 2018, at 17:54, Bastian Rosner bro-sssd@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:
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?
On 04/06/2018 09:59 PM, Jakub Hrozek wrote:
On 6 Apr 2018, at 17:54, Bastian Rosner bro-sssd@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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.
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@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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@SUB2.EXAMPLE.COM' (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 'bro@sub1.example.com' on the SSH client?
HTH
bye, Sumit
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
On Mon, 2018-04-09 at 16:35 +0200, Sumit Bose wrote:
CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.
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@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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.
You might want to try this in krb5.conf: [libdefaults] default_realm = DEF.COM
[realms] DEF.COM = { default_domain = def.com auth_to_local = RULE:[1:$1] auth_to_local = RULE:[2:$1] auth_to_local = DEFAULT } SUB.COM = { default_domain = sub.com auth_to_local = RULE:[1:$1] auth_to_local = RULE:[2:$1] auth_to_local = DEFAULT }
Jocke
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@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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@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@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.
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-sssd@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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@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 'bro@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-leave@lists.fedorahosted.org
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-sssd@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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@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@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-leave@lists.fedorahosted.org
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@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@SUB1.EXAMPLE.COM
Valid starting Expires Service principal 04/06/2018 16:09:54 04/07/2018 02:09:54 krbtgt/SUB1.EXAMPLE.COM@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@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@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-leave@lists.fedorahosted.org
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org
sssd-users@lists.fedorahosted.org
-
Bastian Rosner -
Jakub Hrozek -
Joakim Tjernlund -
Sumit Bose