View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0003685||SOGo||Backend General||public||2016-05-20 08:30||2019-03-18 11:09|
|Target Version||Fixed in Version||4.0.8|
|Summary||0003685: Feature request: support place holder in LDAP base dn, bind dn|
Please consider supporting place holders in LDAP base dn and bind dn, so that we can get flexible LDAP support.
For example, login as user 'firstname.lastname@example.org':
- %s for full login username (full email address)
- %d for domain part in email address (mydomain.com)
- %u for username part in email address (john)
Then we can get flexible LDAP base dn and bind dn like this:
base dn: domainName=%d,o=domains,dc=iredmail,dc=org
bind dn: mail=%s,ou=Users,domainName=%d,o=domains,dc=iredmail,dc=org
|Tags||No tags attached.|
Can i pay you to implement this feature? How much?
If you didn't already, use https://sogo.nu/support/index_new.html#/commercial for such requests ;-)
|Is there already an update regarding this issue? I am intersted in this as well.|
I can understand having a dynamic baseDN but is a dynamic bindDN really useful?
We currently have bindAsCurrentUser has an option in SOGo.
So the bindDN can be used on the 'root' of the source to actually perform an initial lookup in case bindFields are being used.
Are you NOT using bindFields?
|We can use bindAsCurrentUser instead of dynamic bind dn. The most important parts are base dn and ldap filter.|
|So I guess %s and %u don't make sense either.|
|We need %s and %u also, especially in ldap filter.|
|What do you mean by ldap filter?|
Oops, i mixed SOGo with another use case. Sorry about this.
I think %d (domain) is enough for now.
|The feature was implemented. baseDN now accepts %d as a placeholder. Please give a try to the upcoming nightly builds (available in 24 hours from now).|
|Thanks very much. :)|
|Placeholder (%d) in base DN doesn't work with SOGo nightly build: 188.8.131.5290210-1.|
Tested with SOGoUserSources below, it doesn't work. According to OpenLDAP log, the query base dn is "domainName=%d,o=domains,dc=a,dc=io", that means placeholder "%d" was not replaced by real domain name at all. When i remove "domainName=%d," and restart sogo service (all other settings are same), webmail login works fine.
OS: Ubuntu 18.04
SOGo nightly build: 184.108.40.20690210-1
SOGoUserSources = (
type = ldap;
canAuthenticate = YES;
isAddressBook = NO;
displayName = "LDAP Authentication";
hostname = "ldap://127.0.0.1:389";
baseDN = "domainName=%d,o=domains,dc=a,dc=io";
bindDN = "cn=vmail,dc=a,dc=io";
bindPassword = "f70c8f378fa49c3684b84637d790da37";
filter = "objectClass=mailUser AND accountStatus=active AND enabledService=mail AND enabledService=sogo";
scope = SUB;
bindAsCurrentUser = YES;
// The algorithm used for password encryption when changing
// passwords without Password Policies enabled.
// Possible values are: plain, crypt, md5-crypt, ssha, ssha512.
userPasswordAlgorithm = ssha512;
CNFieldName = cn;
IDFieldName = mail;
// value of UIDFieldName must be unique on entire server
UIDFieldName = mail;
IMAPLoginFieldName = mail;
MailFieldNames = (mail);
bindFields = (mail);
Could you implement %s (full login name) and %u (username part in email address) also? so that we can narrow down the base dn to user account itself, it will help improve ldap query performance. for example:
baseDN = "mail=%s,ou=Users,domainName=%d,o=domains,dc=a,dc=io";
I'm sorry that this issue was reported long time ago and i didn't remember all use cases. :(
Which OS are you testing on? You tested a nightly build (Feb 2nd) and the code landed 2 days AFTER that so it's normal it doesn't work.
It makes NO sense to use mail=%s - that's the base of SOGo for all queries so it'll miserably for example in the shared address book. As said before, use bindAsCurrentUser.
- OS: Ubuntu 18.04 LTS.
- SOGo version: 220.127.116.1190210-1 (I suppose this version was packed on Feb 10 - 6 days after your commit).
About base dn "mail=%s,ou=Users,domainName=%d,o=domains,dc=xx,dc=xx", this is the best option if we can have for user authentication (with scope set to BASE), not for per-domain or global address book.
By the way, we use 2 sections in SOGoUserSources, one for user authentication, one for per-domain address book.
For the user authentication, we hope to narrow down the LDAP search base dn, this way we can get best performance due.
For the per-domain address book, we use "domainName=%d,o=domains,dc=xx,dc=xx" to build dynamic base dn (with ACL in OpenLDAP config file as well).
The baseDN can NOT contain a user part as it is used everywhere in SOGo where there's no context of a user.
I see no reason why the baseDN's %d wouldn't work - the code is there, I use it and it works.
I tested again today, it does NOT work.
- OS: Debian 9
- SOGo: 18.104.22.16890213-1
- SOGoUserSources setting in sogo.conf: https://pastebin.com/xjDinJNe
Neither user authentication nor global (per-domain actually) address book works.
If i remove "domainName=%d," from baseDN, it works.
Could you help double check? I believe there's something wrong in the code.
Also, could you implement the %s placeholder for testing? If it doesn't work, let's remove %s before final release. Please.
|I think I know what happens - the domain must not be extracted properly in your configuration while it is on mine. I'll do more testing tomorrow and push a fix.|
Thanks for the reply.
Please also be so kind to implement '%s' support in baseDN, at least give me a chance to test it, i believe it works. If it doesn't, we can remove it before final release 4.0.6.
|Try the upcoming nightly build which will be available in 24 hours from now.|
Tested with SOGo 22.214.171.12490215-1 on Debian 9, %d works in baseDN for user authentication, but NOT for separated global address book.
Also, could you implement the %s placeholder (for user authentication) for testing? If it doesn't work, let's remove %s before final release. Please please please.
What do you mean by separated global address book?
Also, %s CANNOT be implemented, as I said earlier, we do not have the user's context all the time.
|I see what you mean in your previous comment. I pushed a fix for that and it works. Please test the nightly builds that will be available in about 16 hours from now.|
%d doesn't work in separated ldap address book. Full SOGoUserResources here:
- %d works for user authentication (canAuthenticate = YES; isAddressBook = NO;).
- %d does NOT work for ldap address book (canAuthenticate = NO; isAddressBook = YES;).
|Tested with SOGo 126.96.36.19990221, nightly build.|
|That's normal for now, the domain is changed ON THE FLY when the user authenticates.|
I don't get it.
After successfully logged in, the login username (full email) is fixed, so that %d should be always expanded to the domain part of login user's email address. Why is it changed on the fly?
|Because the authentication source is created once, upon SOGo's startup and reused over time. It is a singleton.|
I understand that the latest SOGo release works this way, but can we re-build baseDN each time when we need to query ldap address book? This is the real DYNAMIC base dn, and it's the best per-domain global address book we can get with the flexible LDAP query, and get rid of the "Multi-domains Configuration" which requires updating sogo.conf manually and restart sogo daemon service.
Please please please, help implement this flexible ldap address book.
Any update / comment?
The baseDN is associated with an authentication source.
I'll check if it's possible to change the code, early next week.
Thanks for the reply.
I believe it's ok, because there're many applications which support placeholders like this while querying LDAP, for example, Roundcube webmail. :)
Any update about this change?
|Yes I found a way to do it but it requires many changes which should be done by the end of the week.|
|Thanks Ludovic. Let me know when it's ready and i will test it ASAP. :)|
|Try the upcoming nightly build.|
|It works. Thanks. :)|
sogo: master d9943e55
2019-02-04 07:37:56Details Diff
|(feat) baseDN now accept dynamic domain values (fixes 0003685)||
|mod - Documentation/SOGoInstallationGuide.asciidoc||Diff File|
|mod - NEWS||Diff File|
|mod - SoObjects/SOGo/LDAPSource.h||Diff File|
|mod - SoObjects/SOGo/LDAPSource.m||Diff File|
|2016-05-20 08:30||zhb||New Issue|
|2016-05-20 11:02||ludovic||Severity||minor => feature|
|2017-01-05 00:23||zhb||Note Added: 0011166|
|2017-02-03 05:32||Christian Mack||Note Added: 0011265|
|2019-01-04 09:40||modir||Note Added: 0013235|
|2019-01-31 14:35||ludovic||Note Added: 0013295|
|2019-01-31 20:00||zhb||Note Added: 0013303|
|2019-01-31 20:24||ludovic||Note Added: 0013304|
|2019-01-31 20:35||zhb||Note Added: 0013305|
|2019-01-31 20:35||ludovic||Note Added: 0013306|
|2019-01-31 20:44||zhb||Note Added: 0013307|
|2019-02-04 07:40||ludovic||Changeset attached||=> sogo master d9943e55|
|2019-02-04 07:40||ludovic||Assigned To||=> ludovic|
|2019-02-04 07:40||ludovic||Resolution||open => fixed|
|2019-02-04 07:41||ludovic||Note Added: 0013312|
|2019-02-04 11:00||zhb||Note Added: 0013318|
|2019-02-04 11:24||Christian Mack||Status||new => resolved|
|2019-02-10 09:54||zhb||Note Added: 0013323|
|2019-02-10 09:54||zhb||Status||resolved => feedback|
|2019-02-10 09:54||zhb||Resolution||fixed => reopened|
|2019-02-10 09:59||zhb||Note Added: 0013324|
|2019-02-10 09:59||zhb||Status||feedback => assigned|
|2019-02-10 10:09||zhb||Note Added: 0013325|
|2019-02-11 08:04||ludovic||Note Added: 0013331|
|2019-02-11 09:57||zhb||Note Added: 0013332|
|2019-02-11 09:59||zhb||Note Added: 0013333|
|2019-02-11 13:42||ludovic||Note Added: 0013335|
|2019-02-13 07:45||zhb||Note Added: 0013342|
|2019-02-13 08:02||ludovic||Note Added: 0013343|
|2019-02-13 08:12||zhb||Note Added: 0013344|
|2019-02-14 09:51||ludovic||Note Added: 0013354|
|2019-02-15 20:13||zhb||Note Added: 0013370|
|2019-02-19 11:20||ludovic||Note Added: 0013385|
|2019-02-19 13:44||ludovic||Note Added: 0013392|
|2019-02-19 13:44||ludovic||Status||assigned => resolved|
|2019-02-19 13:44||ludovic||Fixed in Version||=> 4.0.6|
|2019-02-19 13:44||ludovic||Resolution||reopened => fixed|
|2019-02-21 10:47||zhb||Note Added: 0013406|
|2019-02-21 10:47||zhb||Status||resolved => feedback|
|2019-02-21 10:47||zhb||Resolution||fixed => reopened|
|2019-02-21 10:48||zhb||Note Added: 0013407|
|2019-02-21 10:48||zhb||Status||feedback => assigned|
|2019-02-21 10:50||ludovic||Note Added: 0013408|
|2019-02-21 14:10||zhb||Note Added: 0013409|
|2019-02-21 14:11||ludovic||Note Added: 0013410|
|2019-02-22 01:41||zhb||Note Added: 0013412|
|2019-02-26 23:30||zhb||Note Added: 0013420|
|2019-02-27 18:49||ludovic||Note Added: 0013421|
|2019-02-27 18:58||zhb||Note Added: 0013422|
|2019-03-08 00:05||zhb||Note Added: 0013431|
|2019-03-14 13:47||ludovic||Note Added: 0013447|
|2019-03-14 23:27||zhb||Note Added: 0013449|
|2019-03-15 13:39||ludovic||Note Added: 0013451|
|2019-03-18 11:06||zhb||Note Added: 0013466|
|2019-03-18 11:09||ludovic||Status||assigned => resolved|
|2019-03-18 11:09||ludovic||Fixed in Version||4.0.6 => 4.0.8|
|2019-03-18 11:09||ludovic||Resolution||reopened => fixed|