SSSD and Microsoft KB4586845 / CVE-2020-17049

[schindlerd]

Hi,

We have a basic SSSD setup running on some of our Oralce Linux 7 machines to provide AD-authenticated access via SSH for example. After Microsofts Monthly Rollup KB4586845 being applied to our DCs (adressing CVE-2020-17049) it is no longer possible to gain system access via SSH with AD credentials. Only if I set "ad_server =" to a DC not having the MS patch installed it works again.

Is anyone else experiencing such issues after applying KB4586845?

I assume that this is not really an SSSD issue but more of a kerberos issue as such effects are also seen when using keytab in combination with Apache mod_auth_kerb for example.

Thanks in advance and kind regards,
Daniel

https://support.microsoft.com/de-de/help/4586845/windows-8-1-update
https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17049

[sumit-bose]

Hi,

please see discussion on freeipa-users about the issue. To cut is short there seems to be an issue with the current fix for CVE-2020-17049, see https://docs.microsoft.com/en-us/windows/release-information/status-windows-10-20h2#1522msgdesc for details.

I agree that this is currently not an SSSD issue.

bye,
Sumit

[schindlerd]

Microsoft has released updates that should resolve this issue but to me it doesn't seem to be fixed. We have applied the fix to one of our domain controlelrs but I'm still not able to authenticate against it.

I will try to leave and rejoin the domain against the patched domain controller to get a new keytab to see if it works then... I will share my results here if that is okay? ☺️

Anyway, here is a list for the optional update and the different platforms.

Server	Originating update	Optional update
Windows Server, version 20H2	KB4586781	KB4594440
Windows Server, version 2004	KB4586781	KB4594440
Windows Server, version 1909	KB4586786	KB4594443
Windows Server, version 1903	KB4586786	KB4594443
Windows Server, version 1809	KB4586793	KB4594442
Windows Server, version 1607	KB4586830	KB4594441
Windows Server 2019	KB4586793	KB4594442
Windows Server 2016	KB4586830	KB4594441
Windows Server 2012 R2	KB4586845	KB4594439
Windows Server 2012	KB4586834	KB4594438

[sumit-bose]

Hi,

yes, please share your results here. I guess most interesting would be the content of krb5_child.log with debug_level = 9 in the [domain/...] section of sssd.conf.

bye,
Sumit

[abbra]

If you do not see those 'optional updates' fixing the issue for you, please report it back to Microsoft as well. There is nothing yet we can fix on MIT Kerberos side, as far as I understand.

[schindlerd]

@abbra: You are correct 😄 and of course I have reported it back to Microsoft via their Service Hub.

In the meantime I have tried the re-join against our Active Directory to get a new keytab from the patched domain controller. I ensured that communication was only against this DC (iptables rules, adcli option to specify DC).
The machine got joined an it received a new keytab. When using this new keytab against the patched DC I still get the same error message that kerberos validation failed (krb5_child.log):
(2020-11-26 8:40:54): [krb5_child[26956]] [validate_tgt] (0x0020): TGT failed verification using key for ...

When I again set the option to talk only to the un-patched/old DC it works also with the new keytab.

I will report back when Microsoft responds.

[sumit-bose]

Hi,

thanks for the feeback. I wonder if you can share some details at which step the ticket validation fails? Although I agree that a solution most probably should come from Microsoft I'd like to understand if maybe some fallback on the AD side triggered something which can be fixed on the Linux side, e.g. an encryption type currently not allowed by the client-side configuration.

If you set debug_level = 9 in the [domain/...] section of sssd.conf you should see krb5 trace messages. Following the debug message with [validate_tgt] SSSD would try to request a service ticket for a keytab entry and after this request is send to the AD DC you should see a message like TGS request result: 0/Success. Next would be the decryption which is logged with messages like

Decrypted AP-REQ with specified server principal your/principal@YOUR.REALM: aes256-cts/ABFA
AP-REQ ticket: user@YOUR.REALM -> your/principal@YOUR.REALM, session key aes256-cts/989C

If you cannot share a sanitized version of krb5_child.log I wonder if you can say if:

• the user trying to authenticate is from the same domain as the computer is joined to?
• already requesting the service ticket fails or only the decryption and what the Kerberos error messages are
• the same encryption types (aes256-cts in the example above) are used by the DC with and without the patch

Thanks.

bye,
Sumit

[schindlerd]

sanitized-krb5_child_log-defunct-DC.txt

I attached a sanitized krb5_child.log for the not working/patched DC.

• the user trying to authenticate is from the same domain
• the encryption type is for both cases (working/not working) the same for what I see from the logs aes256-cts

(2020-11-26 8:40:54): [krb5_child[26956]] [sss_child_krb5_trace_cb] (0x4000): [26956] 1606376454.6362: Generated subkey for TGS request: aes256-cts/5E7F
(2020-11-26 8:40:54): [krb5_child[26956]] [sss_child_krb5_trace_cb] (0x4000): [26956] 1606376454.6363: etypes requested in TGS request: aes256-cts, aes128-cts, aes256-sha2, aes128-sha2, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts

Thanks!

[sumit-bose]

Hi,

thanks, so it is already the TGS request with failed. Calling

kinit user@SANITIZED
kvno 'host$@SANITIZED'

on the command line should do the same steps as SSSD does and hence show the same Generic error (see e-text) error message. If that's the case you might want to forward those steps to Microsoft as easy reproducer.

bye,
Sumit

[schindlerd]

@sumit-bose I was able to reproduce with kinit/kvno and forwarded the information to MS.

First feedback from MS: They suspect that our issue is related to the fact that the update containing CVE-2020-17049 is not consitently deployed across all DCs. I will reproduce the issue again and provide MS with more logs so they can verify.

[sumit-bose]

Hi,

thanks for the feedback. Please let us know if there are further updates and feel free to ask if you or Microsoft need more details about the Linux client side.

bye,
Sumit

[schindlerd]

Microsoft seems to have identified the described issue regarding their code implementation for addressing CVE-2020-17049.

Summary: All OOB patches must be deployed to all production DCs and then a workaround has to be implemented.

Here is the info from my current support request:

===================================
Issue:
New regression in CVE-2020-17049 which added Kerberos Service Ticket signing prevents unix clients from obtaining a service ticket with PerformTicketSignature = 1

The request completely fails with the following signature rather than returning a tgs without a pac.

KdcGetSidsFromTgt in KdcBuildAuthzContext failed 3c

The signature above indicates that the Unix client is unable to acquire a service ticket because the code in CVE-2020-17049 is failing.

This is a different failure the previous signature where Unix clients fail to request a new signature when unable to renew existing service tickets not marked as renewable

Workaround:
Deploy 2020 11 OOB or 2020 12B Windows Updates on all production DCs AND set PerformTicketSignature = 0 on all DC role computers. 
This configuration disables Kerberos service ticket signing protections in CVE-2020-17049 but allows enterprise customers to install 2020 11B, 2020 12B and superseding Windows Updates on production clients and serves. 

OR 

Set the UF_NO_AUTH_DATA_REQUIRED 0x02000000 in UserAccountControl for the principal that is the client for the service ticket (i.e. the Lixux computer in the case that triggered this investigation / KB article).  

====================================

⚠️ All information provided come without warranty and are under on going investigations!

[schindlerd]

Microsoft has released fix in their monthly rollup addressing the described issue:
"Addresses an issue in which a principal in a trusted MIT realm fails to obtain a Kerberos service ticket from Active Directory domain controllers (DC). This occurs on devices that installed Windows Updates that contain CVE-2020-17049 protections and configured PerfromTicketSignature to 1 or higher. These updates were released between November 10, 2020 and December 8, 2020. Ticket acquisition also fails with the error, “KRB_GENERIC_ERROR”, if callers submit a PAC-less Ticket Granting Ticket (TGT) as an evidence ticket without providing the USER_NO_AUTH_DATA_REQUIRED flag. "

Windows Server 2012 R2 - KB4598285 - https://support.microsoft.com/en-us/help/4598285/windows-8-1-update
Windows Server 2016 - KB4598243 - https://support.microsoft.com/en-us/help/4598243/windows-10-update-kb4598243

We will test it next week but I'm confident that it will resolve the issue 😄

[schindlerd]

Microsoft has released fix in their monthly rollup addressing the described issue:
"Addresses an issue in which a principal in a trusted MIT realm fails to obtain a Kerberos service ticket from Active Directory domain controllers (DC). This occurs on devices that installed Windows Updates that contain CVE-2020-17049 protections and configured PerfromTicketSignature to 1 or higher. These updates were released between November 10, 2020 and December 8, 2020. Ticket acquisition also fails with the error, “KRB_GENERIC_ERROR”, if callers submit a PAC-less Ticket Granting Ticket (TGT) as an evidence ticket without providing the USER_NO_AUTH_DATA_REQUIRED flag. "

Windows Server 2012 R2 - KB4598285 - https://support.microsoft.com/en-us/help/4598285/windows-8-1-update
Windows Server 2016 - KB4598243 - https://support.microsoft.com/en-us/help/4598243/windows-10-update-kb4598243

We will test it next week but I'm confident that it will resolve the issue 😄

The above Patch-Rollup finally fixed the issue 😃

[sumit-bose]

Hi @schindlerd,

thanks a lot for letting us know about your progress and documenting the required updates.

bye,
Sumit