yankcrime/datacentred-ldap

OpenLDAP module for Puppet

Hi 👋

I'm Nick, I work on various things - mostly related to Cloud Native technologies with a particular focus on AI, ML and HPC workloads.

I'm also a CNCF Ambassador and an OpenUK Ambassador.

I have a sporadically updated blog here, and you can find me in the Fediverse here.

datacentred-ldap's Issues

Error: Could not find a suitable provider for ldap_entry - Puppet 6

My Puppet server has been on 6.0.x for a couple months now. I just upgraded an agent that uses this module to 6.0.4 and I started getting this error similar to #70. Are there configuration changes required in the module to support version 6?

Is this module still maintained?

Will the plugin be able to work with pam authentication?

Hello,

I am pretty sure this is not an issue, but i would like to know if its possible to use and configure a pam authentication method with the datacentred-ldap plugin, and if not, can we expect such an extension?

Supporting OLC

As of slapd 2.4, configuration can happen in a config file, /etc/$configdir/slapd.conf and requires a server restart, or online using the cn=config schema (if declared).

slapd can run with or without that schema.

Config changes can be applied online using ldapmodify against cn=config schema, and/or written down in the slapd.conf file.

There needs to be discussion if datacentred-ldap want to

• work with slapd.conf
• work with olc (which is accessed using ldap, and is stored in /etc/$configdir/slapd.d)
• work with both and apply changes to both.

Also, when changing slapd.conf and cn=config is enabled, you'll need to

• wipe out the old olc data using rm -rf /etc/$configdir/slapd.d/*
• generate the initial olc config using slaptest -f /etc/$configdir/slapd.conf -F /etc/$configdir/slapd.d
• chown the entire subtree with slapd.d to the ldap user and group if necessary

Assuming that olc and slapd.conf are maintained by puppet, both should always be in sync.

If third party tools try to olc the thing bypassing puppet your life is becoming interesting.

ACL support is missing

A useful LDAP database declaration in slapd.conf will need a database specific ACL declaration.

A first approximation for support would accept an array of ACL clauses which are simply added as a stanza of lines to the database declaration. This should be relatively easy to add.

A more complete implementation would have some kind of DSL or type notation that would allow a more user friendly declaration of ACL rules. It can be argued that this is useless, as this adds no value to the project and even substracts value.

Adding value would mean that the thing would become more portable, or a whole lot easier to understand than native slapd ACL syntax. Substracting value is when not all native functionality is accessible through using the DSL/type notation, because that added abstraction is less expressive than the native ACL notation.

Could not autoload ldap_entry

I have a problem on my VM to add an ldap entry.

site.pp

node default {
        class { 'ldap::client':
                uri  => 'ldap://localhost ldaps://localhost',
                base => 'dc=ACME,dc=local',
                ssl => false
        }

        class { 'ldap::server':
                suffix  => 'dc=ACME,dc=local',
                rootdn  => 'cn=admin,dc=ACME,dc=local',
                rootpw  => sha1digest('vagrant'),
                ssl => false
        }

        ldap_entry { 'dc=ACME,dc=local':
                ensure      => present,
                host        => 'localhost',
                port        => 386,
                ssl => false,
                base        => 'dc=ACME,dc=local',
                username    => 'cn=admin,dc=ACME,dc=local',
                password    => sha1digest('vagrant'),
                attributes  => { o => 'ACME.local', dc => 'ACME',
                           objectClass => ["dcObject", "organization"]}
        }
}

Error message

puppet apply  /etc/puppet/manifests/site.ppp
Could not autoload ldap_entry: Could not autoload /etc/puppet/modules/ldap/lib/puppet/provider/ldap_entry/ldap.rb: no such file to load -- rubygems at /etc/puppet/manifests/site.ppp:25 on node vagrant.wahl.kdg

The file exists

ls -l /etc/puppet/modules/ldap/lib/puppet/provider/ldap_entry/ldap.rb
-rw-r--r-- 1 root root 6569 Jul 31  2014 /etc/puppet/modules/ldap/lib/puppet/provider/ldap_entry/ldap.rb

The system

vagrant vm inukshuk/debian74-puppet
Debian GNU/Linux 7 \n \l
Linux version 3.2.0-4-amd64 ([email protected]) (gcc version 4.6.3 (Debian 4.6.3-14) ) #1 SMP Debian 3.2.65-1+deb7u1
Puppet 2.7.23
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
ruby-net-ldap 0.3.1-2

Ldap doesnt want to start

Hello,

When provisioning, the ldap doesnt want to start:

May 23 11:26:02 pmaster slapd[13284]: @(#) $OpenLDAP: slapd (Ubuntu) (Mar 17 2014 21:20:08) $#12#011buildd@aatxe:/build/buildd/openldap-2.4.31/debian/build/servers/slapd
May 23 11:26:02 pmaster slapd[13284]: daemon: bind(8) failed errno=13 (Permission denied)

apparently it needs root permissions (which i think it already has, isnt the provision running as root?)

ldap_entry seems to be broken?

Hello

I am trying to use the ldap_entry provided by the module, but it seems to be broken:

Error: /Stage[main]/Main/Node[bastion]/Ldap_entry[cn=Baz,ou=Bar,dc=baz,dc=co,dc=uk]: Could not evaluate: undefined method `keys' for nil:NilClass

Error: /Stage[main]/Main/Node[bastion]/Ldap_entry[cn=Foo,ou=Bar,dc=baz,dc=co,dc=uk]: Could not evaluate: uninitialized constant Net::LDAP

This is my .pp file:

class { 'ldap::server':
          suffix => 'dc=example,dc=com',
          rootdn => 'cn=admin,dc=example,dc=com',
          rootpw => hiera('ldapServerDbPassword'),
          ssl => false
        }

ldap_entry { 'cn=Foo,ou=Bar,dc=baz,dc=co,dc=uk':
          ensure      => present,
          host        => '1.2.3.4',
          port        => 636,
          base        => 'dc=baz,dc=co,dc=uk',
          username    => 'cn=admin,dc=baz,dc=co,dc=uk',
          password    => 'password',
          attributes  => { givenName   => 'Foo',
                 objectClass => ["top", "person", "inetorgPerson"]
          }
        }

        ldap_entry { 'cn=Baz,ou=Bar,dc=baz,dc=co,dc=uk':
          ensure      => absent,
          base        => 'dc=baz,dc=co,dc=uk',
          host        => '1.2.3.4',
          username    => 'cn=admin,dc=baz,dc=co,dc=uk',
          password    => 'password',
        }

Trace Exception:

Error: /Stage[main]/Main/Node[bastion]/Ldap_entry[cn=Baz,ou=Bar,dc=baz,dc=co,dc=uk]: Could not evaluate: undefined method `keys' for nil:NilClass
/var/lib/puppet/lib/puppet/provider/ldap_entry/ldap.rb:60:in `attributes'
/var/lib/puppet/lib/puppet/provider/ldap_entry/ldap.rb:10:in `exists?'
/usr/lib/ruby/vendor_ruby/puppet/property/ensure.rb:81:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1035:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1063:in `retrieve_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:223:in `from_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:19:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:174:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `eval_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `call'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `block (2 levels) in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:327:in `block in thinmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:326:in `thinmark'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `block in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:118:in `traverse'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:108:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:164:in `block in apply'
/usr/lib/ruby/vendor_ruby/puppet/util/log.rb:149:in `with_destination'
/usr/lib/ruby/vendor_ruby/puppet/transaction/report.rb:108:in `as_logging_destination'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:163:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:125:in `block in apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:161:in `block in benchmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:160:in `benchmark'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:124:in `apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:192:in `run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:44:in `block (4 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:44:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:114:in `with_client'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:79:in `run_in_fork'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:40:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `controlled_run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:38:in `run'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:355:in `onetime'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:321:in `run_command'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:470:in `plugin_hook'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:478:in `exit_on_fail'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:137:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:91:in `execute'
/usr/bin/puppet:4:in `<main>'
Error: /Stage[main]/Main/Node[bastion]/Ldap_entry[cn=Foo,ou=Bar,dc=baz,dc=co,dc=uk]: Could not evaluate: uninitialized constant Net::LDAP
/var/lib/puppet/lib/puppet/provider/ldap_entry/ldap.rb:113:in `ldap'
/var/lib/puppet/lib/puppet/provider/ldap_entry/ldap.rb:70:in `ldap_search'
/var/lib/puppet/lib/puppet/provider/ldap_entry/ldap.rb:10:in `exists?'
/usr/lib/ruby/vendor_ruby/puppet/property/ensure.rb:81:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1035:in `retrieve'
/usr/lib/ruby/vendor_ruby/puppet/type.rb:1063:in `retrieve_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:223:in `from_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction/resource_harness.rb:19:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:174:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:187:in `eval_resource'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `call'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `block (2 levels) in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:327:in `block in thinmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:326:in `thinmark'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:117:in `block in evaluate'
/usr/lib/ruby/vendor_ruby/puppet/graph/relationship_graph.rb:118:in `traverse'
/usr/lib/ruby/vendor_ruby/puppet/transaction.rb:108:in `evaluate'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:164:in `block in apply'
/usr/lib/ruby/vendor_ruby/puppet/util/log.rb:149:in `with_destination'
/usr/lib/ruby/vendor_ruby/puppet/transaction/report.rb:108:in `as_logging_destination'
/usr/lib/ruby/vendor_ruby/puppet/resource/catalog.rb:163:in `apply'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:125:in `block in apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:161:in `block in benchmark'
/usr/lib/ruby/1.9.1/benchmark.rb:295:in `realtime'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:160:in `benchmark'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:124:in `apply_catalog'
/usr/lib/ruby/vendor_ruby/puppet/configurer.rb:192:in `run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:44:in `block (4 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent/locker.rb:20:in `lock'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:44:in `block (3 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:114:in `with_client'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:41:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:79:in `run_in_fork'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:40:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `call'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:179:in `controlled_run'
/usr/lib/ruby/vendor_ruby/puppet/agent.rb:38:in `run'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:355:in `onetime'
/usr/lib/ruby/vendor_ruby/puppet/application/agent.rb:321:in `run_command'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block (2 levels) in run'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:470:in `plugin_hook'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `block in run'
/usr/lib/ruby/vendor_ruby/puppet/util.rb:478:in `exit_on_fail'
/usr/lib/ruby/vendor_ruby/puppet/application.rb:364:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:137:in `run'
/usr/lib/ruby/vendor_ruby/puppet/util/command_line.rb:91:in `execute'
/usr/bin/puppet:4:in `<main>'

Puppet version - 3.4.3
OS - Ubuntu 14.04

The configuraiton of the .pp is pretty much a copy from the example page.

Error: Could not find a suitable provider for ldap_entry

I have the following configuration

class { 'ldap::server':
  suffix  => 'dc=piu,dc=de',
  rootdn  => 'cn=admin,dc=piu,dc=de',
  rootpw  => '{MD5}FLasFExRTZnaVKq2ALMPAA==',
}

class { 'ldap::client':
  uri  => 'ldap://127.0.0.1',
  base => 'dc=piu,dc=de',
}

ldap_entry { 'cn=groups,dc=piu,dc=de':
  ensure      => present,
  base        => 'dc=piu,dc=de',
  host        => 'ldap://127.0.0.1',
  username    => 'cn=test,cn=groups,dc=piu,dc=de',
  password    => '{MD5}FLasFExRTZnaVKq2ALMPAA==',
}

Does not define config database (should be optional)

As of 2.4, openldap creates an online configuration database (olc) under the config dn.

It needs to be declared as follows:

# enable on-the-fly configuration (cn=config)
database config
rootdn  "cn=admin,cn=config"
rootpw  test123

access to *
    by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage
    by * none

Initial Password for ldap_entry

Hi! I would like to use datacentred-ldap to provision user accounts within our LDAP directory. Our users are created with an initial password which is subsequently changed by the user. On the next puppet run, however, puppet resets the user's password back to the initial password specified in the ldap_entry. Are there any workaround you can suggest?

CA cert not honored in ldap_entry

When setting up the server, the CA cert can be defined and it configures ldap.conf accordingly, but it is not honored by ldap_entry. (The only workaround is to set self_signed => true, which has security implications.)

According to http://www.rubydoc.info/gems/net-ldap/Net/LDAP the CA certificate could be passed in with tls_options => { :ca_file => "/etc/cafile.pem" }

LDAP provider fails on ruby 1.8.7

Does not define monitor database

The template does not define a monitor database.

Example config section:

# enable server status monitoring (cn=monitor)
database monitor
access to *
        by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read
        by dn.exact="${rootdn}" read
        by * none

Does not generate DB_CONFIG

The bdb database backend requires a DB_CONFIG file to be generated in the actual database directory, declared with the 'directory' directive.

This file defines the sizes of various important buffers, and is required for performance.

database        bdb
suffix          "dc=test,dc=koehntopp,dc=de"
rootdn          "cn=Manager,dc=test,dc=koehntopp,dc=de"
rootpw         cookie

directory       /var/lib/ldap

and in this:

[root@server openldap]# cat /var/lib/ldap/DB_CONFIG
# See the Oracle Berkeley DB documentation
#   <http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html>
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#   <http://www.openldap.org/faq/index.cgi?file=2>
# in particular:
#   <http://www.openldap.org/faq/index.cgi?file=1075>

# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.

# one 0.25 GB cache
set_cachesize 0 268435456 1

# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs

Convert to PDK and use Litmus

Hi,

I tried to get you project up to speed but I could not get the Beaker tests to run.
I was wondering if you would accept a PR that uses the Puppet Devlopment Kit and replaces Beaker with Litmus.
If yes I would like to contribute that.

API Validation

It would be nice to do some type checking on API exposed values to ensure erb templates and puppet DSL operates as intended

Can't connect to the server - SSL config issue?

this is the puppet agent in debug mode. the server is there, the port is bound and listening, the certificates and keys are fine (the syslog shows no complaints), so, where do I start debugging this? (and yes, I know this is very probably an openldap issue and not the puppet module, but I'm hoping somebody bumped into this by now)

Debug: Executing: '/bin/systemctl is-active slapd'
Debug: Executing: '/bin/systemctl is-enabled slapd'
Debug: Connecting to LDAP server ldaps://localhost:389
Error: /Stage[main]/Ob_ldap::Ldap_server/Ldap_entry[dc=dev-ira,dc=own-backup,dc=com]: Could not evaluate: SSL_connect SYSCALL returned=5 errno=0 state=SSLv2/v3 read server hello A

this is on the latest CentOS 7.2.

Does not support multiple database definitions

OpenLDAP Servers can host multiple database definitions, each starting with "database". By default, the server should have the monitor, config and the payload database (the latter using bdb or hdb as a backend).

The server can have any number of payload databases, each with their own bdb/hdb or other backend.

The template and the class infrastructure do not carry this.

Undefined method 'force_encoding'

Following the merge of PR #55, I'm now getting the following error when attempting to use the module on CentOS 6 with Ruby 1.8.7:

Debug: Connecting to LDAP server ldaps://localhost:389
Debug: LDAP Search: {:attributes=>["dc", "objectClass"], :base=>"dc=weareact,dc=net"}
Error: /Stage[main]/Remotepost::Ldap/Ldap_entry[dc=weareact,dc=net]: Could not evaluate: undefined method `force_encoding' for "weareact":String

Release new version to the forge

Unable to login to OpenLDAP on CentOS 7

Hi there,

I've been using this module with great success on CentOS 6 hosts with OpenLDAP 2.4.23.
However upon trying on a CentOS 7 host with OpenLDAP 2.4.39, I get the following error:

Info: Applying configuration version '1413552149'
Debug: Prefetching gem resources for package
Debug: Executing '/bin/gem list --local'
Debug: Prefetching yum resources for package
Debug: Executing '/bin/rpm --version'
Debug: Executing '/bin/rpm -qa --nosignature --nodigest --qf '%{NAME} %|EPOCH?{%{EPOCH}}:{0}| %{VERSION} %{RELEASE} %{ARCH}\n''
Debug: Executing '/bin/systemctl is-active slapd'
Debug: Executing '/bin/systemctl is-enabled slapd'
Debug: Connecting to LDAP server ldaps://localhost:389
Debug: LDAP Search: {:base=>"dc=dt0388,dc=local", :attributes=>["dc", "objectClass"]}
Error: /Stage[main]/Main/Ldap_entry[dc=dt0388,dc=local]: Could not evaluate: LDAP Error 49: Invalid Credentials. Check server log for more info.

This is using the simple manifest here: https://gist.github.com/fatmcgav/05c5f011c10f88d17f05

I get the same error if I try and access OpenLDAP using other tools, such as Apache Directory Studio, so it looks like it's a configuration issue of some sort...

However I've been unable to spot anything obvious. Maybe there's some behavior change between OpenLDAP 2.4.23 and 2.4.39???

Any pointers?

Cheers
Gavin

Import existing schema dump?

Hi,
I would like to import the following schema via Puppet. I think this won't work with your type and provider because it is only for actual entries, not for schemas?