How to resolve the CredSSP encryption Oracle remediation error

Event ID 4648 LOGON in the security log.  No entries in the application or system logs.
This is from the source computer.  I will go grab the data from the target computer and post that in a min.

A logon was attempted using explicit credentials.

Subject:
      Security ID:            domain\DAndries
      Account Name:            DAndries
      Account Domain:            domain
      Logon ID:            0xD1F2A
      Logon GUID:            {00000000-0000-0000-0000-000000000000}

Account Whose Credentials Were Used:
      Account Name:            DAndries
      Account Domain:            mydomain.ORG
      Logon GUID:            {5e9c1762-7222-f67c-0367-486b877919b4}

Target Server:
      Target Server Name:      bensminger
      Additional Information:      TERMSRV/bensminger

Process Information:
      Process ID:            0x410
      Process Name:            C:\Windows\System32\lsass.exe

Network Information:
      Network Address:      -
      Port:                  -

This event is generated when a process attempts to log on an account by explicitly specifying that account’s credentials.  This most commonly occurs in batch-type configurations such as scheduled tasks, or when using the RUNAS command.

Almost guaranteed one machine is pre-march CU and another is patched through may.  

IF you need to log in remotely to patch then you'll need to disable the remediation.  Don't manually edit the registry.  Use local group policy as officially documented.  And that's *IF* you need to log in remotely.  If you have local access, do that instead.  Verify your patch level 100%.

Setting the policy to allow unsecure clients requires a reboot - unless for W10, where it worked immediately for me.
Lowering the security setting on RDP server to allow connections without network level authentication  - the middle setting in RDP security -  should work too, as RDP then falls back to not using the unsecure CredSSP variant at all.

They are both PCs, neither of them are servers.
I checked windows updates and they both say they are up to date.

I created the reg entry on both PCs and set the setting 1, restarted and still doesn't work.

That was before I read the post to NOT change the registry.

I just deleted both registry entries on both computers

mcknife
here's one of the winver outputs

here's the 2nd output

1511 (the second one) is WAY out of support. It never got any of the Cred patches. March nor May's.

That needs to be UPGRADED, not just patched. It's a full four versions behind now.

isn't it not secure to set the local group policy to vulnerable?
Should I just perform this in group policy for all computers?

I am using WSUS internally, so technically all computers should be patched, perhaps some are a week or 2 old, but that would raise the question if my WSUS is not downloading all the updates?  I have it configured to auto approve all security and critical updates.

Feature upgrades are not security or critical updates. They are their own category in WSUS.

Don't change the registry. Don't use group policy. Get that unsupported machine up to date.

isn't WSUS is supposed  to  keep my machines updated?  I understand I need to install the OS, but the WSUS installed the different creator updates MS just rolled out, so I wonder why the other computer did not upgrade?

Cliff, I get that, but if I go windows updates and click on update, and it says it's up to date, then why isn't the OS telling me it needs to be updated.  So I googled how to manually update windows:
https://support.microsoft.com/en-us/help/4028685/windows-10-get-the-update

That's what I did and it said it's up to date.

No, WSUS does not keeo your machines updated for you.  It is a tool, nothing more.  Yes, you can *USE* it to keep your machines up to date, but it takes effort, monitoring, and upkeep.  You should be monitoring the reports regularly as well.  If you were, you'd probably have seen that the feature update you approved didn't install.

A hammer does not build a house on its own.  It still takes effort from the carpenter.

WSUS was never meant to be a "hands-off" tool.   It does what it does well, and can be great when you have thousands of machines to maintain, and can help you ensure compliance.  But you get out of it what you put into it.  If you just set some rules and let it roam freely, you'll continue to have problems.

Why this *specific* update failed...who knows.  But it failed 1709, 1703, 1607....assuming you approved any of those...so this isn't a new sudden problem.  And troubleshooting a problem that old is not trivial.  Anything else posted here would be pure speculation.

Your WSUS policies will taint the results.  1) You left out that you were using WSUS until much later in this thread.  And 2) Windows Update and WSUS cannot be used interchangeably.  You can't read articles about Windows Update and expect that to apply to your WSUS environment.  You need to read up on how to approve Feature Upgrades in WSUS, or you can install manually (via USB, etc) ...but right now you're asking experts to give advice on little to no information. Nor are we in a position to give detailed analysis (posting some information publicly is highly risky...)  You'll have to do some digging/decision making on your own here.

Regardless, the actual CredSSP error that spawned this question has had its cause identified.  One machine is up to date.  One is so old that the OS it is running no longer gets security updates from Microsoft (1511 stopped getting security updates.  That isn't a mystery, and running these two OSes together would cause the error you are seeing.  That is actually expected due to the wide discrepancy.  And the fix isn't group policy or registry.  Mystery solved.

I want to be clear. I didn't say that disabling the check would not work.  I just don't think it is a real fix.  The OP (based on the latest screenshots) has direct access to both machines.  So he wouldn't be disabling RDP as an emergency "get access" method. He already has access.  And he is running 1511, which is out of support completely, which poses a larger security risk than just CredSSP.  There are known unpatched flaws at this point that are in the wild.

To my point, disabling the CredSSP check to allow RDP is like treating a paper-cut while the victim is bleeding out from a gunshot wound.  The paper-cut is certainly real, and arguably needs to be addressed, but it a much lower priority than fixing the gunshot wound (aka getting of 1511.)

And if fixing the latter addresses the former, it makes the former a moot point.

Just my opinion anyways.

so both machines are windows 10, how can windows 10 be out of support?  Aren't they still patching windows 7?

Yes, I know I need to spend more time in WSUS, as you're right, I just configured it when installed and really haven't touched it since, I'm just to busy running from one problem to the other, but I will make it a point to review it weekly.

So, I'll download the the newest update and install it via USB for now, as I have get the user to be able to RDP,
Next week, I'll look at getting WSUS to install the updates, as there are probably other machines that need to be updated.

And to be clear, your *first* screenshot showed a machine running Windows 10-1709 (the fall creators update, released about 9 months ago) and is still fully supported.  That's why the two can't reasonably talk to each other. One is very old, and the other is (relatively) new.  One is getting security updates (1709) and one isn't (1511) because Microsoft simply quit releasing security updates for 1511.

Thank you Cliff for the educational lesson, I really do appreciate it.  It makes sense now, it just wasn't making sense. I'll look at my WSUS sever and make sure that it includes upgrades, as I think I didn't have that checked, and makes sense why none of the PCs were being upgraded to the newest update.

Thanks everyone for your help.!!!  Greatly appreciated.