ja to vyresil tak, ze jsem si vytvoril Naplanovanou ulohu s pravy Administratora (pod uctem Admina) a tuto Naplanovanou ulohu jsem spoustel v davce pomoci prikazu:
C:\Windows\System32\runas.exe /noprofile /savecred /user:uzivatelXY "C:\Windows\System32\schtasks.exe /run /tn RouteADD"
Zadani hesla je pouze pri prvnim spusteni, vystraha od UAC (nebo jak se to jmenuje) se neobjevuje.
Ahoj. Tohle řešení se celkem často uvádí, ale je zde několik ALE. Trochu to celé rezeberu... Ale ne úplně, možností (a jejich vzájemných kombinací) je vícero a na delší debatu.
1. RunAs a Credentials
- Pověření se automaticky uloží (nebo neuloží ale zůstane jen do odhlášení) po spuštění úlohy s požadovanými právy.
- Pověření lze zadat i ručně pomocí "CMDKey", nebo vytvořit přímo správcem pověření (Credentials Manager - Správce hesel v nastavení uživatelského profilu.
- Jednoduchý ekvivalent pro PowerShell zatím neznám (s PowerShellem jsem teprve teď začal zlehka koketovat), se složitým (pro mne) zápasím. Pravděpodobně existují oba (viz. get-help credentials nebo runas).
- Je pravda, že pověření se udělí všem příkazům RunAs (spuštěné uživatelem, kterému byla práva již jednou udělena). Naštěstí na většině systémů Windows nejde o trvale uložené pověření, ale jen dočasné pověření s platností do okamžiku odhlášení uživatele. Přesto po testech doporučuji zkontrolovat záznamy v Credentials Manageru jak "správce" tak "uživatele" a pro jistotu i jejich složky "Credentials".
2. Použití plánovače (TaskSchd)
- Pokud vytvoříte úlohu (ať již pomocí uživateského rozhraní TaskSched, nebo příkazového řádku SchTasks) jako "správce" (vlastník úlohy), nebude ji moci "uživatel" spustit pomocí SchTasks (například pomocí zástupce, či BAT/CMD/VBS...), pokud mu opět nedáte pověření - tedy opět buďto pomocí RunAs, umožní-li to vůbec daná verze Windows, nebo například pro zástupce/LNK. S variantou zástupce by problém v bezpečnosti snad být neměl (nemám to ale kvůli stále aktivnímu UACu odzkoušené), ale podmínkou je že bude deaktivovaný UAC, jinak to nebude proveditelné ani pro účet správce (pro ostatní účty zástupce ani běh aplikace nedokáže zajistit, u WindowsXP to myslím ještě šlo).
- Aby bylo možné úlohu spustit ručně, musí to být úloze povoleno.
- To že se při spuštění aplikace nezobrazí UAC je jen důsledek toho že jste při tvorbě úlohy zadal volbu "Spustit s nejvyšší oprávněním", což způsobí že úloha bude spuštěna s tokenem zvýšeného oprávnění (bez UAC) a ne jen s tokenem nutného oprávnění (UAC). Dávkové úlohy a shell (příkazový řádek) v tomto režimu pracují standardně.
- "Uživatel" nemůže vytvořit úlohu (svoji vlastní úlohu, je jedno pod jakým uživatelským účtem bude spouštěna), která poběží s tokenem zvýšeného oprávnění. Úloha musí být spuštěna pod uživatelským účtem, nemůže být spuštěna pod účtem systému nebo služeb (LOCALSERVICE, NETWORKSERVICE). Příkazový řádek sice tuto možnost připouští, ale vždy jsem skončil na tom, že pověření uživatele nejsou v místním počítači povolena.
- "Uživatel" však může vytvořit úlohu, která nebude spouštěna s nejvyšším oprávněním a která bude spuštěna s právy správce, nebo jakéhokoli jiného požadovaného uživatele. Patřičné pověření bude uloženo v uživatelově správci pověření. Bohužel, poběží taková úloha jen v profilu/kontextu uživatele "jako který byla spuštěna", takže pod účtem z kterého byla úloha skutečně spuštěna (díky uloženým pověřením) bude vnímána spíše jako služba/aplikace běžící na pozadí, ke které právě přihlášený uživatel nemá přístup.
3.Součástí Sysinternals Suite/Tool je aplikace ShellRunas, která si zachovává funkcionalitu RunAs z WindowsXP/Server 2003. To znamená že lze příkaz zadat jak s uvedením uživatele, tak jeho hesla. Od Windows Vista již heslo nemůže být zadáno přímo/dopředu, ale systém/program se na něj vždy zeptá. Za jistých okolností to může být použitelné, třeba ve spojení s překladačem BAT -> EXE. Ale je to jen taková nouzová berlička. V zásadě tu stejnou práci odvede jakýkoli VBScript, například:
set WshShell = WScript.CreateObject("WScript.Shell")
WshShell.run "runas /user:nejaky_uzivatel notepad.exe"
WScript.Sleep 1000
WshShell.SendKeys "heslo_nejakeho_uzivatele"
WshShell.SendKeys "{ENTER}"
set WshShell = Nothing
Skript lze nechat i enkódovat. Ve spojení s ShellRunas (Sysinternals) by vznikla náhrada za BAT2EXE.
Vše jsou to ale pouhé berličky a v zásadě nepoužitelné blbosti...
Práce se zpětnou analýzou by se také dala ztížit například rozkopírováním standardního systémového RunAs (což je EXE soubor) pod jedinečnými názvy, s využítím funkce ukládání pověření (umožňuje-li to daný systém) a okamžitém mazání úlohy po dokončení.
Pokud by byl v systému vypnutý UAC a úloha by měla běžet se právy správce, za situace kdy nebude použit vše komplikující
RunAs, je po problému, protože si můžete uložit pověření k jakémukoli zástupci, naplánované úloze,...
4. Dál to zatím rezebírat nechci. Jen vás vyzívám abyste ověřil že právě váš systém (účet uživatele) si neuložil pověření použitelné pro jakýkoli příkaz "RunAs /savecred". Pokud jste tedy nepoužil fígl, že v účtu uživatele je uloženo pověření ke spuštění naplánované úlohy jako jiný uživatel (třeba s právy správce) a teprve v pověřeních tohoto uživatele existuje pověření pro RunAs (netestováno!)
Ještě zmíním řešení, které ale nemám vyzkoušené, právě ho studuji. Je jím nasazení/aktivace Správce Autorizací (Authorization Manager). Můžete ho vyvolat příkazem AZMan.msc (nebo spustit přes konzoli MMC), ale dále vás zatím musím odkázat na nápovědu a web Microsoftu.
Pochopitelně, vždy je možnost spolehnout se na šifrování hesel v aplikacích třetích stran, nebo například na gallerii Technetu, kde je pár více či méně předpřipravených skriptů pro PowerShell (ten bude muset být pro běh skriptu, tedy ne jen jednoduchého příkazu, v systému povolen) které by měli přímo používat správu pověření v systému Windows.
29 Odpovědí
44161 Zhlédnutí