Possible error in LDAP subsystem

[bubnov-pi]

Hello, everybody!

I'm not sure, but I find some strange thing:
In Zentyal web interface (LDAP settings), I see "Users DN:    ou=Users,dc=test,dc=lan", but in fact, with any ldap-querying tool I can't to see this OU, there is only "cn=Users,dc=test,dc=lan", and all user accounts are placed into this Container (not Organisation unit), moreover, it is impossible to query LDAP with listed in web-interface credentials (for "adressbook" purpose, for example).
Okay, may be this shouldn't be a big problem, but in dovecot "user_attrs" parameter reads attributes from DN with "ou=", and if it changed to "cn=", occurs error.

Can somebody tell me, how it is possible? Is it a bug, or feature?

The second thing is unclear authentication mechanism with LDAP, if GSSAPI is used, but it is for my second topic.

P.S.: Described situation is on just-installed (from "zentyal-3.0-2-i386.iso" disc) for test system; Current core version: 3.0.21, with all actual updates. Active modules: Network, Firewall, Antivirus, DHCP, DNS, Backup, Events, Logs, Mail Filter, Monitoring, NTP, VPN, Users and Groups, Web Server, FTP, Mail, File Sharing, HTTP Proxy, Webmail, Printer Sharing. I explore Zentyal as alternative to our old solution with different authentication databases/user accounts on different physical servers (fileserver, mailserver and proxy/web/GW).
If some my sentences are not clear, please, ask me for more accurate definition - my English is not perfect...

[christian]

Indeed this is strange and deserves some explanations.
Before jumping into technical details, could you please tell us where you look at? Are you looking at LDAP on port 389 or 390?
I'm not sure DIT is 100% identical 

Let's start with some explanation:

"users DN:" in Zentyal interface describes DN of entry in which you will find "accounts". On LDAP (port 390), this branch is "ou=users,dc..."
As you refer to Dovecot, I assume you look at port 390, thus I'm very surprised you can't find this entry.
Notice that such entry can be read but is has very little added value. It should rather be used as baseDN for ldap query.

GSSAPI is implemented with LDAP on port 389 as this is the way kerberos is supported.

Also notice that even on port 390, anonymous access is not supported 

[bubnov-pi]

Thank you for answer - on port 390 i've got expected data! (and it helped me to resolve my confusion with GSSAPI authentication in dovecot)
But it is still very strange, why in two semi-same (in my point of view) ldap-catalogs, we found different structures

[christian]

But it is still very strange, why in two semi-same (in my point of view) ldap-catalogs, we found different structures

I don't understand this sentence. Would you please mind to rephrase it?
I even don't know what "ldap-catalog" is 

[christian]

ha ha ha 
I did my home-work: LDAP-catalog is a Microsoft concept linked to global catalog isn't it?
I'm a bit faulty because when I think LDAP, I can't think Microsoft   

Still I don't understand what you mean 

[bubnov-pi]

Under "ldap-catalog" I mean data, stored in ldap database and returned to query in structured form.
If I understand correct idea, this two instances (?) of slapd returns information about the same data, but in different patterns.
For example, on port 390:

Code: [Select]

[uid=Mailuser,ou=Users,dc=test,dc=lan]
cn=Testname Testsurname
givenName=Testname
homeDirectory=/home/Mailuser
jabberUid=Mailuser
krb5PrincipalName=Mailuser@TEST.LAN
mail=testmail@domain.tld
sn=Testsurname
uid=Mailuser
...And on port 389 (used by my ldap-querying tools as default):

Code: [Select]

[cn=Testname Testsurname,cn=Users,dc=test,dc=lan]
cn=Testname Testsurname
displayName=Testname Testsurname
givenName=Testname
homeDirectory=\\zent.TEST.LAN\Mailuser
homeDrive=H:
mail=testmail@domain.tld
name=Testname Testsurname
sAMAccountName=Mailuser@TEST.LAN
sn=Testsurname
...They seems very much alike, of course, they are diffirent, and stores data for diffirent purposes. But why this two records stores on two different "paths"? - If it is a special reason, then okay. If it is just a mistake, then it needs to be corrected.

In any case, thank you for patience and help!

[bubnov-pi]

Of course, I forget to describe, this data is modifyed by external tools to become more useful for adressbook in Thunderbird, so don't confuse, if in my listings you can see some abnormous 

[bubnov-pi]

And finally, to clarify sources of my term "ldap-catalog": I use this construction as copy from my russian lexem, where to make differences betwen various datasources and datastores, we use different naming. I'm not so familiar with english, to make exact correct translation of my ideas and expiriences... 

[christian]

OK, much clearer.
Nothing to do with any "catalogue" concept then (I hate this Microsoft way of generating mess with proprietary wording where things are easy).
Don't worry with language. what matters is that, at the end, we understand each others.

I'll give you my understanding but you should better cross-check with Zentyal staff member 
Zentyal implements 2 different LDAP servers because they have recently (starting with Zentyal 3.0) moved to Samba 4 that requires LDAP server very close to AD and integrating Zentyal specific DIT and schema into Samba LDAP was not that easy. Because of this, they decided to keep the initial LDAP server, make it listening on port 390 and deployed Samba 4 with its embedded LDAP on port 389.
Synchronization occurs between these 2 LDAP servers (I won't say replication here).

Of course DIT and schema are different but you should not worry.
If I understand well Zentyal strategy, you are not supposed to access Zentyal LDAP servers, reason why anonymous access  is not permitted. These LDAP servers are here for Zentyal components. Samba uses LDAP on port 389, other components use LDAP on port 390 (well, I suppose).
If you have an application that requires LDAP access, you should access on port 390 and there is no confusion with the LDAP that is Samba dedicated 

Some additional comments that will not help but aiming to explain some difference between these 2 LDAP servers:
- the left part of DN, known as RDN, is, by design, unique within the branch.
- one attribute that is for sure unique for accounts is UID. This is why a lot of LDAP servers implement UID as RDN.
- Microsoft had a slightly different view and decided that "cn" (AKA common name) is unique thus they built their DN (for accounts) on CN. Nice clever view isn't it? what is really funny, if you look at this further is that using Microsoft AD, at the time you create an account, CN will be unique because this is enforced by LDAP principle but there is no guaranty (from LDAP standpoint) that such CN is unique in another branch. If you have to move this account from one branch to another, you may have to change CN in case of conflict (meaning, i.e., homonym)

I love the Microsoft approach so much  ...