The only thing I can think of that would require web app accounts to have common group based permissions is for DCOM. Usually when a feature (like publishing – grr) requires additional permissions to activate, I’ll temporarily grant the web app the rights it needs and then revoke it again.
But no doubt you guys will have tooled around with more assemblies/controls then me, so there is likely many other permission areas depending on how the component works. IMO, ‘best practice’ depends on your/your client’s security posture. Banks for example would absolutely require restricted logon rights, but they would want to be granular, so that allowing one account rights to something doesn’t automatically make it available to the others unless all web app accounts are to use the component. But in addition there is a lot of other stuff banks would do too. More importantly, just allowing 3rd party assemblies into the GAC (full trust) is a similar issue to me than interactive logon rights. If you think of the relative probability of passing a dodgy parameter to a custom assembly in the GAC, that is likely your avenue to achieving an interactive logon anyhow. Some security sensitive clients would insist all your custom stuff (where possible) is dropped into the bin folder of each web app and then the trustlevel set to the absolute minimum required. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Daniel Brown Sent: Saturday, 2 February 2008 10:19 AM To: listserver@ozMOSS.com Subject: [SPAM] [OzMOSS] IIS Application Pools Policy Hi all, With running multiple web applications under multiple identities, I’m curious as to what’s peoples polices about these accounts? Currently, I just stick them all in 1 security group so if anything which needs permission on the web server, i just assign the privileges to that group and not single users. As these are valid domain user accounts, I’m wondering if people restrict them down with group policy’s and such inside of AD (say, to prevent logon from console, etc) and if there is a best practice for this? Cheers, ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net No virus found in this incoming message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.18/1255 - Release Date: 1/02/2008 9:59 AM No virus found in this outgoing message. Checked by AVG Free Edition. Version: 7.5.516 / Virus Database: 269.19.18/1255 - Release Date: 1/02/2008 9:59 AM ------------------------------------------------------------------- OzMOSS.com - to unsubscribe from this list, send a message back to the list with 'unsubscribe' as the subject. Powered by mailenable.com - List managed by www.readify.net
