Existe-t-il des alternatives à la connexion à la connexion et à l'impersonnage compte donné pour accéder aux ressources du réseau? Je cherche la méthode d'impersonnation qui me permettrait de me connecter à la machine dans des domaines étrangers (ou des machines de groupe de travail pour la même question).
Pour les données initiales, j'ai: Nom de la machine, Nom d'utilisateur (ou domaine \ Nom d'utilisateur), Mot de passe ClearText.
Je sais qu'il y a un moyen d'établir une connexion avec WnetaDDConnection à un \\ Machinename \ ipc $, puis la plupart des fonctions de réseau s'exécuteront dans un contexte de ce compte, mais Win2008 a ajouté une autre torsion et certaines fonctions utilisent toujours le compte, ce fil est en cours de marche.
Je suis également au courant, qu'il y a un moyen d'obtenir un jeton d'impersonation utilisant SSPI. Quelqu'un a-t-il expérimenté ces jetons, sont-ils utiles pour accéder aux actions, SCM, Registre à distance et Stuff? Est ce que WnetaDdConnection utilise?
EDIT: Pour clarifier, la raison pour laquelle je ne peux pas utiliser Logonuser est parce que je dois imiter l'utilisateur dans un domaine ou un groupe de travail non approuvé
4 Réponses :
La théorie va que vous transmettez les informations d'identification comme un sec_winnt_auth_identity structure sur AcquireCredentialShandle fonction qui crée la poignée utilisée dans InitialiseSecurityContext . Je n'ai jamais essayé cela sur des domaines étrangers et je ne sais pas si cela fonctionne.
Faire cela directement et de manière fiable via l'API Windows semble à côté de Impossible, plus Windows fonctionne autant dans les coulisses pour rendre l'accès au réseau "juste fonctionner". Plus le côté de l'impersonnation des choses ne fonctionne que pour le fil unique qui appelait les API.
Mais ... vous pouvez exécuter tout un programme sous un autre utilisateur ... comme lorsque vous exécutez un service.
Vous pouvez donc modifier le registre dans votre programme principal pour exécuter divers services sous différents jetons de sécurité et utiliser IPC / Sockets pour communiquer avec ces processus de votre application principale. c'est à dire. Toute une bouquet (ou redémarrer et reconfigurer le même processus) des processus d'assistance exécutés sous les différents utilisateurs que votre application principale abuse.
Je me rends compte que c'est un hack, mais il semble viable;)
Nan. pas viable. Besoin de pouvoir obtenir des jetons d'impersonnation pour des machines dans une forêt non fiable. Vous ne pouvez pas exécuter de programme en tant qu'utilisateur de forêt non rigide
Vous pouvez créer l'utilisateur localement car vous avez le mot de passe ClearText et supprimer l'utilisateur lorsque vous avez terminé. Une autre option parle de DSCERPC / MSRPC ( en.wikipedia.org/wiki/msrpc ) directement mais Ensuite, vous descendez effectivement une piste similaire à Samba, mais au moins vous pouvez utiliser Wireshark pour comparer votre mise en œuvre contre ce qui se passe via les API de fenêtre normale. Pouvez-vous installer des programmes d'assistance sur la machine distante et sur l'impulsion à cette fin (et utiliser le protocole que vous souhaitez vous connecter au programme d'assistance distant?)?
Je suppose que je n'ai pas lu votre commentaire sur le service. Mon message a été spécifiquement instigué par le fait que lorsque j'essaie d'installer un service sur une boîte de Windows 2008 distante, et j'ai déjà un partage mappé, SCM distant n'utilisera toujours pas le compte utilisé pour mapper une part.
Les versions plus récentes de Windows STOP permettent des services d'utilisation de lecteurs mappés, ce qui ne laisse que des chemins UNC pour accéder à des lecteurs distants. Il est logique que des lecteurs mappés sont plus liés au bureau que tout autre chose.
Correct. J'aurais dû utiliser soigneusement le libellé. En "mappant un lecteur", je voulais dire "établir une connexion WMNet". Ce que j'ai trouvé, cependant, c'est que même si j'ai établi une connexion et que je puisse copier des fichiers, sous Windows 2008 tente d'ouvrir SCM utilisera actuellement Compte connecté, et non celui que j'ai utilisé pour établir la connexion et copier des fichiers. C'est la raison pour laquelle je cherche quelles alternatives sont
Vous pouvez ouvrir une ligne de commande, cartographier le lecteur en utilisant le nom d'utilisateur et le mot de passe en plainte. Puis débranchez le lecteur: http://technet.microsoft.com/en-us/library/cc756153 (WS.10) .aspx
J'ai mentionné cette solution ne fonctionne pas: "Je sais qu'il y a un moyen d'établir une connexion en utilisant WnetaDDConnection à un \\ Machinename \ ipc $, ..." - Vous suggérez essentiellement la même chose
Désolé, je pensais que wnetadddconnection était quelque chose de différent.
Si vous souhaitez "accéder aux ressources du réseau" en dehors de votre forêt, faites-le avec WnetaDDConnection2 / 3 comme vous l'avez mentionné ou utilisez les API de RPC standard avec RPC_ C__ Authn__ GSS__ Négocier et et explicitement des informations d'identification.
Normalement, "L'impersonnation" est quelque chose qui se passe sur le côté serveur. Le côté serveur sera capable d'imiter la connexion comme compte que vous connectez comme.
Mais la clé est la suivante: L'iméritée n'a aucun sens pour imiter un compte que le serveur peut accéder à son répertoire local Sam / Domain / Forest. Si le client et le serveur sont dans différentes forêts, ils ne peuvent clairement pas être d'accord sur le SID d'un compte d'un jeton d'impersonation (à l'exception du cas de SIDS bien connu comme l'administrateur qui servent principalement à confondre ce genre de chose), et cela semble nécessaire de vérifier contre les DACL etc.
Peut-être que ce que vous voulez, c'est appeler logonuserex avec le logon32__ logon__ NEW__ Drapeau des informations d'identification. Cela devrait réussir (même dans une forêt différente - elle ne authentifie pas réellement les informations d'identification que vous le donnez) vous donnant un jeton avec le nom d'utilisateur / mot de passe que vous avez spécifié. Vous devrez peut-être utiliser duplicateToken pour le transformer en jeton d'impersonation. Ensuite, vous pouvez utiliser SetTHeadToken pour remplacer le jeton sur votre fil.
IMHO Ce n'est pas vraiment "IMPANSONATION", vous utilisez simplement les informations d'identification, mais cela vous permet d'accéder à des ressources réseau de manière transparente en tant que nom d'utilisateur / mot de passe arbitraire que vous fournissez.
EDIT: Oh oui, soyez conscient qu'il n'y a aucune protection contre l'homme au milieu de ce type de connexion. Le client ne peut particulièrement pas authentifier fortement le serveur (à court d'héroïques comme IPsec), donc en théorie, vous ne pouvez rien faire confiance au serveur vous indique.
Wow, sonne comme une excellente approche! Je n'ai jamais pensé à utiliser ça. Laissez-moi vous donner un test rapide pour voir si cela fonctionne
mec, ça l'a fait! Merci beaucoup, c'était exactement ce que je cherchais
N'oubliez pas de restaurer le vieux jeton de votre fil et de nettoyer tous les nouveaux. Vous ne voulez pas fuir les jetons, je suppose qu'ils consomment une ressource rare dans le noyau et / ou lsass.exe.
Par curiosité, avez-vous fini par avoir besoin d'appeler duplicateetoken?
Nan. Toutes les œuvres sans problème, pas de duplicateToken nécessaire. Voici le code: docs.google.com/view?id=DJCGSJZ_1GVHC7WFG
Frais. C'est un cas où C ++ Destructeurs sont parfaits pour nettoyer des objets tels que des jetons et appeler Revertoself ().
Marsh, merci !!!!!!! Après une semaine de sommeil et assez de capitaine. Morgan veut le rétrograder à privé, vous me mettez sur la bonne voie. Vous avez déclaré que "normalement", une "impersonnation" est quelque chose qui se passe sur le côté serveur. " Cela a fait tout clair. J'étais coincé à penser que le client devait pouvoir authentifier les informations d'identification afin d'obtenir un jeton. Mon problème était que l'authentification NTLM contre un serveur SQL avec les pilotes MS ODBC authentifiés dans le contexte de l'utilisateur connecté. Cela nécessite des informations d'identification correspondantes sur le client et le serveur. Pas acceptable. Notre service a hund