Univention Bugzilla – Bug 46745
Disabling DES keys with Samba not possible: S4-Connector: sync_from_ucs: Primary:Kerberos missing
Last modified: 2020-10-14 15:28:33 CEST
This S4-Connector traceback appears in some Tickets: ============================================================================== 25.03.2018 06:25:46,646 LDAP (PROCESS): sync from ucs: [ user] [ add] cn=guest,cn=users,dc=domain,dc=local 25.03.2018 06:25:46,743 LDAP (WARNING): calculate_supplementalCredentials: Primary:Kerberos-Newer-Keys num_keys = 1 25.03.2018 06:25:46,743 LDAP (WARNING): calculate_supplementalCredentials: ctr4.key.keytype: 18 25.03.2018 06:25:46,743 LDAP (WARNING): calculate_supplementalCredentials: Primary:Kerberos-Newer-Keys num_old_keys = 4 25.03.2018 06:25:46,743 LDAP (WARNING): calculate_supplementalCredentials: ctr4.old_key.keytype: 18 25.03.2018 06:25:46,744 LDAP (WARNING): calculate_supplementalCredentials: ctr4.old_key.keytype: 17 25.03.2018 06:25:46,744 LDAP (WARNING): calculate_supplementalCredentials: ctr4.old_key.keytype: 3 25.03.2018 06:25:46,744 LDAP (WARNING): calculate_supplementalCredentials: ctr4.old_key.keytype: 1 25.03.2018 06:25:46,834 LDAP (WARNING): sync failed, saved as rejected /var/lib/univention-connector/s4/1510818361.430555 25.03.2018 06:25:46,898 LDAP (WARNING): Traceback (most recent call last): File "/usr/lib/pymodules/python2.6/univention/s4connector/__init__.py", line 791, in __sync_file_from_ucs or (not old_dn and not self.sync_from_ucs(key, object, premapped_ucs_dn, old_dn, old, new))): File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/__init__.py", line 2520, in sync_from_ucs f(self, property_type, object) File "/usr/lib/pymodules/python2.6/univention/s4connector/s4/password.py", line 641, in password_sync_ucs_to_s4 s4connector.lo_s4.lo.modify_ext_s(compatible_modstring(object['dn']), modlist, serverctrls=[ ctrl_bypass_password_hash ]) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 808, in modify_ext_s return self._apply_method_s(SimpleLDAPObject.modify_ext_s,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 766, in _apply_method_s return func(self,*args,**kwargs) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 295, in modify_ext_s return self.result(msgid,all=1,timeout=self.timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 422, in result res_type,res_data,res_msgid = self.result2(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 426, in result2 res_type, res_data, res_msgid, srv_ctrls = self.result3(msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 432, in result3 ldap_result = self._ldap_call(self._l.result3,msgid,all,timeout) File "/usr/lib/python2.6/dist-packages/ldap/ldapobject.py", line 96, in _ldap_call result = func(*args,**kwargs) CONSTRAINT_VIOLATION: {'info': '0000202F: Primary:Kerberos missing at ../source4/dsdb/samdb/ldb_modules/password_hash.c:320', 'desc': 'Constraint violation'} ============================================================================== I've seen this for guest and also for krbtgt IIRC. Apparently in these cases the accounts only have aes256-cts-hmac-sha1-96 (18) hashes in OpenLDAP. We should collect information as to how this may happen.
I guess the first thing to check would be the supported encryption types for those accounts. E.g. for Guest: univention-s4search sAMAcctountName=Guest \ msDS-SupportedEncryptionTypes https://msdn.microsoft.com/en-us/library/ee808210.aspx
Sorry, that attribute is not stored on the user object but on the object of the domain controller: univention-s4search msDS-SupportedEncryptionTypes=* msDS-SupportedEncryptionTypes
Uhm, actually not. It's stored per user: https://blogs.msdn.microsoft.com/openspecification/2011/05/30/windows-configurations-for-kerberos-supported-encryption-type/
Ok, Comment 1 2 and 3 lead in the wrong direction here. This tracback occurrs during "sync from ucs" and OpenLDAP only supplies AES256 Keys (Keytype 18=0x12) in this situation while the previous supplementalCredentials at that moment still present in Samba/AD had the full set of 4 hash types in the structure Primary:Kerberos-Newer-Keys. The Samba source code (source4/dsdb/samdb/ldb_modules/password_hash.c) doesn't allow modifications of supplementalCredentials if the number of provided hash types is less than before. So, some program has modified the set of krb5key attributes. Maybe the permitted_enctypes (etc) in /etc/krb5.conf had been adjusted and then the password was changed via udm/UMC?
I have noticed exactly the same traceback during a paedML 7.1 training (4.3-5e682) on all environments we provided for the training. Affected user was "guest" I was able to solve the problem by setting a new password for "guest" in UMC. After this modification the rejected transaction have been synced sucessfully.
I assume this is not fixed in UCS 4.4
Happening for ALL users in a customer environment (UCS installed since UCS 2.x) and recently did the Samba3 -> Samba4 migration. ================================= Sobald man in sssd.conf von "auth_provider = krb5" auf "auth_provider = ldap" umstellt, kann man sich wieder einloggen. Sobald der User sein Passwort einmal im UDM ändert, kann er sich auch per "auth_provider = krb5" wieder einloggen. ================================= Further details in the ticket.
For reference: that's Ticket #2020072421000517. - UCS Domain updated from UCS 2.x - Upgrade from UCS 4.2-5 errata539 to UCS 4.4-5 errata652, including migration from Samba3 to Samba4 - New setup works in test env, no error reported - But resync of users from UCS to Samba4 triggers the traceback. Please request the krb5Key values and note them at the Ticket.
krb5Key:: ... # krb5_keytype: aes256-cts-hmac-sha1-96 (18) # keyblock: ... # saltstring: FOO.DOMAIN.NETuser krb5Key:: ... # krb5_keytype: aes128-cts-hmac-sha1-96 (17) # keyblock: ... # saltstring: FOO.DOMAIN.NETuser krb5Key:: ... # krb5_keytype: des3-cbc-sha1 (16) # keyblock: ... # saltstring: FOO.DOMAIN.NETuser krb5Key:: ... # krb5_keytype: arcfour-hmac-md5 (23) # keyblock: ... # as NThash: ... # saltstring: FOO.DOMAIN.NETuser des-cbc-md5 and des-cbc-crc are missing. If you look into the source code line reported in the traceback: source4/dsdb/samdb/ldb_modules/password_hash.c:320 ======================================================================= if (scpk == NULL) { /* * If Primary:Kerberos is missing w2k8r2 reboots * when a password is changed. */ return ldb_error(ldb, LDB_ERR_CONSTRAINT_VIOLATION, "Primary:Kerberos missing"); } ======================================================================= So, there's a reason why. We'll have to AD-Takover a Windows AD 2008R2 and check how the supplementalCredentials are filled there. According to https://support.microsoft.com/en-us/help/977321/kdc-event-id-16-or-27-is-logged-if-des-for-kerberos-is-disabled Windows 2008R2 doesn't use DES-CBC-CRC and DES-CBC-MD5 any longer, maybe using this GPO setting (Kudos to Julia): https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-configure-encryption-types-allowed-for-kerberos
For the synchronization of the Kerberos Keys for Bug #50492 we worked around the missing DES_CBC_CRC by filling the keylist with a "Dummy Hash", which is basically the NT_HASH in the S4-Connector in Commit 78de0ee5991 ``` » » # Windows Server 2012 does not always send the des encryption types. » » # Samba does not allow a key number != 4, which is why we add a "dummy" hash. » » if not krb5_des_crc: » » » next_key = drsblobs.package_PrimaryKerberosKey4() » » » next_key.keytype = 4294967156 » » » next_key.value = nt_hash » » » if nt_hash: » » » » next_key.value_len = len(nt_hash) » » » else: » » » » next_key.value_len = 0 » » » kerberosKey4list.append(next_key) ``` AFAIR only the DES_CBC_CRC was missing in this use-case. Replacing both DES_CBC_CRC and DES_CBC_MD5 with such a dummy hash (always creating a Primary:Kerberos) if both DES are missing led to some "subcontext errors". https://forge.univention.org/bugzilla/show_bug.cgi?id=50492#c13 Some additional logic may be necessary to replace Primary:Kerberos as a whole.
As you pointed out via chat, Samba 4.12 removed DES support https://wiki.samba.org/index.php/Samba_4.12_Features_added/changed#Retiring_DES_encryption_types_in_Kerberos https://bugzilla.samba.org/show_bug.cgi?id=14202 but predictably that caused a regression: https://bugzilla.samba.org/show_bug.cgi?id=14354
Just for understanding: When unsecure encryption types (like DES) are not created in LDAP our Samba complains about the mmissing? So currently there is not way to disable unsecure DES keys?
Created attachment 10495 [details] Allow des-cbc-md5 to be dummy hash As we did with the des_cbc_crc Hash, des_cbc_md5 can be replaced with a dummy hash, filled with the arcfour hash. The attached samba patch allows the des_cbc_md5 to be of type dummy_hash. I committed a patch for the s4connector in branch jbremer/bug46745_disable_cbc_keys_samba, which also replaces "primary:kerberos" if des keys are missing. https://git.knut.univention.de/univention/ucs/-/tree/jbremer/bug46745_disable_cbc_keys_samba If allow_weak_crypto is set to false, no des keys will be created. No ticket can be acquired any more trying to use a key like that. root@master:~# kinit -e des_cbc_md5 testuser kinit: unrecognized enctype: des_cbc_md5
I applied the patches and added a test case - 514disable_des_enctype Waiting for test result. bea315f78c Bug #46745: yaml s4-connector 1fd21f3ac5 Bug #46745: Changelogs + YAML wip 88fee7f777 Bug #46745: Add test ceb49fb081 Bug #46745 replace all des keys with nt_hash if disabled ------ Package: samba Version: 2:4.10.1-1A~4.4.0.202010071533 Branch: ucs_4.4-0 Scope: errata4.4-6 Package: univention-s4-connector Version: 13.0.2-80A~4.4.0.202010071635 Branch: ucs_4.4-0 Scope: errata4.4-6 Package: ucs-test Version: 9.0.5-12A~4.4.0.202010071639 Branch: ucs_4.4-0 Scope: errata4.4-6
TODO - merge request ? OK - test OK - samba/univention OK - jenkins OK - yaml But, this does not disable DES in samba. Samba still creates DES keys on pwchange and they are usable if a client wants to authenticate with DES. DES keys are only deactivated in samba with UCS 5.0.
Added merge request: https://git.knut.univention.de/univention/ucs/-/merge_requests/17 Added the samba patch: svn revision 19170
OK
<https://errata.software-univention.de/#/?erratum=4.4x772> <https://errata.software-univention.de/#/?erratum=4.4x773>