On Wednesday, April 11, 2018 at 2:02:52 PM UTC-5, Jason McMahan wrote:
> Thank you both for your reply.
> The scenario i have is as follows.
> I need to create/destroy/modify active directory group.
> There is a winad module, once i was able to get it working to create the 
> group it was doing it under my user context. 
> To have it run properly i would need to supply it a credential.
> Unless i am missing it i would need to execute powershell with username 
> and password pass it to get-credential and populate a variable.
> Then take a variable pass that to -credential and it would create the 
> group as i need or destroy. 
> I am grateful for any help suggestions.

In general, running the Puppet 'agent' or 'apply' commands in an ordinary 
user context is of limited utility for exactly the sort of reason you've 
run into: Puppet then has insufficient privilege to manage a lot of the 
things that one typically wants to manage.  The usual and recommended way 
to address that is to run the whole Puppet process in a context that has 
sufficient privilege to perform the tasks it must perform.  On Windows, for 
example, the Puppet agent can be set up to run as a service running under 
the SYSTEM account.

The SYSTEM account in particular is probably inappropriate if you want to 
manage institutional AD, but here we come to the crux of the matter: you're 
trying to empower a principal (whatever user is running Puppet) to 
impersonate a different principal so as to exercise that second principal's 
privileges.  From a security perspective, whether the first principal 
should have authority to do that ought to be a question only of the 
identities of the principals involved.  If such authority exists in your 
case then one manifestation is that it is unnecessary to protect the second 
principal's credentials from the first principal, as they are authorized to 
have and use them.

On the other hand, if it is not the case that the principal on whose 
authority Puppet runs should be empowered to impersonate the second 
principal in general, then it is a violation of security protocol to allow 
them to do so under any circumstances.  You should then avoid providing the 
second's credentials at all.  Instead, you might set up a for-purpose 
service or application that the first principal is permitted to use to 
achieve the objective, without impersonating a different principal, 
whether directly or indirectly.


You received this message because you are subscribed to the Google Groups 
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to