LDAP authentication working but with "some weirdness"

Community Support
1

Hello,

we are currently doing a POC for a directory service in our company and therefore we are also testing how to use LDAP authentication in our OpenNebula 5.0.2 setup.

Following the documentation at LDAP authentication setup in Opennebula finally worked, but I think there is a lack of documentation when using “pure” (Open)LDAP. The :user variable has to be a full bind dn to work like:

uid=ldapbind-one,cn=users,dc=example,dc=com

After taking this hurdle, authentication works nice. Doing some tests we found out that in the GUI you are still able to “change” the password - although this is ignored. But even worth, doing this the password is stored in cleartext:

   <USER>
  <ID>2</ID>
  <GID>1</GID>
  <GROUPS>
    <ID>1</ID>
  </GROUPS>
  <GNAME>users</GNAME>
  <NAME>anku</NAME>
  <PASSWORD><![CDATA[test]]></PASSWORD>
  <AUTH_DRIVER><![CDATA[ldap]]></AUTH_DRIVER>
  <ENABLED>1</ENABLED>
  <LOGIN_TOKEN/>
  <TEMPLATE>
    <TOKEN_PASSWORD><![CDATA[3b9727f8a8be6381cb8b0fefe9a6863cd8a52aab]]></TOKEN_PASSWORD>
  </TEMPLATE>
  <DATASTORE_QUOTA/>
  <NETWORK_QUOTA/>
  <VM_QUOTA/>
  <IMAGE_QUOTA/>
  <DEFAULT_USER_QUOTAS>
    <DATASTORE_QUOTA/>
    <NETWORK_QUOTA/>
    <VM_QUOTA/>
    <IMAGE_QUOTA/>
  </DEFAULT_USER_QUOTAS>
</USER>

I expect this is not the wanted behavior … known bug?

Regards,
Andreas

2

When using LDAP the driver can create the users for you (it’ll store the
full dn as a reference). In any case the password is not stored in the DB
for ldap, so there is no need to hash it, just leave a ‘-’ there.

The actual password is either stored in a secret file ($ONE_AUTH) or used
to generate a login token.