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? :)

 

3 KOMENTARZE

  1. 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 .

ZOSTAW KOMENTARZ

Please enter your comment!
Please enter your name here