What's wrong with Zentyal LDAP ? (3.0)

[christian]

Working on this thread, I launched again my 3.0 platform in order to understand better why access to ldap failed.

It confirmed that Zentyal design does not allow anonymous access to LDAP except for RootDSE (this one being, by design mandatory).

I can't share such design and will try to explain why.
I already asked multiple times Zentyal staff to react on one similar post but it looks like nobody cares 

Anyway, let's share now with us why I'm so disappointed 

As a preamble, I assume that Zentyal's strategy is not to enforce "Kerberos only" authenication, meaning they offer Kerberos as authentication service but still allow at least external applications to use Zentyal LDAP server for stand LDAP authentication.
OK, let's assume I'm right with this approach. So what's wrong 

Standard LDAP authentication follows this very simple process:
1 - LDAP client (here the application) connects anonymously to LDAP server and search for entry matching login provided by user (e.g.
2 - if everything goes well, one and only one entry is found. Application is supposed to check that "nentry=1"
3 - then application authenticates using LDAP bind command, using retrieved DN and password provided by user.

Any different implementation as side effects and should be avoided.

- the worst one is to read password related attributes, application side: this is wide open door to brute force attack.
- using DN to authenticate, application side, prevents to implement ACL permitting to control what authenticated user is able to do with LDAP server (e.g. changing his password or browsing specific groups.

Zentyal implements zentyalro uid. Why not for internal use but this doesn't explain why anonymous access at least for authentication is not allowed.

[exekias]

Hi christian,

You don't need anonymous access to authenticate users, some of the Zentyal modules implement bind based authentication. In summary these are the steps you need to make it work:

Configure base dn for your users (or regexp), which will give you the DN for any username. Example:

BASE_DN = ou=Users,dc=zentyal,dc=com

Now, your applications now that for a given user (ie exekias), the DN is:

uid=<username>,ou=Users,dc=zentyal,dc=com

It only needs to bind to Zentyal LDAP, and authenticate the user if everything goes well.

Most applications support this kind of configuration! (I have tested a lot, for example: wordpress, openerp, moodle, sugarcrm...)


Moreover, if you need to do this based on a search, you can use zentyalro account for that I agree that it should be shown on the interface, bug probably we will fix that for 3.2

Best regards

[christian]

Configure base dn for your users (or regexp), which will give you the DN for any username. Example:
BASE_DN = ou=Users,dc=zentyal,dc=com
Now, your applications now that for a given user (ie exekias), the DN is:
uid=<username>,ou=Users,dc=zentyal,dc=com

I'm exactly fighting against this biased approach. Sorry for being abrupt here 

Again, standard (understand here "normal") appraoch is to search for existing entry matching your login.
Why do you make the assumption (even if you're most of the time right with such approach), that user will login with its [uid].
As long as provided string matches unique string permitting to find unique but existing entry, it works.
Guessing and building DN is just wrong.

Let me take an example because I can understand that you don't share it.

For some applications, you may ask user to access providing its mail address.
With your approach, what would be the next step? To assume that mail address looks like [uid]@domain    This is obviously not always true and definitely wrong as approach.

Not convinced already ? OK, let me take another example:
today, your LDAP DIT is flat. No OU permitting to segregate users. You will perhaps, sooner or later, evolve toward more powerful design (e.g. to match what "AD clone", AKA Samba supports, also to better synchronize with real Windows world. Well, whatever the reason, you may evolve toward such design. Cool    how are you going to guess DN for users ? you have forged RDN. So far so good but you're not done.

Do you see where I'm coming from now 

Moreover, if you need to do this based on a search, you can use zentyalro account for that I agree that it should be shown on the interface, bug probably we will fix that for 3.2

Another design I fighting against: this account is currently allowed to read userpassword 
I'm perhaps paranoiac but this permits brute force attack, especially because there is no password policy overlay.

Also feel free to explain to Zentyazl admins where they can find, even if not in Zentyal GUI, password for Zentyalro account, even if "I" do not support such approach.

[exekias]

As far as I know, zentyalro user cannot read passowords, please pay a look to the ACLs:

Code: [Select]

olcAccess: {0}to *
  by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage
  by dn="cn=zentyal,<% $dn %>" manage
  by * break
olcAccess: {1}to attrs=userPassword,shadowLastChange,krb5Key
  by dn="cn=zentyal,<% $dn %>" write
  by anonymous auth
  by dn="cn=zentyalro,<% $dn %>" none
  by self write
  by * none
olcAccess: {2}to * by users read

Only zentyal user can do that.

Sincerely, I think that using zentyalro for your approach is a good option (some zentyal modules already do that, mail, zarafa...). And it's secure. I agree that we may communicate it better to the user, but nothing else

Regards

[Sam Graf]

I want to resurrect this topic not because I understand all the technical issues involved but because I want to understand better the practical outcome now that we have access to 3.1.

I'm experimenting with deployment scenarios, in part to give me some "real world" things to do with 3.1. My first scenario is OpenMediaVault for file sharing in a non-domain context and Zentyal 3.1 providing the infrastructure. OMV does not retrieve the Zentyal user accounts using either zentyal or zentyalro, leaving non-public shares unusable.

Am I missing something or is this the expected behavior?

[christian]

I don't now about 3.1 but with 2.2, OpenMediaVault works like a charm.

For what I guess (rather than "understand"), 3.1 should permit exactly same access, assuming you access on port 390. Well, here again, I suppose Zentyal didn't change the initial choice that is to keep stand LDAP port for internal flow and customize LDAP port for external access.

If I had to do this, I suppose my choice would have been just the opposite (390 for private internal use and standard port,i.e. 389, for external access).
Anyway, it's probably worth to check this then ensure you access the external port and give a try again.

[Sam Graf]

I don't now about 3.1 but with 2.2, OpenMediaVault works like a charm.

Agreed.

Anyway, it's probably worth to check this then ensure you access the external port and give a try again.

Also agreed. I checked the port of the LDAP network service, which is 390, and used it. Access allowed at the firewall level. No joy.

I also tried the OMV default 389. That was a bad experience; the OMV web interface became almost unresponsive.

So I'm not sure if something has changed in 3.1 (or if there is a bug) or if the operator is at fault. Since I don't understand all the technical aspects I can't decide.

[christian]

Code: [Select]

netstat -an | grep 389
and
netstat -an | grep 390
will tell you which one is listening on internal (127.0.0.1) interface only or external interface too (if LDAP is still available on external port  )
another way is to

Code: [Select]

ps -efd | grep ldapOne point you may want to take in account: if file sharing is not installed, you may not have any LDAP server on port 389... or Zentyal may have designed something different 

... or this is still beta and all features are not yet available


EDIT: fixed typo. netstat -an instead of -en    goal is to show all, not only enabled

[christian]

In order to made a quick check, I decided to upgrade my 3.0 platform to 3.1 
It was not that quick because this platform is remote and although upgrade went fine, I was not able to access this remote server anymore because server-to-server VPN is broken (Zentyal 2.2 VPN server side, 3.1 VPN client side).

Anyway, after some tweaks, I got again to this server (not using VPN BTW) and confirm that:
- LDAP is listening on all interfaces, port 390, no change compared to 3.0
- Samba-LDAP is listening on port 389 but not on all interfaces, only the ones describes as internal.

Notice that I can't, like with 3.0, authenticate against port 389 using basic LDAP authentication. I guess it accepts only GSSAPI or SASL ?

Funny, trying to reconnect to Zentyal GUI, I quickly got "bad gateway" error message from... Nginx engine 

Answering to your question: there is no reason why OpenLDAP could not access Zentyal on port 390 for what I see so far.

[Sam Graf]

Funny, trying to reconnect to Zentyal GUI, I quickly got "bad gateway" error message from... Nginx engine 

Answering to your question: there is no reason why OpenLDAP could not access Zentyal on port 390 for what I see so far.

Thank you for going to the trouble to test this. I will try again mid week.

[Sam Graf]

... or this is still beta and all features are not yet available

That may be what's going on. (Captive portal also doesn't work, though probably for an unrelated reason.)

I think I need to focus on the modules listed so far in the release announcement and not play randomly just yet. I can retry LDAP without file sharing installed later.

Thanks again for checking it out.

[christian]

it's up to you.
here it works running Zentyal 3.1

I can access LDAP on port 390 from external application, meaning you should perhaps investigate elsewhere for some problem.

[christian]

I tried to help with LDAP but it looks like I failed 
Let me try another direction with Captive portal (well, we should create a new thread but I'll be quick 

While testing LDAP, I noticed, as explained above, that Nginx is now acting as reverse proxy.
It seems there is a side effect with little bug preventing Apache to start.

You could perhaps look at Captive portal implementation and check whenever it also conflicts or not.

my $0.02 

[Sam Graf]

I tried to help with LDAP but it looks like I failed 

Not at all. I'm the problem. I get to tinker with 3.1 in 15-30 minute spurts, maybe twice a day. I should have more time later in the week and will take all the information you provided and see if I can figure out where I've gone wrong with LDAP. So you have been a great help; I'm just a little slow in taking advantage of it.

[ap1821]

Same problem as author's problem. I have made a custom application which connects to LDAP and autheticates users trough it. Well now it's completely broken and I haven't still managed to fix it. What the hell have they done with LDAP in 3.0. In 2.2 it was working well, how about 3.1?
By the way the application I made was made using PHP, maybe someone has some good scripts to authenticate users with PHP? And one more thing, I won't be able to authenticate linux users via ldap and pam now, right?

EDIT: Okay, I wrote a custom script in PHP using bind to rootdn, so now this seems to work, and most linux distros can be joined to domain now using likewise-open? I admit that it is a more secure approach, but not all applications work with it. In my script i'm still using cn=zentyal user to get into LDAP and the port must be 390.