LDAP Authentication using Apache DS 1.5.7

[bgrieder]

Hello,

We are trying to set-up LDAP authentication to an Apache DS 1.5.7 (from Proxmox VE 2.1).

Authentication fails (see trace below) and we seem to have 2 problems

• Proxmox VE is attempting a search request without binding to an user.
• The search request is systematically looking for an attribute 'dn' that does not exist on our entries.

Did anyone get authentication working on Apache DS before ?
Can we get it to bind to an user ?
What sort of configuration do wee need on the DS ? Anonymous access ?

Thank you for helping us sort this out.

[14:09:45] DEBUG [org.apache.directory.shared.ldap.codec.LdapDecoder] - Decoded LdapMessage :     Search Request
        Base Object : 'ou=proxmox,ou=****,ou=****,o=****'
        Scope : whole subtree
        Deref Aliases : deref Finding Base Obj
        Size Limit : no limit
        Time Limit : no limit
        Types Only : false
        Filter : '(uid=vmadmin)'
        Attributes : dn

[14:09:45] WARN [org.apache.directory.server.core.interceptor.context.SearchingOperationContext] - Requested attribute dn does not exist in the schema, it will be ignored
[14:09:45] ERROR [org.apache.directory.server.core.authn.AuthenticationInterceptor] - ERR_5 Attempted operation SEARCH_REQUEST by unauthenticated caller.

 

[udo]

Hello,

We are trying to set-up LDAP authentication to an Apache DS 1.5.7 (from Proxmox VE 2.1).

Authentication fails (see trace below) and we seem to have 2 problems

• Proxmox VE is attempting a search request without binding to an user.
• The search request is systematically looking for an attribute 'dn' that does not exist on our entries.

Did anyone get authentication working on Apache DS before ?
Can we get it to bind to an user ?
What sort of configuration do wee need on the DS ? Anonymous access ?

Thank you for helping us sort this out.

[14:09:45] DEBUG [org.apache.directory.shared.ldap.codec.LdapDecoder] - Decoded LdapMessage :     Search Request
        Base Object : 'ou=proxmox,ou=****,ou=****,o=****'
        Scope : whole subtree
        Deref Aliases : deref Finding Base Obj
        Size Limit : no limit
        Time Limit : no limit
        Types Only : false
        Filter : '(uid=vmadmin)'
        Attributes : dn

[14:09:45] WARN [org.apache.directory.server.core.interceptor.context.SearchingOperationContext] - Requested attribute dn does not exist in the schema, it will be ignored
[14:09:45] ERROR [org.apache.directory.server.core.authn.AuthenticationInterceptor] - ERR_5 Attempted operation SEARCH_REQUEST by unauthenticated caller.

Hi,
sorry I don't know the Apache DS.
AFAIK pve don't use anonymous access but use the user/password to access the ldap-server. How looks your /etc/pve/domains.cfg?
with gosa it's looks something like this:

ldap: ldap
        base_dn dc=company,dc=com
        comment gosa
        default
        secure
        server1 172.20.1.10
        server2 172.20.1.11
        user_attr uid

And you must define the User again in the pve-gui - the ldap-connection is only to verify the password.

Udo

 

[dietmar]

We never really tested Apache DS, sorry. Each LDAP server behaves slightly different, so someone needs to adopt the code that for Apache DS.

 

[bgrieder]

We never really tested Apache DS, sorry. Each LDAP server behaves slightly different, so someone needs to adopt the code that for Apache DS.

Thank you for your reply.

Is there any detailed documentation available on the content of the /etc/pve/domains.cfg ?

b.

 

[dietmar]

Is there any detailed documentation available on the content of the /etc/pve/domains.cfg ?

https://git.proxmox.com/?p=pve-acce...c229775e32ea3458e4d34c9aa5b2c8f732017;hb=HEAD

 

[dietmar]

Maybe that server is AD compatible? Already tried using the AD type?

 

[gracinet]

Hi, sorry if this is a bit old, but I have exactly the same problem on our OpenLDAP server.

I think the original poster is right, Proxmox' login process does an anonymous search before binding as the user (to find the user, obviously).
In our case, no anonymous search is allowed on the LDAP.

Code extract from the current version of the above GitHub link:

 314     my $ldap = Net::LDAP->new($conn_string, verify => 'none') || die "$@\n";
 315     my $search = $entry->{user_attr} . "=" . $userid;
 316     my $result = $ldap->search( base    => "$entry->{base_dn}",
 317                                 scope   => "sub",
 318                                 filter  => "$search",
 319                                 attrs   => ['dn']
 320                                 );
 321     die "no entries returned\n" if !$result->entries;
 322     my @entries = $result->entries;
 323     my $res = $ldap->bind($entries[0]->dn, password => $password);

While I don't speak Perl, it's rather obvious that no bind is done before the search.
Searching before the bind is very common in web applications LDAP logic, but it's also a very common need to bind as a dedicated user to do that user search, because directories tend to be tight-controlled.

I've even witnessed enterprise directories in which the only thing an employee is allowed to do on her entry is to bind, not even read her own details. Granted, that's maybe not the target audience, here.

I'd be glad to propose an improvement and contribute it on GitHub, but I really can't (Perl again). The best I could would be to patch this precise part, and that would not be enough (UI, optionnality…)

Now, my practical question would be:

is there a way to customize this piece of code in a not-too-dirty way, that is, living accross updates while there's no real conflict ?

I've been using Proxmox and OpenVz since less than a month, and I really appreciate it. Thank you for that.

PS: Retrieving the DN as an attribute is also probably not standard LDAP, I can try that against OpenLDAP if that helps anyone.

 

[mir]

 314     my $ldap = Net::LDAP->new($conn_string, verify => 'none') || die "$@\n";
 315     my $search = $entry->{user_attr} . "=" . $userid;
 316     my $result = $ldap->search( base    => "$entry->{base_dn}",
 317                                 scope   => "sub",
 318                                 filter  => "$search",
 319                                 attrs   => ['dn']
 320                                 );
 321     die "no entries returned\n" if !$result->entries;
 322     my @entries = $result->entries;
 323     my $res = $ldap->bind($entries[0]->dn, password => $password);

Above could be rewritten this way:

ldap: ldap
        base_dn dc=company,dc=com
        bind_uid uid=bind_user,ou=people,dc=company,dc=com
        bind_pwd changeme
        comment gosa
        default
        secure
        server1 172.20.1.10
        server2 172.20.1.11
        user_attr uid

my $res = 0;
my $ldap = Net::LDAP->new($conn_string, verify => 'none') || die "$@\n";
if ($bind_uid) {
    if ($bind_pwd) {
        $res = $ldap->bind($bind_uid, password => $bind_pwd) || die "$@\n";
    }
    else {
        $res = $ldap->bind($bind_uid, password => '') || die "$@\n";
    }
}
else {
    my $search = $entry->{user_attr} . "=" . $userid;
    my $result = $ldap->search( base    => "$entry->{base_dn}",
                                           scope   => "sub",
                                           filter  => "$search",
                                           attrs   => ['dn']
                                         );
         die "no entries returned\n" if !$result->entries;
    my @entries = $result->entries;
    $res = $ldap->bind($entries[0]->dn, password => $password);
}

Disclaimer: The code above is untested.

PS: Retrieving the DN as an attribute is also probably not standard LDAP, I can try that against OpenLDAP if that helps anyone.

A directory server without the DN attribute is like a database with one table containing only a column of the type text. DN is the unique identifier for every object in a directory.

 

[gracinet]

(...)

Disclaimer: The code above is untested.

Thanks, I'll try it. Indeed, directly using the contents of that .cfg file could be a worthwhile first step ?
Still wondering how to keep a patched versions on my servers, but that's another story.

A directory server without the DN attribute is like a database with one table containing only a column of the type text. DN is the unique identifier for every object in a directory.

Yes, sure, but it's not really like an SQL column either, it's more akin to the key in a key/value database and it has specific behaviour. For instance, on my OpenLDAP, searching on dn as a filter does not work (there's another simple way of doing that), but the dn is always included in results whatever you ask for (including the dn in the wanted attributes through ldapsearch does not produce an error, as Apache DS seems to, according to the original poster's issue description.

Regards,