2009-10-16 8 views
3

J'appelle la fonction AdvaDesign.dll LsaEnumerateAccountRights ayant un handle de politique de LsaOpenPolicy et un SID de compte de LookupAccountName.LsaEnumerateAccountRights retourne toujours "Fichier non trouvé"

Cependant, essayez comme je le ferais, je suis toujours de retour 0xC0000034 qui après traduction par LsaNtStatusToWinError me donne "Le fichier référencé est introuvable."

Ce qui n'est pas très bien. Mon code gère cela et continue à accorder le compte SID le SeServiceLogonRight en utilisant LsaAddAccountRights, donc je sais que le handle de la politique et le SID du compte sont bien car cela serait bombe si quelque chose n'allait pas avec l'un d'entre eux.

Le résultat final est que le compte a le droit dont il a besoin donc globalement le code fonctionne.

Cependant, je l'utilise dans une action personnalisée MSI, l'installation vérifie si le compte a le droit et si ce n'est pas le cas (ou échoue comme ci-dessus), il accorde le droit et se souvient qu'il a fait dans l'état d'installation. Si une annulation se produit et qu'elle ajoute le droit, elle le supprime. Nous ne supprimons jamais dans une désinstallation car d'autres applications peuvent avoir été installées en utilisant le même compte de domaine que les services que nous utilisons.

Ainsi, le problème est lorsqu'un MSI effectue une restauration - il supprimera toujours le droit car il pense toujours l'avoir ajouté. Donc, vérifier les droits en utilisant LsaEnumerateAccountRights est utilisé pour cela - mais je ne peux tout simplement pas le faire fonctionner. Une idée - notez que j'utilise C# avec l'attribut DllImport pour exposer les fonctions Win32, et je ne suis pas le meilleur programmeur Win32 au monde ayant été Unix avant C#!

Répondre

1

J'ai récemment rencontré ce même problème. Dans mes tests avec ce problème, il semble que l'appel LookupAccountName renvoie un principal de sécurité plutôt que le SID complet. L'échec réel semble être que la section dans le SID où les droits de l'utilisateur serait soit n'est pas là ou raccourcie à seulement le droit de connexion.

L'exécution d'un appel LookupAccountName sur l'utilisateur actuellement connecté, puis l'exécution de LsaEnumerateAccountRights par rapport à ce SID aboutissent uniquement à la connexion de l'utilisateur. Même si clairement, il y a beaucoup d'autres droits attachés. Essayer d'extraire tous les autres utilisateurs, autres que l'utilisateur connecté, renvoie avec succès un SID. Cependant, ce SID ne contiendra aucun droit d'utilisateur.

J'ai testé cela sur des systèmes de groupes de travail sans domaine et des systèmes membres de domaines à la fois en tant qu'administrateurs et utilisateurs réguliers. L'appel LookupAccountName en cas de succès aboutit toujours à un SID qui ne contient pas l'ensemble des droits d'utilisateur.

Je ne peux que supposer que si un SID complet pouvait être obtenu à partir de la base de données de sécurité, alors le LookupAccountName itérerait correctement les droits.

0

J'ai aussi le même problème. Quelqu'un a suggéré que je reçois le SID via WMI avec cette requête:

SELECT * FROM Win32_Account WHERE domain = 'ntdomain' AND name = 'username' 

Je l'ai essayé, en utilisant ConvertStringSidToSid() pour obtenir le blob magique LsaEnumerateAccountRights() ... et attend même erreur. "Le système ne peut pas trouver le fichier spécifié."

7

J'ai lutté avec cela, aussi, mais je viens de le craquer ...Rétrospectivement, je vois maintenant qu'il y avait un indice dans la documentation msdn: "Les comptes retournés par cette fonction détiennent le privilège spécifié directement via le compte d'utilisateur, et non dans le cadre de l'appartenance à un groupe."

Voir: link text

Obtenez la poignée de la politique de LsaOpenPolicy() et un SID de compte à partir LookupAccountName() exactement comme vous.

Si le nom d'utilisateur que vous avez entré était le nom d'un groupe ("Utilisateurs", "Administrateurs", etc) alors LsaEnumerateAccountRights() fonctionne correctement et énumère tous les droits pour le groupe.

Si vous l'appelez sur un nom d'utilisateur dont les droits dérivent uniquement des groupes dont il est membre, alors il renvoie 0xc0000034 (= erreur Windows 2 - Le système ne trouve pas le "fichier" spécifié), ce qui signifie (nous réaliser) "ne trouve aucun droit supplémentaire attribué individuellement". Il semble que la traduction Windows Error 2 est un fourre-tout pour "ce que vous cherchiez n'a pas été trouvé".

maintenant ... Si vous avez ntrights.exe, exécutez ... par exemple:

ntrights + r SeNetworkLogonRight -u NomUtilisateur

Ensuite, LsaEnumerateAccountRights() fonctionne très bien, retourne sans erreur et énumère un seul droit, "SeNetworkLogonRight".

+0

Super incroyable !! Merci pour ça! – Ajay

0

je rencontre le même problème, il est parce que vous n'attribuer spefic privledge à l'utilisateur, de sorte que le priveldge utilisateur est vide, si vous ajoutez un à elle, échouer coutume.

Appelez la même fonction avec un groupe, vous pouvez voir tout fonctionne correctement.