Github user justinleet commented on the issue:
https://github.com/apache/metron/pull/1246
To run this up against an OpenLDAP instance, make sure Docker is installed
and running, we'll be using https://github.com/osixia/docker-openldap.
## OpenLDAP setup
### Setup Users
There is an LDIF file we'll load into this container at
https://gist.github.com/justinleet/b8f0350f27b32d4d705f45b9c1ba8c6e
It'll set up an admin user (admin), a regular user (sam), and a user
without a role (tom).
We'll want to save that file somewhere. I'll be using `/tmp/ldif/test.ldif`
in this example.
### Run the container.
Run the container with
```
docker run \
-p 33389:389 \
--name metron_ldap_demo \
--env LDAP_ORGANISATION=Hadoop \
--env LDAP_DOMAIN=apache.org \
--env LDAP_TLS_FALSE \
--volume
/tmp/ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom \
osixia/openldap:1.2.2 --copy-service
```
This does a few things
* Exposes the LDAP port (389) on the host's port 33389. The host port is
arbitrarily chosen
* Makes sure we have the appropriate org and domain for the users
* Makes sure we aren't using TLS. There are options for in the configs, but
I wasn't able to get the certs lined up properly (although I was able to see
both sides connecting, then failing).
* Makes the test.ldif available in the right place
* --copy-service needs to be provided for some reason or another. I didn't
really dig into why, it's just part of the documentation
This will spin up the OpenLDAP instance and let it run.
## Ambari LDAP setup
From the command line of the vagrant machine, run
`netstat -rn | grep "^0.0.0.0 " | cut -d " " -f10`. It should return the
address it can use to address the host machine. E.g. for me it was "10.0.2.2".
This is needed to be able to hit the Docker container from inside the Vagrant
VM.
A new tab is added "Security" with the various LDAP related properties.
In here, we'll went to set
* LDAP URL = ldaps://10.0.2.2:33636
* Make sure to fill in the IP from above!
* Bind User = cn=admin,dc=apache,dc=org
* Bind User Password = admin
The other fields are set already set to defaults to match the modified Knox
users-ldif provided, so nothing should change.
These values are
* User dn pattern = uid={0},ou=people,dc=hadoop,dc=apache,dc=org
* User password attribute = userPassword
* Group Search Base = ou=people,dc=hadoop,dc=apache,dc=org
* User Search Filter is empty
* Group Search Base = ou=groups,dc=hadoop,dc=apache,dc=org
* Group Search Filter = member={0}
* LDAP group role attribute = cn
Additionally, we also need to tell REST we will be using LDAP.
In the REST tab
* Active Spring profiles = dev,ldap
Restart Metron REST
## Testing LDAP
Go to the Swagger UI. You should meet a login screen. There are 3 users
that should work in LDAP
* admin/admin-password
* {SSHA} format in LDAP
* sam/sam-password
* Plaintext format in LDAP
* tom/tom-password
* Plaintext format in LDAP
In Swagger, the UserController has another endpoint: "/whoami/roles".
Using this endpoint should return the roles for each user
* admin has ROLE_ADMIN
* sam has ROLE_USER
* tom has no roles.
These ROLES can be altered by changing the LDAP groups each user belongs
to, e.g. see
https://gist.github.com/justinleet/b8f0350f27b32d4d705f45b9c1ba8c6e#file-test-ldif-L95
for how "sam" is added to the "user" group.
This same login should also apply to the Alerts UI and Management UI.
Login via JDBC should also not be able to happen (e.g. user/password login
should no longer work).
## SSL Note
If anyone is brave enough to try, or wants to help me, you can run the
container with
```
docker run \
-p 33389:389 \
-p 33636:636 \
--name metron_ldap_demo \
--env LDAP_ORGANISATION=Hadoop \
--env LDAP_DOMAIN=apache.org \
--env LDAP_TLS_VERIFY_CLIENT=try \
--volume
/tmp/ldif:/container/service/slapd/assets/config/bootstrap/ldif/custom \
osixia/openldap:1.2.2 --copy-service
```
This will setup the appropriate SSL port and map it to 33636.
`LDAP_TLS_VERIFY_CLIENT=try ` seems necessary to be able to connect from
outside the container.
In the Vagrant box, it's necessary to import the appropriate certificates
to the truststore to be used. Generally this can be done with
```
keytool -importcert -keystore <keystore file> -alias <unique alias>
-storepass <password> -file <certificate file>
```
Additionally, in the configs, there are settings for "LDAP Truststore" and
"LDAP Truststore Password". These should be set to match the keystore you
imported certificates to.
I attempted to pull the certs out of the container itself, as well as to use
```
echo -n | openssl s_client -showcerts -connect 10.0.2.2:33636 | sed -ne
'/-BEGIN CERTIFICATE-/,/-END CERTIFICATE-/p' >> ldapserver.pem
```
in order to get certs. Neither seemed to make SSL happy, I can only assume
my sacrificial offerings have been lacking lately.
The log error in Vagrant:
```
Warning: no suitable certificate found - continuing without client
authentication
*** Certificate chain
```
while the container gives:
```
5bd1d66c conn=1011 fd=13 ACCEPT from IP=172.17.0.1:35946 (IP=0.0.0.0:636)
TLS: can't accept: No certificate was found..
5bd1d66c conn=1011 fd=13 closed (TLS negotiation failure)
```
Given that this is a negotiation failure, rather than an inability to make
it to the handshake, I'm kind of inclined to not troubleshoot it too much here.
---
