Re: W2k and Front Page Security
From: Jenny (jklippe@yahoo.com)
Date: 03/17/03
- Next message: Ed Thurber: "Re: Prevent users from installing software"
- Previous message: Mike: "Re: Prevent users from installing software"
- In reply to: Roger Abell [MVP]: "Re: W2k and Front Page Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Jenny" <jklippe@yahoo.com> Date: Mon, 17 Mar 2003 05:17:56 -0800
Thank You your awesome this is what I needed. Thanks again.
>-----Original Message-----
>"Jenny" <jklippe@yahoo.com> wrote in message
news:012301c2ea72$4434fd90$a501280a@phx.gbl...
>> Here we go We now have 16 different web authors for our
>> site, each dept maintains their own. I have the site
set
>> up now using subweb and setting permissions throgh
Front
>> Page/. We have have contracted out our web redesign to
a
>> vendor. We have noone here that knows how to code. She
>> wants me to use NTFS file permissions instead of
subwebs,
>> We have sahred drop down menu bar that will need to be
>> updated 16 times when changes are made by 16 different
>> people. How can I still allow our users to update and
>> maintain with Front Page and still have a folder
structure
>> with NTFS permissions contolling folders.When I set
>> permissions and by pass the Font Page control of
>> permission I get server error cannot open *file for
>> read/write " I have done every fix suggested by
microsoft
>> for this error and nothing is workin. I need to keep
some
>> kind of seperate permissions so that others are not
>> screwing up anothers pages Please Help
>> Thnk you
>> .
>>
>
>When you start tweaking around at the NTFS level within
>FrontPage managed content areas you do really need to
>know what you are doing.
>
>>From what little you have said, I assume you had
initially
>something like
>../sitemain
>../sitemain/group1
>../sitemain/group2
>etc
>../sitemain/group16
>or 17 FP webs nested as shown
>and with each having different authors
>and now, within
>../sitemain
>this designer wants for you to have
>../sitemain/subinfo
>../sitemain/subinfo/group1
>etc
>../sitemain/subinfo/group16
>where these are all part of the one
>FP web ./sitemain but have NTFS
>to allow authors of groupX subweb
>ability to update some info within
>../sitemain/subinfo/groupX that the
>../sitemain web uses for menu display
>in order for the main menu to reflect
>changes they have made within their
>../sitemain/groupX subweb
>Perhaps ./sitemain/subinfo/groupX
>actually represents some file within
>../sitemain/subinfo/ instead of a
>folder, but the idea/effect is the same.
>
>Close ?
>
>FrontPage web/subweb boundaries serve
>only a couple of purposes, logically.
>They can be used for chunking content into
>pieces so that one may work on a defined
>piece and copy it for versioning without having
>to work with and/or copy everything
>and
>They are used for permission boundaries, either
>for browsing or authoring permissions,
>
>Basically, whereever the designer is asking for
>different NTFS permissions one could use a
>FrontPage web/subweb to effect the permission
>difference. The main impact is that one then has
>changed the chunking - which should be only
>a minor inconvenience to the author of the parent
>web.
>
>If the designer had said, take the 17 webs
>../sitemain
>../sitemain/group1
>../sitemain/group2
>etc
>../sitemain/group16
>and make them one, but set different NTFS
>permissions on the folders
>../sitemain/group1
>../sitemain/group2
>etc
>../sitemain/group16
>when you do this you destroy the ability of
>the 16 departments to open and modify their
>area as a FrontPage web or web folder.
>
>If you leave them as separate webs, with
>authorship of the main top web also having
>authorship of every groupX subweb in addition
>to the people in that department having authorship,
>you have introduced the ability of the author of the
>main web to accidently change the work of any of
>the groupX departments. But they should be able
>to work around that by good paractices - it would
>be a human error thing.
>And, if in each ./sitemain/groupX subweb there
>was a folder ./sitemain/groupX/menuinfo that
>the groupX authors kept updated for use by the
>../sitemain web in its menu display - then all (assumed)
>needs are covered (in fact, the ./sitemain author does
>not really even need authorship on the ./sitemain/groupX
>webs to do this)
>Alternatively, you can leave the 17 webs
>../sitemain
>../sitemain/group1
>../sitemain/group2
>etc
>../sitemain/group16
>as they are, as separate FrontPage webs with
>17 different authorships and then define
>../sitemain/subinfo
>../sitemain/subinfo/group1
>etc
>../sitemain/subinfo/group16
>as 17 additional subwebs, with authorship over
>all by the ./sitemain authors, and authorship also
>in each ./sitemain/subinfo/groupX subweb given
>also to the groupX authors.
>
>I have many issues with how FrontPage goes about
>seeming to manage NTFS settings. But, unless you
>want to drill into some fairly ugly things you are best
>off trying to work with FrontPage by using subwebs
>as permission boundaries and letting it keep the grants
>of authorship straight for you, rather than by starting
>to micromanage at the NTFS level. Anyway, even if
>you did directly modify at NTFS level successfully,
>you may find that FrontPage (either on trigger by
>someone using the Server Health function, or on its own
>when new subsebs get defined) someday can and/or will
>wipe out the NTFS modification you have made.
>
>--
>Roger Abell
>MS MVP (Security, Windows), MCDBA, MCSE both
>.
>
- Next message: Ed Thurber: "Re: Prevent users from installing software"
- Previous message: Mike: "Re: Prevent users from installing software"
- In reply to: Roger Abell [MVP]: "Re: W2k and Front Page Security"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
