2010-10-12 14 views
20

Mam skrypt Powershell, który będzie uruchamiany za pomocą narzędzia do automatyzacji na wielu serwerach. Działa dobrze na komputerach z systemem Windows, ponieważ połączenia zdalne korzystają z konta usługi tego narzędzia bez potrzeby monitowania lub ujawniania jakichkolwiek poświadczeń w kodzie. Ten skrypt działa również na komputerach z systemem Linux za pośrednictwem SSH przy użyciu pakietu SharpSSH. SharpSSH nie korzysta automatycznie z poświadczeń użytkownika Powershell, ale wymaga nazwy użytkownika i hasła, pliku kluczy RSA lub obiektu PSCredential. Nie mogę pytać o dane uwierzytelniające za pomocą Get-Credential, ponieważ jest on uruchamiany przez narzędzie do automatyzacji. Nie chcę ujawniać nazwy użytkownika i hasła w kodzie ani mieć klucza RSA. Chciałbym skonstruować obiekt PSCredential z bieżącego użytkownika Powershell (konto usługi). Próbuję [System.Net.CredentialCache] :: DefaultNetworkCredentials pokazuje puste, a [System.Security.Principal.WindowsIdentity] :: GetCurrent() nie dostarcza potrzebnego mi obiektu lub informacji.Uzyskiwanie bieżącego obiektu referencji użytkownika w Powershell bez pytania

Czy ktoś ma metodę tworzenia obiektu PSCredential od bieżącego użytkownika? A może zupełnie inna alternatywa dla tego problemu?

Wielkie dzięki!

Odpowiedz

14

Interfejs API systemu Windows nie udostępnia potrzebnych informacji, dlatego funkcja Powershell nie może uzyskać do nich dostępu. Jest to celowa funkcja podsystemu bezpieczeństwa. Jedynym sposobem, aby to zadziałało, jest to, że maszyny linuksowe ufają maszynie wywołującej, takiej jak dołączenie ich do Active Directory (lub jakakolwiek konfiguracja Kerberos naprawdę).

Poza tym, musisz jakoś przechowywać i przekazywać te informacje.

Można przechowywać klucz RSA w magazynie kluczy użytkownika i wyodrębnić go w czasie wykonywania (przy użyciu bibliotek .NET Crypto/Keystore), więc nie przechowujesz klucza za pomocą kodu. W ten sposób sam klucz będzie chroniony przez system operacyjny i będzie dostępny tylko wtedy, gdy użytkownik dzwoniący zostanie uwierzytelniony. Będziesz mieć jeszcze jedną rzecz do zainstalowania, ale może to być jedyny sposób na osiągnięcie tego, na co masz ochotę.

+1

Ahh, to niefortunne. Po kilku dyskusjach i badaniach pójdziemy za pomocą klucza RSA. W przyszłości będzie to w przyszłości zapewniało więcej. Dzięki, Taylor! – Beege

+0

Mówisz, że jeśli użytkownik jest częścią AD, możesz uzyskać obiekt poświadczeń; czy to jest poprawne? Próbuję to zrobić (tytuł pytania) w systemie Windows. – ryanwebjackson

3

Ponieważ można uzyskać hasło w postaci zwykłego tekstu z obiektu poświadczenia, wątpię, aby uzyskać to bez pytania.

3

Co powiesz na zaszyfrowanie hasła przy użyciu klucza szyfrowania konta usługi?

Szybki przykład:

Run PowerShell jako konto usługi, należy uruchomić następujące polecenie i zapisywać dane wyjściowe do pliku tekstowego (lub osadzić go w zaplanowanym wywołaniu zadania):

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

użyć następujące zadania w zaplanowanym w celu odszyfrowania i wykorzystać hasło:

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

To powinno załatwić sprawę. Nie można jednak ponownie użyć zaszyfrowanego hasła na innym komputerze lub z jakiegoś powodu zniszczyć lokalny magazyn kluczy :)

+0

Metoda secureString jest odwracalna, więc hasło nie jest technicznie bezpieczne. Bez opcji -force otrzymasz: "ConvertTo-SecureString: system nie może zabezpieczyć wprowadzania zwykłego tekstu." – cmcginty