Ovirt Simple LDAP AAA

I recently implemented simple ldap to make things easier to manage in oVirt, and allowing people to self register. I will give a quick run down of how this is accomplished in oVirt 3.5.

All commands and file reside on the engine machine. commands are in bold

All of the example configs are located on the engine after installing

yum install ovirt-engine-extension-aaa-ldap

Then copy the examples from

cp /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/extensions.d/*  /etc/ovirt-engine/extensions.d/

*NOTE* The names of the extension files in the extensions.d folder are relevant to you only, what matters is inside the file. I will try my best to explain them.

domain1-authn.properties

ovirt.engine.extension.name = cloudspin-authn
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthnExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authn
ovirt.engine.aaa.authn.profile.name = cloudspin
ovirt.engine.aaa.authn.authz.plugin = cloudspin-auth
config.profile.file.1 = /etc/ovirt-engine/aaa/ldap1.properties

The bolded lines are the important ones.

ovirt.engine.extension.name = cloudspin-authn – The NAME this extension that gets registered to the Engine

ovirt.engine.aaa.authn.profile.name = cloudspin – The name  you want everyone to see on the login screen

ovirt.engine.aaa.authn.authz.plugin = cloudspin-auth –  The name of the extension in the domain1-authz.properties

config.profile.file.1 = /etc/ovirt-engine/aaa/ldap1.properties – The FULL path of the ldap server config file

Now configure

domain1-authz.properties

ovirt.engine.extension.name = cloudspin-auth
ovirt.engine.extension.bindings.method = jbossmodule
ovirt.engine.extension.binding.jbossmodule.module = org.ovirt.engine-extensions.aaa.ldap
ovirt.engine.extension.binding.jbossmodule.class = org.ovirt.engineextensions.aaa.ldap.AuthzExtension
ovirt.engine.extension.provides = org.ovirt.engine.api.extensions.aaa.Authz
config.profile.file.1 = /etc/ovirt-engine/aaa/ldap1.properties

The bolded lines are the important ones

ovirt.engine.extension.name = cloudspin-auth – The NAME of this extension that gets registered to the Engine

config.profile.file.1 = /etc/ovirt-engine/aaa/ldap1.properties – The FULL path of the ldap server config file

 

Now your extensions should be configured. Once again, don’t get hung up on the file names, they really only mean something to you. Maybe someone that knows more than me can shed some light on this??

From Alon at RedHat : Indeed the file names are not important as long as the extension is .properties the files will be read.

Moving on to the LDAP Server config file

cp /usr/share/ovirt-engine-extension-aaa-ldap/examples/simple/aaa/ldap1.properties /etc/ovirt-engine/aaa/

 

#
# Select one – Uncomment what you are using. and comment or delete what you are not.
#
include = <openldap.properties>
#include = <389ds.properties>
#include = <rhds.properties>
#include = <ipa.properties>
#include = <iplanet.properties>
#include = <rfc2307.properties>

#
# Server
#
vars.server = ldap1.company.com –  Important to note, that if you use an IP Address here you may have TLS problems, and once again I am no pro, but I had problems trying to get TLS and IP addresses to play nice

From Alon at RedHat: Indeed, the certificate should contain ip address in subject or subject alternate name in order to ip to be usable in tls, this is not specific to this implementation.

This is only if you are using an IP ADDRESS for the vars.server variable. If you are using a hostname, or fqdn your cert needs to contain the name you use. Are you confused, I sure am… But that’s the way it works 🙂

#
# Search user and its password.
#
vars.user = uid=search,cn=users,cn=accounts,dc=company,dc=com                                     >  These two lines are your bind DN if you ldap server requires binding.
vars.password = 123456                                                                                                                                        >

pool.default.serverset.single.server = ${global:vars.server}
pool.default.auth.simple.bindDN = ${global:vars.user}
pool.default.auth.simple.password = ${global:vars.password}

pool.default.socketfactory.type = java   –  Add this to use your /etc/hosts file

Add the below to enable TLS

DO NOT ADD THIS TO START. GET YOUR LDAP WORKING FIRST 🙂

pool.default.ssl.startTLS = true
pool.default.ssl.truststore.file = ${local:_basedir}/${global:vars.server}.jks
pool.default.ssl.truststore.password = ***********            

Now we need to create the .jks file this line is referencing – pool.default.ssl.truststore.file = ${local:_basedir}/${global:vars.server}.jks

 

Get your CA cert from the ldap server and copy it to the engine in any manner you wish

I like to have many terminals open and use the copy and paste method

cat /etc/pki/tls/cacerts/ldapCA.pem – This is done on the LDAP machine or wherever your CA resides

nano ca.pem – This is done on your engine, and you paste the above output into this file

The you will create a .jks or keystore file

keytool -importcert -noprompt -trustcacerts -alias myrootca  -file ca.pem -keystore myrootca.jks -storepass yourstorepasswordhere

 

As you can see from the above input you are creating a java keystore file called myrootca.jks – Now you need to copy this file to /etc/ovirt-engine/aaa/

For security reasons I cannot devulge the names of my files, but I can tell you that it is important. The engine logs will tell you the file name that they are looking for when setting up ldap, or you can go another way an manually tell the engine what file to look for.

pool.default.ssl.truststore.file = ${local:_basedir}/${global:vars.server}.jks

${local:_basedir} = my current directory which in this case is /etc/ovirt-engine/aaa

${global:vars.server} = vars.server = ldap1.company.com This was the variable that was previously declared.

Any questions ?

Happy LDAPing

 

Donny D

Leave a comment