Re: [Puppet Users] Windows ACL best practise

Josh Cooper
Wed, 20 Mar 2013 04:28:14 -0000

On Tuesday, March 19, 2013, Thomas Bendler wrote:

> Hi @all,
>
> I''ve started to extend some classes I wrote with support for
Windows.
> Unfortunately I got stucked with the ACLs. The plan is (as I thougth) quite
> simple, I would like to create a central directory (i.e. c:\managed) and I
> would like to put some additional files and directories underneath this
> directory (i.e. a repository, a project directory and some programs). The
> idea is to have everything related to Puppet in one place. So far, so good,
> creating the resources is not a big deal but when it comes to ACLs it
> become complicated (at least for me). I''ve wrote a param class
with
> something like this inside:
>
> # Operating system definitions
> case $::osfamily {
>   redhat: {
>     $osUser = ''root''
>     $osGroup = ''root''
>     $osFilePermissions = ''0644''
>     $osDirectoryPermissions = ''0755''
>   }
>   windows: {
>     $osUser = ''Administrator''
>     $osGroup = ''Administrators''
>     $osFilePermissions = ''0660''
>     $osDirectoryPermissions = ''0770''
>   }
> }
>
> In the common class I have for Windows something like this:
>
> # Create central manged directory
> file {
>   "c:\managed":
>     ensure => directory,
>     mode => "${common::params::osDirectoryPermissions}",
>     owner => "${common::params::osUser}",
>     group => "${common::params::osGroup}";
> }
>
> Now I ran into the first problem, we have english Windows systems as well
> as german Windows systems where the administrator group is Administrators
> (english) and Administratoren (german). So on german systems, the group is
> invalid and all depending stuff is not working because the central
> directory isn''t available.
>

Specify the owner and/or group as a SID, e.g. S-1-5-32-544. See also
 http://support.microsoft.com/kb/243330

If this isn''t documented on the file type reference, please file a
ticket,
as it should be.


>  Sometimes it''s even worst, the directory is created but only the
local
> Administrator can access the directory, neither local system nor anyone
> else.
>

If LocalSystem (S-1-5-18) is not explicitly specified as the owner or
group, then that account will not have permission to access the resource.
For example, owner => Administrator, group => Administrators, although
seemingly reasonable, can lead to the behavior you describe. Instead, you
are better off doing something like owner => LocalSystem, group =>
Administrators (using the appropriate SIDs).

Really puppet should always ensure LocalSystem has Full Control, which it
effectively does (since it can always take ownership). But thats a two step
operation, unlike POSIX where root can always access. There is a ticket
filed on this already (to ensure puppet never removes LocalSystem access)

I was thinking about two approaches to solve the problem, first,
create
> something base on exec with mkdir if directory does not exist and a script
> setting the correct ACLs (with inheritance) or second, create a local
> puppet group and assign the correct groups to it (what could result in
> manual actions because of the language settings). Any ideas how to deal
> with that situation or even better, does someone have already working
> solutions dealing with that kind of problem?
>

HTH,
Josh






--
Josh Cooper
Developer, Puppet Labs