Userbase

Hoi,

Ik vind hier precies geen best practices voor, maar ik zou graag het volgende voor mekaar krijgen:
Ik heb een server (Windows Server 2008 R2 en/of 2012) met Powershell 2.0 en/of 3.0.
Op die server hebben bepaalde "half-admins" wel RDP-rechten en bepaalde delegated rechten, maar ze zijn GEEN local administrator. Zij kunnen dus géén "run as administrator" doen.
Nu zijn er bepaalde acties die zij zouden moeten kunnen doen niet mogelijk omdat je daarvoor local admin moet zijn.
Een voorbeeld: een IIS application pool recyclen, dat ziet er zo uit: Is er een manier waarmee je dit als non-admin tóch kan uitvoeren?
Ik was aan het denken aan via new-pssession, maar je kan daar geen elevated rights in krijgen als je bron-proces dat ook niet al is. Bovendien wil ik vermijden dat deze half-admins het proces kunnen onderbreken en dus in een elvated prompt terechtkomen.

Heeft er iemand ervaring met een dergelijke setup? Of slimme bedenkingen?

Ik was aan't denken dat je iets met een nieuwe security.principal zou kunnen doen die wél de nodige rechten heeft. Maar je probleem blijft dan: hoe ga je vermijden dat deze creds "misbruikt" worden om andere elevated commands te runnen.

Jij wil eigenlijk bepaalde commando's vrijgeven voor niet-admins en niet niet-admins tijdelijk elevaten, want dat zal altijd een security issue blijven. Maar hoe je bepaalde commando's vrijgeeft voor niet admins heb ik geen idee van. Ben wel eens benieuwd of iemand dit weet (en of het überhaupt kan)

Probleem ook met credentials opslaan in een tekstfile... dat die gebruiker daar leesrechten op moet hebben en dus onderhevig is aan een replay-attack (bij wijze van spreken).

AppSense kan elevated rechten geven aan non admin accounts...?

Booh AppSense
Laat m'n issue nu net bestaan bij 2 klanten die geen AppSense geïmplementeerd hebben.

Ik was aan het denken om richting task scheduler te gaan?
Die kan je acties laten doen onder andere credentials op basis van een trigger; dus als ik iets kon triggeren om zo achterliggende commando's uit te voeren...

Je kan dacht ik ook een framework maken waarin je laat bepaalde scripts signen, die dan commands kunnen uitvoeren..

ps. domme klanten

Kun je bij een shortcut naar dit script geen runas met een andere usernaam meegeven met saved credientials?

Ik neem aan dat het probleem met credentials hetzelfde is als ik voorhad met de oudere batch commandos.
Namelijk dat je wel een runas kan doen, maar dat je de paswoorden meegeeft in een bat of cmd file, en dat die leesbaar is.
Bat2com in dat geval hielp niet, want het ging om het elevaten om een nieuwe prompt te openen met elevated rights en daar een script in te runnen, maar ik heb dat nooit aan het werk gekregen.
Het is altijd miserie als je rechten wil delegeren die je niet zomaar kan delegeren. Ik heb dat ook voorgehad bij het willen toekennen van aflogrechten (om andere users af te loggen als ze hun account gelocked hadden) aan niet-admins, maar dat is ook nooit goedgekomen.
Als je een manier moest vinden wil ik het wel weten, want de mogelijkheden naar scripts toe zijn wel legio.

[ Post made via mobile device ]

Ha! I've done it!
't is wel ugly
Je hebt 2 of 3 files nodig:
1) script 1 dat een non-privileged user zal runnen
2) script 2 dat privileged user zal runnen
3) file om parameters door te geven

script 2: Dit script schedule via de task scheduler en laat je runnen onder een privileged account (service account).
Pas de permissies op deze task aan zodat ook gewone users deze kunnen executen.

script 1 is dan iets à la: Niet vergeten schrijfrechten op de folder of file tmp_recycle.txt te geven en tadaa: ik kan onder m'n non-privileged account "./script1.ps1 Testsite" doen.
Nadelen: bijzonder onderhoud-onvriendelijk en best ingewikkeld; en je kan geen enkele vorm van feedback teruggeven (tenzij je dat in je script 2 verwerkt natuurlijk).

johan.devos schreef:Kun je bij een shortcut naar dit script geen runas met een andere usernaam meegeven met saved credientials?

Dat zou waarschijnlijk een oplossing kunnen zijn, maar om die credentials te saven moet je wel onder dat account eens ingelogd zijn geweest. 't Is dus niet erg overdraagbaar...