Bonjour,
 
MS doit pousser un KB de sécurité au cours du second semestre 2020 "forçant" le passage au LDAPS au détriment du LDAP.
 
Nous constatons que certaines de nos applications ne sont pas compatibles LDAPS. Avez-vous déjà réfléchi de votre côté à des solutions de contournement svp ? (hormis ne pas passer le patch )

C'est pas exactement ça non ...

 
Je me suis mal exprimé, t'as toujours le choix de ne pas passer au LDAPS (en ne pas installant le KB) mais du coup tu laisses certaines failles de sécurité ouvertes.
 
Si je dis des conneries, faut pas hésiter à me corriger mais faut être un peu plus bavard stp.

MS ne force pas du tout le passage en LDAPS.
Ils forcent la signature et le channel binding, que ce soit en LDAP ou LDAPS.
Et oui bcp d'équipements ne savent pas gérer ça (même des trucs très récents, d'éditeurs très connus genre vmware).
https://portal.msrc.microsoft.com/e [...] /ADV190023
https://techcommunity.microsoft.com [...] -p/921536#
https://support.microsoft.com/en-us [...] or-windows
 
Ca fait des mois que ça doit être mis en place et à chaque fois décalé.

Aux dernières nouvelles, ça ne sera même jamais forcé.

 
Désolé, si je vous parais noob en la matière mais je débarque sur la partie AD prochainement, donc je n'ai pas encore toutes les compétences sur le sujet.
On m'a refilé le bébé du passage LDAP ==> LDAPS en me disant que ça devait être obligatoire pour toute nos applis d'ici la fin de l'année (puisque MS annonce second semestre 2020)
Je pensais naïvement que la signature et le channel binding étaient des éléments du LDAPS non présents dans LDAP, de ce que tu mets à priori je me goure complètement.
Le LDAPS est quand même plus sécurisé que le LDAP ? (je fais peut-être à tort le parallèle avec HTTP/HTTPS)
 
Merci à tous pour vos précieuses réponses.

Oui ldaps est plus sécurisé si on veut. Tu as un Channel chiffré avec TLS comme pour HTTPS.
Mais c'est pas parce que tu es en ldaps que tu as résolu le problème précédent. J'ai plein d'applis qui sont en ldaps et non compatibles non plus

 
Merci pour ce retour, mon futur responsable s'est donc fourvoyé sur le sujet (et moi aussi )
On n'est pas pressé donc
On va quand même poursuivre les migrations LDAP vers LDAPS, ça va augmenter le niveau de sécurité (cheval de bataille de mon DSI)
 
En quelques mots, le channel binding c'est quoi svp ?
 
(bien fait de passer par ici encore une fois)

Je pourrais pas t'expliquer sans relire la Doc en profondeur haha, je m'étais pas mal intéressé au sujet l'année dernière.
J'ai pas envie de dire de conneries, je crois que c'est la façon dont tu t'authentifies en ldap a partir d'un challenge ntlm

En gros, soit tu fais channel binding + signature et tu es secure (c'est ce que fait une machine Windows nativement par exemple).
 
Si tu ne peux pas (à la louche, à peu près tous les produits/équipements non MS) tu peux quand même renforcer la sécu en implémentant LDAPS.

Je comprends mieux pourquoi vous me dites que MS ne forcera jamais ce Channel Binding, ça mettrait par terre 99% des connexions aux applis.
Je ne vais pas remettre en cause le passage au LDAPS cependant et garder la pression (légère je vous rassure) sur les chefs de projet afin d'augmenter la sécurité de notre infra.

A la base, ils font ça pour de varies bonnes raisons. Dans l'état actuel, tu peux péter un AD en claquant des doigts ou presque sans ldaps ou channel binding + signature partout.
Les méthodes sont connues, faciles d'accès, faciles à mettre en oeuvre. Il y a vraiment un gros risque derrière.

Je reste perplexe par rapport à vos explications, j'ai poursuivi mes recherches et dans plusieurs sources, ils indiquent que le passage au LDAPS règle le problème :
 
https://www.worteks.com/fr/2020/03/ [...] lications/

 
ou encore

Alors les sites qui installent une PKI interne en mode porki, je ne suis pas sûr que ce sont des références
 
Mais accessoirement ça ne contredit pas ce que l'on dit non.

Vous, vous dites que passer toutes les applis en LDAPS ne suffit pas pour ce patch, eux à priori disent que oui (du mal à trouver des sources francophones, je fais avec ce que je trouve )

Bah écoute j'ai une appli (Vmware AppVolume) qui est bien en LDAPS mais qui ne fonctionne pas car n'implémente pas le channel binding.
Peut être que ton appli si, j'en sais rien mais vu les passages que tu quotes, on sent vraiment une grosse conviction du mec... ça sent plutôt le mec qui comprend rien ce qu'il fait et fait juste des constatations
 
C'est con, j'avais à l'époque bon tableau avec du rouge et du vert sur les différents scénarios qui marchent ou pas.
LDAPS permet d'implémenter du LDAP signing mais c'est pas la seule méthode

Je travaille pour un Département, on a 180 applis différentes environ, ça serait donc un beau carnage. Si déjà VmWare ne l'implémente pas je doute que des applis de niche le fassent.

LDAPS c'est plus une solution de contournement en fait. Donc ça peut être problématique à implementer, à gérer, faire évoluer, et ne pas forcément répondre à l'entièreté du besoin.

 
LDAPS peut se poser en alternative au LDAP signing : c'est bien une alternative, pas un "fix" car les cas d'usages sont bien différents, la nécessité de maintenir un certificat sur le DC notamment pour pouvoir passer en TLS.
 
https://support.microsoft.com/en-us [...] ows-server
https://support.microsoft.com/fr-fr [...] ows-server
 

 
=> en d'autres termes une fois la config appliquée c'est LDAPS ou LDAP signé ou rien.
 
Channel Binding c'est tout autre chose...
 
https://support.microsoft.com/en-us [...] stry-entry
https://support.microsoft.com/fr-fr [...] stry-entry
 
... et ne concerne QUE LDAP sur TLS.
 

 
C'est quand même plus simple d'aller taper à la source non ?

Merci pour cet éclairage. Le LDAPS est donc le minimum vital à appliquer avant le patch. Le top serait le channel binding mais peu d'applis le supportent. J'ai bon ?

Euh non, pas la peine d'appliquer du ldaps, c'est ce qu'on s'efforce de te dire depuis le début

 
Je vais devenir    
D'après la phrase quotée, vu que je ne fais du LDAP signé, il faut que je fasse du LDAPS (et ça toutes les applis concernées ou presque le permettent)
Je comprends vite mais faut m'expliquer longtemps

 
Tu as raté aussi la partie "une fois la configuration appliquée".
 
Comme ça a également été dit dans le sujet :
 
Important: The March 10, 2020 updates, and updates in the foreseeable future, will not change LDAP signing or LDAP channel binding default policies or their registry equivalent on new or existing Active Directory domain controllers.
 
https://support.microsoft.com/en-us [...] or-windows
 
(désolé pas d'équivalent en français dans l'article)
 
Donc pour le moment si tu fais ni l'un ni l'autre, bah, RAS. Ca ne solutionne pas le problème de sécurité mais ça a l'avantage de pas te mettre au pied du mur.
 
La seule chose que fait le dernier patch dispo est d'ajouter un paramètre de stratégie dans l'UI pour piloter le comportement de channel binding via la valeur de registre LdapEnforceChannelBinding (que tu pouvais déjà positionner à la main)

Et activer l'audit quand ce genre de configuration est détectée  

+1, je pense qu'il est urgent d'activer l'audit pour avoir toutes les infos sur qui fait des appels non secure et regarder comment y remédier

Je voulais dire que l'audit est maintenant automatiquement activé après installation du patch de mars. Il faudrait que je vérifie ça.

 
OK, je pensais que le prochain patch allait "forcer" cette configuration et ne pas nous laisser la main.
Donc on touche à rien mais on peut mettre du LDAPS à la place du LDAP non signé pour un peu plus de sécurité (faute de mieux)