what we need to test here?

work with OpenLDAP

Here is how Juan Hernandez verified the patch (on fc18)

This are instructions to setup an environment for testing authentication
of ovirt-engine with OpenLDAP. All the instructions are based on
Fedora 18 and assume that the name of the domain is f18.example.com and
that the name of the realm is F18.EXAMPLE.COM.

1. Install the OpenLDAP server and clients:

# yum -y install openldap-{clients,servers}

2. Start and enable the OpenLDAP service:

# systemctl start slapd
# systemctl enable slapd

3. Add the cosine and inetorgperson schemas:

# ldapadd -H ldapi:/// -Y EXTERNAL -f /etc/openldap/schema/cosine.ldif
# ldapadd -H ldapi:/// -Y EXTERNAL -f /etc/openldap/schema/inetorgperson.ldif

4. Add the memberof overlay:

# cat > memberof.ldif <<'.'
dn: cn={0}module,cn=config
objectClass: olcModuleList
cn: {0}module
olcModulePath: /usr/lib64/openldap
olcModuleLoad: {0}memberof.la

dn: olcOverlay={0}memberof,olcDatabase={2}hdb,cn=config
objectClass: olcConfig
objectClass: olcMemberOf
objectClass: olcOverlayConfig
objectClass: top
olcOverlay: {0}memberof
.

# ldapadd -H ldapi:/// -Y EXTERNAL -f overlay.ldif

5. Create a password for the directory administrator (I used example123):

# slappasswd 
New password: 
Re-enter new password: 
{SSHA}0EAIzAxRBMZ1LP/XAhq4q80DLpNpDzr2

6. Change the suffix and the credentians of the directory manager:

# cat > config.ldif <<'.'
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=f18,dc=example,dc=com
-
replace: olcRootDN
olcRootDN: cn=Manager,dc=f18,dc=example,dc=com
-
replace: olcRootPW
olcRootPW: {SSHA}0EAIzAxRBMZ1LP/XAhq4q80DLpNpDzr2
-
.

# ldapmodify -H ldapi:/// -Y EXTERNAL -f config.ldif

7. Create the top level structure of the directory, with a branch for
users and another for groups:

# cat > structure.ldif <<'.'
dn: dc=f18,dc=example,dc=com
objectClass: dcObject
objectClass: organization
dc: f18
o: F18 Example Inc.

dn: ou=Users,dc=f18,dc=example,dc=com
objectClass: organizationalUnit
ou: Users

dn: ou=Groups,dc=f18,dc=example,dc=com
objectClass: organizationalUnit
ou: Groups
.

# ldapadd -H ldapi:/// -D 'cn=Manager,dc=f18,dc=example,dc=com' -x -W -f structure.ldif

8. Create some users:

# cat > users.ldif <<'.'
dn: uid=user0,ou=Users,dc=f18,dc=example,dc=com
objectclass: inetOrgPerson
objectclass: uidObject
uid: user0
cn: User2
givenName: User
title: User
mail: user0.com
sn: 0

dn: uid=user1,ou=Users,dc=f18,dc=example,dc=com
objectclass: inetOrgPerson
objectclass: uidObject
uid: user1
cn: User1
givenName: User
title: User
mail: user1.com
sn: 1
.

Note that the users don't need to have a memberof attribute, as this
will be calculated and assigned by the memberof overlay when the group
is created or modified.

# ldapadd -H ldapi:/// -D 'cn=Manager,dc=f18,dc=example,dc=com' -x -W -f users.ldif

9. Create some groups:

# cat > groups.ldif <<'.'
dn: cn=Group0,ou=Groups,dc=f18,dc=example,dc=com
objectclass: groupOfNames
cn: Group0
member: uid=user0,ou=Users,dc=f18,dc=example,dc=com
member: uid=user1,ou=Users,dc=f18,dc=example,dc=com
.

# ldapadd -H ldapi:/// -D 'cn=Manager,dc=f18,dc=example,dc=com' -x -W -f groups.ldif

Once this is done the directory should return the memberOf attributes
when quering users:

# ldapsearch -H ldapi:/// -b 'dc=f18,dc=example,dc=com' -x '(uid=user0)' memberOf -LLL
dn: uid=user0,ou=Users,dc=f18,dc=example,dc=com
memberOf: cn=Group0,ou=Groups,dc=f18,dc=example,dc=com

10. Install the kerberos server packages:

# yum -y install krb5-{workstation,server}

11. Adjust the /etc/krb5.conf file, should be something like this:

[logging]
 default = FILE:/var/log/krb5libs.log
 kdc = FILE:/var/log/krb5kdc.log
 admin_server = FILE:/var/log/kadmind.log

[libdefaults]
 dns_lookup_realm = false
 ticket_lifetime = 24h
 renew_lifetime = 7d
 forwardable = true
 default_realm = F18.EXAMPLE.COM

[realms]
 F18.EXAMPLE.COM = {
  kdc = f18.example.com
  admin_server = f18.example.com
 }

[domain_realm]
 .f18.example.com = F18.EXAMPLE.COM
 f18.example.com = F18.EXAMPLE.COM

11. Create the kerberos database:

# cd /var/kerberos/krb5kdc
# kdb5_util create -s

Modify the /var/kerberos/krb5kdc.conf and
/var/kerberos/krb5kdc/kadm5.acl and replace EXAMPLE.COM with your realm
name.

12. Create the a kerberos admin user, for root, for example:

# kadmin.local
Authenticating as principal root/admin.COM with password.
kadmin.local:  add_principal root/admin
WARNING: no policy specified for root/admin.COM; defaulting to no policy
Enter password for principal "root/admin.COM": 
Re-enter password for principal "root/admin.COM": 
Principal "root/admin.COM" created.

13. Start and enable the krb5kdc and kadmin services:

# systemctl start krb5kdc
# systemctl enable krb5kdc
# systemctl start kadmin
# systemctl enable kadmin

14. Check that you can login with the admin user:

# kadmin
Authenticating as principal root/admin.COM with password.
Password for root/admin.COM: 
kadmin:  list_principals
K/M.COM
kadmin/admin.COM

15. Add the users to the kerberos database and verify that they can login:

# kadmin
kadmin: add_principal user0
kadmin: add_principal user1

# kinit user0
Password for user0.COM: 

16. Create a password for the LDAP server and extract it to a keytab
file with read permissions for the user running the LDAP server (usually
the "ldap" user):

# kadmin
kadmin:  add_principal -randkey ldap/f18.example.com
kadmin:  ktadd -keytab /etc/openldap/ldap.keytab

# chgrp ldap /etc/openldap/ldap.keytab
# chmod 640 /etc/openldap/ldap.keytab

17. Make sure that the LDAP server is using the keytab file created in
the previous step, adding the KRB5_KTNAME to the /etc/sysconfig/slapd
file (it is already there, just uncomment it):

KRB5_KTNAME="FILE:/etc/openldap/ldap.keytab"

18. Test that users can do LDAP queries using the kerberos credentials:

# kinit user0
# Password for user0.COM:

# ldapsearch -H ldap://f18.example.com -Y GSSAPI -b 'dc=f18,dc=example,dc=com' '(uid=user0)' memberOf

The query should succeed without asking any password.

19. Add DNS SRV records for the LDAP and Kerberos servers, something
like this in the zone file:

_kerberos._tcp.f18.example.com. SRV 0 100 88 f18.example.com.
_ldap._tcp.f18.example.com. SRV 0 100 389 f18.example.com.

20. Register the domain with engine-manage-domains:

# engine-manage-domains -action=add -domain=f18.example.com -provider=OpenLDAP -user=user0 -interactive

Known issues and limitations -
1. Kerberos must be installed and co-hosted with the openldap server.
2. Step 3 and 4 (installation of the ldif files) in comment #4 must be performed.
3. The fields we use to query for groups and users are:
  uid for user name.
  groupOfNames for groups.
4. The fields we use to map returned results to engine entities are:

entryuuid , memberof for group
entryuuid, givenname, title, mail, sn, memberof, uid - for user

Please pay attention to 3 and 4, as it is possible to modify the schema - the mentioned attributes are mandatory by rhev-m.

This bug is currently attached to errata RHEA-2013:15231. If this change is not to be documented in the text for this errata please either remove it from the errata, set the requires_doc_text flag to minus (-), or leave a "Doc Text" value of "--no tech note required" if you do not have permission to alter the flag.

Otherwise to aid in the development of relevant and accurate release documentation, please fill out the "Doc Text" field above with these four (4) pieces of information:

* Cause: What actions or circumstances cause this bug to present.
* Consequence: What happens when the bug presents.
* Fix: What was done to fix the bug.
* Result: What now happens when the actions or circumstances above occur. (NB: this is not the same as 'the bug doesn't present anymore')

Once filled out, please set the "Doc Type" field to the appropriate value for the type of change made and submit your edits to the bug.

For further details on the Cause, Consequence, Fix, Result format please refer to:

https://bugzilla.redhat.com/page.cgi?id=fields.html#cf_release_notes 

Thanks in advance.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHSA-2014-0038.html