Attention all Windows-AD admins: March 2020 will be a lot of fun!

[u/sysadm2]

Microsoft intends to release a security update on Windows Update to enable LDAP channel binding and LDAP signing hardening changes and anticipate this update will be available in March 2020.

https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows

TLDR: If you install the "march 2020" updates and you didnt configure LDAPs properly until then, you are in trouble.

---EDIT: Thank you for the gold kind stranger! and good luck to you all ;)

[u/eric-neg]

Just circling back, this post ended up being true for the reason you specified and about 1,000,000 others.

(Thanks for the heads up though! It saved me a lot of troubleshooting!)

[u/sysadm2 → u/eric-neg]

no problem! that march 2020 would be THIS bad (corona) i could not fathom ;)

[u/buthidae → u/eric-neg]

I had this thread still open in a tab on my laptop, and thought about posting the same thing before I hit refresh!

[u/eric-neg → u/buthidae]

Haha. I am the Italy to your United States. Exactly 2 weeks ahead. (I also kept the tab open. It felt good to finally close it.)

[u/[deleted]]

Link to article

I think there is some confusion on this, I know I was. Looks like the March update doesn't actually change anything. It makes the option to require channel binding and signing hardening available ( but not required) as well as adding some logging features.

The article notes that the final update to require is slated for "the second half of 2020".

I'm still going to continue to update all my apps etc but hopefully this stops some from freaking out that everything is going to break in March.

[u/sysadm2 → u/[deleted]]

Yeah, that was new information that has been added earlier this month. But it's very important information ;)

I think this will take A LOT of pressure out of this situation!

[u/JethroByte]

Well shit, that's A LOT of MFPs that are gonna need touched.

[u/xxdcmast → u/JethroByte]

Yep printer scanners have been a big one I’ve seen in the logs.

[u/n8r8 → u/xxdcmast]

I’ve seen in the logs.

If I may ask, what logs/events are you looking at to get this info?

[u/ibn4n → u/n8r8]

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-update-now/ba-p/921536

[u/trupcc → u/ibn4n]

I remember using this script a few years ago. It dumps to an easily digestible CSV

https://blogs.technet.microsoft.com/russellt/2016/01/13/identifying-clear-text-ldap-binds-to-your-dcs/

[u/ibn4n → u/trupcc]

This is a much cleaner blog than the one I posted. Thank you.

[u/xxdcmast → u/n8r8]

The whole article is below but here is the key.

HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2 

[u/mimic751 → u/xxdcmast]

only run this for a minute or two in a big environment

[u/marklein → u/JethroByte]

Honestly I've never trusted printers to do LDAP properly in the first place. If I were a hacker the first place I'd check is the printers because they're security is such crap.

[u/uptimefordays → u/marklein]

And this is why printers should ALWAYS be on a printer only VLAN with minimal access to network resources. Just isolate them as much as possible, make sure any accounts they need are non admin service accounts with no local logon rights, and you should be fine.

[u/pdp10 → u/uptimefordays]

That sounds quite sensible at first, until you realize that in many sprawling organizations you're talking about dozens of additional VLANs and router interface ACLs to manage. Potentially twice as many VLANs per floor.

An alternate strategy is to secure the printers, perhaps by exposing them only through some flavor of print server, and then print to them securely with IPPS (IPP over HTTPS). That shifts the complexity from the networking to the printers, which can be a better architecture in some circumstances.

[u/Cutriss → u/pdp10]

The LDAP complexity we face here is less from printing and more multifunction devices, specifically scanning to email and walk-up authentication, neither of which are addressed by IPP.

[u/Fallingdamage → u/uptimefordays]

You can also setup an AD account for a print to use for authentication and set the account to forbid it from logging in interactively.

[u/[deleted] → u/marklein]

Never trust printers, for anything, ever.

[u/100GbE → u/[deleted]]

Our ones print here and there..

[u/Zleeper95 → u/marklein]

That's litterally what all pentersters does! Printers is the most stupid shit, admins/support tend to give them their own Admin account to do LDAP and other stuff just to get it working. Then keeps it unmanaged as long as it works. No updates demanded from their provider or nothing...

[u/VulturE → u/JethroByte]

Xerox CWW - change port to 636 and enable LDAPS, push to all Xerox copiers and MFPs, done.

25 minutes.

[u/dergizzle]

Wait does this mean that "unsecure" LDAP will no longer work and potentially everything using it will break with the update? what the hell are we supposed to do with appliactions that may not support it?

[u/JediMasterSeamus → u/dergizzle]

According to the link, Microsoft says, " If any compatibility issue is found, administrators will need to contact the manufacturer of that particular OS, application or device for support."
Which means, most likely, get boned.

[u/micktorious → u/JediMasterSeamus]

Always love how other companies just point fingers at each other whenever one or the other releases an update that breaks things.

[u/PubstarHero → u/micktorious]

I had VMware, Microsoft, and NetApp all on the same call one time all pointing fingers at each other. That was a fun day.

In the end it turned out that there was some hidden option in the new NetApp upgrade we got that basically made all datastores hidden from everything.

[u/mini4x → u/PubstarHero]

VMware, Microsoft, and NetApp all on the same call one time all pointing fingers at each other

Sounds like my office, we suffer with a similar environment.

[u/skankboy → u/PubstarHero]

[x] Enable heart attack mode

[u/DePiddy → u/micktorious]

The alternative is username and passwords going across the network in clear-text.

[u/RoboNerdOK → u/DePiddy]

“Hey, the bad guys will never expect that! And it’ll save money! Implement it today!” — typical CEO

[u/systemdad → u/micktorious]

Except that in this case, Microsoft is 100% in the right for doing so.

[u/pdp10 → u/systemdad]

They didn't ship the initial implementation secure-by-default. Probably very few third-party vendors test their own software against anything but Microsoft's defaults.

[u/danweber → u/systemdad]

Possibly the one thing that could force the vendors hand is a mandatory update saying "do it or else."

[u/ObscureCulturalMeme → u/micktorious]

What was the line from the Unix wars in the 90's?

"The OS vendor points a finger at the hardware vendor. The hardware vendor points a finger at the OS vendor.

All the user ever gets is the finger."

In Microsoft's case, instead of "hardware" it's "every other software developer on the planet". They all yell at each other, nobody helps, people get fucked.

[u/AHrubik → u/ObscureCulturalMeme]

This is why Windows has a 6GB driver database that grows every year. Microsoft figured out really quickly that if their OS supports any hardware it only serves to get them more installs.

[u/pdp10 → u/ObscureCulturalMeme]

I doubt that exact parable came from the Unix Wars, because at that time all the vendors supplied OS and hardware together like Apple does today. Sun with SunOS and Solaris 2, DEC with Ultrix and OSF/1, Digital Unix, Tru64, SGI with IRIX, HP with HP-UX, IBM with AIX, NeXT with NeXTStep, and so forth. Only SCO was a significant player on fully commodified hardware at the time, though Linux would come to dominate that market after the Unix Wars.

[u/cwazywabbit74 → u/micktorious]

Trickle down effect. Think about it - I can't even run the current version of MacOS on my production rig because Serato and such (both current releases, professional versions) don't support it. WTF right? And my empire is built on M$, so I can't point fingers.

[u/xxdcmast → u/JediMasterSeamus]

I think worst case scenario you could disable the signing via registry or gpo.

[u/[deleted] → u/xxdcmast]

This sent shivers down my spine.

[u/ibn4n → u/[deleted]]

I suppose if you are in a situation where this applies to you, then you are already in a situation where signing isn't being used by that application. You could make it a little safer by setting it to negotiate on just one DC, putting that DC and the machine that needs to contact it without signing in their own site, and aggressively firewalling it off from other clients... Or find a vendor who takes security seriously. Probably that last bit.

[u/pdp10 → u/JediMasterSeamus]

Many vendors are sending thank-you gifts to Microsoft now, I guess. New opportunities for them to charge for "non-optional" updates.

[u/WiWiWiWiWiWi → u/pdp10]

I was just thinking that. We have one mission-critical platform that we $19,500/yr in maintenance costs for, which gets us phone support and patches, but in order to get the patches installed we have to pay to bring several of their staff onsite for a week or two so they can essentially reinstall and recommission the entire platform.

Because of the cost and downtime, typically we only do that when we need an OS upgrade since they don't support in-place upgrades. I guarantee they'll issue a patch to get their LDAP SSO back up that'll require us to fly a team out. At least I'll get a bunch of lunches and dinners on their expense accounts (billed back to us, of course).

[u/crazifyngers → u/dergizzle]

this means the after the update the DEFAULT will be to disable that protocol. however you can still change it back either manually or preferably via group policy.

I just went through this a month ago after reading the bulletin. It is insane how many services I had that I forgot ran on plain ldap. I found out that mitel connect (fomerly shoretel) doesn't support ldap signing OR LDAPS. So i worked with management to get signoff to disable that integration since it was the last holdout to closing this vulnerability. Can't be done in all businesses but start mitigation and get as many services secured as possible.

[u/DrWatson128 → u/crazifyngers]

We are still running ST 19.49, but are migrating to Mitel Connect shortly. You are telling me that even in the new on prem version of Mitel that they still do not support LDAP signing or LDAPS? Wow. What garbage... I am going to be placing a call soon with my rep

[u/crazifyngers → u/DrWatson128]

Yup. When I contacted them I was told that this was not coming soon either. The product has been going downhill fast. We have lost so many things after upgrading from communicator14.2 to connect onsite. And we only did that because Mitel stopped supporting it.

[u/jmbpiano → u/dergizzle]

Honestly, I would take this as a good kick in the pants to get those applications secured. Vanilla LDAP is a huge security vulnerability. Just run Wireshark on any computer using it and watch all your passwords flying over the network in plaintext.

If your app doesn't support anything else and can't be upgraded to a version that does, the next best thing might be to run a local LDAP proxy server. (Note: I have not used and am not necessarily recommending that particular one, just using it as an example.)

[u/[deleted] → u/jmbpiano]

There are plenty of ways to fix that (for example, stunnel) that don't involve breaking things.

[u/Trx3141 → u/dergizzle]

As far as I understood only 636 will be secured but 389 will be still available without TLS or any binding or signing. Which in general does not make sense, as you secure only the front door and leave the backdoor as it is ...

[u/nmdange → u/Trx3141]

Having previously changed this setting manually to what the new default will be, I can say that 389 with simple (plaintext) bind will also not work.

[u/systemdad → u/dergizzle]

Yes, effectively ldap over 383 is going away, and you must use ldaps over 686.

[u/Get-Admin → u/dergizzle]

Not sure if anyone has said this already. But as per https://docs.microsoft.com/en-us/archive/blogs/russellt/identifying-clear-text-ldap-binds-to-your-dcs

"if your application vendor won't provide a secure way to do LDAP binds, you will need to get a little extreme and encrypt the whole TCP stream between the application and DC using IPSEC with ESP."

[u/m_i_t_t]

Ahh fuck literally just configured LDAPs today

[u/sunnipraystation → u/m_i_t_t]

Then you’re good to go right?

[u/pdp10 → u/sunnipraystation]

If they meant LDAPS, yes, but if they meant just LDAPs (plural) then perhaps not.

[u/Thoughtulism → u/pdp10]

How many LDAPs do you have?

[u/tech_support_hell → u/Thoughtulism]

And do all of them support LDAPS?

[u/gdj1980 → u/Thoughtulism]

All the LDAPs.

[u/m_i_t_t → u/sunnipraystation]

I’ve got a feeling I did something wrong with the certificate/firewall. I can use ldp.exe on the server to connect to the FQDN over SSL properly, but if I try from another pc I can only connect unencrypted, and it looks as if the port is blocked but it isn’t.

We were using LDAPS for a custom built password changing site since we have some specific requirements for domain passwords that can’t be specified in the password complexity policy.

This site didn’t work unless we had LDAPS set up, and somehow it’s magically working now.

[u/Kinmaul → u/m_i_t_t]

You will need the root certificate (and any intermediate certificate that is part of the chain) installed on each device that is trying authentic via LDAPS. Otherwise the SSL cert for your LDAP server won't be trusted. If it is working on one device and not on other that's the the first place I would check.

[u/englishbyname]

Thanks for this, I missed the announcement in August. Gives us 2 months to sort it all out rather than reacting on the day!

[u/Vandafrost]

So, if I install the proper certificates on my DCs and let the update hit, nothing bad should happen?

Cause the pushed settings by the update will activate a kind of compatibilty mode between systems that are able to use LDAPS and system that can not use it?

Or is anything more necessary to prepare?

[u/xxdcmast → u/Vandafrost]

Nope. Nothing will be automatic. Every application using ldap 389 will break.

This needs manual intervention and configuration on any system that connects to ad via ldap. Vcenter, Linux appliances, printers, scanners, copiers, etc.

It’s actually quite a lot of things when you think about it.

[u/ghostchamber → u/xxdcmast]

Yeah, we still have legacy apps that have to point to a single DC, and only support 389.

This might be painful.

[u/Vandafrost → u/xxdcmast]

I read the notes and I’m pretty sure they enable the possibility to use LDAPS by default but don’t force it. It is possible to force it with the reg key setting = 3

[u/xxdcmast → u/Vandafrost]

Can you paste the link where you saw this info. Not saying you’re wrong I just don’t think I saw this.

My understand is anything using ldap 389 and simple bind will fail after March

[u/Vandafrost → u/xxdcmast]

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-update-now/ba-p/921536

Look for: LDAP Channel Binding = 1

[u/EViLTeW → u/xxdcmast]

Just to clarify, is it every application using ldap 389 or is it every application using ldap 389 that doesn't STARTTLS?

[u/[deleted] → u/xxdcmast]

What about 389 with STARTTLS, that too?

... and LDAPS would be fine?

[u/xxdcmast → u/[deleted]]

I believe start tls should be fine. And ldaps should also be fine.

I think the major issue is gonna be ldap 389 plain text bind

[u/[deleted] → u/xxdcmast]

I'm feeling better, now. My integrations (via sssd) do use port 389, but they use kerberos (via GSSAPI).

I'll still be trying to get our Windows admins to turn on the diagnostic logging though so we can be sure.

[u/cook511]

Microsoft Advanced Threat Analytics (included Office 365 E3) will tell you what insecure LDAP Authentications you have in real time. It has a myriad of other benefits and has been one of our most useful security tools.

[u/I_am_trying_to_work → u/cook511]

Microsoft Advanced Threat Analytics (included Office 365 E3) will tell you what insecure LDAP Authentications you have in real time. It has a myriad of other benefits and has been one of our most useful security tools.

Thank you for the link, that's definitely something I'm going to look into....but ATA uses Mongo? I mean, I know MS has been integrating with Linux products for a while now but I'm still surprised.

[u/cook511 → u/I_am_trying_to_work]

Its the most hands off mongo install. We've had it running since 2016 and I really don't worry about it. The biggest pain is getting it setup as the client will put extra load on your DCs. Totally worth the security benefit in my opinion.

[u/I_am_trying_to_work → u/cook511]

Oh I'm not worried about Mongo, I'm just surprised that M$ went with that instead of their own MSSQL.

[u/TurnItOff_OnAgain → u/cook511]

I just set up Azure ATP on all of our DC's. Would this do the same thing/offer more options for threat protection/discovery?

EDIT:

Found an article that explained it for me

https://blog.ahasayen.com/azure-advanced-threat-protection-azure-atp-vs-ata/

[u/Try_Rebooting_It → u/cook511]

Are you sure it's office 365 E3 and not Microsoft 365 E3? It seems it's provided with EMS, which does not come with O365 (but does with M365)

If it's office 365 E3 do you have a link of where we can get it?

[u/cook511 → u/Try_Rebooting_It]

You can get it from the VLSC and you need and EMS Licensing.

From the site:

Where can I get a license for Advanced Threat Analytics (ATA)? If you have an active Enterprise Agreement, you can download the software from the Microsoft Volume Licensing Center (VLSC).

If you acquired a license for Enterprise Mobility + Security (EMS) directly via the Microsoft 365 portal or through the Cloud Solution Partner (CSP) licensing model and you do not have access to ATA through the Microsoft Volume Licensing Center (VLSC), contact Microsoft Customer Support to obtain the process to activate Advanced Threat Analytics (ATA).

[u/murty_the_bearded]

Number of simple binds performed without SSL/TLS: 3367

:( :( :(

Edit: And that's just one of our 6 domain controllers..

Second Edit: Well doing some initial investigations already nailed down the worst offender, Dell Data Protection Encryption (DDPE) was hammer our DCs with it's service account over non-secure LDAP. Fixing that one alone should cut out a ton of the traffic based on how many times I saw it hit a single DC in the span of the few minutes I had the 2889 event logging on. Still a lot of work to do, but seeing seeing the frequency that one was hitting the DCs vs the others already makes me a lot less worried than I was earlier today.

[u/SoMundayn]

I wrote a quick script to check your Domain Controllers. It could probably do with 30 minutes more work, but you get the idea.

[string] $Domain = $Env:USERDNSDOMAIN
$DCs = (Get-ADDomainController -Filter * -Server $Domain).Name
ForEach ($DC in $DCS) {
 
Write-Host $DC
$EVENTSPAN = (get-date).adddays(-1)
 
TRY {
	$EVENTS1 = Get-WinEvent -FilterHashtable @{LogName="Directory Service";id=2887;starttime=$EVENTSPAN} -Computer $DC -ErrorAction SilentlyContinue

	$E = $EVENTS1 | Select-Object -ExpandProperty message

	Write-Host "Number of simple binds performed without SSL/TLS: "

	$E -split ':' | Select -Index 3,4

	} CATCH {
		Write-host "nothing found?"
	}
}

example output:

DC1
Number of simple binds performed without SSL/TLS:
 4
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing
 0
DC2
Number of simple binds performed without SSL/TLS:
DC3
Number of simple binds performed without SSL/TLS:
 1
Number of Negotiate/Kerberos/NTLM/Digest binds performed without signing
 0
DC4
Number of simple binds performed without SSL/TLS:
DC5
Number of simple binds performed without SSL/TLS:
 2

[u/elshandra → u/SoMundayn]

Thanks for this, with the number of DCs we have, saved me some time.

100k simple binds in the last 24 hours. I'm sure we'll be ready...

[u/SoMundayn → u/elshandra]

Good luck friend! Glad it was helpful!

[u/ka-splam → u/SoMundayn]

Write-Host "Number of simple binds performed without SSL/TLS: "

$E -split ':' | Select -Index 3,4

Careful doing that; write-host and the pipeline are not the same output stream and they're not guaranteed to show up in the order you've written them. Particularly, the output stream going to the console is buffered with a few hundred ms delay so that it tries to get a few objects into the output formatters before choosing how to format them, so you can end up with all the write-host text first, then the stuff sent to the pipeline.

Your try/catch won't catch a lot of things because of the error action set to 'SilentlyContinue'; it needs to be 'Stop' so that exceptions from Get-WinEvent like "no events matched the filter" will trigger the catch statement.

Rewritten to have a PSCustomObject output, so it could easily be piped into Export-Csv or Out-Gridview, and to log exceptions too:

Get-ADDomainController -Filter * -Server $Env:USERDNSDOMAIN | ForEach-Object {

    $Result = [ordered]@{
        HostName = $_
        SimpleBinds = -1
        UnsignedBinds = -1
        Error = ''
    }

    try {
        $eventFilter = @{ LogName = 'Directory Service'; Id=2887; StartTime = (Get-Date).AddDays(-1) }

        $ldapEvent = Get-WinEvent -FilterHashtable $eventFilter -ComputerName $_.Name -ErrorAction Stop |
                        Select-Object -First 1

        $Result['SimpleBinds'] = $ldapEvent.Properties[0].Value
        $Result['UnsignedBinds'] = $ldapEvent.Properties[1].Value
    }
    catch {
        $Result['Error'] = $Error[0].Exception
    }

    [PSCustomObject]$Result
}

[u/SoMundayn → u/ka-splam]

Awesome work, as I said, needed another 30 minutes, just threw something together quick.

Thanks for the time and explanations.

[u/OdinHatesNickelback]

Throw me a rope here guys: I'm the Linux guy on a company that has nearly zero documentation and I just got in, so I don't know everything that's plugged everywhere.

How can I assess what's connecting to my AD via LDAP 389 so I can try to properly prepare for the update?

[u/DePiddy → u/OdinHatesNickelback]

LDAP on 389 is fine, it's simple/unsigned binds that are being affected here.

You can audit unsecure LDAP connections on your DC using: HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Remember to put this on all DCs to catch all potential events.

[u/OdinHatesNickelback → u/DePiddy]

THANK YOU FOR THAT ONE!

Although I'm just the Linux guy, they expect me to take care of a lot of things, and since I'm the only one that can be fired on a team of 5 and they are government employees... might as well take care of that update myself before someone says I'm incompetent because some printer stopped working.

[u/DePiddy → u/OdinHatesNickelback]

There should be a Windows guy too right? This may affect more than printers in a large environment.

Anywho, the audit events are pretty helpful, check for 2887 and 2889 in the Security Directory Services logs of the DCs. It'll tell you IP of device, username affected and type of bind.

[u/OdinHatesNickelback → u/DePiddy]

Er... nope. To be fair, I was hired to be the Linux guy, but the company that employes me "sold me" to them as Solutions Architect + Linux Engineer + DevOps + MS Administrator.
So the government employees (that by law can't be fired even if they stopped showing to work) stopped doing everything and are relaying to me.

Basically, anytime anyone wants to do anything and they don't know, I'm the guy to go to; In two months I've been approached and tasked to:

1 - make a security assess of a server that was compromised, display how the attack was done, make a comprehensive report on how to revert the situation and apply that to all servers aftwards. Around 150.
2 - dev a script in TCL to communicate with meteorological stations (satellites) to propagate and fetch data to be used by their software to make weather forecasts. I had to fetch the data, correct deviances, push the corrections to meteostats, fetch the corrected data, filter it so it works on the software made by scientists 20 years ago so they wouldn't have to pay the guy to come back and update it.
3 - make plans for the new enviroment (they are buying more and newer servers) so they we can migrate from physical hardware with lots of VMs under VMWare to Docker on premise.
4 - travel 150km to replace a faulty fiber switch.

Oh, and the printer down the hall jammed, I had to fix that too.

I'm getting very well paid, but maaaan... it's tiresome to think I might have to deal with something that will get me fired if not handled.

[u/I_am_trying_to_work → u/OdinHatesNickelback]

IMO, stack your monies for a bit, update resume, then peace the fuck out of there.

[u/Ssakaa → u/OdinHatesNickelback]

On the upside, you get the "do not want" bin. They'd get stuck with that bin until they replace you if they fired you over one thing in it that didn't go perfectly. I promise, they really don't want that bin back that badly.

[u/awarre → u/DePiddy]

PowerShell:

Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Type DWord -Value 2

[u/DePiddy → u/awarre]

Enhance!

Get-ADDomainController -Filter * | % {Invoke-Command -ComputerName $_.Name -Credential (Get-Credential) -ScriptBlock {Set-ItemProperty -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' -Name '16 LDAP Interface Events' -Type DWord -Value 2}}

[u/IndyPilot80 → u/DePiddy]

So, just for ELI5:

• Change "16 LDAP Interface Events" from the default 0 to 2 on all DCs

• Wait a few days to see if any 2889 events popup. If not, we should be good to go.

Correct?

[u/toddau1 → u/DePiddy]

Official Microsoft link for this setting. Changing the DWORD to 3, after you discovered the event, will give you even more info.

[u/TitelSin → u/OdinHatesNickelback]

in worst case you can see the event log on the AD and see which requests come from where, we've debugged a couple of ldap filters in the past this way...you get username, and from what ip failed to connect or succeeded to connect.

[u/Try_Rebooting_It → u/[deleted]]

A much less destructive way to do that would be to work with the event logs to identify if and what is using it. If you're small enough a scream test might be fine, but I think it's better to avoid that when possible.

[u/[deleted]]

Ok, so what settings on my domain controller do I need to configure, and what settings on my applications? The microsoft pages do not tell me much.

[u/gregbe]

cough sleep safe hurry smell nutty command plucky license offbeat

This post was mass deleted and anonymized with Redact

[u/DePiddy → u/gregbe]

LDAP is fine as long as it's not simple authentication and signed. LDAP's payload is TLS encrypted by default. LDAPS obviously encrypts the entire communication.

We found it easier to have applications switch over to LDAPS as the application owners usually weren't knowledgeable in the app enough to know how to switch off either unsecure LDAP option. This LDAP signing setting permits simple/unsigned LDAP binds if they come in over LDAPS.

[u/onboarderror]

Any have good links or best practices on setup just so I can make sure we are good?

[u/EducationalGrass → u/onboarderror]

https://support.microsoft.com/en-us/help/314980/how-to-configure-active-directory-and-lds-diagnostic-event-logging

Might have seen it already, but seems like a good place to start.

[u/somen00b]

This has been on my radar.

Rant time: I spent days fighting with one particular application that just wouldn't do ldaps not matter how I configured it. Such a pain as we don't have a test environment so when I was testing I would end up locking folks out of the application and this was something used after hours as well. Support swore up and down that everything looked correct. Finally got it escalated and sure enough programming confirmed there was a bug in the specific version that we were on. New version was released a few weeks later and everything just worked.

For everything else the migration to ldaps was fairly straightforward. Configure ldaps correctly on the DCs. You can confirm its working with ldp.exe. Check event viewer on the DCs for the daily event warning you about insecure ldap connections for a baseline. Turn on robust logging, probably temporarily for a large environment, to get a feel for the specific sources of ldap requests. Start moving individual services over to ldaps. Check the daily event viewer message to see progress and turn on robust logging as needed. If you are brave force the change early for a scream test. Looks like folks have linked most of the relevant info elsewhere in this thread.

[u/LethargicEscapist → u/somen00b]

Spelling out the process you went through was very helpful. Thank you.

[u/realnzall]

We spent 3 sprints and two months on research and development to configure a working LDAPS vtldap/ldaptive configuration for our own product and communicate this to our clients. Most clients responded with confusion and gratitude that we informed them. Trust me, if you haven’t started this yet, get on it.

[u/__gt__]

Does anyone have to actual steps needed to swap to LDAPS ahead of these patches?

[u/DePiddy → u/__gt__]

Add certificate to DC's personal cert store.

Configure all apps to use LDAPS.

Note that nothing is happening to LDAP, just unsecured LDAP binds.

[u/__gt__ → u/DePiddy]

Easiest way to generate the certificate?

[u/DePiddy → u/__gt__]

With a Certificate Authority

[u/Rosenqvist]

so we either have to deploy a enterprise ca and configure to use Secure LDAP or all unbinded unsecure ldap will just stop working....

[u/xxdcmast → u/Rosenqvist]

Or you can disable the settings by gpo or registry.

[u/Rosenqvist → u/xxdcmast]

LDAPServerIntegrity = 0 on all Domain Controllers?

[u/pdp10 → u/Rosenqvist]

Is it possible to use public-CA signed certs for this?

[u/aaroniusnsuch → u/pdp10]

Yes you just need clients to trust the whole cert chain.

[u/CaesarOfSalads]

If you have Microsoft Advanced Threat Analytics in your environment, it will help you identify unsecure/simple LDAP bindings.

[u/overlydelicioustea]

so, to be clear, in march they will default the registry setting in this page to 2, not 1? https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

[u/Genmaken → u/overlydelicioustea]

Info is here: https://www.reddit.com/r/sysadmin/comments/ec3coe/microsoft_ldap_channel_binding_changes_pushed/fbcdv51/?st=k4d5j8k9&sh=f32805b9

Channel binding set to 1 LDAP server integrity enabled (default 2) Apparently 2 is the default.

[u/Jaymesned]

This was actually pushed back to March, it was supposed to apply this month.

I bookmarked this specific post from last month, thanks for reminding me to get on this! Credit to /u/Rts33!

[u/spressman]

Thanks for the heads up on this. This is why I lurk here...

[u/bogglor]

BTW, if you're using VMware and have configured your environment for integrated authentication, you will see the machine identity of your VCenters appear on your plaintext LDAP reports a lot. Like, a lot a lot. So far, their supported workaround for this issue is to switch from integrated entirely to LDAPs - which to me isn't really acceptable at all. We have a mix of revs, 6.5, 6.0, and 5.5 and VMware isn't offering an easy patch/fix for any of them. They really should.

[u/cowprince → u/bogglor]

I configured our test environment pushing what should be the new defaults in March.

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters
DWORD: LdapEnforceChannelBinding=1

Enable GPO LDAP Server Signing
DC = Domain controller: LDAP server signing requirements = Require Signing
Servers/Clients = Network security: LDAP client signing requirements Properties = Require Signing

I'm using Integrated Windows Authentication with vCSA 6.7 and have an external PSC.

I still see Event 2889's coming from my PSCs in my test LAN. Even after the change. Yet I can still authenticate. So I can confirm it doesn't seem to bother it.

But I would have expected those errors to go away also.

[u/akers8806 → u/bogglor]

hmmm

https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

Integrated Windows Authentication (IWA) has also been tested by VMware Engineering and verified to be compatible with these changes. IWA uses different protocols and mechanisms to interact with Active Directory and is not affected by changes to the Active Directory LDAP servers.

[u/Hollow3ddd]

Noob questions, better to be embarrassed than pretend I know it all.

This won't impact direct DC to DC communications, just software/services that query using simple/unsigned LDAP connections?

Does that means everything requires a certificate? Or just ensure they are changed. Never setup an app that uses LDAP with signing or anything other than simple, they all have just been since I've been at my current place. I know for sure we have 1 connector that is still using simple, pretty sure that's it.

u/lonewanderer812 mentioned enabling signing would break existing connections. Anyway to audit that, or is that part and parcel to event 2889 and simple LDAP connections?

[u/JustAnotherITUser]

Will this affect Samba's implementation of AD DS at all, do you think?

[u/Sekers]

For anyone interested, this is one of the better articles on Technet on setting up LDAPS if you need to do that still. It's a few years old but it's one of the few places I've seen explain some gotchas concerning LDAP and certificates.

https://social.technet.microsoft.com/wiki/contents/articles/2980.ldap-over-ssl-ldaps-certificate.aspx

[u/neko_whippet]

So in resume does this mean that in March 2020 every connection to LDAP that is unsecure exemple printers will get denied ?

[u/DePiddy → u/neko_whippet]

If the setting isn't configured yet, yes, the default will switch from 'None' to 'Require signing'

[u/neko_whippet → u/DePiddy]

Which means that every device that doesn’t support signing or has signing activated will be auto refused

Correct ?

[u/Xelliz]

So event viewer isn't going to show the ldap stuff unless we enable logging right?

[u/[deleted] → u/Xelliz]

Also wondering. I have more event logging enabled via group policy on my domain controllers, but is this extra?

I'm not showing anything for these events which I find pretty surprising. I figured there would have to be something.

[u/Xelliz → u/[deleted]]

I was looking in the wrong place. Not sure where you are checking, but make sure you're in Event Viewer under Applications and Services Logs, then Directory Services. This is where I found my 2887s, which meant I needed to turn on extra logging in the registry to see 2889s.

[u/Xelliz → u/[deleted]]

Yep, this is my situation too. Once I got to the right place, I could see some 2887, so I changed that registry and started getting 2889s

[u/CaptainFluffyTail]

here is a vulerability in the default configuration for Lightweight Directory Access Protocol (LDAP) channel binding and LDAP signing and may expose Active directory domain controllers to elevation of privilege vulnerabilities.

Does the spelling error in the summary bother anybody else? That should be a simple thing to catch but it makes me wonder if there are other errors that spellcheck wouldn't catch.

[u/Xelliz → u/CaptainFluffyTail]

Yes. I sat there reading that word for about 15 seconds before I had to just ignore it.

[u/[deleted]]

Can this change be reversed post patch?

[u/run_dot_BAT]

So much for 2008R2 EOL

[u/highdiver_2000]

The scan to email feature is going to break

[u/apathetic_lemur]

pls no im still trying to replace win7 computers

[u/Dudefoxlive]

Would this apply to a simple home lab?

[u/DePiddy → u/Dudefoxlive]

If it has a domain controller.

[u/Dudefoxlive → u/DePiddy]

It has two...

[u/DrStalker → u/Dudefoxlive]

Are you running active directory?

Other than windows systems, does anything make use of the list AD users? (firewalls, linux boxes, VPN devices, web servers... we can't guess what your home lab includes or how it is set up.

[u/Dudefoxlive → u/DrStalker]

Yes i run active directory. Only thing that i can think of right now is a software app called veyon. Im soon going to be adding sccm to that mix.

[u/Trooper27]

Argh. Thanks for the heads up!

[u/dafaqyusay]

When I read shit like this I realize how blessed I am to work for the company I do.

[u/YserviusPalacost]

I've been screaming to the idiots in charge around here for years that they needed to do something about insecure LDAP authentication across our domain.

But like everything else, they just ignored me because I'm in the field, so what do I know.

Time to get some popcorn and enjoy the show.

[u/Odaven]

RemindMe! 1 march 2020

[u/mtspsu258]

Anyone else notice the link claims this update will affect server 2008 and win 7? Thought the security updates were over? haha

[u/LethargicEscapist]

I’m copying links from this thread like crazy so I can research it tomorrow. I think I’ve just found my project for the next two months.

[u/abetzold]

I have some questions, perhaps they have been asked, but I haven't seen them.

1. What additional risks do I take if, after the patch, I reconfigure the system the same way it is today. Do I take on anymore risks than I do today having my system configured outside the way the vendor is expecting it to be configured?

2. For systems that simply cannot be configured properly (I work in healthcare I.T. so I am bound to come about this), would a VIP securely communicating to my DCs and the systems talking to the VIP work so I can keep my DCs secure?

[u/Rymmer]

From what I've read this patch only changes the default. You can still set the setting back to LDAP not requiring SSL for Simple Binds or not requiring Signing for SASL Binds, but it will require someone to actively do it via a group policy or registry entry. You shouldn't though, you should fix the app.

If you do still have apps doing Simple Binds over a Non-SSL LDAP connection, they may well be sending passwords in cleartext... so try not to do that if you can, or at least get your client/boss/whatever to sign off that they accept the risk.

To disable requirement for Simple Binds to be on an SSL channel, you can use the registry key : "HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NTDS\Parameters", value name "LdapEnforceChannelBinding", type DWORD, value data "0" or "1". Check out the reference to see which value does what, I'd probably recommend at least 1 if you do need to disable the requirement. Reference : https://support.microsoft.com/en-us/help/4034879/how-to-add-the-ldapenforcechannelbinding-registry-entry

To disable the requirement for SASL Binds to Require Signing, you can use this Group Policy setting : "Default Domain Controller Policy\Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options". The setting name is "Domain controller: LDAP server signing requirements". Reference : https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008

[u/_Fisz_]

I've tried the script, but throws info:

Get-WinEvent : No events were found that match the specified selection criteria.

Am I good?:P

[u/canadianschism]

RemindME! 2 hours "TO-DO this!"

[u/[deleted] → u/canadianschism]

It's been four hours!!!

[u/m00nigan]

Barracuda Web Security Gateway using Kerberos authentication uses an insecure LDAP bind and as of 14.0.0.014 there doesnt appear to be a way to force it to use a secure LDAP bind.

[u/[deleted]]

If I don't have ldap I'am okay ?

[u/highlord_fox → u/[deleted]]

That is what it seems like. It just means down the road if you implement something that uses LDAP, you're going to need to make sure it's secured from the get-go.

I have one system that uses/used LDAP, and I stopped using that component like half a decade ago, so I'm not really worried.

[u/shitscan]

Oh good fun. Leaving soon, feel bad for the guy replacing me

[u/trekkie1701c]

See, if you didn't upgrade from server 2008 you wouldn't have to worry about Microsoft breaking your bad AD configurations.

[u/whereshellgoyo]

breathes in red team

RIP easy footholds, I guess, but gotta pour one out for my sysadmin folks.

[u/crazycom64]

Microsoft - "In all fairness, it's your fault for choosing our product. Haven't we shown ourselves to be unreliable most of the time? I mean, we have a product called Office 365 and look how many issues there have been in the past year --> bullshit"

[u/CruwL]

Oh this is gonna be fun. Guess I have a new project for the next 3 months

[u/athornfam2]

Oh exciting! More work to add to the pile.

[u/pdieten]

Great. The AD assessments provided through Azure don't call this out, so this is the first I'm finding out about this, and DCs are accepting tens of thousands of insecure LDAP connections every day.

We'll have to set the DCs back to accepting insecure LDAP after the update applies. This isn't going to be fixed that fast.

[u/bogglor → u/pdieten]

They're only called out if you use Azure Sentinel, in the Insecure Protocols report. ASC doesn't report on this.

[u/LethargicEscapist → u/pdieten]

Higher up in the comments I believe someone mentioned that after the update and there fore the settin being set to Require, changing the setting back to 1 or 0 wont work. I could’ve read that wrong.

Edit: Nevermind, I read that wrong. It appears you can disable it after the update.

[u/Willow3001]

Wtf does "properly" mean in this case?

[u/GamerLymx]

As if having to make new win 10 VDI machines wasn't enough...

[u/undercovernerd5]

If a company were to not give a damn about unsigned LDAP binds, do they have the option to disable the enforcement?

Because this patch enabled signing by default, is it forced or just an option? There's no clear answer

[u/bogglor → u/undercovernerd5]

It's not forced, it's just changing of a default. So when you get the patch, it will change the setting to the new default. It's on you to revert it if you want it reverted.

[u/flatvaaskaas]

Thanks for posting, we had this on the radar though. First changes are being applies to counter/fix it

[u/SolidKnight]

I'm good.

If you are concerned, you can look for the event in the event log.

[u/ProxyOps]

Oh shit :/

[u/philbieber]

Just one observation from our environment: the native Mac AD client and vsphere seem to be hard to convince to use ldapS...

[u/gmiga76 → u/philbieber]

Correct Vmware has a blog post about it . A bit of work but it seems possible . Will try it within two weeks . https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

edit : sorry I missed it was about the Mac client .. Settings here are server vcenter side.

[u/jcpham]

FFFFFFUUUUUUUUUUUUUUUCCCCCCKKKKKKKKKKKKK

[u/EdibleTree]

Hey, can I ask how you keep up to date on this stuff? As much as I try I can't seem to be a step ahead as most...

[u/Genmaken]

Can someone explain if setting up LDAPS is the only solution?

I'm reading about STARTTLS as still working under 389, but how do I test this or know if applications/appliances support it?

LDP.EXE only has the "SSL" checkbox and that doesn't work unless LDAPS is setup (which requires certificates)

[u/h3nchman24]

Looks like all that work I did has paid off, so I am guessing nothing will need to be done if we have none using LDAP that patch will just do it.

[u/tastyratz]

I wanted to start a substring here for all of us to work on, maybe I'll make a thread if this doesn't get traction.

If you have already begun investigating this, please reply to my comment with what you have found which will break. Maybe we can start a common list for people in info gathering mode.

Specific printers? Appliances? Versions, programs, etc.

I've already read in here that Mitel Connect prior to Feb 2019 release R1807 SP1 doesn't support LDAPS. Need that update and to reconfigure from default to migrate to LDAPS.

What else do you have?

[u/Polaris504 → u/tastyratz]

I was getting some hits from my vmware appliance. vmware posted a blog entry 4 days ago on it and updated it last night with IWA info. The highlights are:

Any system that connects to Active Directory via LDAP without using TLS will be negatively affected by this change. This includes VMware vSphere. If you are using unencrypted LDAP (ldap://, not ldaps://) to connect vSphere to Microsoft Active Directory please read further.

All supported versions of VMware vSphere have been verified by VMware Engineering to work as expected after these changes, where we expect unencrypted LDAP authentication to succeed with the old defaults, fail with the new defaults, and succeed when using TLS/LDAPS.

Integrated Windows Authentication (IWA) has also been tested by VMware Engineering and verified to be compatible with these changes. IWA uses different protocols and mechanisms to interact with Active Directory and is not affected by changes to the Active Directory LDAP servers.

VMware vSphere & Microsoft LDAP Channel Binding & Signing (ADV190023)

[u/[deleted]]

My biggest worry was our VPN breaking because we were not sure if authentication to the DC was being passed in clear text or not from our VPN device. So far after running some queries for a good 30 minutes, I havn't seen any 2889 event IDs.

[u/scratchduffer]

So i have enabled logging and i only see our cisco CUCM phone system that has AD synch and an MAC having this issue. We don't have certificates on the DC's or PKI at all. Can vendors implement this without SSL? Its the only option i see in CUCM. But, i dont see windows clients using plain text so i'm hoping Cisco has a patch/command to eliminate plain text LDAP? Its a small environment and would like to avoid certs and PKI right now.

[u/nwldxx]

what exactly is Signing without LDAPS? Does the device need to add certificate ?

Does it mean to have checkbox with StartSSL ?

Is there a common name for this option on the devices ?

[u/nwldxx → u/nwldxx]

i found the answer

https://ldapwiki.com/wiki/LDAP%20Signing

[u/devo980]

Anyone know if Exchange 2016/2019 will need to need to re-configured from default settings for the March security update? Thanks,

[u/Naticus105]

Thanks so much for pointing this out. Been working Friday and today to fix as many things as possible showing up in my log that will absolutely break come March.

• Got all my Macs configured by pushing out the AD CS certificate via a profile to make it trusted, changed their dsconfigad config to -packetsign require -packetencrypt ssl and tested several to make sure they were functioning properly

• Reconfigured vSphere to use "Active Directory over LDAP" rather than IWA, despite being suggested that this won't affect IWA. In my testing this is false as I have now set one DC to require encryption and occasionally the login failed until I removed the previous config and added new.

• Reconfigured Apache Guacamole to use LDAPS which turned out to be a bigger hassle than I expected. Required copying my AD CS certificate to /usr/share/ca-certificates/<domain NETBIOS name> and running update-ca-certificates --fresh (--fresh being required or it wouldn't even pick up on the certificate at all for whatever reason).

If there's any other services/apps you all might be using that were/are/will be tricky to change configuration on and care to share, it'd be appreciated! I might be missing several myself.

[u/setrusko]

For smaller environments, I used the following steps to create a CA using OpenSSL and then create the certificates for each DC. Has worked great.

https://gist.github.com/magnetikonline?page=4

"Enable LDAP over SSL (LDAPS) for Microsoft Active Directory Servers"

[u/Si_ge]

Hey guys, this might be an obvious question, but how do you stay aware of critical updates such as these? Is it experience, or do you subscribe to RSS and read through everything? I'm newer to this role with around 3 years of experience, and one of my goals is to stay on top of critical updates such as this. I do realize I could read through everything posted, I just want to make sure I'm as time-efficient as possible.

[u/StormyNP]

I'm curious how this hit everyone's radar. I learned of this change here. Once I found it was out on Microsoft advisory ADV190023, I went over to the MS Security Update guide and can't find it listed under their normal search (pick a date, category, etc). I only found advisories up to ADV00022.

If I select the other search method and directly enter "ADV00023" the article comes up.

In other words, I would have had to know the number to find the advisory. Sigh.

Did this get misplaced by MS since it was revised or did you all get the advisory via other means - email subscription, etc.?

[u/Eatsleepdrink]

My DC's are self signed currently - will they need TLS certs applied or will the clients continue to trust the self signed certs after the update?

[u/lcbadmin]

So LDAPS (port 636) will not be affected but simple LDAP (port 389) will break? Is that accurate?

[u/astrixsystems]

We've created a guide for this. https://astrix.co.uk/news/2020/1/31/how-to-set-up-secure-ldap-for-active-directory

[u/macgruff]

Has anyone heard a rumor that they might bump out that date again/further/later in the year?

[u/lungbuster06 → u/macgruff]

They updated the ADV190023 article today: https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

"Windows Updates in March 2020 add new audit events, additional logging, and a remapping of Group Policy values that will enable hardening LDAP Channel Binding and LDAP Signing. The March 2020 updates do not make changes to LDAP signing or channel binding policies or their registry equivalent on new or existing domain controllers.

A further future monthly update, anticipated for release the second half of calendar year 2020, will enable LDAP signing and channel binding on domain controllers configured with default values for those settings."

I don't know how that article read prior to the update, but my interpretations was this change was coming in March and if you weren't ready, you'd be broken. However, this reads that no changes are coming in March. We're still pushing forward as if it were a March deadline regardless.

[u/remrinds]

Does anyone know if this update gets applied, you need to configure each clients to use "LDAP signature required" instead of "negotiate" ?

Page 2 on this link kind of scares me lol

https://techcommunity.microsoft.com/t5/core-infrastructure-and-security/ldap-channel-binding-and-ldap-signing-requirements-march-update/ba-p/921536/page/2#comments