On ma, 16 marras 2020, Jerry TrÃ¤skelin via FreeIPA-users wrote:
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.
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
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
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
Microsoft claims that the fix for CVE-2020-17049 produces a 'known issue':
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.
/ Alexander Bokovoy
Sr. Principal Software Engineer
Security / Identity Management Engineering
Red Hat Limited, Finland