Description of problem: When 2 domains are configured in sssd only login as remote user works only for the 2nd one. This is doe to krb5_use_enterprise_principal, because when it is set to False the login starts to work. Version-Release number of selected component (if applicable): sssd-1.10.0-5.fc19.beta1 How reproducible: always Steps to Reproduce: # cat /etc/sssd/sssd.conf [sssd] domains = ad.baseos.qe, security.baseos.qe config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/ad.baseos.qe] ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [domain/security.baseos.qe] ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad # getent passwd Bender.qe bender.qe:*:1197601112:1197600513:Bender:/home/ad.baseos.qe/bender:/bin/bash # getent passwd Bender.qe bender.qe:*:89801133:89800513:Bender:/home/security.baseos.qe/bender:/bin/bash $ ssh Bender.qe.100.19 Bender.qe.100.19's password: Last login: Thu May 16 17:23:59 2013 from 192.168.100.1 [bender.qe@pkis ~]$ exit logout Connection to 192.168.100.19 closed. $ $ ssh Bender.qe.100.19 Bender.qe.100.19's password: Permission denied, please try again. ^C Setting krb5_use_enterprise_principal=False for booth domain in sssd.conf solves the problem.
Upstream ticket: https://fedorahosted.org/sssd/ticket/1931
Do the domains belong to the same forest or do they have a trust relationship? Can you attach logs with a high debug level?
Created attachment 752519 [details] sssd logs with anabled debug
(In reply to Sumit Bose from comment #2) > Do the domains belong to the same forest or do they have a trust > relationship? Can you attach logs with a high debug level? Each domain have it's own forest, but they are in trust relationship (trust type = forest, transitive = yes, whatever does that mean). I did the same test as above, the logs with enabled debug are attached: https://bugzilla.redhat.com/attachment.cgi?id=752519 # cat /etc/sssd/sssd.conf [sssd] debug_level=0xFFFF domains = ad.baseos.qe, security.baseos.qe config_file_version = 2 services = nss, pam [nss] debug_level=0xFFFF default_shell = /bin/bash [domain/ad.baseos.qe] debug_level=0xFFFF ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [domain/security.baseos.qe] debug_level=0xFFFF ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad # getent passwd Bender.qe bender.qe:*:89801133:89800513:Bender:/home/security.baseos.qe/bender:/bin/bash $ ssh Bender.qe.100.19 ^^^ pass # getent passwd Bender.qe bender.qe:*:1197601112:1197600513:Bender:/home/ad.baseos.qe/bender:/bin/bash $ ssh Bender.qe.100.19 Permission denied, please try again. $
Thank you for the logs, they help a lot. Can you check the time on your AD servers? the lrb5_child.log contains errors like 'TGS request result: -1765328351/Ticket not yet valid' which indicates that the AD servers are running on different times and for some reason sssd tries to validate the ticket Bender.QE against host/pkis.ipa.baseos.qe.QE. In general this is ok because of the trust, but requires the same time on the AD servers. Can you attach the content of your keytab?
Created attachment 752582 [details] sssd logs after synced AD times
(In reply to Sumit Bose from comment #5) > Thank you for the logs, they help a lot. Can you check the time on your AD > servers? the lrb5_child.log contains errors like 'TGS request result: > -1765328351/Ticket not yet valid' which indicates that the AD servers are > running on different times and for some reason sssd tries to validate the > ticket Bender.QE against > host/pkis.ipa.baseos.qe.QE. In general this is ok because of > the trust, but requires the same time on the AD servers. > > Can you attach the content of your keytab? Yes, the times were different on the two AD servers. I synced them and tried the test again. The result is slightly different. In previous cases I always succeeded with login to 2nd domain, not I succeeded to the 1st one. I'm not sure if the order in configuration file matter. The new logs are attached again. https://bugzilla.redhat.com/attachment.cgi?id=752582 # cat /etc/sssd/sssd.conf [sssd] debug_level=0xFFFF domains = ad.baseos.qe, security.baseos.qe config_file_version = 2 services = nss, pam [nss] debug_level=0xFFFF default_shell = /bin/bash [domain/ad.baseos.qe] debug_level=0xFFFF ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [domain/security.baseos.qe] debug_level=0xFFFF ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad # klist -ke /etc/krb5.keytab Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 7 host/pkis.ipa.baseos.qe.QE (des-cbc-crc) 7 host/pkis.ipa.baseos.qe.QE (des-cbc-md5) 7 host/pkis.ipa.baseos.qe.QE (aes128-cts-hmac-sha1-96) 7 host/pkis.ipa.baseos.qe.QE (aes256-cts-hmac-sha1-96) 7 host/pkis.ipa.baseos.qe.QE (arcfour-hmac) 7 host/PKIS.QE (des-cbc-crc) 7 host/PKIS.QE (des-cbc-md5) 7 host/PKIS.QE (aes128-cts-hmac-sha1-96) 7 host/PKIS.QE (aes256-cts-hmac-sha1-96) 7 host/PKIS.QE (arcfour-hmac) 7 PKIS$@AD.BASEOS.QE (des-cbc-crc) 7 PKIS$@AD.BASEOS.QE (des-cbc-md5) 7 PKIS$@AD.BASEOS.QE (aes128-cts-hmac-sha1-96) 7 PKIS$@AD.BASEOS.QE (aes256-cts-hmac-sha1-96) 7 PKIS$@AD.BASEOS.QE (arcfour-hmac) 7 host/PKIS.qe (des-cbc-crc) 7 host/PKIS.qe (des-cbc-md5) 7 host/PKIS.qe (aes128-cts-hmac-sha1-96) 7 host/PKIS.qe (aes256-cts-hmac-sha1-96) 7 host/PKIS.qe (arcfour-hmac) 6 host/PKIS.qe (des-cbc-crc) 6 host/PKIS.qe (des-cbc-md5) 6 host/PKIS.qe (aes128-cts-hmac-sha1-96) 6 host/PKIS.qe (aes256-cts-hmac-sha1-96) 6 host/PKIS.qe (arcfour-hmac) 7 host/pkis.ipa.baseos.qe.QE (des-cbc-crc) 7 host/pkis.QE (des-cbc-crc) 7 host/pkis.ipa.baseos.qe.QE (des-cbc-md5) 7 host/pkis.QE (des-cbc-md5) 7 host/pkis.QE (aes128-cts-hmac-sha1-96) 7 host/pkis.QE (arcfour-hmac) 7 PKIS$@SECURITY.BASEOS.QE (des-cbc-crc) 7 host/pkis.ipa.baseos.qe.QE (aes128-cts-hmac-sha1-96) 7 PKIS$@SECURITY.BASEOS.QE (des-cbc-md5) 7 PKIS$@SECURITY.BASEOS.QE (aes128-cts-hmac-sha1-96) 7 PKIS$@SECURITY.BASEOS.QE (arcfour-hmac) 7 host/pkis.ipa.baseos.qe.QE (arcfour-hmac) 7 PKIS$@SECURITY.BASEOS.QE (aes256-cts-hmac-sha1-96) 7 host/pkis.QE (aes256-cts-hmac-sha1-96) 7 host/pkis.ipa.baseos.qe.QE (aes256-cts-hmac-sha1-96) # $ ssh Bender.qe.100.19 Last login: Fri May 24 14:34:15 2013 from 192.168.100.1 $ $ ssh Bender.qe.100.19 Permission denied, please try again.
In beta2 there are some improvements related to enterprise principals, especially the canonization which must be requested explicitly when using AD. Can you update to beta2, delete the cache and try again?
I'm packaging beta2 right now, I'll post links to Koji builds here so that if the builds worked, you could add karma.
(In reply to Jakub Hrozek from comment #9) > I'm packaging beta2 right now, I'll post links to Koji builds here so that > if the builds worked, you could add karma. http://koji.fedoraproject.org/koji/taskinfo?taskID=5495371
I see no progress here; see the details below. sssd-1.10.0-10.fc19.beta2.x86_64 realmd-0.14.1-1.fc19.x86_64 +-------------------------------------------- With one realm it works: # cat /etc/sssd/sssd.conf [sssd] domains = ad.baseos.qe config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/ad.baseos.qe] ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad $ ssh -o StrictHostKeyChecking=no bender.qe@fed1Your password will expire in 3 day(s). Last failed login: Fri Jun 14 14:39:12 CEST 2013 from 192.168.100.1 on ssh:notty There was 1 failed login attempt since the last successful login. Last login: Fri Jun 14 14:37:22 2013 from 192.168.100.1 [bender.qe@fed1 ~]$ +-------------------------------------------- With 2 don't: # realm -v join --user=Administrator security.baseos.qe ... # cat /etc/sssd/sssd.conf [sssd] domains = ad.baseos.qe, security.baseos.qe config_file_version = 2 services = nss, pam [nss] default_shell = /bin/bash [domain/ad.baseos.qe] ad_domain = ad.baseos.qe krb5_realm = AD.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad [domain/security.baseos.qe] ad_domain = security.baseos.qe krb5_realm = SECURITY.BASEOS.QE cache_credentials = True id_provider = ad krb5_store_password_if_offline = True ldap_id_mapping = True use_fully_qualified_names = True fallback_homedir = /home/%d/%u access_provider = ad $ SSHPASS='Pass2012!' sshpass -e ssh -o StrictHostKeyChecking=no bender.qe@fed1 Permission denied, please try again. $ $ SSHPASS='Pass2012!' sshpass -e ssh -o StrictHostKeyChecking=no bender.qe@fed1 Your password will expire in 2 day(s). Last login: Fri Jun 14 14:39:17 2013 from 192.168.100.1 [bender.qe@fed1 ~]$
Thank you for testing, can you attach the logs again?
Created attachment 761970 [details] sssd logs with sssd-1.10.0-10.fc19.beta2
(In reply to Sumit Bose from comment #12) > Thank you for testing, can you attach the logs again? Here it is: https://bugzilla.redhat.com/attachment.cgi?id=761970
Thank you for the logs. In theory it should have worked but it looks that the time is not exactly in sync in your two domains. If create a scratch build (http://koji.fedoraproject.org/koji/taskinfo?taskID=5511969) with two patches which should help SSSD to be more robust in your use case. It would be nice if you can test the new packages.
Great! It works with: sssd-1.10.0-11.fc19.beta2sb Thanks to not giving up!
Thank you for testing again and again. I've updated the upstream ticket and send the patches to sssd-devel for review.
Patches pushed upstream.
sssd-1.10.0-13.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.10.0-13.fc19
Package sssd-1.10.0-13.fc19: * should fix your issue, * was pushed to the Fedora 19 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=updates-testing sssd-1.10.0-13.fc19' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-2013-11899/sssd-1.10.0-13.fc19 then log in and leave karma (feedback).
Fixed in sssd-1.10.0-16 which is in stable updates already.
sssd-1.10.1-1.fc19 has been submitted as an update for Fedora 19. https://admin.fedoraproject.org/updates/sssd-1.10.1-1.fc19
sssd-1.10.1-1.fc19 has been pushed to the Fedora 19 stable repository. If problems still persist, please make note of it in this bug report.