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. John -- 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 https://groups.google.com/d/msgid/puppet-users/3c16a7e4-877e-4e69-a27c-826f439ff311%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
