linux domain machines - cert error

[empb...@gmail.com]

Hello guys,

At my place of work we have some computer labs. In these laboratories each computer has the operating system windows and linux. Both systems are in our AD domain.

I did a lab of tests and I have a functional puppet server. I put some nodes as root of the system. Everything working perfectly.

When I log in with a domain user on linux machines and run the "puppet agent -t" command, a new certificate is generated, but an error occurs stating that it does not match the server's certificate.

How can I get around this and make it always the same certificate?

[jcbollinger]

It sounds like your machines use the same hostname whether they are running Windows or Linux.  This makes sense from a physical perspective, but not from a logical one -- one of your machines has very different characteristics when running Windows than it does when running Linux.

In any case, the Puppet installations on Windows and Linux are separate and do not share data (by default), so each manages its own certificate.  In that sense, they absolutely are distinct machines from Puppet's perspective.  By default, however, Puppet uses machines' hostnames as their certificate names, so if you have two machines with the same hostname then their certificates will collide.  It will also happen if you rebuild / re-image your machines without preserving their certificates, but reusing the same hostnames.

You have several options for working around that, among them:

• Give your machines different hostnames for Windows and Linux.  The easiest way to do that might be to add "-linux" and / or "-windows" suffixes to the hostnames you are using now.  Then each personality of each machine has a distinct name, and everything should just work.
• Use the 'certname' setting in your machines' Puppet configuration ([main] section) to assign a unique certname to each personality of each machine.  Perhaps you could use a pattern similar to the one I suggested for unique hostnames.
• You could also arrange for your machines to share their certificates between their two personalities, either by copying them or by putting them in a place that both personalities can access.  I have several technical reasons to dislike this alternative, and I don't recommend it, but having understood the problem, you probably would have thought of it anyway.

 John

[empb...@gmail.com]

hello John, thanks for the answer!!!

This problem only happens in linux machines that are in the domain, because I have not yet tested on windows.

Linux machines names in the test:

- mint-client.mycompany.intra

- ubuntu-client.mycompany.intra

Use the 'certname' setting in your machines' Puppet configuration ([main] section) to assign a unique certname to each personality of each machine.  Perhaps you could use a pattern similar to the one I suggested for unique hostnames.

So I would put an entry in puppet.conf, something like this?

[main]
certname = mint-client.mycompany.intra

[agent]
server = puppet.mycompany.intra

If yes, yet not works.

The user "xiru" is part of the domain. I logged on to the machine and executed "puppet agent -t" command and the error of certificates not match occurs.

It creates the new certificate on the path: "/home/xiru/.puppetlabs/etc/puppet/ssl"

[jcbollinger]

On Monday, April 23, 2018 at 10:34:56 AM UTC-5, empb...@gmail.com wrote:

hello John, thanks for the answer!!!

This problem only happens in linux machines that are in the domain, because I have not yet tested on windows.

Linux machines names in the test:

- mint-client.mycompany.intra

- ubuntu-client.mycompany.intra

Use the 'certname' setting in your machines' Puppet configuration ([main] section) to assign a unique certname to each personality of each machine.  Perhaps you could use a pattern similar to the one I suggested for unique hostnames.

So I would put an entry in puppet.conf, something like this?

[main]
certname = mint-client.mycompany.intra

[agent]
server = puppet.mycompany.intra

If yes, yet not works.

The user "xiru" is part of the domain. I logged on to the machine and executed "puppet agent -t" command and the error of certificates not match occurs.

It creates the new certificate on the path: "/home/xiru/.puppetlabs/etc/puppet/ssl"

My apologies.  It escaped my attention that you are running the agent as an unprivileged user instead of via a system account.  This is unusual, because the capabilities of the agent are limited to those of the user running it, so running it as an unprivileged user means that many of the resources one might normally want the agent to manage cannot, in fact, be managed.  It is more typical to run the agent as a system service, or to have the system's scheduler (e.g. cron) run it with privilege, so as to be able to manage everything.

Nevertheless, the problem is along the same lines I already described.  The system does not share its Puppet credentials with ordinary users, and they don't share theirs with each other.  Each of them, on each machine, on each OS, needs to be identified by a distinct certname.

If supporting multiple individual users running the agent as themselves is in fact what you want, then the solution is along the same lines as I already described.  Ordinary users will use Puppet configuration recorded in their own space, under .puppetlabs/etc/puppet.  You can form unique certnames by also adding the username, so, for example,

/home/xiru/.puppetlabs/etc/puppet/puppet.conf:

[main]
certname = lab1-machine1.mycompany.intra-linux-xiru

[agent]
server = puppet.mycompany.intra

Note well that this configuration is under the control of your users, so you would be wise to exercise careful oversight and control of certificate signing.

Again, however, this seems very unusual.  Unprivileged end users more typically rely on 'puppet apply' to apply local manifests under their own control to manage resources within their own limited sphere of influence.  This does not involve interacting with a master, and does not require cryptographic certificates at all.

John

[Elias Pereira]

John,

So the puppet is not designed to work with machines that are in the AD domain? Maybe, only in servers that the root user are used with security by sysadmin?

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9c0f8082-5f5b-4248-92a6-04d6b368c63c%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Elias Pereira

[jcbollinger]

On Tuesday, April 24, 2018 at 3:55:23 PM UTC-5, Elias Pereira wrote:

John,

So the puppet is not designed to work with machines that are in the AD domain? Maybe, only in servers that the root user are used with security by sysadmin?

Puppet works fine with machines in AD domains, both Windows and Linux.  In fact, some of the machines under my own Puppet management are Linux machines belonging to the institutional AD domain.  None of what I have described so far has anything particularly to do with AD.

Even if your machines are configured to grant administrative privileges to some users based on their AD identities or group membership (not an essential characteristic of machine AD membership), that changes little.  In particular, it does not change the fact that users do not, by default, share Puppet configuration or certificates with each other or with the system.

If you want users to make catalog requests using the system identity, then the most natural way for them to do so is to assume the system identity.  This is among the purposes served by the sudo and su commands on Linux.  Alternatively, non-root users who have sufficient privileges to usefully do so can certainly run the agent as themselves.  By default, such users will rely on their own personal configuration, certificates, etc., and all certificates used with Puppet need distinct certnames, as we've already discussed.

However, a user with sufficient local privilege to access all the system's Puppet configuration should be able to instruct the agent to use that configuration instead of the default personal one by issuing the --confdir command-line option to point it to the system's config directory.  For Puppet 5 on Linux, that would look like this:

puppet agent --confdir=/etc/puppetlabs/puppet

Most other relevant directory settings are relative to the $confdir by default, but it's possible that you might discover a need for additional CLI options to make it work fully.

John