VMware Cloud Community
lch12mc
Contributor
Contributor

Issue when setting VIO3 LDAP to AD with SSL

I have tried to add AD as a LDAP identity source in my VIO3 deployment and got an error when I selected SSL encryption (port 636).

When I switched the encryption to None everything works fine.

Initially I suspect if my AD has not enabled SSL for LDAP but LDAP browser could make a query to my AD through port 636 without issue.

After drilling down to ansible script, I found that when ever the script run to a task "write the LDAP certificate to keystone" no output appeared in the destination directory as specified in the task. As a result the next task "copy the LDAP certificates to keystone and ca-certificates" which trying to copy the output in previous task would failed the deployment.

Anyone has idea on this issue?

Did I missed anything before setting up the LDAP identity source in VIO?

Thanks.

Tags (1)
Reply
0 Kudos
10 Replies
AMINEat
Enthusiast
Enthusiast

I'm in the same situation, did you resolve it ?

Reply
0 Kudos
lch12mc
Contributor
Contributor

No .. have to use no encryption as a work around temporarily ..

I have tried to import a CA signed certificate to VIO though I got the same result.

Reply
0 Kudos
AMINEat
Enthusiast
Enthusiast

I found this :

  • AD/LDAP configuration validates but keystone fails to start.
    During the installation process, the Active Directory/LDAP configuration validates, but the Keystone service fails to start during actual deployment. This issue is caused because the common name of the certificate does not match with the hostname of the LDAP server

but i don't know how to do it

Reply
0 Kudos
zlao
Enthusiast
Enthusiast

Hi,

The server certificates will be picked up when validating the input on the UI.

Could you grep the inventory directory and check what value ldap_certificate was set when you enable SSL?

Regards,

Zhongcheng

Reply
0 Kudos
lch12mc
Contributor
Contributor

Hi,

Which "Inventory" directory are you referring to?

A directory on VIO Manager or controller? And the actual path?

Thanks.

Reply
0 Kudos
AMINEat
Enthusiast
Enthusiast

hi,

you must check your request for LDAP that's the problem ( unique name users : DC=..... , DC=.........)

After that the problem will be resolve

Smiley Wink

Reply
0 Kudos
AndreCampos89
Enthusiast
Enthusiast

Hi,

I'm in the same situation. What do you mean by "check your request for LDAP?" Where exactly must I do that?

Thanks.

Reply
0 Kudos
AndreCampos89
Enthusiast
Enthusiast

Hi, were you able to solve this issue?

I have the same problem. When I deploy with no encryption, it works fine. But using SSL over port 636, the deploy fails.

My ansible log says this:

"2017-03-30 13:28:34,204 p=10290 u=jarvis |  failed: [10.7.206.31] => {"changed": true, "cmd": "for d in '/etc/keystone/ssl/certs' '/usr/local/share/ca-certificates'; do ls $d/vio_*.crt; done", "delta": "0:00:00.017267", "end": "2017-03-30 13:28:34.187163", "rc": 2, "start": "2017-03-30 13:28:34.169896", "warnings": []}

2017-03-30 13:28:34,204 p=10290 u=jarvis |  stderr: ls: cannot access /etc/keystone/ssl/certs/vio_*.crt: No such file or directory

ls: cannot access /usr/local/share/ca-certificates/vio_*.crt: No such file or directory

2017-03-30 13:28:34,205 p=10290 u=jarvis |  ...ignoring

2017-03-30 13:28:36,468 p=10290 u=jarvis |  TASK: [keystone | copy the LDAP certificates to keystone and ca-certificates] ***

2017-03-30 13:28:36,698 p=10290 u=jarvis |  failed: [10.7.206.30] => (item=/etc/keystone/ssl/certs) => {"changed": true, "cmd": "cp /tmp/certs/* \"/etc/keystone/ssl/certs\"", "delta": "0:00:00.016303", "end": "2017-03-30 13:28:36.685051", "item": "/etc/keystone/ssl/certs", "rc": 1, "start": "2017-03-30 13:28:36.668748", "warnings": []}

2017-03-30 13:28:36,699 p=10290 u=jarvis |  stderr: cp: cannot stat ‘/tmp/certs/*’: No such file or directory

2017-03-30 13:28:36,706 p=10290 u=jarvis |  failed: [10.7.206.31] => (item=/etc/keystone/ssl/certs) => {"changed": true, "cmd": "cp /tmp/certs/* \"/etc/keystone/ssl/certs\"", "delta": "0:00:00.017540", "end": "2017-03-30 13:28:36.691601", "item": "/etc/keystone/ssl/certs", "rc": 1, "start": "2017-03-30 13:28:36.674061", "warnings": []}

2017-03-30 13:28:36,707 p=10290 u=jarvis |  stderr: cp: cannot stat ‘/tmp/certs/*’: No such file or directory

2017-03-30 13:28:36,855 p=10290 u=jarvis |  failed: [10.7.206.30] => (item=/usr/local/share/ca-certificates) => {"changed": true, "cmd": "cp /tmp/certs/* \"/usr/local/share/ca-certificates\"", "delta": "0:00:00.016911", "end": "2017-03-30 13:28:36.840453", "item": "/usr/local/share/ca-certificates", "rc": 1, "start": "2017-03-30 13:28:36.823542", "warnings": []}

2017-03-30 13:28:36,855 p=10290 u=jarvis |  stderr: cp: cannot stat ‘/tmp/certs/*’: No such file or directory"

Anybody?

Reply
0 Kudos
lch12mc
Contributor
Contributor

Hi,

The problem still there.

I am now using LDAP without SSL as a temporary workaround.

My Ansible log showing the same as you and I have tried to adjust my LDAP filter but problem persists.

Anyone can help?

Reply
0 Kudos
AMINEat
Enthusiast
Enthusiast

HI,

i was in the same problem beaucause i used very complexe filter.

the solution is : in filter you have write just domain name for exemple DC=Exemple,DC=com

after that you update domain default, you create new project and you add a user for a project and domain default.

  • Determine the IP address of the OMS so you can SSH into it. You can find the IP address of the server in the summary screen of VM named 'management-server'. The IP address should be in the port group that was used for management.
  • SSH into that machine as 'viouser' and use the password that you specified for the 'admin' user when you built VIO.
  • Once logged into the OMS, you will use the OMS as a jump-off point to the two controller VMs. The reason for this is ease of use since the OMS uses password-less SSH to get to all of the Openstack specific VMs. You should be able to simply SSH into one of the controllers by typing in 'ssh controller01'. If that doesn't work, 'cat /etc/hosts' will bring up the list of server names.
  • Once logged into one of the controllers (doesn't matter which one) you need to switch to the root user. The root user has the required files that you need to source into your shell's environment in order to communicate with Keystone. You can switch to the 'root' user from the 'viouser' shell by typing in 'sudo su -' and, if prompted, entering in the password you used for the 'admin' user when you set up VIO.
  • Source the environment variables. There are two files in the root home directory, one is called 'cloudadmin.rc' and the other is 'cloudadmin_v3.rc'. The VIO version we are using is version 3, and that version uses Keystone v3 so we need to source the 'cloudadmin_v3.rc' file. We do that by typing in 'source ~/.cloudadmin_v3.rc' in the root shell.
  • Now that we have sourced our environment, we can begin to issue commands that will communicate with the Openstack APIs.
  • As a test, type in 'openstack user list –domain default' into the CLI. The Openstack client will prompt you for a password, make sure you use the same password that you used for the 'admin' user when you initially setup VIO.
  • The output from the previous step should list out all the users that you have added to the group you specified in the LDAP configuration above. If this list matches what you expect, you can proceed.
  • List out the active projects with 'openstack project list'. Once more with the password.
  • If this is a freshly installed VIO, you will only see the 'service' and 'admin' projects. You do NOT want to grant users direct access to these projects. If needed, create a project with the following command 'openstack project create –domain default –enable <project name>' command. This project will most likely be for your administrator users.
  • Retrieve a list of roles by typing in 'openstack role list'. Openstack will prompt you for a password again.
  • Grant users access to Projects by adding them to one or more of these roles. If this is a vanilla VIO install, you'll probably want to grant access to the admins first. Do this by 'openstack role add --user <user ID> admin'.
  • From here, test logging into the Horizon dashboard using 'default' for the domain and your AD username and password. Once logged in as an admin user, you can manage projects from either Horizon or the CLI.

That's all

Reply
0 Kudos