thnks…. ik zag oude versie met ldap nieuwe kunnen ldaps. Betreft het probleem hoe je dat oude gebruik weg krijgt.

Ik zag daar een keer wat over voorbijkomen en daar stond bij dat je er voor moest zorgen dat er op de client een of andere
Microsoft KB update was geinstalleerd en dan zou je geen probleem hebben.

Fijn, maar wat gaat de impact van deze wijziging worden voor niet-Windows systemen als client?
Kan ik nog gewoon AD queries doen vanuit een standaard LDAP plugin in Perl, PHP en met "ldapsearch" ?

Onveilige protocollen, handmatig lapwerk in de registry (wat sowieso al een onding is), onduidelijkheid, uitgestelde updates, het is toch gewoon niet meer te doen om dat bij te houden? En dat de beheerders maar de schuld geven als het weer eens misgaat.

Heb je de links wel gelezen? Hoe staat het met de eigen voet waar je net in geschoten hebt?

Dit laat eigenlijk zien hoe ongeschikt bij bent om de impact te bepalen van veranderingen.

Uit https://isc.sans.edu/forums/diary/March+Patch+Tuesday+is+Coming+the+LDAP+Changes+will+Change+Your+Life/25796/:

Enkele voorbeelden:

- Instellingen voor VMware vCenter server en vSphere client: https://blogs.vmware.com/vsphere/2020/01/microsoft-ldap-vsphere-channel-binding-signing-adv190023.html

- "LDAPS is deprecated and StartTLS should be used" maar toont wel sourcecode voor het benaderen van een LDAPS server: https://directory.apache.org/api/user-guide/5.1-ldaps.html
- Het gebruik van StartTLS over de standaard LDAP poort wordt hier beschreven: https://directory.apache.org/api/user-guide/5.2-start-tls.html

- Wellicht kun je hier aanvullende info vinden: https://stackoverflow.com/questions/tagged/ldap

Of Google zelf even ldaps gecombineerd met jouw specifieke use case.

Ja, jij? En ik ben geen beheerder als je daarop doelt.

Het probleem is dat het Microsoft artikel suggereert dat het niet alleen ldaps is maar er ook een specifiek client
cert benodigd is voor authenticatie dat dan natuurlijk automatisch naar de clients verspreid wordt. Althans dat
was wat ik tussen de regels door lees. Dan zou simpelweg omzetten naar LDAPS en wel gewoon simple bind
met een user@domain en password niet meer werken.
Maar daar heb je waarschijnlijk geen praktijkervaring mee dan? Iemand anders wellicht?

https://searchcode.com/ kan ook handig zijn. Zoekfilters in linkerbalk; o.a. PHP, Perl.

Ik ben absoluut geen LDAP expert, maar ik ken me niet voorstellen dat client certs [*] automatisch naar clients worden verspreid. Daar bestrijd je immers geen MitM aanvallen mee.

[*] Feitelijk gaat het om de bijbehorende private key, de component die geheim moet blijven; het client cert zelf is niet geheim.

Ik heb er nu geen tijd voor (over) om dit uit te spitten, weet iemand meer?

Nee dat was al duidelijk en nog meer dat soort zaken zitten niet in het dagelijks beheer maar in de grotere lijnen van een geheel. Het zijn de clients die dit aanroepen waar het probleem zit, dat zijn geen desktops.
De "used case" is vrij specifiek van geval tot geval in een van de links staan wat voorbeelden. SSO in de enterprise.

In mijn use case kom ik deze tegen: https://docs.cloudfoundry.org/buildpacks/java/#bosh-trusted-cert
Als je product via Java loopt kan die poort switch met encryptie voor SSO opgezet worden.

Toch is dat standaard functionaliteit in AD!
Ik denk dat men er vanuit gaat dat je bij het joinen van een werkstation een veilige verbinding gebruikt en dan evt later
op minder veilige verbindingen overgaat (joinen op ethernet en dan later wifi bijvoorbeeld).

Ik heb me er wat verder over ingelezen (daarmee ben ik natuurlijk nog steeds geen expert) maar ik kan nergens vinden dat het gebruik van client certificaten bij LDAPS verplicht is, noch dat provisioning automatisch plaatsvindt als je client certs gebruikt.

De LDAP client hoort natuurlijk het TLS server-certificaat te controleren ([*]) om zeker te weten dat met de echte server (niet met een MitM) wordt gecommuniceerd. Aan de hand van een gebruikersnaam en wachtwoord, verstrekt door de LDAP client, weet op haar beurt de server dat de client is wie hij zegt dat hij is. Goed vergelijkbaar met de manier waarop je op security.nl inlogt (als je een account hebt). Daar heb je ook geen client certificaat voor nodig.

[*] Dat server certificaat is RFC 3280-compliant, en dat lijkt iets te zijn waar niet elke LDAP client client mee om kan gaan, zie https://serverfault.com/questions/926546/active-directory-ldaps-client-certificate-authentication en https://blogs.technet.microsoft.com/askds/2008/09/16/third-party-application-fails-using-ldap-over-ssl/. Vergeet ook niet dat firewalls de poorten 636 en/of 3269 zouden kunnen blokkeren als het verbinding maken niet lukt (zie de volgende URL voor uitleg over deze poorten).

Voor het overschakelen van LDAP naar LDAPS vond ik dit artikel van Kurt Roggen erg verhelderend (en aansluiten op mijn kennisniveau): https://kurtroggen.wordpress.com/2018/08/03/are-you-using-ldap-over-ssl-tls/.

Van certificaten weet ik meer. Inderdaad vindt provisioning (uitrollen, configureren) van client certificaten niet altijd even veilig plaats. Bijvoorbeeld de Sophos VPN client installer die je vanaf een door de Sophos UTM gegenereerd portal kunt downloaden is duidelijk een compromis tussen beveiliging en gebruiksgemak. Want die executable bevat, naast het client certificaat, ook de bijbehorende private key (beide buiten het met authenticode ondertekende gebied, maar dat terzijde). Het veiligst is het om het sleutelpaar op de client te genereren, dan hoeft de private key nooit de client te verlaten. Bij het downloaden van die software is het van belang dat je heel goed oplet dat je deze niet van een fake server downloadt (bijv. na een nepmail waarin staat dat je jouw client moet updaten tezamen met een link naar die fake server), want dan kan een MitM toeslaan.

In https://docs.microsoft.com/en-us/azure/active-directory/authentication/active-directory-certificate-based-authentication-get-started wordt beschreven hoe AD clients met een client certificaat kunnen authenticeren, maar in dat verhaal wordt het mij niet duidelijk hoe client cert + private key op zo'n device terechtkomen. Nadat op het einde van de requirements genoemd wordt:
staat in stap 4:
Met andere woorden, tenzij hier achter de schermen, ongedocumenteerd dus, iets magisch gebeurt, lijkt er - in elk geval in dit scenario - geen sprake van het automatisch provisionen van client certificaten en de bijbehorende private keys.

Heb je verwijzingen naar documentatie waaruit blijkt dat dit automatisch provisionen van client certificaten "standaard functionaliteit in AD" is?

De titel van het Microsoft document is "ldap-channel-binding-and-ldap-signing-requirement-for-windows".
Ik snap niet goed waarom het niet "ldap-tls-connection-requirement-for-windows" heet als dat was wat er verandert.
Als er een "ldap signing" requirement is hoe gaat dat dan werken zonder dat er ergens mee gesigned kan worden?
Om dat te weten ben ik er nog niet diep genoeg in gedoken. Ik hoopte dat er hier iemand was die het al geimplementeerd
had buiten een strictly-Microsoft environment en die kon vertellen wat er nodig is om een AD query te kunnen doen op
een gepatchte server. Ik heb in het verleden allerlei dingen gemaakt op Linux machines die bijv even de lijst van
gebruikers opvragen of de groepen waar een gebruiker lid van is om dit te gebruiken in een context waar beveiliging
niet zo van belang is. Read-only access, via een daarvoor aangemaakt account. Dat werkte altijd gewoon met een
LDAP query op poort 389. We hebben bijv ook copiers staan waar je op kunt scannen en mailen en waarin je het
bestemmingsadres kunt opzoeken in AD. Ik ben benieuwd of dat straks allemaal nog werkt of dat die copiers dan
ineens "lid van het domein" moeten gaan worden.... en of ze dat wel supporten.
Vandaar de vraag eigenlijk.


Verwijzingen naar documentatie niet, maar er heeft een tijd een WiFi netwerk gedraaid bij ons waar laptops die lid zijn van het domein konden iconnecten met een SSID die toegang gaf tot het LAN met een WPA2-EAP authenticatie dmv een client certificaat, en die client certificaten werden via AD naar de client gestuurd bij het joinen aan het domein. Dat moest je dan via ethernet doen.
(neem ik maar even aan, het kan natuurlijk ook nog zijn dat de client ze genereerde en naar de server stuurde, maar ze stonden in ieder geval gewoon in de Windows cert store)
Dit werd allemaal geregeld door een group policy.

Volgens mij gaat het net zo als je je Windows netwerk optuigt voor 802.1x

Absoluut verwarrend, je hebt helemaal gelijk.

Voor zover ik weet hoeft dat niet.

Ik heb me verder ingelezen in LDAP authenticatie, en in mijn bijdrage onder https://isc.sans.edu/forums/diary/Authmageddon+deferred+but+not+averted+Microsoft+LDAP+Changes+now+slated+for+Q3Q4+2020/25800/ leg ik uit wat het voordeel is van een TLS verbinding: de client kan dan zelfs veilig authenticeren met plain text username/password (geen risico op het lekken van password-hashes e.d.). Onder voorwaarde dat de client het DC certificaat accepteert en op correcte wijze valideert.

Devices die dat niet ondersteunen zijn niet veilig genoeg meer om te worden gebruikt, en zul je moeten updaten of vervangen. Of de risico's accepteren en, zodra Microsoft de patch uitrolt, opt-outen.

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.

Het gaat niet enkel om die devices zoals printers. In een enterprise heb je de stacks met services - applicaties die via een SSO (single signon) de provisioning krijgen. Die "applicaties" bouwen daarvoor op de LDAP stack door naar AD.
Dat is waar ik de hit en link van gaf. Het viel me daarbij op dat de huidige versie enkel op de plain-text poort werkt bij een nieuwere zit die bosh java als optie. apache: https://directory.apache.org/api/user-guide/5.1-ldaps.html

Ik noemde het switchen van poorten omdat de uncrypted versie poort 389 gebruikt en de encrypted standaard: 636 (indien onder root draaiend default keuzes). Heb je een verbinding naar LDAP(s) in je "applicatie" en die gebruikt de poortnummers dan moeten die poortnummers in je code aangepast worden.
Het wordt interessant in je "applicatie" als er een synchronisatie mechanisme gebouwd is om te valideren dat alle gebruikers opgenomen je "applicatie" overeenkomen met die in LDAP. Een RDBMS moet bijvoorbeeld de gebruikers allemaal intern opgenomen krijgen voor de autorisatie naar de DBMS bronnen. Er zijn veel meer van dat soort applicaties al een DBMS. een Enterprise staat er vol mee

SAP is heel bekend en veel gebruikt. https://help.sap.com/doc/saphelp_smp309svr/3.0.9/en-US/7c/2df7fb70061014a74296ccd5fdc63e/content.htm?no_cache=true Ga je gang als je alle SAP devices-servers-clients omgezet moet zien te krijgen.

Een toevoeging vanuit ervaring. LDAP clients kunnen de gewoon Linux servers zijn.
Heel verwarrend dat een LDAP client device moet gaan zoeken en dan uitkomt op wat anderen "mijn Linux server" noemen.
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/5/html/deployment_guide/s1-ldap-pam

Is er veel activiteit en log je alles dan kun je in performance problemen raken.
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.1/html/Configuration_and_Command_Reference/logs-reference.html
Dat wordt een aardig verhaal als de uitrol van LDAP clients opgeschort moet worden wegens performance issues en je wet niet over welke apparaten je het hebt.

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? TLS lost meestal maar heel weinig op als het om
beveiliging van een lokaal netwerk gaat, hoeveel tamtam er ook altijd over gemaakt wordt. Client certificaten daarentegen
zouden wel wat toevoegen.

We gaan het zien. Ik heb een tijd geleden onze Windows beheerder gevraagd om een testomgeving zodat ik het kan
checken, bijv 1 van de domain controllers omzetten en de andere niet. Is nog niet gebeurd.

Als Linux zich moet verlagen tot niveau Windows dan krijg je natuurlijk problemen!

Het probleem hier is dat Windows (AD server LDAP) zich moet verlagen tot het niveau van Linux.
De clients ofwel Linux devices zijn niet op orde, Ik zei niet voor niets praktijkervaring.

Wat je dan moet doen is die Linux devices in een apart fysiek segment zetten met een eigen LDAP (AD) server zodat enkel daar dat onveilige protocol langskomt.
https://docs.microsoft.com/en-us/windows/security/threat-protection/windows-firewall/domain-isolation-policy-design
https://www.dellemc.com/en-us/collaterals/unauth/technical-guides-support-information/products/data-protection/docu91924.pdf (pag 16 ) lijkt me basiskennis voor ICT.
"LDAP without TLS protocol communicates in clear text without encryption. Secure LDAP (LDAPS) does not support communication in clear text. When you configure LDAP without TLS, to improve security, it is recommended that you use a segmented network containing only the LDAP server and the Data Protection Central server."

Omdat een gesloten protocol gereverse engineered moest worden? Als Microsoft haar werk goed zou doen dan zouden zij de client libraries voor Linux leveren. Als open source software natuurlijk. Maar nee, alles zoveel mogelijk gesloten houden en dan anderen de schuld gaan geven...

Verdiep je eest even in LDAP dat is een open protocol wat ook gesupport wordt onder AD. Het is de OSS wereld die hier faalt door de slechte support in LDAPS. Het protocol heeft niet eens client libaries die speiciek voor een implementatie zijn.
Je hebt wel de afhankelijkheid in vele producten zoals SAP en pivotal welke dan heel specifiek naar LDAP gaan omdat het op de server (Linux) niet geregeld is. Je heb t er duidelijk nooit mee te maken gehad.

Het is een Microsoft protocol dus zij zouden de software moeten leveren. Net als device drivers door de fabrikant van de hardware worden geleverd. Waarom Microsoft hier in gebreke blijft en andere mensen hieraan tijd en geld laat verspillen is zoals gewoonlijk weer onduidelijk.

Volgens mij is ldap of ldaps geen microsoft protocol. En Microsoft hoeft daar dus ook geen libraries voor te leveren. Iets met open standaarden, en daar is LDAP er 1 van. Nu heeft Microsoft wel wat aanpassingen doorgevoerd, maar voor de standaard LDAP (of ldaps) is hier niets speciaals voor nodig.

Dan snap ik karma4's hele probleem niet! Wat wordt er dan gezeurd over dat het onder Linux niet zou werken? Onzin dus!

En wat bedoel je daar mee?
Oude clients ondersteunen dus niet altijd SSL? Menig vbs script doet eigenlijk het zelfde. Als je opbasis van ldap verbinding maakt en geen ldaps gebruikt, tja... Dan gebruik je unsecure authenticatie.

Wat heeft root hier mee te maken? Het zelfde is namelijk van toepassing als je een script onder een admin account, of onder system laat draaien?
En het is inderdaad een keuze ldap of ldaps.

Das meestal het geval als je van unsecure naar secure gaat. Zelfde is met http, pop3 of imap.
Als de secure versie op een andere port luistert, dan heb je inderdaad een andere port in je configuratie nodig. Vergeet je (linux) firewalls trouwens ook niet in je segmentatie.

Wat heeft dit met een aanpassing van ldap naar ldaps te maken? Ik ken trouwens ook menige windows applicatie die samaccountnames of upn accounts gebruikt. Komt inderdaad regelmatig voor bij een Enterprise. Maar staat los van ldap of ldaps.

Ja... Dus? Wat is daar bijzonder aan?
Ik zou eerder als SAML of kerberos gaan: https://help.sap.com/doc/saphelp_smp309svr/3.0.9/en-US/7c/2f3e3f70061014b3f2b329b9c52f4e/frameset.htm. Maar LDAP is een mogelijkheid, en ja... Dat kan zijn dat die dit moet aanpassen als je van ldap naar ldaps gaat. Maar wordt niet op honderden locaties bewaard. Ik zie dit nu niet echt als een mega operatie of heel bijzonder.

Ik zie daar niet echt een probleem. ALS men al LDAP gebruikt. De meeste enterprise SAP omgevingen zullen waarschijnlijk kerberos, SAML of native AD gebruiken.

Waar is linux hier precies? Het gaat om applicaties die ldap gebruiken en niet secure ldap. Ik heb heel wat applicaties draaien die ook onder Windows gewoon standaard ldap gebruiken ipv ldaps (helaas). Moeten deze Windows servers dan ook verlagen tot Linux servers?

Nee de applicaties zijn niet goed geconfigureerd. Dat heeft niets met een OS te maken.

Nee... De applicatie (en daarmee ook de servers) moet draaien in een ander segment. Ik zou dus in dit geval ook mijn WINDOWS servers moeten verplaatsen als ik deze architectuur zou volgen.

Als je het verschil tussen de applicatie en een OS niet snap, dan is der inderdaad wat basiskennis afwezig.

De printers maar ook Linux systemen met middelware dbms big data zitten te vaak vast aan die unsecure autenticatie.
Dan moet de LDAP server, het geval van dit draadje ook die unsecure devices bedienen.
Je moet eerst alle clients in beeld hebben en die om kunnen zetten.

Alles onder de 1024 als poortnummer moet verplicht onder root draaien. Het is een verplichte standaard.
Dat betekent dat ook alle processen voor LDAP LDAPS kwetsbaar zijn voor root access als er wat mis gaat in de protocolafhandeling. Je kunt dat verminderen met subprocessen onder andere rechten wat meer complexiteit brengt.


Natuurlijk is dat gewoonlijk het geval. Dan is het inventariseren en dan planmatig om gaan hangen. Dat omhangen moet wel mogelijk zijn. Als de client een kostbaar iets is en kritisch in de organisatie dan zul je daar veel werk mee hebben.

Het issue staat los van ldap ldaps er zijn vele andere verandertrjecten met zo'n uitdaging.
Je zult het wel moeten nalopen voor alle SAP installaties. In de OTAP van infrastructuur testen met gebruikers etc.
Technisch niet bijzonder maar je weet dat je hier moeilijk doorheen komt omdat in de dagelijks operationele keten hangt.
SSO moet al snel wegens de gebruikersacceptatie. SAP projecten zijn al berucht om de lange doorloop en complexiteit.


Die applicatie die gewoonlijk een Linux versie draaien. LDAP(s) is niet van de applicatie zelf.
Je komt we degelijk bij het OS uit. Of zeg je dat LDAP en AD de applicaties zijn?

..

TLS lost het probleem van authenticatie, vertrouwelijkheid en integriteit zo goed op, dat we het op internet voor steeds meer onveilige protocollen gaan gebruiken. Ik zie niet in waarom dit op lokale netwerken niet zo zou zijn. En als dit al zo zou zijn, waarom client certificaten dan wel zinvol zouden zijn?

Het zou fijn zijn als ZiZi, karma4 en The Foss hun zinloze oorlogen in hun eigen draad zouden uitvoeren.

Zelfs mijn verzoek bovenin deze draad "Nb. comments hieronder in de lijn van dat je een ander OS dan Windows moet gebruiken, worden niet op prijs gesteld" lezen zij niet en drammen hun vetes door de strot van iedereen die inhoudelijk geïnteresseerd is in de door mij aangekaarte problematiek - notabene over het scheidingsvlak tussen Microsoft en non-Microsoft systemen en/of software.

Ik zou het eerder gewoon applicaties noemen. Wat we hebben hier ook diverse windows applicaties die LDAP/LDAPS praten.
Maar 99% van deze applicaties ondersteund gewoon LDAPs, dat dit tijdens configuratie niet geactiveerd is, is het werkelijke probleem.

Dat is met iedere aanpassing van toepassing.

Volgens mij is dit alleen op het openen van de socket. Daarna kunnen de rechten aangepast worden.
Iets wat iedere webserver op Linux dus eigenlijk al doet? Dus draait het process gewoon onder een standaard rechten en doet het niets meer met root. Toch?

Dit klopt. Bijzondere is dat je dan even vergeet te melden dat bijvoorbeeld op een Windows domain controllers bijvoorbeeld DNS en Active Directory Domain Services onder het system account draait. Dat komt overeen met administrator (root) rechten. Sterker nog…. dit betekend dat deze computer dus ALLE rechten heeft op de AD en eventueel afhankelijke settings. Dat gaat nog een stukje verder dan root op 1 Linux server.
En laat ldap nu net een onderdeel van Active Directory Domain Services zijn.

Hoe zie jij dit nu dit met commentaar?


Voordeel dat het een server is, je hetb dus alle controle hierover. Nog afgezien van ldap naar ldap niet een mega aanpassing is.

Dit is nu niet echt een hele complexe technische aanpassing, ldap naar ldaps. Ja het is een change, en ja je moet deze goed door testen. Maar we hebben over een betrekkelijke eenvoudige aanpassing.
SAP projecten zijn onderdaad berucht, maar dat is voornamelijk functioneel, en niet vanuit de techniek.

De applicatie is AD of LDAP of ldaps. En de clients zijn LDAP clients. Welk OS hieronder draait maakt niet uit voor de configuratie van beide.

Het zou fijn zijn als ZiZi, karma4 en The Foss hun zinloze oorlogen in hun eigen draad zouden uitvoeren.

Zelfs mijn verzoek bovenin deze draad "Nb. comments hieronder in de lijn van dat je een ander OS dan Windows moet gebruiken, worden niet op prijs gesteld" lezen zij niet en drammen hun vetes door de strot van iedereen die inhoudelijk geïnteresseerd is in de door mij aangekaarte problematiek - notabene over het scheidingsvlak tussen Microsoft en non-Microsoft systemen en/of software.

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:
In hoeverre non-Microsoft LDAP clients hiermee om kunnen gaan, weet ik niet.

B) Uit https://u-tools.com/help/LdapMismatch.asp
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.

CONCLUSIE
Kortom, 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):

Het zou fijn zijn als ZiZi, karma4 en The Foss hun zinloze oorlogen in hun eigen draad zouden uitvoeren.

Zelfs mijn verzoek bovenin deze draad "Nb. comments hieronder in de lijn van dat je een ander OS dan Windows moet gebruiken, worden niet op prijs gesteld" lezen zij niet en drammen hun vetes door de strot van iedereen die inhoudelijk geïnteresseerd is in de door mij aangekaarte problematiek - notabene over het scheidingsvlak tussen Microsoft en non-Microsoft systemen en/of software.

Je zou het socketdeel moeten ontkoppelen van de rest en dat van die rest onder een specifiek eigen serviceaccount moeten draaien. Nou wil ik van jou een lijst zien waar dat zo geïmplementeerd is. Ik ken er geen meer.
Shellshock was het bewijs dat het bij geen enkel webserver zo geregeld is, met code injection heb je hetzelfde argument.
Het is meer werk niet moeilijker eerder eenvoudiger, toch gebeurt dat niet. Leg maar uit waarom niet.
Dat zelfde verhaal heb je met de netwerksegmentering (fysiek en logisch) en admin gebruik. Geef maar uitleg voor die weerstand. Dat zelfde verhaal met LDAP/LDAPS, je vind het technisch eenvoudig, prima. Leg dan maar uit waarom het trajecten van vele moeizame jaren zijn. Denk dan eens aan die vele duizenden servers en honderden applicaties.
Gaarne plan van aanpak beschikbare capaciteit etc.l

Dat zien anderen geheel anders. Applicatief fucntioneel dan kom je bijvoorbeeld bij de HR afdleling als beheerder en verantwoordelijke voor de installatie uit. Kom je met een middelware pakket dan verwijzen die je naar de technische ICT afdeling om iets te regelen. Stond zo ook bij Redhat en Dell. .

Dat zou inderdaad mooi zijn. Maar als het OS dit niet ondersteund is dat een constraint. Bijzonder zou zijn, waarom het op andere OS-sen wel mogelijk is, maar juist niet gedaan wordt. Zoals ldap in AD. Draait daar exact daar onder rechten op de complete infrastructuur.

Gaat hier vrij snel... Maar de vraag zou zijn, waarom gebruikt de applicatie al niet standaard ldaps?

Dit hangt natuurlijk helemaal af van je omgeving, hoe het beheerd wordt/is. Je kunt duizenden servers hebben, maar met 1 configuratie file.

Maar overdrijven ben jij altijd goed in.

Dat zien anderen geheel anders. Applicatief fucntioneel dan kom je bijvoorbeeld bij de HR afdleling als beheerder en verantwoordelijke voor de installatie uit. Kom je met een middelware pakket dan verwijzen die je naar de technische ICT afdeling om iets te regelen. Stond zo ook bij Redhat en Dell. .[/quote][/quote]Dan is het nog steeds geen OS aanpassing, maar een applicatie aanpassing. Dit zou onder technisch applicatie beheer moeten vallen en niet direct functioneel applicatie beheer.
Maar de technische ICT kan inderdaad de configuratie informatie aanleveren voor de applicatie beheerders.

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!

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:
In hoeverre non-Microsoft LDAP clients hiermee om kunnen gaan, weet ik niet.

B) Uit https://u-tools.com/help/LdapMismatch.asp
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.

CONCLUSIE
Kortom, 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):

Bedankt voor het maken van het overzicht Erik. Dit gaat dus nog heel wat uitzoekwerk worden zeker als er geen
testomgeving beschikbaar is waarin ik even kan kijken wat er gebeurt met mijn bestaande PHP en Perl code+libraries
en wat ik daarin minimaal moet aanpassen om het weer te laten draaien. Van ldap naar ldaps overschakelen dat
kan wel zo te zien maar of er dan problemen komen met een simple bind en of er support is voor al die extra opties
in die omgevingen dat is natuurlijk de vraag. Zeker omdat de systemen niet helemaal uptodate zijn, dat ga ik eerst
maar eens oppakken om meer kans te hebben dat het straks weer werkend te maken is.

Gelukkig is het allemaal niet super kritisch voor de operationele systemen, het is meer "voor het gemak" allemaal.
(tooling voor het maken van overzichten en koppelingen)

@Anoniem 10:46: dank voor jouw reactie en succes met het uitzoekwerk!

Ik heb met succes getest met comtarsia , .. NTLM auth.. SSL "search for user" ADV190023
https://signon.comtarsia.com/main/en/Update-b26
wie heeft er ervaring mee?

FYI: Afgelopen week heeft Microsoft https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023 bijgewerkt met o.a. de toevoeging van een verwijzing naar een nieuwe FAQ pagina "Frequently asked questions about changes to Lightweight Directory Access Protocol": https://support.microsoft.com/en-us/help/4546509/frequently-asked-questions-about-changes-to-ldap.

Ik denk dat jij dan maar moet stopen met je computer en smartphone. Allemaal veel te moeilijk.

Daarom is het legacy spul en moet je het niet meer gebruiken als het veilig moet.

Met LDAP (zonder S) gaat alles cleartext over het netwerk en kan je de accountinfo (inclusief wachtwoorden) van je gebruikers gewoon via het netwerk sniffen.

Ongeveer zoals bij telnet, dat gebruikt daarom niemand meer (behalve cisco voor hun backdoors :) )

Over het scheidingsvlak gesproken. Dat kan maar 1 ding zijn en dat is een dikke vette firewall. Ga geen AD gebruiken in je Linuxomgeving maar IPA (als je toch een SSO wil hebben dan hooguit een beperkte koppeling tussen AD en IPA). Alleen hiermee garandeer je dat je Linuxomgeving blijft werken als MS iets onverwachts verandert. Gebruik verder ook niets uit het windows netwerk maar regel je eigen DNS en DHCP anders kan je nog diverse windows licenties betalen voor elke Linux device! Dat geldt ook voor http servers op basis van windows. Voor elke gebruiker of Linux device die een windows webserver bezoekt heb je een licentie nodig! Geen samba shares etc, alleen dns, https en ssh door die firewall.

Wij gebruiken deze koppeling niet voor user authenticatie maar voor het in batch ophalen van AD gegevens om deze
te importeren in een lokale database voor gebruik in rapportages en voor een interne telefoonlijst. Het is helemaal
geen security issue en de boel stort niet in als het een dag of een paar dagen niet werkt.
Ik ben nu eerst bezig met de machine te updaten naar Debian Buster om in ieder geval van alles het nieuwste te
hebben zodat we niet aanlopen tegen "deze SSL/TLS versie of opties doen we niet". Daarna ga ik met ldaps testen.

2.0 03/10/2020
Microsoft is announcing that the March 10, 2020 security updates are available that add options for administrators to harden the configurations for LDAP channel binding on Active Directory domain controllers. These options are: 1. "Domain controller: LDAP server channel binding token requirements" group policy. 2. CBT signing events 3039, 3040, and 3041 with event source Microsoft-Windows-ActiveDirectory_DomainService in the Directory Service event log. Note that these March 10, 2020 updates and updates in the foreseeable future will not make changes to LDAP signing or LDAP channel binding policies or their registry equivalent on new or existing domain controllers.

@Anoniem 09:33: dank voor het vestigen van de aandacht hierop!