Ask Your Question
0

How to prevent puppet agent from being disabled in a non-admin session?

asked 2017-06-27 07:37:15 -0500

Frank Klasens gravatar image

Currently in our Puppet setup on Windows I can disable and enable the puppet agent in a non-admin session. Disabling will write the specified reason in %USERPROFILE%.puppetlabs\opt\puppet\cache\state\agent_disabled.lock.

Running the Puppet agent in a non-admin session does not work. And it should not so that's ok. But it gives developers the wrong impression that the agent is disabled. Because if you run the agent is a admin session it will run. Checking the status of the agent in that session will also state that it is enabled.

Disabling in a non-admin session gives the impression the agent is disabled:

> puppet agent --configprint agent_catalog_run_lockfile
C:/Users/xxxxx.adm/.puppetlabs/opt/puppet/cache/state/agent_catalog_run.lock

> puppet agent --disable "testing STRY0011213"
> type .\.puppetlabs\opt\puppet\cache\state\agent_disabled.lock
{"disabled_message":"testing STRY0011213"}

Running in an admin session just works. Nothing seems to indicate the agent is disabled:

> puppet agent --configprint agent_catalog_run_lockfile
C:/ProgramData/PuppetLabs/puppet/cache/state/agent_catalog_run.lock
> type C:\programdata\PuppetLabs\puppet\cache\state\agent_disabled.lock
type : Cannot find path 'C:\programdata\PuppetLabs\puppet\cache\state\agent_disabled.lock' because it does not exist.

> puppet agent -tv
Notice: Local environment: 'production' doesn't match server specified node environment 'development', switching agent to 'development'.
...

You can enable the agent in a non-admin session but to no use, the agent will not run:

> puppet agent --enable
> type .\.puppetlabs\opt\puppet\cache\state\agent_disabled.lock
type : Cannot find path 'C:\Users\xxxxx.adm\.puppetlabs\opt\puppet\cache\state\agent_disabled.lock' because it does not exist.
> puppet agent -tv
Error: Could not request certificate: getaddrinfo: No such host is known.
Exiting; failed to retrieve certificate and waitforcert is disabled

The agent should only run in an admin session and enabling/disabling should also only be possible in an admin session. How could I accomplish that, or what am I doing wrong?

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
1

answered 2017-06-28 00:15:18 -0500

joshc gravatar image

Disabling puppet as a non-privileged user won't affect puppet when running as a privileged user (member of Administrators or LocalSystem) and vice-versa. The way to think about it is, there is one puppet instance for the machine (running in a privileged context). and optionally you there may be 0 or more unprivileged puppet instances. However, each instance has a unique identity based on its SSL client cert when communicating with the puppet master. So unprivileged puppet instances can only make changes if 1) they use a different certname than the per-machine instance, and 2) you issue client certs for the agent, e.g. puppet cert sign <unprivileged agent certname>.

Since each puppet instance is independent, when you disable puppet from an unprivileged context running as the xxxxx.adm user, it doesn't prevent puppet from running in a privileged context, and vice-versa.

The second part of your question:

puppet agent -tv
Error: Could not request certificate: getaddrinfo: No such host is known.
Exiting; failed to retrieve certificate and waitforcert is disabled

is unrelated to the agent being disabled or not. The waitforcert is disabled is trying to say that the agent tried to connect to the puppet master, but the DNS name is not resolvable, so the agent couldn't submit its CSR. And since the waitforcert command line option wasn't specified, the agent will exit instead of waiting for the cert to be signed. This issue is likely, because the non-privileged agent has a different $confdir, so it doesn't use whatever settings you've made for the privileged agent, e.g. server=<your puppet master>. As a result, the unprivileged agent tried to connect to the default puppet, and failed.

The agent should only run in an admin session

If puppet is installed, then there isn't anything to prevent a non-admin user from running the puppet binary. However, they will only be able to make changes that the unprivileged user is authorized to do, e..g install packages, start/stop services, etc. But if that's the case, then they could do that without puppet, e.g. start /w msiexec /qn /norestart /i http://.../bitcoin-miner.msi.

enabling/disabling should also only be possible in an admin session.

Only an administrator will be able to enable/display the privileged instance of the puppet agent. So for example, an unprivileged user can't disable the privileged puppet agent.

edit flag offensive delete link more

Comments

Thanks! That clarifies a lot. In fact the situation as we have it is good. It's only confusing if you disable the agent in a non-admin session (non-intentionally) because it suggests the agent is disabled while it keeps running in the admin context making changes to your system.

Frank Klasens gravatar imageFrank Klasens ( 2017-06-29 00:55:02 -0500 )edit

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower

Stats

Asked: 2017-06-27 07:37:15 -0500

Seen: 41 times

Last updated: Jun 28