J'ai un script Powershell qui va être exécuté via un outil d'automatisation sur plusieurs serveurs. Cela fonctionne très bien sur les machines Windows, car les appels distants utilisent le compte de service de l'outil sans avoir besoin de demander ou d'exposer des informations d'identification dans le code. Ce script s'exécute également sur les machines Linux via SSH à l'aide du package SharpSSH. SharpSSH n'utilise pas automatiquement les informations d'identification de l'utilisateur Powershell mais nécessite soit un nom d'utilisateur et un mot de passe, un fichier de clé RSA ou un objet PSCredential. Je ne peux pas demander les 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 le mot de passe dans le code ou avoir une clé RSA assise 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 blanc et [System.Security.Principal.WindowsIdentity] :: GetCurrent () ne fournit pas l'objet ou les informations dont j'ai besoin.
Quelqu'un a-t-il 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!
L'API Windows n'exposera pas les informations dont vous avez besoin, c'est 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 à n'importe quelle configuration Kerberos vraiment).
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 (à l'aide des bibliothèques .NET Crypto/Keystore), de sorte que vous ne stockez 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 serait authentifié. Vous auriez encore une chose à installer, mais c'est peut-être le seul moyen d'atteindre ce que vous visez.
Que diriez-vous de chiffrer le mot de passe à l'aide de la clé de chiffrement du compte de service?
Un exemple rapide:
Exécutez PowerShell en tant que compte de service, exécutez ce qui suit et enregistrez la sortie dans un fichier texte (ou incorporez-la dans l'appel de tâche planifié):
$String = '<PASSWORD>'
ConvertFrom-SecureString -SecureString (ConvertTo-SecureString -String $String -AsPlainText -Force)
Utilisez les éléments suivants dans votre tâche planifiée afin de déchiffrer et d'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, ou si pour une raison quelconque, vous détruisez votre magasin de clés local :)
Étant donné que vous pouvez obtenir le mot de passe en texte brut à partir d'un objet d'informations d'identification, je doute que vous puissiez l'obtenir sans invite.