[Puppet Users] Puppet Support for Windows

I have big problem on localized Wondows:
https://groups.google.com/forum/?fromgroups=#!topic/puppet-users/HN9Fg3Q_n3M

You can't use non-ANSI characters in file\folder names, user names, etc.
Now I try workaround.

воскресенье, 27 января 2013 г., 1:12:03 UTC+4 пользователь
damian.[email protected] написал:

Hi Damian,
This is on our Windows roadmap, filed as
https://projects.puppetlabs.com/issues/13249. Recently, the priority
has increased as we've been hearing similar comments from other users.
With that said, I'm curious what use cases you're looking to solve.
Are you looking to specify the complete state of the DACL, e.g. grant
permissions to these accounts, deny to these, control inheritance? Or
a partial state, e.g. ensure administrators has full control and
ignore other ACEs that are present. Or is it a compliance issue, e.g.
ensure only administrators can write?

Also are you looking to manage DACLs on other securable objects, e.g.
registry keys.

Also are you looking to manage SACLs?
This is filed as https://projects.puppetlabs.com/issues/17706. It
would be trivial to implement, as we already have the SID resolution
code in place, and it would be similar to how we manage the user
account for scheduled tasks.
I can't specify when exactly, but this is a high priority for us. The
top-level ticket is filed as
https://projects.puppetlabs.com/issues/11206. The hard work of getting
mcollective running on windows has already been done. The remaining
issues are around packaging, updating PE modules to support windows,
and better mcollective control of the puppet agent, all of which are
straightforward tasks.

Josh

Hi Josh,

First of all thanks for the quick reply.

The main priorities to make Puppet usable on Windows for us would be:

1> Control complete state of the DACL for grant (we don't use deny).
2> Control inheritance on DACL (at the same time as being able to control
other DACL grant entries for that object).
3> Control inheritance on SACL (we only set this at a higher level).
4> Set user account on Service.

It would also be good to have the following (although don't think it would
be a showstopper for adoption):
5> Control ACL on local SMB shares.
6> Control ACL on registry.

And finally the nice to haves:
7> (Nice to have) Set DACL on parent directory but inherit permissions on
all children when using source param with multiple levels of hierarchy.
8> (Nice to have) Set DACL on parent directory but inherit permissions on
all children when using recurse param.

Off the top of my head (not fully worked out all our requirements with the
devs yet) I don't think we control access to any other types of windows
object (e.g. service)

I did start having a dig in the Puppet code for the file type and all of
the building blocks are already there. I'm not sure how much effort it
would be to write an ntfsfile class but I have started having a play with
writing my own (in my spare time) but I've never written Ruby before so a
reasonable learning curve (not least just to understand the mass of file
and windows provider Puppet code let alone Ruby!). The permission setting
methods are all there (e.g. set_acl and get_acl from security.rb including
the protected parameter that i couldn't see a way of setting anywhere). My
plan was to replace the mode param on file.rb with a dacl param that could
take some form of friendly dacl description. The get_mode and set_mode
methods could then be changed to translate between friendly dacl and real
dacl rather than POSIX mode and dacl.

The friendly DACL would use something like the following to describe each
ACE:
  ntfsfile { 'myfile.txt' :
     require => file,
     dacl => [
                   ['user1', grant, [FULL_CONTROL]],
                   ['user2', grant, [FILE_READ]],
                   ['group1', grant, [FILE_READ, FILE_WRITE,
CHANGE_PERMISSIONS]],
                   ['user3', deny, [FILE_READ, FILE_WRITE, FILE_EXECUTE]]
                  ],
     inheritparent => false,
     source => 'puppet://modules/something/file.txt',
}

Do you have any code on github? Perhaps we can collaborate. I am doing a
bit of windows type and provider development currently (mostly learning how
;) I have a pendinga windows clustering provider, and a windows ad dns
provider in the works. I have also wrote a chocolatey provider that we
are now officially using on 100s of servers.

no sorry, i'm only on day 2 of learning Ruby and about day 5 of Puppet. If
i'm lucky i get about an hour every other evening to look at this so
progress is slow. Once I've got something worthwhile sharing i'll post it
somewhere.

My two projects are an ntfsfile type (in which you can specify a full DACL
and inheritance) and a windowsservice type (which will install a service
via installutil.exe if it doesn't already exist and allow you to specify a
username and password).

Hi Rich,

I'm new in Puppet and will start working on a windows module so I would
like to look at your code in github. I think it's a good point to start for
me.
Hopefully you can let me know your code name or others related to windows.
Any advice would be greatly appreciated...

Thanks,
Jaisol

El martes, 29 de enero de 2013 08:53:18 UTC-6, Rich Siegel escribió:

Hi Damian,
It sounds like you're wanting to model the security descriptor, and
not just the DACL.
Ideally the type should be applicable to any windows securable object,
e.g. desktops, services, etc.
I'd recommend using the win32-security gem[1] as a starting point and
adding whatever methods aren't yet implemented, using the puppet code
for comparison. Ideally, I'd like to see all of the ACL manipulation
done in win32-security and not in puppet.
Josh

[1] https://github.com/djberg96/win32-security

Thanks Josh. Unfortunately I have had zero time to dedicate to this.

Tbh if I could just model the dacl plus control the inheritance of dacl from parent that would be enough.

I did start to write an ntfsfile class but wanted to keep all of the existing file class functionality except setting user, group, and mode so started by copying all the related ruby for that. . Thats a pretty complicated type and provider and a combination of this being my first Puppet development plus not knowing Ruby made it tough going.
The plan was to have a string property which was a JSON representation of a dacl which got munged into a combination of arrays and hashes plus an inherit property. I wrote the code to then set the dacl on the file based upon the arrays etc. This worked but was v hacky and was based upon a hard coded array (not yet written the validate and munge methods!)
Overall I'm not sure how good quality I could make this.

So..., are we likely to see any progress on the ticket for Puppetlabs to release an official version for this?
Would it help speed things up if a request came from a PE customer (with 1500 node licence)?

Hi Josh,

Did PuppetLabs ever get anywhere with ticket 13249. I'm guessing not as it
hasn't been updated for months. I see that PE 3 is now available and that
there has been plenty of activity on the Windows side of things (we are
about to start a trial with it on some of our Windows estate as Windows
support especially MCollective is much better).
Do you have any sort of timescale for this ticket. I'd like to vote on it
but the "gatekeepers" of our PE login details are not letting me near it
(the sysadmins own it, we're an app development department and having some
fun and games with them trying to do continuous deployment type stuff!).

If you have any early release type versions of this I might be able to help
out with some testing etc.

Damian
This is on our Windows roadmap, filed as
https://projects.puppetlabs.com/issues/13249. Recently, the priority
has increased as we've been hearing similar comments from other users.
With that said, I'm curious what use cases you're looking to solve.
Are you looking to specify the complete state of the DACL, e.g. grant
permissions to these accounts, deny to these, control inheritance? Or
a partial state, e.g. ensure administrators has full control and
ignore other ACEs that are present. Or is it a compliance issue, e.g.
ensure only administrators can write?
>>

Hi Damian,
Yes, mcollective is fully supported on windows now!

I don't have a time estimate, other than to say that we are working on a
set of improvements to file system management, including NTFS ACLs,
symlinks, and some bug fixes, and it's one of our top priorities, along
with powershell and reboot support.

If you have any early release type versions of this I might be able to help

That'd be great! Managing the ACL via Win32 API's is not hard (we do much
of it today). The hard part is deciding how best to model the ACL in
puppet. Should it be a separate resource type or a property of the file
type? Do we create a new file acl type with multiple providers, e.g.
windows, solaris, etc? If so, what parameters and properties are common,
and which are unique to a specific provider, e.g. protected on windows?

Josh

Hi Josh,
That's amazing news. Powershell support alone would be killer - I had to
wrap nearly my entire universe with cmd.exe to make like easier - to the
point of writing a shared module for this pain. Powershell can't come fast
enough :)

<snip>
Hopefully my $0.02 can we worth something here ;) I'd argue that it's
really a separate resource type - since the ACL is related to the user
space. If you're going to extend it to multiple providers (solaris as per
your example) it's really similar in idea to RBAC. In fact, if you look at
Windows ACLs, RBAC, and set/get facl you pretty much have a new type. Or
at least that's what I'd hope :)

--c
Chayim Kirshen
Founder, Lyrical Software
@lyricaldevops | http://www.lyricaldevops.com

I have a powershell provider here:
http://forge.puppetlabs.com/joshcooper/powershell. And as of puppet 3.2,
that the module tool supports windows, so you can do:

C:\>puppet module install joshcooper-powershell
C:\>puppet apply -e "exec { 'Write-Host hello': provider=> powershell,
logoutput => true }"
Notice: /Stage[main]//Exec[Write-Host hello]/returns: hello
Notice: /Stage[main]//Exec[Write-Host hello]/returns: executed successfully

We've recently made some improvements around powershell invocation. See
https://github.com/joshcooper/puppetlabs-powershell/issues for more info.

Josh

a set of improvements to file system management, including NTFS ACLs,
symlinks, and some bug fixes, and it's one of our top priorities, along
with powershell and reboot support.
wrap nearly my entire universe with cmd.exe to make like easier - to the
point of writing a shared module for this pain. Powershell can't come fast
enough :)
http://forge.puppetlabs.com/joshcooper/powershell. And as of puppet 3.2,
that the module tool supports windows, so you can do:
Fantastic thank you! I'm going to bang on this next week.

Cheers,
--c

Chayim Kirshen
Founder, Lyrical Software
@lyricaldevops

And of course some Solaris is by no means the only Unix-y OS with ACL
support. It is available on Linux, too, at least for the most frequently
used filesystems, and I'm sure there are others. I'm inclined to agree
that a type aimed at broad ACL / RBAC support would be a win.


John

Hi John,

Yep, I agree. Now, how exactly to map the type across different
implementations?

Windows ACLs support inheritance. An ACL can be marked as protected,
breaking inheritance, and for directories, everything below it.

ACEs specify a subject (SID) and the rights that are granted/denied. This
is a bitfield, though users are more typically used to saying "Full
Control" or "Read & Execute".

Windows ACEs can either be allow or deny, the order matters, and if no ACEs
match, access is denied.

An ACE for a directory can be marked as object-inherit and/or
container-inherit. This doesn't affect the effective permissions on the
directory, only files and subdirectories, respectively.

How are these similar & different to Unix-y ACLs?

Josh

Please allow me to refine my terminology from "Unix-y" to "POSIX". Here's
a document that does a pretty good job of explaining POSIX ACLs:
http://users.suse.com/~agruen/acl/linux-acls/online/.

To answer your questions more directly, however:


*ACL Inheritance*:

POSIX defines "default" ACLs for directories, which provide the closest
analog to Windows ACL inheritance. A directory's default ACL is assigned
as the ACL of each file or directory created therein, and also as the
default ACL of each directory created therein (subject to further
restriction according to the requested initial mode for the
file/directory). POSIX does not differentiate between files and
directories in this regard, except inasmuch as only directories have
default ACLs.

ACLs are bound directly to each file and directory; they do not
automatically change if their parent directory's default ACLs are changed,
and access control decisions are based only on Files own ACLs (and I
suspect this is true under the covers for Windows, too). POSIX differs
from Windows in not defining features for automatically or implicitly
updating the ACLs of a directory's contents when that directory's default
ACL is modified: POSIX default ACLs are relevant only at the creation of
new files and subdirectories.


*ACL Scope and Structure*:

POSIX ACEs reflect and extend the standard POSIX file permission scheme,
allowing for read, write, and execute permission to be granted (or not) to
specified users or groups. The traditional POSIX 'group' permissions map
to a mask of the maximum permissions that any ACE other than the owner's or
'other' can grant.

Access attempts that are not otherwise mapped to an ACE use the 'other' ACE
that all files have; this is analogous to Windows's "Everyone". It does
not necessarily grant any access.

There is no affirmative permission denial as such, only absence of
permission grant. It amounts to the same thing for users because if there
is an ACE matching the UID of the process requesting access then that ACE
determines access, or lack thereof. For groups, however, access can be
granted through any of the process's groups, even if others of its groups
do not have the requested access.

POSIX ACL order is not significant, but ACE specificity is. When a
user-specific ACE is applicable, it determines access, possibly in
conjunction with the mask ACE. Otherwise, when one or more group-specific
ACEs are applicable, they jointly determine access, together with any mask
ACE. Only if no other ACE applies is the 'other' ACE relevant.


John