"Kör som" via genväg

Vissa program måste köras med högre previlegier än vad den inloggade användaren har tillgång till och då är det lite omständigt ibland.
Man kan ju välja avancerat på genvägen och tala om att programmet ska "köras som" men man måste alltid välja vem samt lösenord.
Finns det inget sätt att fixa detta automatiskt via genvägen genom att lägga till lite extra parametrar?
Exempelvis "c:\Program\programmet.exe" -u username:password ellr något.

Det här borde fungera, har dock inte testat själv;

runas /profile /env /user:dindomän\admin "C:\program\programmet.exe"

Lösenord måste dock anges om programmet frågar efter det.

För mer utförlig info, skriv; "runas /?" i kommandotolken.

Och så får man gärna ge lite feedback :l

Har desvärre inte haft tid att testa runas.exe men efter en snabbkoll så verkar det dock vara samma program som "Run As" som är det som används när man högerklickar på en genväg eller programfil.
Skillnaden ligger i att man promptas för lösenordet i ett dos-fönster istället för en dialogruta.

Programmet i sig kräver ingen inloggning (som är ett spel) men använder antagligen registret för att spara eventuella inställningar o.s.v. Det gör att man inte kan köra spelet som normal användare utan måste köras med administratörsrättigheter.
De flesta spel kan köras normalt så jag tyckte inte det fanns anledning att sätta en 6-åring som administratör. För att jag ska slippa starta spelet varje gång, så vore det alltså praktiskt om man på något sätt kunde automatisera detta genom att ange diverse växlar men det verkar som att man alltid får upp frågan om lösenord.

Har svårt att tänka mig att man kan ange lösenord i genvägen, det vore en säkerhetsrisk!

Har inte fördjupat mig så mycket i MS säkerhetssystem, men om dom har gjort så att man kan ange admin-lösenordet i en genäg för en normal användare så är det inte mycket till säkerhet!

En vanlig användare kan ju i princip redan göra detta, bara det att man anger lösenordet i dialogrutan istället. Det var mest det momentet som jag tänkte man kunde passera förbi genom att använda växlar i runas-programmet.

Men det är nog som du säger, det ska nog inte få finnas i klartext i en genväg.

Ett sätt att lösa problemet är att skapa ett enkelt program som startar det andra programmet.

Jovisst, allt är möjligt :)
Tänkte mest om det kanske redan fanns ett tillgängligt alternativ.

Det råkar inte vara som så att programmet försöker skriva i eller skapa en fil i systemkatalogen? Jag minns att det kan bli problem för vanliga användare att tex skapa ett organisationsschema i PowerPoint men efter att ha ställt om rättigheterna på de två filer som hör till som ligger i systemkatalogen så funkar det fint.

Du skulle behöva ett program typ sudo, fast för windows. :)

Har inte hittat något sådant program när jag letat runt (har också saknat den funktionaliteten). Så det alternativ du har kvar är att ta reda på (genom att göra en "audit" t.ex.) vilken registernyckel och/eller fil som användaren behöver skrivrättigheter och ändra rättigheterna på objektet så att det fungerar.

Tänkte mest om det kanske redan fanns ett tillgängligt alternativ.

Är det något fel på mitt alternativ? Det tar inte många minuter att skriva ett sånt program.

På "Resource Kit"-skivan finns su.exe som kanke kan hjälpa.

Det tar inte många minuter att skriva ett sånt program.

Beror väl på vilka programmeringskunskaper man har, misstänker jag? Och vilka verktyg (kanske inte vill köpa Visual Studio, VB eller vad som nu kan behövas, för ett enda program). :)

Personligen skulle jag t.ex. inte ha en aning om hur man skriver en wrapper för Windows, som kör ett program under en annan användare än den som startar programmet. Speciellt inte hur man gör det säkert.

Skulle gärna vilja klocka dig på den uppgiften Swey...

Du får gärna tala om hur det skulle gå till...

Eftersom rättigheterna på programmet som startar det andra programmet måste vara minst de samma, så är man ju tillbaka där man började.

Eftersom Windows använder en resursbaserad säkerhetsmodell (till skillnad från *Nix filbaserade), så är det inte helt enkelt.

/T

Om det duger att lagra lösenordet i programmet räcker det med en enda funktion för att lösa uppgiften. Det ger ingen bra säkerhet, men tillräcklig.

Använder man inte Windows 2000/XP så blir det lite mer kod.

I Windows NT 4.0 loggar man in med LogonWindows och startar processen med CreateProcessAsUser. I Windows 2000/XP gör man både och med CreateProcessWithLogonW. Endast processen och underprocesser till den som startas körs under administratörens konto.

Namn och lösenord måste givetvis anges.

#define UNICODE
#define _UNICODE
#define _WIN32_WINNT 0x500
#include <windows.h>
#include <tchar.h>

TCHAR *user = TEXT("Administrator");
TCHAR *password = TEXT("lösenord");
TCHAR *domain = TEXT(".");

int APIENTRY _tWinMain(HINSTANCE hInstance,
                     HINSTANCE hPrevInstance,
                     LPTSTR    lpCmdLine,
                     int       nCmdShow)

{
	STARTUPINFO si;
	ZeroMemory(&si, sizeof si);

	PROCESS_INFORMATION pi;
	//if(CreateProcess(0, lpCmdLine, 0, 0, 0, 0, 0, 0, &si, &pi))
	if(CreateProcessWithLogonW(user, domain, password, 0,
		0, lpCmdLine, 0, 0, 0, &si, &pi))
	{
		CloseHandle(pi.hThread);
		CloseHandle(pi.hProcess);
	}
	//else
	//	Rapportera fel

}

Används: runas.exe <program> <argument>

[r] Eftersom det går att välja vilket program man vill starta är detta väldigt osäkert egentligen. Jag vet dock inte hur man ska göra det säkert.

Programmet i sig kräver ingen inloggning (som är ett spel) men använder antagligen registret för att spara eventuella inställningar o.s.v. Det gör att man inte kan köra spelet som normal användare utan måste köras med administratörsrättigheter

Ta reda på var i registret den skriver och ändra säkerhetsinställningarna där med hjälp av regedt32.
Förmodligen finns nyckeln redan och ligger med stor sannolikhet i någon annan hive än HKEY_USERS - där den borde ligga.

Tycker det börjar bli lite avancerat nu och inte lika lätt som jag först trodde :)
Eftersom funktionen "Kör som" redan existerade så trodde jag att det fanns ett sätt att skicka med inloggningen och har därför inte kollat vilka filer, eller registernycklar som avses. Jag installerade spelet som normal användare först men precis när installationen skulle slutföras, så dök det upp något meddelande om behörighet. Installerade därför som administratör och trodde problemet skulle vara ur världen.

emission, vad kan man göra med su.exe? Antar att man byter användare men kan man göra det automatiskt med några förinställda värden?

Eftersom jag inte beräknade att det skulle vara så omständigt så har jag heller inte kollat vad det är för filer eller nycklar som berörs. Gör nog en nyinstallation så jag kan analyser det hela lite bättre.

Kan rekommendera två gratisverktyg från Sysinternals, Filemon och Regmon.

http://www.sysinternals.com/ntw2k/utilities.shtml

Logga in som vanlig användare, kör igång dessa två program som Administrator, försök starta spelet och leta sedan efter skrivningar som du inte fick "SUCCESS" på.

Faktiskt ganska smidigt att hitta sådana här problem med dessa verktyg. :)

Wow, smutt!
Tack för tipset Robban!

Det ska jag testa när jag kommer hem :D