Setting Up Win2008 R2 Server - IIS_IUSRS Permissions

Question

So Magic Fields 2 doesn't have "write panels." and since MF2 is so sleek - I am thinking there is some other thing that takes it's place that I can't find.

problem is this: creating a simple page with some fields in it.

in MF1//

1. create some m-Fields
2. create a page
3. fill out the fields on the page
4. select the fields that i want as a write panel.
5. echo them out on the page

STRUCTURE: page>fields

in MF2//

1. create a page template
2. create a page
3. assign the template to the page
4. create a custom post type
5. create the fields for that post type
6. create a post
7. fill in all the fields
8. run a loop in the page for the post type (for 1 post)
9. echo out the m-Fields data

STRUCTURE: page>post>fields

so a client would have to select the post type "about" then go in there and get(the only post in there) "about" then adjust the fields... meanwhile the page "about" is never touched... seems really strange...

or --- you could put ALL of the magic-fields on "page" - which in my case would mean that there would be 100 plus fields on every page and 90 of them wouldn't have to do with that page and then couldn't be required --- which is all way too confusing for clients.

I feel like I'm just not checking a special box somewhere.

Solution 1

You can go through the article http://learn.iis.net/page.aspx/140/understanding-the-built-in-user-and-group-accounts-in-iis-70/. As TomTom said, yes security has changed a lot from what it was in IIS 6.0. The article gives good in-depth on the User and Group level changes that has happened in IIS 7.0.

Below is part from the Web site link and from the help available in IIS 7.

IIS_IUSRS group has been granted access on all the necessary file and system resources so that an account, when added to this group, can act as an application pool identity seamlessly. By default, the ApplicationPoolIdentity account is selected. The ApplicationPoolIdentity account is dynamically created when an application pool is started, and therefore this account provides the most security for your applications.

Solution 2

Here's my understanding:

According to here:

IIS 7 also makes the process of configuring an application pool identity and making all necessary changes easier. When IIS starts a worker process, it needs to create a token that the process will use. When this token is created, IIS 7 automatically adds the IIS_IUSRS membership to the worker processes token at runtime. The accounts that run as 'application pool identities' no longer need to be an explicit part of the IIS_IUSRS group. This change helps you to set up your systems with fewer obstacles and makes your overall experience more favorable.

So, it could be said no matter which account we use as a Application Pool Identity, this account will be given the IIS_IUSRS group permission at runtime dynamically and implicitly. This so-called convenience is claimed to provide the most security. Anyway, who doesn't want IIS_IUSRS permissions if the account is running as an Application Pool Identity. But I just like everything to be in the sun.

Thanks

Comments

[sheriffderek]

i found this github.com/magic-fields-team/Magic-Fields-2/issues/5

[sheriffderek]

but i still think there is a way to do what I need... without having to make 3 things where I used to make 1.

[Ov's Pianist]

If you don't like it: turn on manualGroupMembership :)

[Marco Rehmer]

Thanks for reminding~ now I have one more thing to take care of... >_<