Hello,
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error KDC has no support for encryption type
which prevents authentication. The server has been remove and rejoin to the Active Directory with realm join -U user@DOMAIN. The object has been created in the AD (2012R2 in case it would be relevant) with SPNs: host/HOSTNAME host/fqdn RestrictedKrbHost/HOSTNAME RestrictedKrbHost/fqdn
sssd_domain.log contains (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$ (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type) (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)] (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000): Waiting for child [2234]. (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100): child [2234] finished successfully. (2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158227]: Authentication Failed (2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2095
We have tried numerous things with kinit for example : [root@hostname sssd]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal ---- -------------------------------------------------------------------------- 2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96) 2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
[root@hostname sssd]# kinit -V -k Using new cache: persistent:0:krb_ccache_PECiZeh Using principal: host/fqdn@DOMAIN kinit: Client 'host/fqdn@domain' not found in Kerberos database while getting initial credentials
[root@hostname sssd]# kinit -V -k HOSTNAME$ Using new cache: persistent:0:krb_ccache_cFLtQ1H Using principal: HOSTNAME$@DOMAIN kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while getting initial credentials
We have added krb5_validate = False in sssd.conf and [libdefaults] allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 in krb5.conf
and set msDS-SupportedEncTypes to 31 (which means "all" if I understand correctly) on the AD object.
With no success.
I do not know what to do now :-)
Thanks for your help
Jeremy
I believe DES is not even compiled into krb5-utils on 8.3
Pat
On Wed, 2021-05-05 at 21:27 +0200, Jeremy Monnet wrote:
Hello,
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error KDC has no support for encryption type
which prevents authentication. The server has been remove and rejoin to the Active Directory with realm join -U user@DOMAIN. The object has been created in the AD (2012R2 in case it would be relevant) with SPNs: host/HOSTNAME host/fqdn RestrictedKrbHost/HOSTNAME RestrictedKrbHost/fqdn
sssd_domain.log contains (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$ (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type) (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)] (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000): Waiting for child [2234]. (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100): child [2234] finished successfully. (2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158227]: Authentication Failed (2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2095
We have tried numerous things with kinit for example : [root@hostname sssd]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96) 2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
[root@hostname sssd]# kinit -V -k Using new cache: persistent:0:krb_ccache_PECiZeh Using principal: host/fqdn@DOMAIN kinit: Client 'host/fqdn@domain' not found in Kerberos database while getting initial credentials
[root@hostname sssd]# kinit -V -k HOSTNAME$ Using new cache: persistent:0:krb_ccache_cFLtQ1H Using principal: HOSTNAME$@DOMAIN kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while getting initial credentials
We have added krb5_validate = False in sssd.conf and [libdefaults] allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 in krb5.conf
and set msDS-SupportedEncTypes to 31 (which means "all" if I understand correctly) on the AD object.
With no success.
I do not know what to do now :-)
Thanks for your help
Jeremy _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_... Do not reply to spam on the list, report it: https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfr...
Am Wed, May 05, 2021 at 07:34:18PM +0000 schrieb Patrick Riehecky:
I believe DES is not even compiled into krb5-utils on 8.3
Pat
On Wed, 2021-05-05 at 21:27 +0200, Jeremy Monnet wrote:
Hello,
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error KDC has no support for encryption type
Hi,
this is most probably about the rc4 encryption type which is still heavily used in AD environments but already disabled by default in RHEL-8.3. It can be re-enabled by calling
update-crypto-policies --set DEFAULT:AD-SUPPORT
see RHEL-8.3 Release Notes at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... for details.
After that you have to re-join or at least update your keytab becasue ...
which prevents authentication. The server has been remove and rejoin to the Active Directory with realm join -U user@DOMAIN. The object has been created in the AD (2012R2 in case it would be relevant) with SPNs: host/HOSTNAME host/fqdn RestrictedKrbHost/HOSTNAME RestrictedKrbHost/fqdn
sssd_domain.log contains (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$ (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type) (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)] (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000): Waiting for child [2234]. (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100): child [2234] finished successfully. (2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158227]: Authentication Failed (2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2095
We have tried numerous things with kinit for example : [root@hostname sssd]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96) 2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
... as you can see currently there are only AES keys in the keytab. After a re-join or key update you should see rc4 keys as well.
HTH
bye, Sumit
[root@hostname sssd]# kinit -V -k Using new cache: persistent:0:krb_ccache_PECiZeh Using principal: host/fqdn@DOMAIN kinit: Client 'host/fqdn@domain' not found in Kerberos database while getting initial credentials
[root@hostname sssd]# kinit -V -k HOSTNAME$ Using new cache: persistent:0:krb_ccache_cFLtQ1H Using principal: HOSTNAME$@DOMAIN kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while getting initial credentials
We have added krb5_validate = False in sssd.conf and [libdefaults] allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 in krb5.conf
and set msDS-SupportedEncTypes to 31 (which means "all" if I understand correctly) on the AD object.
With no success.
I do not know what to do now :-)
Thanks for your help
Jeremy _______________________________________________ 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://urldefense.proofpoint.com/v2/url?u=https-3A__docs.fedoraproject.org_... List Guidelines: https://urldefense.proofpoint.com/v2/url?u=https-3A__fedoraproject.org_wiki_... List Archives: https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.fedorahosted.org_... Do not reply to spam on the list, report it: https://urldefense.proofpoint.com/v2/url?u=https-3A__pagure.io_fedora-2Dinfr...
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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hello,
On Thu, May 6, 2021 at 7:40 AM Sumit Bose sbose@redhat.com wrote:
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error KDC has no support for encryption type
Hi,
this is most probably about the rc4 encryption type which is still heavily used in AD environments but already disabled by default in RHEL-8.3. It can be re-enabled by calling
update-crypto-policies --set DEFAULT:AD-SUPPORT
see RHEL-8.3 Release Notes at https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/htm... for details.
https://access.redhat.com/solutions/5728591 that is written here also, we couldn't find it yesterday unfortunately.
After that you have to re-join or at least update your keytab becasue ...
... as you can see currently there are only AES keys in the keytab. After a re-join or key update you should see rc4 keys as well.
I have now (DEPRECATED:arcfour-hmac) in the keytab, and authentication works after rejoining the AD !
Thank you very much !
Jeremy
On 5/6/21 9:44 AM, Jeremy Monnet wrote:
I have now (DEPRECATED:arcfour-hmac) in the keytab, and authentication works after rejoining the AD !
RC4 is deprecated for very good reasons.
You should rather try to set attribute msDs-supportedEncryptionTypes in the service / host entry to enable using AES-256.
Ciao, Michael.
On Wed, May 5, 2021 at 3:27 PM Jeremy Monnet jmonnet@gmail.com wrote:
[root@hostname sssd]# kinit -V -k Using new cache: persistent:0:krb_ccache_PECiZeh Using principal: host/fqdn@DOMAIN kinit: Client 'host/fqdn@domain' not found in Kerberos database while getting initial credentials
You cannot knit against host/fqdn unless sAMAccountName was set to host/fqdn when the host was joined to AD.
[root@hostname sssd]# kinit -V -k HOSTNAME$ Using new cache: persistent:0:krb_ccache_cFLtQ1H Using principal: HOSTNAME$@DOMAIN kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while getting initial credentials
This may mean that the KDC does not support the aes encryption types (only rc4-hmac). You can test this by logging in as a normal user with a valid TGT and running:
$ kvno -e aes256-cts-hmac-sha1-96 'HOSTNAME$' $ kinit $ kvno -e aes128-cts-hmac-sha1-96 'HOSTNAME$' $ kinit $ kvno -e arcfour-hmac 'HOSTNAME$'
(The kinit commands are to flush any successfully-acquired service ticket; if the preceding kvno command fails, you can skip them.)
We have added krb5_validate = False in sssd.conf and [libdefaults] allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 in krb5.conf
If you mean you literally edited /etc/krb5.conf, then this will not work, because the "includedir" directive at the top of /etc/krb5.conf will read the configuration files in the /etc/krb5.conf.d first, and the crypto-policies file will set permitted_enctypes to whatever the system-wide crypto policy is. Because the first setting wins, by the time your settings in /etc/krb5.conf are parsed, permitted_enctypes has already been set and your attempt to override it will (silently!) fail.
You should restore the package default /etc/krb5.conf file and perform any overrides in a separate file in /etc/krb5.conf.d, selecting a filename that will sort lexicographically before the other files; e.g., create /etc/krb5.conf.d/50-override with:
[libdefaults] permitted_enctypes = aes rc4
If the problem is that your AD only supports rc4, then performing "kinit -V -k 'HOSTNAME$'" should then succeed.
Jeremy,
First off, this is not a sssd problem. You've proven that by your kinit -k attempts failing. This is an underlying problem between your kerberos client, your AD DC and your /etc/krb5.keytab file. Once you fix this underlying issue, I expect sssd will work.
Your AD domain may be accepting only weak crypto ciphers. By default, RHEL8 sets crypto-policies to DEFAULT.
You can do this:
update-crypto-policies --show
to see the current crypto policy. As a simple test, you can do this:
update-crypto-policies --set LEGACY
To allow all the old (weak) RHEL7 crypto ciphers (like 3des-cbc and arcfour-hmac).
It's not advisable to leave crypto-polcies at LEGACY -- that accepts some truly weak ciphers.
Spike
On Wed, May 5, 2021 at 2:27 PM Jeremy Monnet jmonnet@gmail.com wrote:
Hello,
We upgraded today a RHEL 7.9 to RHEL8.3. We encounter now that error KDC has no support for encryption type
which prevents authentication. The server has been remove and rejoin to the Active Directory with realm join -U user@DOMAIN. The object has been created in the AD (2012R2 in case it would be relevant) with SPNs: host/HOSTNAME host/fqdn RestrictedKrbHost/HOSTNAME RestrictedKrbHost/fqdn
sssd_domain.log contains (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0100): Executing sasl bind mech: GSS-SPNEGO, user: HOSTNAME$ (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x4000): SASL: GSSAPI client step 1 (2021-05-05 21:06:55): [be[bcrs.fr]] [ad_sasl_log] (0x0040): SASL: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type) (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (2021-05-05 21:06:55): [be[bcrs.fr]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC has no support for encryption type)] (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x1000): Waiting for child [2234]. (2021-05-05 21:06:55): [be[bcrs.fr]] [child_sig_handler] (0x0100): child [2234] finished successfully. (2021-05-05 21:06:55): [be[bcrs.fr]] [sdap_cli_connect_recv] (0x0040): Unable to establish connection [1432158227]: Authentication Failed (2021-05-05 21:06:55): [be[bcrs.fr]] [_be_fo_set_port_status] (0x8000): Setting status: PORT_NOT_WORKING. Called from: src/providers/ldap/sdap_async_connection.c: sdap_cli_connect_recv: 2095
We have tried numerous things with kinit for example : [root@hostname sssd]# klist -ke Keytab name: FILE:/etc/krb5.keytab KVNO Principal
2 HOSTNAME$@DOMAIN (aes128-cts-hmac-sha1-96) 2 HOSTNAME$@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 host/fqdn@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/HOSTNAME@DOMAIN (aes256-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes128-cts-hmac-sha1-96) 2 RestrictedKrbHost/fqdn@DOMAIN (aes256-cts-hmac-sha1-96)
[root@hostname sssd]# kinit -V -k Using new cache: persistent:0:krb_ccache_PECiZeh Using principal: host/fqdn@DOMAIN kinit: Client 'host/fqdn@domain' not found in Kerberos database while getting initial credentials
[root@hostname sssd]# kinit -V -k HOSTNAME$ Using new cache: persistent:0:krb_ccache_cFLtQ1H Using principal: HOSTNAME$@DOMAIN kinit: Keytab contains no suitable keys for HOSTNAME$@DOMAIN while getting initial credentials
We have added krb5_validate = False in sssd.conf and [libdefaults] allow_weak_crypto = true default_tgs_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 default_tkt_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 permitted_enctypes = aes256-cts-hmac-sha1-96 rc4-hmac des-cbc-crc des-cbc-md5 in krb5.conf
and set msDS-SupportedEncTypes to 31 (which means "all" if I understand correctly) on the AD object.
With no success.
I do not know what to do now :-)
Thanks for your help
Jeremy _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
Hi,
To allow all the old (weak) RHEL7 crypto ciphers (like 3des-cbc and arcfour-hmac).
It's not advisable to leave crypto-polcies at LEGACY -- that accepts some truly weak ciphers.
You are right, only I do not decide the AD version used... 2012R2 is still supported by Microsoft, so people are not eager to migrate to 2016 or 2019. That brings me to another question : - Is there a reference to supported ciphers, eg will rhel without enabling weak ciphers will work out of the box with an AD 2016 (that could another argument to upgrade) ?
And yes you are right, the issue is pure kerberos, sssd just sits on top...
Regards,
Jeremy
Jeremy,
My understanding is that even AD 2016 will support arcfour-hmac (even though it's deprecated and not recommended). Local company AD teams will make the decision to stop supporting arcfour-hmac or not. (for instance, our company's team tried -- and it broke something to do with cross-domain auth. So they reverted.)
I don't know when AD quit supporting 3des-cbc.
Spike
On Sun, May 9, 2021 at 5:09 PM Jeremy Monnet jmonnet@gmail.com wrote:
Hi,
To allow all the old (weak) RHEL7 crypto ciphers (like 3des-cbc and
arcfour-hmac).
It's not advisable to leave crypto-polcies at LEGACY -- that accepts
some truly weak ciphers.
You are right, only I do not decide the AD version used... 2012R2 is still supported by Microsoft, so people are not eager to migrate to 2016 or 2019. That brings me to another question :
- Is there a reference to supported ciphers, eg will rhel without
enabling weak ciphers will work out of the box with an AD 2016 (that could another argument to upgrade) ?
And yes you are right, the issue is pure kerberos, sssd just sits on top...
Regards,
Jeremy _______________________________________________ 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-users@lists.fedorahosted.o... Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
On Sun, May 9, 2021 at 9:23 PM Spike White spikewhitetx@gmail.com wrote:
My understanding is that even AD 2016 will support arcfour-hmac (even though it's deprecated and not recommended).
Correct; we are using it with Windows Server 2016.
Local company AD teams will make the decision to stop supporting arcfour-hmac or not. (for instance, our company's team tried -- and it broke something to do with cross-domain auth. So they reverted.)
In order to kill arcfour-hmac-md5 you must ensure that literally *every* Kerberos principal in your AD domain has at least one of the Kerberos encryption types enabled. Alas, that’s a high bar…
On Sun, May 9, 2021 at 6:09 PM Jeremy Monnet jmonnet@gmail.com wrote:
It's not advisable to leave crypto-polcies at LEGACY -- that accepts some truly weak ciphers.
You are right, only I do not decide the AD version used... 2012R2 is still supported by Microsoft, so people are not eager to migrate to 2016 or 2019.
Microsoft has supported the AES Kerberos encryption types since Windows Server 2008:
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-se...)
That brings me to another question : - Is there a reference to supported ciphers, eg will rhel without enabling weak ciphers will work out of the box with an AD 2016 (that could another argument to upgrade) ?
You need to join the computer to AD such that the encryption types used in the keytab file agree with the encryption types added to AD and the value of the msDs-supportedEncryptionTypes attribute.
From the keytab you posted, the join operation thought it had successfully created the aes128-cts-hmac-sha1-96 and aes256-cts-hmac-sha1-96 encryption types in AD, because it added those encryption types to the keytab file. Either it failed to do that, or else it failed to set the msDs-supportedEncryptionTypes attribute correctly.
Honestly, the best tool we have found to join computers to AD is msktutil:
https://github.com/msktutil/msktutil/
E.g.:
$ msktutil create \ --base OU=Linux,OU=Servers \ --computer-name $(echo "${HOSTNAME}" | sed -e 's/..*$//g' | tr '[:lower:]' '[:upper:]') --hostname "${HOSTNAME}" \ --upn "host/${HOSTNAME}" \ --enctypes 0x18 \ --verbose
Adjust the argument for --base to reflect the OU where you wish to place the host machine account.
sssd-users@lists.fedorahosted.org