J'ai un PC Windows 10 Pro, aucun domaine, je n'utilise pas BitLocker sur le lecteur système, mais j'ai crypté quelques disques de données fixes à l'aide de BitLocker et d'un mot de passe (pas de TPM).
Lorsque j'aime déverrouiller ces disques, je peux les sélectionner dans l'explorateur de fichiers et choisir Unlock Drive...
, après avoir entré mon mot de passe, le lecteur est déchiffré et je peux l'utiliser.
Parce que j'ai quelques-uns de ces disques avec le même mot de passe, j'ai écrit un script pour les déverrouiller tous en même temps.
Unlock-BitLocker -MountPoint X: -Password $myPassword
Cela fonctionne bien lorsqu'il est exécuté en tant qu'administrateur élevé, mais lorsque j'exécute le script comme étant mon utilisateur standard normal, il échoue:
Get-Ciminstance: Accès refusé
WBEM_E_Access_Denied (0x80041003) L'utilisateur actuel n'a pas la permission d'effectuer l'action.
J'assume à la fois l'explorateur de fichiers et le module PowerShell BitLocker utilise la même API Win32, pourquoi fonctionne-t-on comme un utilisateur standard et l'autre ne le fait pas?
Lorsque vous utilisez:
manage-bde –unlock E: -rp password
Je reçois:
BitLocker Drive Encryption: Configuration Tool version 10.0.14393
ERROR: An attempt to access a required resource was denied.
Check that you have administrative rights on the computer.
Utilisation du moniteur de processus, je peux voir que l'accès est refusé à la clé de registre suivante:
HKLM\Software\Microsoft\WBEM\CIMOM
J'ai également découvert que le menu du contenu de l'explorateur de fichiers appelle l'exécutable:
%systemroot%\System32\bdeunlock.exe
qui affiche la petite fenêtre contextuelle pour entrer le mot de passe.
Lorsque vous utilisez bdeunlock.exe
Pas d'accès à HKLM\Software\Microsoft\WBEM\CIMOM
est montré dans le moniteur de processus. Donc, il semble qu'il déverrouille le lecteur sans accéder à cette clé.
Il semble que les cmdlets PowerShell et manage-bde.exe
Utilisez WMI:
Get-CimInstance
-Namespace "root\cimv2\Security\MicrosoftVolumeEncryption"
-ClassName Win32_EncryptableVolume
et un utilisateur standard n'a pas accès à cela.
Mais bdeunlock.exe
Peut utiliser la fonction FveOpenVolumeW
in FVEAPI.dll
(Fichier API BitLocker) directement sans utiliser WMI d'abord.
Existe-t-il un moyen de déverrouiller un lecteur de données fixe BitLocked sur la ligne de commande comme utilisateur standard?
Vous pouvez accorder l'utilisateur standard ou un groupe de sécurité dont ils sont membres de l'accès explicite à l'objet WMI par le chemin que vous avez trouvé à partir de wmimgmt.msc
.
De cette façon, vous n'avez pas besoin de donner à l'administrateur local ou des autorisations élevées locales, et ils auront seulement l'accès exact et explicite dont ils ont besoin pour les espaces de noms de la WMI corrélés, selon les besoins et que rien de plus minimum d'autorisations nécessaires pour effectuer l'opération.
Instructions
Presse +
R
, type inwmimgmt.msc
et appuyez surEnter
. Cliquez avec le bouton droit de la souris sur le WMI Control (local) Option à gauche, puis sélectionnezProperties
.Allez le
Security
onglet des fenêtres de propriétés, puis développez leRoot
Espace de noms à l'espace de noms WMI spécifique Objet (s) Vous devez accorder l'accès explicitement.Une fois que vous avez l'objet d'espace d'espace de noms WMI applicable en surbrillance, à partir de là, vous sélectionnerez le
Security
Option à partir du côté droit inférieur des fenêtres de propriétés et d'ajouter dans le compte d'utilisateur ou des groupes de sécurité en conséquence, et accordez-la et définissez les autorisations applicables selon les besoins.
J'ai examiné le processus à l'aide du moniteur de processus pour savoir ce que Windows Explorer effectue exactement lors de la sélection de "Déverrouiller le lecteur" dans l'interface graphique. Il arrive de lancer bdeunlock.exe suivi de la lettre de lecteur. Cela semble être une application qui invite le mot de passe. Cela fonctionne à l'aide des autorisations utilisateur standard.
Compte tenu de la discussion ci-dessus, je peux voir deux solutions:
Pour le deuxième point, je peux voir une méthode (un peu encombrant) pour un utilisateur standard de lancer un script comme administrateur, en supposant que vous ayez accès au compte administrateur, mais ne souhaitez pas l'utiliser pour une utilisation quotidienne.
L'idée est d'utiliser une tâche planifiée qui s'exécutera à plusieurs reprises comme administrateur chaque minute après la connexion et vérifiera la présence d'un fichier qui contiendra la clé BitLocker et n'agira que si le fichier existe. Un tel déclencheur n'utilisera pas trop de ressources et ne ralentira pas l'ordinateur.
La discussion ci-dessous utilise la syntaxe de commande DOS, mais si nécessaire, PowerShell a une fonctionnalité similaire.
Si le fichier contenant la clé est dans /path/to/keyfile.txt
, la gâchette de tâche planifiée pour le déverrouillage sera similaire à ce script .bat:
if exists "/path/to/keyfile.txt" (
type "/path/to/keyfile.txt" | your-unlock-command-1
type "/path/to/keyfile.txt" | your-unlock-command-2
del "/path/to/keyfile.txt"
)
Pour démarrer le déclencheur, créez le fichier via un autre script qui sera exécuté sous un compte utilisateur standard:
set /P key=Enter key:
if %key% neq '' echo %key% > "/path/to/keyfile.txt"
Les détails sur ces commandes DOS peuvent être trouvés dans l'article:
[.____] n index A-Z de la ligne de commande Windows CMD
Je crains que vous ne puissiez pas faire cela avec le script en cours d'exécution comme vous, sauf si vous désactivez complètement UAC sur votre ordinateur. Toutefois, si votre question est liée à simplifier l'utilisation de votre script, j'ai trouvé une solution il y a quelque temps et que j'utilise chaque fois que je dois exécuter des scripts avec des autorisations élevées.
If (-NOT ([Security.Principal.WindowsPrincipal][Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole([Security.Principal.WindowsBuiltInRole] "Administrator"))
{
$arguments = $myInvocation.mycommand.definition
Start-Process powershell -Verb runAs -ArgumentList $arguments
Break
}
Après avoir inséré ce code au début d'un script, il effectuera automatiquement le script avec des autorisations élevées, passant à nouveau tous ses arguments à une nouvelle "instance élevée".