[ovirt-users] LDAP bind DN generation problem

[Mitja Mihelič]

On 18/06/15 14:49, Ondra Machacek wrote:
> On 06/18/2015 02:07 PM, Mitja Mihelič wrote:
>> Hi!
> Hi
>>
>> We just upgaded oVirt from 3.4 to 3.5 and now users cannot select the 
>> LDAP domain on the login screen. Only internal is available.
>> Our LDAP server is actually a 389DS instance and we are using for 
>> authentication in oVirt without Kerberos. The existing setup has 
>> worked since the days of 3.2.
>>
>> When we try to validate the domain, we get
>> [root at brda ~]# engine-manage-domains validate
>> Error: Cannot authenticate user ovirt to domain guest.arnes.si, 
>> details: [LDAP: error code 32 - No Such Object]; nested exception is 
>> javax.naming.AuthenticationException: [LDAP: error code 32 - No Such 
>> Object]
>> Failure while testing domain guest.arnes.si. Details: Cannot 
>> authenticate user to LDAP server.
>>
>> The LDAP log reports
>> [18/Jun/2015:13:52:38 +0200] conn=3 op=0 BIND 
>> dn="uid=ovirt,ou=Peopledc=guest,dc=arnes,dc=si" method=128 version=3
>> As you can see there is a comma missing before "dc=guest,dc=arnes,dc=si".
>>
>> Before the upgrade the bind DN was generated properly as
>> [18/Jun/2015:12:42:45 +0200] conn=10219 op=0 BIND 
>> dn="uid=ovirt,ou=People,dc=arnes,dc=si" method=128 version=3
>
> So what is your search user's DN ?
> Is it:
> dn="uid=ovirt,ou=People,dc=guest,dc=arnes,dc=si"
>
> or
>
> dn="uid=ovirt,ou=People,dc=arnes,dc=si"
>
> Is it possible for you to try if different user works fine?
> Because user with very similar DN works for me just OK.
At the time of posting I did not notice the difference, thanks for the 
spot. The correct DN is dn="uid=ovirt,ou=People,dc=arnes,dc=si".
Although that means that after upgrading to 3.5 the DN for the search 
user is formatted differently when issuing an LDAP bind request.

In the end we noticed that the AAA part of oVirt was reworked in 3.5. We 
deleted the old LDAP domain, that we manually inserted into the database 
back in 3.2 days. Then we added LDAP as an authentication source as per 
AAA instructions, which we found a bit vague. The README on github for 
the AAA extension provided most of the information.

We also found that the format of external_id in the users table had been 
changed from fdfc627c-d875-11e0-90f0-83df133b58cc to 
fdfc627c-d87511e0-90f083df-133b58cc. So naturally users could not log 
in. Instead additional users were created with this new format 
external_id, a namespace with "dc=arnes,dc=si" and a new user_id.
We manually deleted the faux users, updated the external_id to the new 
format and added a namespace entry for existing users.
That worked for us.

Kind regards, Mitja
>
>>
>> This looks like a bug.
>> Is there a quick fix we can do to fix this typo?
>>
>> We are also interested in knowing what is the correct way in 3.5 to 
>> add a domain that uses an LDAP server for its authentication source 
>> without Kerberos.
>
> Please see following links:
> *https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD
> *https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README.profile;hb=HEAD
> *http://www.ovirt.org/Features/AAA
> *https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=tree;f=examples;hb=HEAD
> *https://gerrit.ovirt.org/gitweb?p=ovirt-engine-extension-aaa-ldap.git;a=blob;f=README;hb=HEAD#l6
> *https://github.com/machacekondra/ovirt-engine-kerbldap-migration
>
>>
>> Kind regards, Mitja
>> -- 
>> --
>> Mitja Mihelič
>> ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia
>> tel: +386 1 479 8800, fax: +386 1 479 88 99
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/users
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/users/attachments/20150619/deb0e5a8/attachment-0001.html>