Hi
I have two servers "L" & "R" which are connected to the AD. On server L I can login with SSO and I don't have to type password. On server R I can't login with SSO and I have to type the AD password. The user is only defined in the AD not locally.
I have tried "realm leave" + "realm join" and "sss_cache -E". Removed /etc/sssd/* /etc/krb5.keytab /var/lib/sss/db/* to make sure no config was leftover.
The /etc/sssd/sssd.conf is equal on both servers.
Both servers are running RHEL 7.6.
/etc/sssd/sssd.conf : [sssd] domains = acme.com config_file_version = 2 services = nss, pam
[domain/acme.com] ad_domain = acme.com krb5_realm = ACME.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad debug_level = 7
Any hint much appreciated.
best regards Hans
On Fri, Feb 15, 2019 at 08:33:21AM +0100, Hans Schou wrote:
Hi
I have two servers "L" & "R" which are connected to the AD. On server L I can login with SSO and I don't have to type password. On server R I can't login with SSO and I have to type the AD password. The user is only defined in the AD not locally.
I assume you are using ssh (putty) to log in with SSO?
For a start you can check on R by increasing the LogLevel in /etc/ssh/sshd_config and restarting sshd if GSSAPI authentication is tried at all?
As on alternative the ssh client logs might show this as well. Additionally it would be good to check on the client after trying to connect with ssh if there is a Kerberos ticket for R. For this you can call klist and it should show something like 'host/R.fully.qualified@AD.REALM'.
HTH
bye, Sumit
I have tried "realm leave" + "realm join" and "sss_cache -E". Removed /etc/sssd/* /etc/krb5.keytab /var/lib/sss/db/* to make sure no config was leftover.
The /etc/sssd/sssd.conf is equal on both servers.
Both servers are running RHEL 7.6.
/etc/sssd/sssd.conf : [sssd] domains = acme.com config_file_version = 2 services = nss, pam
[domain/acme.com] ad_domain = acme.com krb5_realm = ACME.COM realmd_tags = manages-system joined-with-samba cache_credentials = True id_provider = ad krb5_store_password_if_offline = True default_shell = /bin/bash ldap_id_mapping = True use_fully_qualified_names = False fallback_homedir = /home/%u access_provider = ad debug_level = 7
Any hint much appreciated.
best regards Hans
sssd-users mailing list -- sssd-users@lists.fedorahosted.org To unsubscribe send an email to sssd-users-leave@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o...
On Fri, 15 Feb 2019 at 09:14, Sumit Bose sbose@redhat.com wrote:
I assume you are using ssh (putty) to log in with SSO?
Yes, and also SecureCRT
For a start you can check on R by increasing the LogLevel in
/etc/ssh/sshd_config and restarting sshd if GSSAPI authentication is tried at all?
I changed sshd_config to: LogLevel DEBUG
Then I tried a login and looked at /var/log/secure which said: sshd[14664]: debug1: Unspecified GSS failure. Minor code may provide more information\nNo key table entry found matching host/fiksudb@\n
I don't know what that "fiksudb" is but I guessed it most be some kind of a server. A look in /etc/hosts revealed the problem.
I comment all out in /etc/hosts and that solved the problem.
So lesson learned: Increase LogLevel in sshd_config and look for GSS in /var/log/secure
Thank you very much for help Sumit!
best regards Hans
sssd-users@lists.fedorahosted.org