Re: File perms & group policy problem
From: Derek Melber [MVP] (derekm_at_braincore.net)
Date: 02/20/04
- Next message: Derek Melber [MVP]: "Re: Policies having no effect on XP workstation"
- Previous message: scott: "enumerating active directory users in sql new login"
- In reply to: Chriss3: "Re: File perms & group policy problem"
- Next in thread: Dave: "Re: File perms & group policy problem"
- Reply: Dave: "Re: File perms & group policy problem"
- Messages sorted by: [ date ] [ thread ]
Date: Thu, 19 Feb 2004 18:08:46 -0700
Glad to see you home!
Yeah, that is a great idea, but that is not the way GPOs work. They don't
apply in the order, rather, they are compiled to create the RSOP, then
applied in the order I mentioned. So, security always comes first, then
software.
-- Derek Melber "Chriss3" <noSpamHere@chrisse.se> wrote in message news:u6a5kKz9DHA.2644@TK2MSFTNGP11.phx.gbl... > Hi Derek! at least home again=) I'm a bit tired. but what about place the > MSI package in another policy than the particular security setting and > change the order of them. > > -- > Regards, > > Christoffer Andersson > No email replies please - reply in the newsgroup > If the information was help full, you can let me know at: > http://www.itsystem.se/employers.asp?ID=1 > > "Derek Melber [MVP]" <derekm@braincore.net> skrev i meddelandet > news:ucUezIw9DHA.1632@TK2MSFTNGP12.phx.gbl... > > Dave, > > > > I think you have the solution already, which is to force policy > application, > > even if nothing has changed. Yes, software is installed AFTER the security > > is in place. Just the way it works. I know of no way to change this, > unless > > you want to alter the code of GPOs:-). > > > > The worst case scenario is that you have the settings open for 90 minutes. > I > > can't imagine that this will be that horrible. However, maybe I don't > > understand the application or your environment much. > > > > -- > > Derek Melber > > > > "Dave" <NOSPAMd.ford@bath.ac.uk> wrote in message > > news:Xns94946736BDC88NOSPAMdfordbathacuk@207.46.248.16... > > > Sorry if this drags on a bit - it's a bit of a mixture of observation > and > > > intuition and mostly lack of documentation - I want to know if this is > > > right, and if my conclusions are right too... > > > > > > I'm setting the file permissions on some files on a PC using the policy > > > under Computer Configuration -> Windows Settings -> Security Settings -> > > > File System settings in a Group Policy. > > > > > > This works as expected. > > > > > > *However*... This policy is altering the security permissions of files > > > that will only exist after the installation of an MSI package... > > > > > > Now - if the file permissions settings are bundled into a policy > > > alongside the software installation then the file's don't get their > > > permissions applied. > > > > > > Checking C:\WINDOWS\security\logs\winlogon.log confirms my conclusion > > > that the file permissions are taking effect _before_ the software gets > > > installed. I.e., the policy changes the permissions of non-existent > > > files, then installs the files with the broken permissions, but leaves > > > them alone because it's already tried (but failed) to change them. > > > > > > Plus, it appears that the periodic policy refreshes (or ones forced with > > > the GPUPDATE command) do not appear to make any difference. I *think* > > > (though am not sure - opinions?) that this is because the security > policy > > > itself is not changing - so the computer never tries to re-apply it. > > > > > > Thinking about this for a while has left me with some strategies for > > > dealing with changing file perms on AD systems: > > > > > > 1) Turn on the 'Process even if the Group Policy objects have not > > > changed.' policy alongside the software and file security permissions. > > > This doesn't do anything to eliminate the initial problem - filesec > > > changes still happen before the files get created - but it does mean > that > > > the policy gets re-applied on every refresh interval. So, after 90 mins > > > (the default rate, I believe?) the intended permissions come good after > > > all. This is slow, and probably inefficient but does at least work > > > > > > 2) Wait 16 hours for the security policies to get refreshed. > > > > > > 3) Abandon attempting to set file permissions using Group Policies. > > > Instead, use cacls, batch scripts, custom actions in MSI files, etc. > > > instead. This is potentially complex, inconvenient, and hard to > > > maintain. I prefer the idea of keeping all install code in the one > > > place/package/policy. > > > > > > Now is here a way to force the order of policy application? I know that > > > the policies are supposed to be applied in a specific order - but even > > > when I split my setup into two policies - one containing the software > and > > > the other containing the file permissions, the software still gets > > > installed after the permissions settings are applied. > > > > > > Any thoughts as how to deal with this? > > > > > > Thanks > > > Dave > > > > > >
- Next message: Derek Melber [MVP]: "Re: Policies having no effect on XP workstation"
- Previous message: scott: "enumerating active directory users in sql new login"
- In reply to: Chriss3: "Re: File perms & group policy problem"
- Next in thread: Dave: "Re: File perms & group policy problem"
- Reply: Dave: "Re: File perms & group policy problem"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
