Soumettre un 'job' avec un autre compte

**zifox** · 22/10/2008, 15h06

Bonjour,

J'ai une question de sécurité à laquelle je ne trouve pas de réponse.
Je travaille sur une application qui lance des traitements (applis, scripts, etc...).

Actuellement l'application utilise la fonction LogonUser pour changer de session, ce qui impose à l'appli de pouvoir récupérer le mot de passe en clair de la session en question.

Or, souhaitant me plugger à un annuaire (LDAP), afin de ne plus avoir à remplir les infos de comptes utilisateurs dans mon application, je me trouve coincé car je ne peux pas changer de session si je ne connais pas le mot de passe.
Or dans les annuaires, les mots de passe étant hashés, il m'est impossible de retrouver le mot de passe clair.

Donc ma question est la suivante: existe t il un moyen de changer de session sans mot de passe, comme on peut le faire sous unix en étant root ?

J'ai vu sur la msdn qu'un service qui tourne en tant que 'Local system' et qui a le droit 'SE_IMPERSONATE_NAME' est censé pouvoir le faire (ça fonctionne d'ailleurs puisqu'il suffit de demander à un service de se lancer 'en tant que...'). Comment puis je reproduire ceci ?

**bacelar** · 22/10/2008, 15h30

"l'impersonnalisation", c'est le fait de prendre l'identité du demandeur d'un service, pas de ce faire passer pour lui.
Si votre application doit être l'instigatrice d'une tâche, il faudra soit qu'il crée une session et donc connaisse le mot de passe, soit que le système la lance dans une session adéquate via la déclaration d'un service.
S'il était possible de changer d'utilisateur sans restriction cela serait un énorme trois de sécurité.
Si votre application n'est pas l'instigatrice des tache, soit elle est dans une session interactive avec un utilisateur, soit elle n'est pas ou n'a pas de session avec le bon user et cela est le cas typique d'un service avec impersonnalisation.
Donc normalement, soit votre application est un service et donc utilisation de l'impersonnalisation, soit elle hérite de l'utilisateur courant (runas.exe ou raccourcis avec changement d'utilisateur peuvent cacher la création d'une session utilisateur), soit la demande d'un login-mot de passe est impérative.

**Médinoc** · 22/10/2008, 15h34

L'impersonation ne permet pas de créer un nouveau process.
Tu dois utiliser CreateProcessAsUser() (qui nécessite le privilège "Assign Primary Token", que seul LocalSystem possède), ou CreateProcessWithLogonW(), qui nécessite seulement que le service de connexion secondaire tourne.

**zifox** · 22/10/2008, 16h38

Je complète un peu ma description:

Pour soumettre un job actuellement, j'ai trois étapes:
1- J'appelle LogonUser pour récupérer un Handle du user concerné.
2- J'appelle ImpersonateLoggedOnUser en lui passant le handle de manière à ce que le thread courant récupère le contexte
3- J'appelle CreateProcessAsUser en lui passant ma commande et le même handle.

Ceci fonctionne que l'appli tourne en service ou lancée à la main avec un compte local.

bacelar: d'après ce que tu dis, je dois pouvoir, si mon appli tourne en tant que service, me passer de mot de passe ?
Médinoc: que j'utilise l'un ou l'autre, dans tous les cas je dois passer par un logon quelque part, et donc donner un user et un mot de passe, c'est ça ?

**Médinoc** · 22/10/2008, 16h40

Non, je dis que CreateProcessAsUser() devrait échouer si tu ne tournes pas en service en tant qu'utilisateur NT AUTHORITY\LocalSystem.
Car par défaut, lui seul possède le privilège Assign Primary Token, nécessaire pour que CreateProcessAsUser() réussisse avec le token d'un autre utilisateur.

Par contre, si tu a joué avec les privilèges avant, tu peux peut-être l'ajouter à d'autres utilisateurs que LocalSystem...

**bacelar** · 22/10/2008, 18h45

Quand on enregistre un service Windows, on peut lui assigner on compte utilisateur et donner son mot de passe une seule fois, au moment de l'enregistrement.
C'est ainsi qu'IIS utilise toujours en compte avec le minimum de droit.
Si l'identité de l'utilisateur ne change pas au cours du temps, cela serais l'option la plus naturelle.
Si le compte utilisateur doit changer en cours d'utilisation, j'utiliserais l'impersonnalisation dans un service qui recevrait des requêtes des différents utilisateurs.

**zifox** · 23/10/2008, 09h36

bacelar: comme je l'ai dis dans mon dernier message, c'est déjà ce que je fais, et j'ai besoin du mot de passe pour le faire.

**Médinoc** · 23/10/2008, 09h43

Sous Windows, je ne connais pas 36 moyens de changer de session sans mot de passe, et tous impliquent de le faire à la demande de l'utilisateur en question.

Ça permet typiquement à un serveur de prendre l'identité d'un client connecté (en tubes nommés ou en DCOM) pour agir en son nom...

**bacelar** · 23/10/2008, 10h25

Vous n'avez pas besoin du mot de passe pour faire une "impersonnalisation".

**Médinoc** · 23/10/2008, 11h39

Ça dépend sur quoi.

ImpersonateNamedPipeClient(), c'est comme je l'ai dit pour le client d'un serveur.
Avec DCOM, c'est parail.
Pour ImpersonateLoggedOnUser(), il te faut un jeton d'accès avec les bons droits dessus. Et pour obtenir ledit jeton, généralement on utilise LogonUser(), qui exige le mot de passe.