Learn more about these different git repos.
Other Git URLs
When configuring the Windows 2012R2 AD GPO (CIS Level 1) to not use RC4 (DES disabled by default) authentication becomes seemingly impossible with the following setup:
Domain Controllers: Windows 2012 R2 (forest / domain level 2012R2)
Member Servers: RHEL 6.7 (updated and rebooted to apply latest kernel updates)
Configuration used: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server - LDAP schema = ad - Start_TLS = enabled - SASL_Mech = GSSAPI
When changing the GPO to disable the use of RC4 on the domain controllers (effectively limiting use to AES128-CTR and AES256-CTR) authentication for the interactive session from my RHEL server becomes impossible.
Messages log gives back this: sssd[be[default]]: Could not start TLS encryption. TLS error -5961:TCP connection reset by peer
When using a different debug level the following feedback is noted: TLS: error: connect - force handshake failure: errno 104 - moznss error -5961 - No specific feedback is found when searching around for this specific failure. - This message is also shown when using ldapwhoami -Z -d8 ..., so not completely sure is this is ultimately related to SSSD.
This guide: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server should not be used for new setups..
Is there a reason you can't use id_provider=ad ? The ldap/krb5 combo should only be used if you can't join the system to the domain for some reason.
And as I told you in the downstream bug, this error comes from the NSS crypto library.
_comment0: This guide: https://fedorahosted.org/sssd/wiki/Configuring%20sssd%20to%20authenticate%20with%20a%20Windows%202008%20Domain%20Server
Is there a reason you can't use id_provider=ad ? The ldap/krb5 combo should only be used if you can't join the system to the domain for some reason. => 1455363739689966
System is succesfully joined to the domain (both ldap/krb5 combo and ad guides configure krb5.conf for that use). Tried the AD provider as well. Same error applies, so I already figured it would be related to a lower level component. Is this error actually coming from NSS or moreover from KRB5Libs?
Found an entry that specified the following for krb5.conf: # Without these settings, sssd will fail, although kinit may still work permitted_enctypes = arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 default_tkt_enctypes = arcfour-hmac-md5 aes128-cts-hmac-sha1-96 aes256-cts-hmac-sha1-96 I will be trying the above and see what happens. If it resolves issues then one could state aes ciphers are not correctly bound?
I'm going to close this bug, as far as I can see from this ticket and downstream bug report, the issue is in the configuration of the underlying crypto libraries, not sssd.
resolution: => worksforme status: new => closed
Fields changed
rhbz: => 0
Metadata Update from @espaans: - Issue set to the milestone: NEEDS_TRIAGE
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/3997
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.