is dit best practise voor IIS en shares?

[_H_G_]

Ik heb:
- een 2003 server met een share (ook DC als dit van belang is)
- een sbs2003 r2 server met asp.net applicaties die bestanden wijzigen in die share

Na vervanging van de 2003 server werkt dit onderdeel niet meer, en al gevonden waar het aan ligt: op de oude server stond die share open met schrijfrechten voor iedereen, wat nu ook een optie zou kunnen zijn (zodat de user Network Service van de IIS server er kan wijzigen).

Daarna wat gelezen en zie dat sommige het oplossen door een ad gebruiker te maken:
- de identity van de application pool te veranderen in deze gebruiker (IIS instellingen, betreffende pool opsporen, tabbblad identity)
- in de domain controller security policy, deze gebruiker toevoegen bij computer configuration->windows->security settings->local policies->user rights assignments->Log on as a service
- en vast nog wel wat zaken zoals 'wachtwoord niet te wijzigen'

Op zich klinkt het goed, al ben ik zelf niet zo kapot van extra "service accounts" aanmaken. Daar dit niet echt een unieke situatie is, vind ik het wat vreemd dat er geen standaard account voor is. Ik kan ook niks vinden wat Microsoft er van vindt, al is het lastig zoeken. Op MS sites kom je al snel terecht op reference material over hoe web.config in te stellen, maar niet dat je het beste een domeingebruiker kan aanmaken.

[Question Mark]

_H_G_ schreef op maandag 10 november 2008 @ 09:26:
Op zich klinkt het goed, al ben ik zelf niet zo kapot van extra "service accounts" aanmaken.

Wat staat je precies tegen dan?

Je maakt gewoon een service-account, met een wachtwoord als bijvoorbeeld: "$ASDFJQ$ROuudh%^##afiu73r87t6". Zet het account op never-expires en documenteer de gegevens. Je bent dan in staat om dit account (en dus de app die dit account gebruikt) heel precies de benodigde rechten te geven. (en niet meer dan nodig).

Een alternatief is er niet. Een "standaard" account moet (gezien het feit dat vooraf niet duidelijk is waar deze rechten tot moet hebben) al gauw Admin rechten hebben, terwijl dat vaak niet nodig is. Vanuit security oogpunt niet echt aan te raden.

[_H_G_]

Question Mark schreef op maandag 10 november 2008 @ 09:34:
[...]
Wat staat je precies tegen dan?

Niet echt een hele goeie reden voor. Het stikt al van de service accounts en gebruikers (ben blij als ik van 75% weet waar het voor bedoeld is. 'Leuk' dat het in dit geval ook de extra server nederlands is). En de nodige reboots, als gevolg van de dc security policy, is ook niet zo'n pretje.

[Question Mark]

_H_G_ schreef op maandag 10 november 2008 @ 09:50:
[...]Het stikt al van de service accounts en gebruikers (ben blij als ik van 75% weet waar het voor bedoeld is.

Daarom meld ik ook dat de gegevens gedocumenteerd moeten worden

[ Voor 6% gewijzigd door Question Mark op 10-11-2008 10:06 ]

[Verwijderd]

De asp.net app gebruikt niet de credentials van een ingelogde gebruiker om wijzigingen te maken (impersonate)? Anders heeft het weinig zin om een ander account te gebruiken voor de app pool.

op de share kan je even object access aanzetten en even proberen met welke accounts er gewijzigd wordt. ik zou het niet geheel onlogisch vinden als dat gewoon domain users zijn en domain users change rechten te moeten geven om het werkend te krijgen.

[_H_G_]

Nope, impersonate staat uit en heb al gecontroleerd dat het Network Service (de ingestelde identity) is, die toegang probeert te krijgen. Sorry, vergeten erbij te vermelden (impersonate aan was geen optie daar gebruikers het proces wel mogen starten, maar niet handmatig in de share mogen wijzigen).

Andere identity geeft ook gewenste resultaat, al heeft de zelfgemaakte gebruiker nog geen rechten om een service te draaien (moet reboots nog doen). Daarna zal het wel werken.

(tenminste, wel van plan om alle beide dcs een schop te geven. dc policy wijzigen en dan niet alle dcs te rebooten lijkt me ook niet echt best practise).