2010-10-12 4 views
20

J'ai un script Powershell qui va être exécuté via un outil d'automatisation sur plusieurs serveurs. Il fonctionne correctement sur les machines Windows, car les appels distants utilisent le compte de service de l'outil sans avoir besoin d'être invité ou d'exposer des informations d'identification dans le code. Ce script s'exécute également sur des machines Linux via SSH en utilisant le paquet SharpSSH. SharpSSH n'utilise pas automatiquement les informations d'identification de l'utilisateur Powershell, mais requiert un nom d'utilisateur et un mot de passe, un fichier de clé RSA ou un objet PSCredential. Je ne peux pas demander d'informations d'identification à l'aide de Get-Credential, car il est exécuté via l'outil d'automatisation. Je ne veux pas exposer le nom d'utilisateur et mot de passe dans le code ou avoir une clé RSA assis là-bas. Je voudrais construire un objet PSCredential à partir de l'utilisateur Powershell actuel (le compte de service). Essayer [System.Net.CredentialCache] :: DefaultNetworkCredentials affiche un espace vide, et [System.Security.Principal.WindowsIdentity] :: GetCurrent() ne fournit pas l'objet ou l'information dont j'ai besoin.Récupère l'objet d'identification de l'utilisateur actuel dans Powershell sans le demander

Est-ce que quelqu'un a une méthode pour créer un objet PSCredential à partir de l'utilisateur actuel? Ou peut-être une alternative complètement différente pour ce problème?

Merci beaucoup!

Répondre

14

L'API Windows n'expose pas les informations dont vous avez besoin, ce qui explique pourquoi Powershell ne peut pas y accéder. C'est une caractéristique intentionnelle du sous-système de sécurité. La seule façon pour que cela fonctionne est que les machines Linux fassent confiance à la machine appelante, par exemple en les joignant à un Active Directory (ou à toute autre installation de Kerberos). En dehors de cela, vous devez stocker et transmettre ces informations d'une manière ou d'une autre.

Vous pouvez stocker la clé RSA dans le magasin de clés de l'utilisateur et l'extraire au moment de l'exécution (en utilisant les bibliothèques .NET Crypto/Keystore). Vous ne stockez donc pas la clé avec le code. De cette façon, la clé elle-même serait protégée par le système d'exploitation et disponible uniquement lorsque l'utilisateur appelant était authentifié. Vous auriez encore une chose à installer, mais c'est peut-être la seule façon de réaliser ce que vous visez.

+1

Ahh, c'est dommage. Après quelques discussions et recherches, nous allons utiliser la clé RSA. Cela finira par permettre plus dans le futur de toute façon. Merci, Taylor! – Beege

+0

Vous dites que si l'utilisateur fait partie de AD, vous pouvez obtenir un objet d'identification; Est-ce exact? J'essaye de faire ceci (le titre de la question), sur Windows. – ryanwebjackson

3

Étant donné que vous pouvez obtenir le mot de passe en texte brut à partir d'un objet d'identification, je doute que vous puissiez l'obtenir sans invite.

3

Pourquoi ne pas crypter le mot de passe à l'aide de la clé de cryptage du compte de service?

Un exemple rapide:

Exécuter PowerShell comme le compte de service, exécutez la commande suivante et enregistrez la sortie vers un fichier texte (ou l'intégrer dans l'appel de tâche planifiée):

$String = '<PASSWORD>' 
ConvertFrom-SecureString -SecureString (ConvertTo-SecureString -String $String -AsPlainText -Force) 

Utilisez le suivant dans votre tâche planifiée afin de décrypter et utiliser le mot de passe:

$EncryptedString = '<ENCRYPTED PASSWORD FROM ABOVE>' 
[Runtime.InteropServices.Marshal]::PtrToStringAuto([Runtime.InteropServices.Marshal]::SecureStringToBSTR((ConvertTo-SecureString -String $EncryptedString))) 

Cela devrait faire l'affaire. Vous ne pouvez pas réutiliser le mot de passe crypté sur un autre ordinateur, cependant, ou si pour une raison quelconque vous détruisez votre magasin de clés local :)

+0

La méthode secureString est réversible, donc le mot de passe n'est pas techniquement sécurisé. Sans l'option -force, vous obtiendrez: "ConvertTo-SecureString: Le système ne peut pas protéger la saisie de texte brut." – cmcginty

Questions connexes