[2003] Login als 'de' Administrator zonder password

[DarthPlastic]

De titel klinkt enigszins vreemd, maar dit is het probleem:

Op een server zijn meerdere accounts met adminrechten aanwezig, zowel 'de' Administrator, als enkele losse beheeraccounts.
Het probleem is dat er soms dingen moeten plaatsvinden die niet zomaar adminrechten veriesen, maar ook persé het echte Administrator-password vereisen (bijvoorbeeld services en geplande taken)
Nu is er tot nu toe altijd beheer uitgevoerd met de losse accounts, en is er waar nodig het echte Administrator-password ingevoerd (wat dus verder niet bekend dient te zijn).

Nu is het eigenlijk handig om hier een systeem voor te bedenken zodat beheerders met een eigen account zaken kunnen invoeren waar normaal het echte password voor benodigd is, zonder dat zij dit daadwerkelijk weten.

Toen ik hierover nadacht zou het bijv. mogelijk zijn het password tijdelijk te resetten naar iets simpels, en na een tijdje weer terug te veranderen, maar het probleem is dat je bij bv. services en geplande taken het juiste password moet invullen (wat NIET meeverandert met het Windows-wachtwoord), wat dus persé het 'echte' wachtwoord moet zijn.

Heeft iemand suggesties of ideeën hoe dit bereikt kan worden?

[alt-92]

DarthPlastic schreef op woensdag 03 september 2008 @ 13:16:

Het probleem is dat er soms dingen moeten plaatsvinden die niet zomaar adminrechten veriesen, maar ook persé het echte Administrator-password vereisen (bijvoorbeeld services en geplande taken)

Dáár zit je probleem.

Los dat op en je hoeft het Administrator password niet te gebruiken.
Hint:
Service-accounts.

[DarthPlastic]

Dan houd je nog steeds het probleem eigenlijk, want service-accounts moeten ook een password hebben, en beheerders moeten alleen hun eigen wachtwoord kunnen gebruiken om alles te beheren.
Het is ook niet handig om een geplande taak onder een eigen account van een beheerder aan te maken, want dan loop je het risico dat de taak niet meer werkt zodra je een account disabled oid.

[sanfranjake]

Maar een service-account kan je wel gewoon beperkte rechten geven (zelden dat iets (local)admin moet zijn). Daarmee kan je die risico's prima beperken lijkt me

[alt-92]

DarthPlastic schreef op woensdag 03 september 2008 @ 14:03:

Het is ook niet handig om een geplande taak onder een eigen account van een beheerder aan te maken, want dan loop je het risico dat de taak niet meer werkt zodra je een account disabled oid.

En waarin verschilt dat van het gebruik van de Administrator account?

[Mike2k]

Service accounts is toch wel een best practice inderdaad. Meestal geef je deze ook alleen Domain User rechten wat betekent dat dingen als remote desktop gedisabled zijn.

Lees ook:
http://www.windowsecurity...ces-Service-Accounts.html

@DarthPlastic...
Beheerders moeten een apart account hebben wat hen toegaan geeft op de voor hun belangrijke servers met de benodigde rechten (User, Power User, Administrator).
Dat staat echter los van service accounts. Service accounts zijn accounts met wachtwoorden die niet verlopen (anders kapt je service er ineens mee) die niet mogen inloggen op een server en die de laagst mogelijke rechten hebben....

[ Voor 43% gewijzigd door Mike2k op 03-09-2008 14:17 ]

[DarthPlastic]

alt-92 schreef op woensdag 03 september 2008 @ 14:12:
[...]

En waarin verschilt dat van het gebruik van de Administrator account?

De Administrator wordt niet gedisabled uiteraard, en bij sommige servers waar verouderde applicaties op draaien (die wel moeten blijven werken) wordt de lokale Administrator-desktop gebruikt om deze te draaien. Hier moeten beheerders dus bij kunnen, zonder het wachtwoord te hoeven kennen.

[Mike2k]

Applicaties die een actieve console sessie nodig hebben om hun werk te doen moet je echt op straat gooien....motto: voor alles is een alternatief....

[DarthPlastic]

Fastex schreef op woensdag 03 september 2008 @ 14:18:
Applicaties die een actieve console sessie nodig hebben om hun werk te doen moet je echt op straat gooien....motto: voor alles is een alternatief....

True... maar als klanten een dergelijke applicatie echt nodig hebben (bijv. ooit custom laten schrijven, en nooit verbeterd sindsdien) is het wel nodig.

Wat ik overigens nog niet genoemd heb, is dat hetzelfde probleem voorkomt bij bureaubladen van users, tot nu toe wordt er elke keer een password reset uitgevoerd om bepaalde fouten te kunnen testen onder een bepaalde useraccount, het zou handig zijn als hier ook een oplossing voor komt zodat beheerders (zonder het userpassword te moeten vragen) netjes kunnen inloggen onder een useraccount.

[Mike2k]

het zou handig zijn als hier ook een oplossing voor komt zodat beheerders (zonder het userpassword te moeten vragen) netjes kunnen inloggen onder een useraccount.

Wij zijn hier om te helpen, niet om op te lossen

Ook die applicatie die een actieve console nodig heeft kan je onder een service account plaatsen...Die moet dan alleen wel lokaal de juiste rechten hebben...

[DarthPlastic]

Uiteraard, ik ben diegene die het probleem op gaat lossen, ik vraag echter alleen advies

Het lastige is dus dat je als beheerder $random gebruikers moet kunnen 'overnemen', zonder het password persé nodig te hebben.

edit: Dit is een soortgelijke situatie:
http://groups.google.com/...d/thread/74c909eab2d78dae
Wat ik me dus afvraag is of dit mogelijk is, maar dan niet via runas.exe, maar via het complete useraccount.

[ Voor 36% gewijzigd door DarthPlastic op 03-09-2008 14:53 ]

[_H_G_]

Snap dat het handig zou zijn, maar het recht wat jij wil (login als een andere gebruiker zonder wachtwoord te geven) bestaat gewoon niet. Misschien in 2008 of in unix. Maar ook daar lijkt het me sterk.

Een gebruiker zou dan kunnen zeggen: "maar dat heb ik niet gedaan! die maffe beheerders hebben zeker weer onder mijn naam ingelogd". En zo zijn er nog wel wat gevolgen te bedenken die je uberhaupt niet wil.

Edit: schijnbaar heeft unix het dus wel, als je link waar is. Vraag me af wat daar het nut van is. Taken die je beschrijft zijn zeker niet voor de 'root'.

[ Voor 16% gewijzigd door _H_G_ op 03-09-2008 14:58 ]

[Mike2k]

In windows-beheerdersland gebruiken we daar meestal tst (test) accounts voor die dezelfde rechten hebben als een gebruiker.....

Zo heb je dus:
svc (service account)
adm (admin account)
tst (test account)

Om maar een naamgeving te noemen....

[ Voor 32% gewijzigd door Mike2k op 03-09-2008 15:04 ]

[alt-92]

DarthPlastic schreef op woensdag 03 september 2008 @ 14:44:

edit: Dit is een soortgelijke situatie:
http://groups.google.com/...d/thread/74c909eab2d78dae
Wat ik me dus afvraag is of dit mogelijk is, maar dan niet via runas.exe, maar via het complete useraccount.

Mwah.. Vind je het erg als ik daar totaal het nut niet van inzie?

Account impersonation zonder authenticatie (om het dan maar even zo te noemen) is binnen een grotere bedrijfsomgeving vragen om dikke shit omdat het namelijk ervoor zorgt dat je gaten schiet in je scheiding van permissies.
Daar gaat je SOX/Compliance de deur uit.


Of je moet weer terug willen naar het Win9x tijdperk dat iedereen in potentie alles mocht en kon?

[ Voor 8% gewijzigd door alt-92 op 03-09-2008 15:29 ]

[Mike2k]

@alt-92: Like I always say: If it doesn't work, just give everyone full control