IPA Kerberos Trust problem with Windows Update kb4586830

[Jerry Träskelin]

Hello,

first let me introduce our setup:

- FreeIPA 4.6.5 (I know it's a bit old already) masters CentOS 7
- FreeIPA 4.6.6 client CentOS 7
- Windows Server 2016 DCs
- Netapp Filer NFS server

There's a two-way trust between the AD and IPA domains which works nicely. User accounts exist in the AD domain and can be used on IPA members as well. The Netapp has a computer account in AD. IPA clients mount NFSv4 shares using krb5p encryption.

The problem:

After installing the latest Windows updates on the DCs (kb4586830) the Kerberos authentication to the file server started failing. We were able to identify it as a Kerberos problem by trying to mount without Kerberos, which worked but of course nothing was accessible. After trying a bunch of different things and reading a lot of logs, we finally uninstalled the update on the DCs and everything worked again. There's not a whole lot of error messages to go on even though log/debug levels were set to the highest. The mounting client will simply say "mount.nfs: access denied by server while mounting". On the DC I was a able to find a Failure Code 0x3C for the Kerberos ticket request. 0x3C is a generic error, according to https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing.... None of the possible causes listed by Microsoft apply to our situation.

Since uninstalling the update on the DCs made the problem go away, I guess it's safe to assume that Microsoft changed something. The update notes don't really mention anything useful, but after some googling I found https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17049 which seems like something that could have caused this. Is there some settings in the IPA that could be changed to comply with the changes made by Microsoft?

Thanks!

[Alexander Bokovoy]

Hi Jerry,

On ma, 16 marras 2020, Jerry Träskelin via FreeIPA-users wrote:
> Hello,
>
> first let me introduce our setup:
> FreeIPA 4.6.5 (I know it's a bit old already) masters CentOS 7
> FreeIPA 4.6.6 client CentOS 7
> Windows Server 2016 DCs
> Netapp Filer NFS server
>
> There's a two-way trust between the AD and IPA domains which works
> nicely. User accounts exist in the AD domain and can be used on IPA
> members as well. The Netapp has a computer account in AD. IPA clients
> mount NFSv4 shares using krb5p encryption.
>
> The problem:
>
> After installing the latest Windows updates on the DCs (kb4586830) the
> Kerberos authentication to the file server started failing. We were
> able to identify it as a Kerberos problem by trying to mount without
> Kerberos, which worked but of course nothing was accessible. After
> trying a bunch of different things and reading a lot of logs, we
> finally uninstalled the update on the DCs and everything worked again.
> There's not a whole lot of error messages to go on even though
> log/debug levels were set to the highest. The mounting client will
> simply say "mount.nfs: access denied by server while mounting". On the
> DC I was a able to find a Failure Code 0x3C for the Kerberos ticket
> request. 0x3C is a generic error, according to
> https://docs.microsoft.com/en-us/windows/security/threat-protection/auditing....
> None of the possible causes listed by Microsoft apply to our situation.
>
> Since uninstalling the update on the DCs made the problem go away, I
> guess it's safe to assume that Microsoft changed something. The update
> notes don't really mention anything useful, but after some googling I
> found
> https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2020-17049
> which seems like something that could have caused this. Is there some
> settings in the IPA that could be changed to comply with the changes
> made by Microsoft?

Details for CVE-2020-17049 are still not public so we can only guess
what is the problem. It also means MIT Kerberos cannot be fixed unless
we'll get to know what is the real problem.

Robbie, was this raised with the upstream beyond our recent discussion
on #kerberos?

Microsoft claims that the fix for CVE-2020-17049 produces a 'known issue':
https://docs.microsoft.com/en-us/windows/release-information/status-windows-...

Looking at the possible registry settings outlined on that page, none
of them would actually work, it seems. You already mentioned that '1'
(default) is breaking the configuration. '0' is explicitly marked as
breaking S4U2Self (this would break access to IPA Web UI or IPA CLI for
AD users it seems). '2' introduces an enforcement mode that we have no
idea how to comply with.

I would recommend to stay away from this fix until Microsoft clarifies
the 'fix' in the future updates. Please refer your Windows
administrators to the page above.

[Robbie Harwood]

Alexander Bokovoy  writes:
> Details for CVE-2020-17049 are still not public so we can only guess
> what is the problem. It also means MIT Kerberos cannot be fixed unless
> we'll get to know what is the real problem.
>
> Robbie, was this raised with the upstream beyond our recent discussion
> on #kerberos?

To my knowledge Microsoft has not been in contact with us about this
vulnerability.  Reporting so far suggests that it's a Microsoft-specific
issue - i.e., MIT and other Kerberos implementations are not affected.

Affected by the vulnerability, that is.  There is of course this known
issue with Linux clients; my reading of
https://docs.microsoft.com/en-us/windows/release-information/status-windows-...
is that they plan to fix this on their side somehow.

Thanks,
--Robbie

[Thorsten Scherf]

On [Tue, 17.11.2020 10:49], Robbie Harwood via FreeIPA-users wrote:
> Alexander Bokovoy  writes:
> > Details for CVE-2020-17049 are still not public so we can only guess
> > what is the problem. It also means MIT Kerberos cannot be fixed unless
> > we'll get to know what is the real problem.
> >
> > Robbie, was this raised with the upstream beyond our recent discussion
> > on #kerberos?
>
> To my knowledge Microsoft has not been in contact with us about this
> vulnerability.  Reporting so far suggests that it's a Microsoft-specific
> issue - i.e., MIT and other Kerberos implementations are not affected.
>
> Affected by the vulnerability, that is.  There is of course this known
> issue with Linux clients; my reading of
> https://docs.microsoft.com/en-us/windows/release-information/status-windows-...
> is that they plan to fix this on their side somehow.

Microsoft resolved this issue with the release of KB4594440:
https://support.microsoft.com/en-us/help/4594440/windows-10-update-kb4594440

Cheers,
Thorsten

[Jerry Träskelin]

KB4594440 doesn't seem to quite resolve this, at least for me. The problem still persists unless I set PerformTicketSignature to 0 on DC's. As I understand, this will not be possible when the change becomes mandatory in a few months. I'm trying to get a hold of someone at Microsoft via my company's support contract.