Discussion :

[nesswaw]

Bonjour,

Un petit soucis que nous avons, depuis que Microsoft à bloqué, dans les GPO, le fait de pouvoir monter un lecteur réseau en se connectant avec un autre user (mnt le champ user/mdp est grisé), la seule (pour l'instant) solution que nous avons trouvé, est de monté ce lecteur via un script de démarrage au login de l'user.

Ce script est stocké dans NETLOGON, le script contient le mpd en clair...et NETLOGON est accessible en lecture à tous les users, ceci est le fonctionnement par défaut dans un domaine...

Ce qui en fait une faille de sécurité, potentiellement, n’importe quel user peut accéder à ce mot de passe...

Comment faire? On ne peut pas bloquer la lecture du dossier aux users, vu que utiliser par le domaine et les scripts doivent pouvroi être exécuté au login du user...

Bloquer la lecture du contenu du script? Mais du coup cela bloque la lecture complet du script...? Ou alors comment faites-vous?

Merci d'avance

[cerede2000]

Bonjour à toi,

Selon mon expérience, best practice de base :

• Soit créer un compte AD spécifique qui ne sert qu'as une unique chose c'est donner accès au partage mappé via le lecteur réseau.
  Ce compte n'as pas le droit d'ouvrir de session interactive bien sur, il n'est admin de rien du tout.....
• Soit créer un groupe AD, dans lequel tu place les membres qui doivent avoir accès à cette ressource, et du donne les droits d'accès à ce groupe.
  Du coup plus besoin de crédences pour monter le lecteur réseau si la personne à le droit, ce que tu vérifiera préalablement dans ton script bien sur

Et sinon pour garder le script tu peux déjà rendre difficile la lecture du login/MDP en l'obfusquant, moi j'utilise la base 64 par exemple.
L'utilisateur lambda qui ouvrira le script ne saura pas lire le MDP.

Ensuite pour rajouter une couche, tu peux par exemple stocker le MDP ailleurs que dans le script, toujours encodé mais pour aller plus loin tu peux en plus crypté le fichier qui contient le MDP avec un certificat que tu dépose sur les postes via GPO.

Mais il est clair que de toute façon une personne mal intentionnée qui chopera le script aura tôt fait de comprendre comment il fonctionne et il sera comment récupérer les informations...

Sinon il faut aller plus loin, mais vraiment
[MODE DELIRE]
Ton script appel un code compilé (.exe).
Celui-ci appel un webservice qui check l'authentification kerberos de ton user windows, mais aussi la validité de la machine depuis lequel il est appelé.
L'échange avec le WS est bien sur chiffré SSL.
Le WS renvoi les informations nécessaires : le chemin du lecteur, sa lettre, les crédences à utiliser pour le monter...
Le code compilé monte le lecteur.

Cette fois rien n’apparaît en clair, même si on récupère le code compilé, il faudra le dé-compiler, mais dedans aucune informations critique.
Et pour pouvoir le lancer et récupérer les informations il faut une machine connectée au domaine avec une session utilisateur valide.

Tu peux en plus dissimulé l'URL du WS pour qu'elle ne soit pas visible directement.
[/MODE DELIRE]

Après tout dépends du niveau de criticité des données à protéger sur ce lecteur réseau.

[nesswaw]

Bonjour,

Merci pour votre réponse.

C'est un user/mdp d'un autre domaine que nous ne gérons pas, c'est pour connecter un partage qui est externe à notre réseau, je ne peux donc utiliser un compte interne

La solution que j'avais retenu est d'utiliser un genre de Dropbox/NextCloud, pour échanger les fichiers, mais refusé par la hiérarchie .

Oui, comme vous le dites, le fait d'encoder le mdp est déjà mieux que rien, mais la personne qui va accéder à netlogon ne sera pas là par hasard, va donc trouvé rapidement le vrai mdp

Le coup de l'exe est pas mal, mais effectivement usine à gaz

Voyez-vous d'autre solution?

Merci

[cerede2000]

Dans ce cas il faut partir sur une idée d'exe compilé quand même...
Mais qui embarquera les identifiants et qui sera appelé par le script.

Attention les programme C# par exemple si non obfusqué sont très simple à dé-compiler.

Pas vraiment de solution miracle et de toute façon même si tu l'avais défini dans la GPO comme cela était possible à l'époque, il était très facile d'y accéder. C'est bien pour cela que MS à retirer cette fonction laissant le soins au admins de se débrouillé pour ne pas faire mieux
Mais au moins ils ne sont plus responsables...

[nesswaw]

Alors bravo et merci Microsoft...

Que voulez-vous dire par "si non obfusqué"?

Mais je trouve quand même dingue qu'il existe pas de solution plus simple, comment font les autres? Nous ne sommes pas les seuls à vouloir mapper un lecteru réseau avec un user/mdp précis?

Merci

[cerede2000]

Obfusquer signifie cacher le code.
En gros même si tu arrive à le décompiler en clair il est incompréhensible de base.
Le fonctions, les variables... sont renommés avec des lettres, des chiffres, rien n'as de sens pour un humain.
Cela rend le reverse engineering complexe.

Je ne sais pas comment font les autres, je n'ai pas traité ce cas depuis un moment car j'ai toujours pu faire autrement.
Mais j'ai eu d'autres cas de crédences à dissimuler et j'ai utiliser différentes techniques en fonction des cas.
Il est de toute façon difficile de totalement masquer tout, car forcément à un moment tu as besoin des crédences pour monter le lecteur au final.

Alors même en mémoire on pourrais imaginer qu'il serait possible de les récupérer, c'est toujours complexe mais bon rien n'est impossible de nos jours...
C'est toujours l'histoire du degré de risque par rapport au niveau de protection désiré.

Si déjà tu cache les crédences et qu'elle ne sont pas lisible en clair dans le script c'est un premier point.
Ensuite tu as une multitude de possibilités.

Est-ce que tu veux rester au niveau de l'ouverture de session ? Est-ce que tu as un outil de télédistribution ?
Tu peux utiliser une base de données, stocker les crédences chiffré dans le registre...

Une idée comme ça, dans les GPP tu créé une clé registre dans laquelle tu stock ton login/mdp que tu as préalablement "protégé", donc au minimum encodé en base64 et tu peux inclure dedans des choses en plus que tu retirera au moment de les décodés.

Puis ton script au lancement vérifie si le lecteur réseau est déjà mappé, si ce n'est pas le cas, alors il va chercher les crédences dans le registre, les décodes puis monte le lecteur.
Il supprime ensuite les crédences.
Ta GPP est paramétré pour ne poser la clé registre qu'une fois par user (tu pose dans HKCU). Donc les crédences ne reviennent pas.

Du coup même si un user choppe le script, l'emplacement dans le registre sera vide