Dlouho, velmi dlouho, to v mém týmu fungovalo takto - z naších počítačů jsme se mohli přihlásit k vývojářskému databázovému serveru pomocí SQL autentizace. Na server určený pro testování jsme se ale mohli dostat jen přes odpovídající doménový účet. Což byl problém, neboť naše počítače v té dotyčné doméně nejsou a SQL Server Management Studio sice umožňuje přepnutí se na Windows autentizaci, ale použije při tom aktuální účet, tj. ten pod kterým jsem přihlášen ve Windows - a ten samozřejmě vyžadovanému doménovému neodpovídal.
U jiných programů to problém není, třeba Outlook nebo TFS umožňuje zadat jiný účet. Nicméně výše popsané skutečnosti nás ani moc netrápily, máme zřízeny virtuální stroje v dotyčné doméně a u nich přístup k databázovému serveru přes Windows Authentication pochopitelně fungoval. Nebylo to sice moc pohodlné, tyhle virtuálky jsou na druhém konci světa a tedy poměrně pomalé (pomalé na plnohodnotnou práci, neboť zpoždění při psaní je postřehnutelné) - ale pro naše potřeby to bylo řešení.
U jiných programů to problém není, třeba Outlook nebo TFS umožňuje zadat jiný účet. Nicméně výše popsané skutečnosti nás ani moc netrápily, máme zřízeny virtuální stroje v dotyčné doméně a u nich přístup k databázovému serveru přes Windows Authentication pochopitelně fungoval. Nebylo to sice moc pohodlné, tyhle virtuálky jsou na druhém konci světa a tedy poměrně pomalé (pomalé na plnohodnotnou práci, neboť zpoždění při psaní je postřehnutelné) - ale pro naše potřeby to bylo řešení.
Jenže v poslední dobou jsme museli začít něco řešit s jinou databází na našem vývojářském serveru a ukázalo se, že SQL účet nemá dostatečná práva a nějaké objekty (tabulky či procedury) v této databázi nevidí, natož aby je dokázal spustit či vybrat nějaká data.
Krátká komunikace s odpovědnou osobou k řešení nevedla, tedy vlastně vedla - odkázala nás (zcela pochopitelně) na nutnost použití našeho doménového učtu - což by tedy mělo znamenat nutnost používat virtuálky se všemi jejími nevýhodami. Tato představa byla dostatečně silným impulzem k hledání řešení a to nakonec našlo. Stačí příslušný program, tedy MS SQL Server Management studio, spustit tímto příkazem z příkazové řádky:
runas /netonly /user:<doména>\<název účtu> "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
Po spuštění se objeví výzva k zadání hesla a pak se již spustí samotný program. V něm je sice při přepnutí na Windows autentizaci pořád zobrazen lokální účet, ale pod pokličkou se použije ten doménový. A najednou jsou přístupné nejen všechny chybějící objekty ve vývojářské databázi, ale i ostatní servery, ke kterým jsme se dříve museli připojovat jen ve virtuálkách.
Aby to bylo ještě více pohodlné, udělal jsem si zástupce, s názvem SQL Management Studio NETWORK a jako Target jsem zadal:
C:\Windows\System32\runas.exe /netonly /user:ser:<doména>\<název účtu> "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe"
Aby se zástupce co nejvíce blížil originálu, po kliknutí na tlačítko Change Icon jsem použil odpovídající ikonku ze souboru %ProgramFiles% (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\Ssms.exe
Po kliknutí na zástupce se objeví výzva k zadání hesla:
a poté se již spustí samotný program. Jak jsem již napsal, tváří se po přepnutí na Windows authentication, že používá místní účet, ale ve skutečnosti je použit účet specifikovaný při přihlášení. Přístup k místnímu databázovému serveru není nijak dotčen.
Zábavné je, že s výše popsaným omezením jsme jako tým žili několik let a nikoho nenapadlo, že by to šlo jinak. Vlastně jsme se asi všichni smířili s tím, že to nejde a tak proč hledat řešení - když to nejde......Tenhle postoj přijali i nově příchozí a teprve vyhlídka nutnosti pracovat i s vývojářským serverem přes virtuálku byla tím správným impulzem pro nalezení řešení - které je při tom tak triviální, až se za tenhle příspěvek a přiznání v něm trochu stydím.
Nebo nad ssms.exe přidržet Shift + pravé tlačítko myši a v context menu přibyla položka "Spustit jako jiný uživatel". Stačí v dialogu doplnil login a heslo a spuštěný proces běží pod jiným doménovým účtem. Takto to řešívám já při potřebě dostat se doménově do nějaké db pro různé účty :)
OdpovědětVymazatTenhle přístup nám nefunguje, pod pokličkou se asi děje něco trochu jiného.
OdpovědětVymazathttp://stackoverflow.com/questions/15607315/difference-between-runas-exe-and-start-process-credential
popřípadě
http://codebetter.com/jameskovacs/2009/10/12/tip-how-to-run-programs-as-a-domain-user-from-a-non-domain-computer/