Cookbook to deploy a LDAP server (389 Directory Server) #115

greg · 2019-11-22T12:54:11Z

greg commented

2019-11-22 12:54:11 +00:00

Initial version of the kosmos-dirsrv cookbook

It sets up 389 Directory Server, including a TLS cert acquired using Let's Encrypt in production (that requires ldap.kosmos.org pointing to the server's IP).

Extracted from #112 (I have removed the commits adding LDAP support to our services, this will be a separate PR)

Initial version of the kosmos-dirsrv cookbook It sets up 389 Directory Server, including a TLS cert acquired using Let's Encrypt in production (that requires ldap.kosmos.org pointing to the server's IP). Extracted from #112 (I have removed the commits adding LDAP support to our services, this will be a separate PR)

raucao commented

2019-11-23 15:47:25 +00:00

LGTM. A few questions:

Has it been deployed to the actual production domain yet?
If not, which machine should we run this on?
Have you thought about replication yet? I.e. ldap2.kosmos.org for example.

LGTM. A few questions: 1. Has it been deployed to the actual production domain yet? 2. If not, which machine should we run this on? 3. Have you thought about replication yet? I.e. `ldap2.kosmos.org` for example.

greg commented

2019-11-27 16:40:50 +00:00

I haven't deployed it yet. I think we could start by running it on barnard, dirsrv doesn't take a lot of RAM (each instance takes around 30MB in my VM)

I got replication to work in my VM by using the Red Hat docs, I'm going to turn this into recipes, that's a lot of different LDIF files

I haven't deployed it yet. I think we could start by running it on barnard, dirsrv doesn't take a lot of RAM (each instance takes around 30MB in my VM) I got replication to work in my VM by using [the Red Hat docs](https://access.redhat.com/documentation/en-us/red_hat_directory_server/10/html/administration_guide/managing_replication), I'm going to turn this into recipes, that's a lot of different LDIF files

raucao commented

2019-11-27 18:31:35 +00:00

I haven’t deployed it yet. I think we could start by running it on barnard, dirsrv doesn’t take a lot of RAM (each instance takes around 30MB in my VM)

Ok, sounds good.

I got replication to work in my VM by using the Red Hat docs, I’m going to turn this into recipes, that’s a lot of different LDIF files

Why would we need this from the start? Is it really that important? It was just a general question to learn if it's on the radar and if it's possible at all.

> I haven’t deployed it yet. I think we could start by running it on barnard, dirsrv doesn’t take a lot of RAM (each instance takes around 30MB in my VM) Ok, sounds good. > I got replication to work in my VM by using the Red Hat docs, I’m going to turn this into recipes, that’s a lot of different LDIF files Why would we need this from the start? Is it really that important? It was just a general question to learn if it's on the radar and if it's possible at all.

greg changed title from ~~Cookbook to deploy a LDAP server (389 Directory Server)~~ to WIP: Cookbook to deploy a LDAP server (389 Directory Server)

2019-12-04 16:48:08 +00:00

greg commented

2019-12-04 16:49:10 +00:00

I ran into a couple issues (see the commits from today), but this is now running on barnard as ldap.kosmos.org, with a TLS cert.

Example usage:

$ ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v
ldap_initialize( ldaps://ldap.kosmos.org:636/??base )
filter: (objectclass=*)
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=kosmos,dc=org> with scope subtree
# filter: (objectclass=*)
# requesting: ALL
#

# users, kosmos.org
dn: ou=users,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalUnit
ou: users

# search result
search: 2
result: 0 Success

# numResponses: 2
# numEntries: 1

I have just discovered this is missing the certbot hooks for cert renewal, I'm pushing that and then we can merge this one

I ran into a couple issues (see the commits from today), but this is now running on barnard as ldap.kosmos.org, with a TLS cert. Example usage: ``` $ ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v ldap_initialize( ldaps://ldap.kosmos.org:636/??base ) filter: (objectclass=*) requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <ou=users,dc=kosmos,dc=org> with scope subtree # filter: (objectclass=*) # requesting: ALL # # users, kosmos.org dn: ou=users,dc=kosmos,dc=org objectClass: top objectClass: organizationalUnit ou: users # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 ``` I have just discovered this is missing the certbot hooks for cert renewal, I'm pushing that and then we can merge this one

greg changed title from ~~WIP: Cookbook to deploy a LDAP server (389 Directory Server)~~ to Cookbook to deploy a LDAP server (389 Directory Server)

2019-12-05 14:48:08 +00:00

greg commented

2019-12-05 14:55:17 +00:00

This should be good to merge now

raucao commented

2019-12-06 08:02:13 +00:00

ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v

I get the same result without having a password stored in that variable. Is that intended?

Also, where can I find the documentation for how it's set up in terms of admin accounts, where to find the passwords, etc.? I did a quick search through the changed files, but there doesn't seem to be anything in doc/.

> ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v I get the same result without having a password stored in that variable. Is that intended? Also, where can I find the documentation for how it's set up in terms of admin accounts, where to find the passwords, etc.? I did a quick search through the changed files, but there doesn't seem to be anything in `doc/`.

greg commented

2019-12-06 09:56:38 +00:00

I get the same result without having a password stored in that variable. Is that intended?

The same result, meaning successful search results without a password? I can't reproduce that

Also, where can I find the documentation for how it’s set up in terms of admin accounts, where to find the passwords, etc.? I did a quick search through the changed files, but there doesn’t seem to be anything in doc/.

I have added doc/ldap.md with the instructions to get the admin password from the encrypted data bag

> I get the same result without having a password stored in that variable. Is that intended? The same result, meaning successful search results without a password? I can't reproduce that > Also, where can I find the documentation for how it’s set up in terms of admin accounts, where to find the passwords, etc.? I did a quick search through the changed files, but there doesn’t seem to be anything in doc/. I have added `doc/ldap.md` with the instructions to get the admin password from the encrypted data bag

raucao commented

2019-12-07 11:48:18 +00:00

The same result, meaning successful search results without a password? I can’t reproduce that

Yes, just the exact same output that you posted with the 2 search results. I used the empty $password variable, by just copying the bash command without defining $password first.

> The same result, meaning successful search results without a password? I can’t reproduce that Yes, just the exact same output that you posted with the 2 search results. I used the empty $password variable, by just copying the bash command without defining $password first.

raucao commented

2019-12-07 11:49:54 +00:00

I have added doc/ldap.md with the instructions to get the admin password from the encrypted data bag

> I have added doc/ldap.md with the instructions to get the admin password from the encrypted data bag

thumbs-up-asian-guy-gif.gif

480 KiB

raucao commented

2019-12-07 11:50:49 +00:00

Get you some easy kredits for updating this one, too: https://wiki.kosmos.org/Infrastructure

greg commented

2019-12-10 14:36:59 +00:00

@raucao I don't understand how you can get search results without the correct admin password. With an incorrect password I get ldap_bind: Invalid credentials (49) and with an empty one:

ldap_bind: Server is unwilling to perform (53)
        additional info: Unauthenticated binds are not allowed

Edit: I updated the Infra wiki page

@raucao I don't understand how you can get search results without the correct admin password. With an incorrect password I get `ldap_bind: Invalid credentials (49)` and with an empty one: ``` ldap_bind: Server is unwilling to perform (53) additional info: Unauthenticated binds are not allowed ``` Edit: I updated the Infra wiki page

raucao commented

2019-12-10 14:52:58 +00:00

I cannot tell you how it's possible. Only that it happened exactly as I described. I never looked up the password or copied it anywhere.

raucao commented

2019-12-19 11:54:38 +00:00

I just double-checked, even though I was certain before. I can still do this by just SSHing into barnard, and without doing anything else, running ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v will yield the result almost exactly as posted in the example:

basti@barnard:~$ echo $password

basti@barnard:~$ ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v
ldap_initialize( ldaps://ldap.kosmos.org:636/??base )
filter: cn=Directory Manager
requesting: All userApplication attributes
# extended LDIF
#
# LDAPv3
# base <ou=users,dc=kosmos,dc=org> with scope subtree
# filter: cn=Directory Manager
# requesting: ALL
#

# search result
search: 2
result: 0 Success

# numResponses: 1

I just double-checked, even though I was certain before. I can still do this by just SSHing into barnard, and without doing anything else, running `ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v` will yield the result almost exactly as posted in the example: ``` basti@barnard:~$ echo $password basti@barnard:~$ ldapsearch -x -w $password -D 'cn=Directory Manager' -b "ou=users,dc=kosmos,dc=org" -H "ldaps://ldap.kosmos.org" -v ldap_initialize( ldaps://ldap.kosmos.org:636/??base ) filter: cn=Directory Manager requesting: All userApplication attributes # extended LDIF # # LDAPv3 # base <ou=users,dc=kosmos,dc=org> with scope subtree # filter: cn=Directory Manager # requesting: ALL # # search result search: 2 result: 0 Success # numResponses: 1 ```

greg commented

2019-12-19 15:49:34 +00:00

Thanks, I can reproduce that on barnard. The search does not return actual results with that empty password variable, but it is successful, unlike with an empty/wrong password, or without a -w switch. It does not look like it is a problem since no results are returned on local requests without the correct password

This appears to happen because the server is running on localhost, with an empty password variable from another server the search isn't successful as on barnard.

kare@barnard:~$ host ldap.kosmos.org
ldap.kosmos.org is an alias for barnard.kosmos.org.
barnard.kosmos.org has address 127.0.1.1

Thanks, I can reproduce that on barnard. The search does not return actual results with that empty password variable, but it is successful, unlike with an empty/wrong password, or without a `-w` switch. It does not look like it is a problem since no results are returned on local requests without the correct password This appears to happen because the server is running on localhost, with an empty password variable from another server the search isn't successful as on barnard. ``` kare@barnard:~$ host ldap.kosmos.org ldap.kosmos.org is an alias for barnard.kosmos.org. barnard.kosmos.org has address 127.0.1.1 ```

raucao commented

2019-12-19 20:44:25 +00:00

It says "search result" and then shows some numbers. Running the same command with an actual password also doesn't yield "actual results" for me. Are you referring to different commands?

greg commented

2019-12-19 21:55:23 +00:00

By actual results I mean this part:

# users, kosmos.org
dn: ou=users,dc=kosmos,dc=org
objectClass: top
objectClass: organizationalUnit
ou: users

By actual results I mean this part: ```ldif # users, kosmos.org dn: ou=users,dc=kosmos,dc=org objectClass: top objectClass: organizationalUnit ou: users ```

raucao commented

2019-12-20 09:20:41 +00:00

I still don't see what is the actual result in that. But OK.

I just want to make certain that we don't overlook a security issue there, and that people with shell access cannot randomly access all user data.

I still don't see what is the actual result in that. But OK. I just want to make certain that we don't overlook a security issue there, and that people with shell access cannot randomly access all user data.

greg commented

2019-12-20 15:35:28 +00:00

I got it, passing the empty unquoted variable as a password is the same as doing this:

$ ldapsearch -x -b "ou=users,dc=kosmos,dc=org" -H "ldap://ldap.kosmos.org" -v

This is called Anonymous Bind (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/configuring-special-binds.html#disabling-anonymous-binds). We can set nsslapd-allow-anonymous-access: off to disable it.

I got it, passing the empty unquoted variable as a password is the same as doing this: ``` $ ldapsearch -x -b "ou=users,dc=kosmos,dc=org" -H "ldap://ldap.kosmos.org" -v ``` This is called Anonymous Bind (https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/configuring-special-binds.html#disabling-anonymous-binds). We can set `nsslapd-allow-anonymous-access: off` to disable it.

greg commented

2019-12-20 15:45:35 +00:00

I have set nsslapd-allow-anonymous-access: off on barnard, pushing the code changes

I have set `nsslapd-allow-anonymous-access: off` on barnard, pushing the code changes

raucao commented

2019-12-21 09:56:59 +00:00

That looks much better. 👍

That looks much better. :+1:

raucao approved these changes 2019-12-21 09:57:45 +00:00

raucao left a comment

I think we can merge it now.

greg closed this pull request