Ik post deze bijdrage nogmaals in de hoop dat deze informatie niet opnieuw wordt ondergesneeuwd door trollen die niets inhoudelijks toevoegen. Correcties en aanvullingen door niet-OSS/Microsoft haters zijn van harte welkom!
Door Anoniem: Door Erik van Straten:
Ah, ik vermoed dat de verwarring is ontstaan door client certs voor NAC (Network Access Control). Wellicht is dat ook waarom karma4 het over switchpoorten had. NAC via bijv. dot1x (802.1X) heeft niets met LDAP(S) authenticatie te maken.
Ja de vraag is nu alleen nog even wie er gelijk heeft, jij die denkt dat het geen signing requirement is maar alleen een
verplichting om van ldap naar ldaps over te schakelen, of ik die vermoed dat er meer aan de hand is en dat straks de
toegang tot AD via LDAP op vergelijkbare wijze wordt geautoriseerd als 802.1x en WiFi-EAP met client certificaat.
Immers hoe wil je anders het onderliggende probleem oplossen?
Ik heb me nog wat verder verdiept in de materie. Er zijn waarschijnlijk 4 manieren om een LDAP client te laten inloggen op AD:
1) "simple bind": plain text username/password over je netwerk;
2) SASL: "SASL authentication uses the Simple Authentication and Security Layer, as defined in RFC 4422. SASL is an extensible framework that makes it possible to plug almost any kind of authentication into LDAP (or any of the other protocols that use SASL). SASL authentication is performed with a SASL mechanism name and an encoded set of credentials. Some SASL mechanisms may require the client and server to exchange information multiple times (via multiple bind requests and responses) in order to complete the authentication process".
(bron:
https://ldap.com/the-ldap-bind-operation/);
3) "simple bind" via TLS;
4) SASL via TLS (kan, maar niet erg zinvol).
DAARNAAST spelen er nog twee aspecten (genoemd bovenin
https://support.microsoft.com/en-us/help/4520412/2020-ldap-channel-binding-and-ldap-signing-requirement-for-windows):
A) LDAP channel binding, ook bekend als Channel Binding Tokens (CBT), onderdeel van "Extended Protection for Authentication";
B) LDAP signing.
Toelichting op A) en B):A) Een m.i. goede uitleg van CBT vond ik in
https://www.reddit.com/r/sysadmin/comments/eril29/comment/ff4b1rm. In het kort: een LDAP CBT zorgt ervoor dat de client een geslaagde authenticatie
uitsluitend voor LDAP kan gebruiken, en niet voor andere "kanalen" zoals authenticatie voor RDP, Sharepoint, Exchange, SMB shares etc.
Meer info over LDAP channel binding vind je bijv. onder "More information" in
https://support.microsoft.com/en-nz/help/976918/authentication-failure-from-non-windows-ntlm-or-kerberos-servers en in
https://dirteam.com/sander/2019/11/26/howto-enable-extended-protection-for-authentication-on-the-ad-fs-farm/, dat op zijn beurt verwijst naar een generieke "channel binding" RFC:
https://tools.ietf.org/html/rfc5056.
Het combineren van 3) en A) is zinvol! Uit
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/CVE-2017-8563:
FAQ
In addition to installing the updates for CVE-2017-8563 are there any further steps I need to carry out to be protected from this CVE? Yes. To make LDAP authentication over SSL/TLS more secure, administrators need to create a LdapEnforceChannelBinding registry setting on machine running AD DS or AD LDS. For more information about setting this registry key, see Microsoft Knowledge Base article 4034879.
In hoeverre non-Microsoft LDAP clients hiermee om kunnen gaan, weet ik niet.
B) Uit
https://u-tools.com/help/LdapMismatch.aspWhat is LDAP Signing?
LDAP signing is a feature of the Simple Authentication and Security Layer (SASL) of the Lightweight Directory Access Protocol (LDAP), the communication protocol used to access Active Directory.
SASL provides several mechanisms to increase the security of an LDAP connection, including user authentication, anti-tampering (message signing), and confidentiality (encryption). SASL is a communication layer that operates within LDAP on the default AD data ports (TCP port 389 and TCP port 3268).
Signing gebeurt hier niet m.b.v. (client-) certificaten, maar (als ik het goed begrijp) op basis van een HMAC - met een hash van het client-wachtwoord als shared secret. Vereenvoudigd kun je een HMAC beschouwen als een hash van twee achter elkaar geplakte reeksen bytes, bijvoorbeeld de hash van een datapakketje en, als secret, de hash van een wachtwoord (HMAC is ietsje ingewikkelder om bepaalde aanvallen te pareren, maar dat doet niets af aan deze uitleg). Als zowel de client als de server die wachtwoordhash kennen, en zij van elk datapakketje de HMAC meesturen, zelf uitrekenen en vergelijken, kunnen beide partijen controleren dat datapakketjes "onderweg" niet zijn gewijzigd. SMB siging maakt gebruik van iets vergelijkbaars.
Nb. om "replay attacks" van dit soort pakketjes onmogelijk te maken, zijn er aanvullende maatregelen nodig.
Meer info over "LDAP signing":
https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/network-security-ldap-client-signing-requirements. Mocht je nog Server 2008 draaien:
https://support.microsoft.com/en-us/help/935834/how-to-enable-ldap-signing-in-windows-server-2008.
CONCLUSIEKortom, behalve over
wanneer Microsoft wijzigingen doorvoert, bestaat er (in elk geval bij mij) verwarring over wat dan precies afgedwongen wordt
als je niks doet (geen opt-out instelt). Het
lijkt erop dat je, als Microsoft later dit jaar de patch uitrolt, niks hoeft te doen als jouw LDAP clients:
- Ofwel 2) (SASL) combineren met verplichte support voor signing en waarschijnlijk CBT;
- Ofwel 3) of 4) gebruiken, TLS dus, waarbij signing niet nodig lijkt, maar het mij niet duidelijk is of CBT support verplicht is (verstandig is dat duidelijk wel).
Dit lijkt bevestigd te worden in
https://www.ultimatewindowssecurity.com/wiki/page.aspx?spid=DCldap (vette opmaak toegevoegd door mij):
“Require signature” means the domain controller will only bind with clients that negotiate LDAP data-signing OR are using TLS/SSL. If the client established the LDAP connect with SSL, data-signing is redundant. (Domain controllers support LDAP over SSL).