Miałem dość specyficzny problem w pracy. Ja pracuję sobie na normalnym komputerze i do swojego klienta podłączam się przez VPN. Tam już zaś operuje na dwóch domenach i dwóch różnych swoich użytkownikach – podłączam się do TFS jednym, a innego używam do przeglądania intranetu. Tak naprawdę nie jestem w domenie. To tylko VPN. Co ostatnio zaczęło przeszkadzać mi w pracy, gdyż nowy nuget server został przerzucony na portal TFSowy. To znaczy, za każdym razem jak próbowałem się dam dostać musiałem podać użytkownika i hasło. Musiałem znaleźć rozwiązanie albo żyć z tym, że codziennie będzie wpisywał 10 razy swojego dane.
runas
nie działało, gdyż użytkownik domenowy nie ma dostępu do mojego kompa, to trochę zrozumiałe. Na szczęście runas
ma opcję /netonly
która umożliwia uruchomienie aplikacji z danymi uwierzytelniającymi które będą wykorzystywane jedynie do dostępu sieciowego. Czyli aplikacja działa w moim kontekście do póki nie musi się skontaktować zewnętrznym źródłem danych. Bardzo fajna opcja. Tak naprawdę dokładnie to co było mi potrzebne. Moja komenda przybrała więc taką postać:
runas /netonly /user:DOMAIN\gutkowskij "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe"
Po uruchomieniu której musiałem podać hasło
Enter the password for DOMAIN\gutkowskij: Attempting to start C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe as user "DOMAIN\gutkowskij" ...
Czyli to naprawiło jedynie problem przeniesienia miejsca odpytania o hasło – z VS do cmd. Więc nie to co mnie interesuje. Poszukałem szybko rozwiązania i jest takie narzędzie co się zwie PsExec które umożliwia podanie użytkownika i hasło w trakcie odpalenia procesu – jednak nie jest to /netonly.
Już miałem się poddać na szczęście sprawdziłem jedną rzecz o której bym nie pomyślał, że zadziała… serio. Wykorzystałem redirection oprator w cmd, który czyta zawartość pliku i wrzuca ją jako input oczekujący na wpisanie z klawiatury. To znaczy, każdy z nas zna w cmd przekierowanie wyniku działania do pliku:
echo "TEST" > plik_z_test.txt
Po otwarciu pliku dostaniemy następującą zawartość:
"TEST"
Przeciwieństwem tego operatora jest operator <
który właśnie czyta zawartość pliku i wrzuca jako “tekst” do pierwszego miejsca które oczekuje na wpisanie danych z klawiatury. Dla przykładu
Stwórzcie sobie plik z zawartością:
TEST 231 123 321
I następnie odpalcie:
> sort < plik_z_test.txt 123 231 321 TEST
Fajne? Super!
Wiedząc, że tak się da, stworzyłem sobie plik pwd.txt (plain text!!!! A co? Mogę? MOGĘ) i wykonałem polecenie:
runas /netonly /user:DOMAIN\gutkowskij "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe" < d:\pwd.txt
Boom, zadziałało. VS się odpalił, hasła nie musiałem podawać.
Opcja fajna i może być przydatna. Pamiętajcie jednak, że w ten sposób mamy hasło dostępne dla każdego kto się dostanie do naszego komputera. Nie jest to najlepsze rozwiązanie. Jak trzeba to można napisać mini apkę w .NET która tę sprawę nam załatwi. Jednak dla moich potrzeb opcja z przekierowaniem zawartością pliku jest wystarczająco dobra.
No chyba, że jest jakieś inne rozwiązanie? :)
No jasne, że jest wszystko możesz w PowerShell-u dziś zrobić :)
Start-Process -FilePath “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe” -Credential ( Get-Credential -UserName ‘DOMAIN\gutkowskij’ -Message ‘Put
password’)
A tak bez hasła:
Raz uruchom :
read-host -assecurestring | convertfrom-securestring | out-file C:\cred.txt
Nastepnie za akżdym razem ten skrypt wykonujesz:
$password = get-content C:\cred.txt | convertto-securestring
$credentials = new-object -typename System.Management.Automation.PSCredential -argumentlist ‘DOMAIN\gutkowskij’,$pass
Start-Process -FilePath “C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe” -Credential $credentials
Troche lepeij, ale przynajmiej hasła nie pdoajesz plain plaintextem .
no nie bardzo :) nie moge odpalic w kontekscie domeny i uzytkownika bo ten uzytkownik na ma zadnych praw u mnie na kompie. moj komputer nie jest w zadnej domenie.
bo tak to tez mialem inne opcje bez PowerShell
To faktycznie nie da się innaczej :)
Comments are closed.