View Issue Details

Related ChangesetsJump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0002253SOGoBackend Generalpublic2013-02-22 16:002017-01-09 20:49
Reporterachim71 Assigned Toludovic  
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Product Version2.0.4b 
Fixed in Version3.2.5 
Summary0002253: SOGoGroup does not resolve LDAP Group users via the User Sources UIDField but via the Groups Source UIDField
Description

On my server i use samba4 as the ldap source for users and groups.

For my users i use "samaccountname" as UIDFieldName for the groups "description". If an users has the "description" attribute defined, the function getLoginForDN in SOGOUserManager.m does return the "description" value and not the "samaccountname" value for the inspected user record and so the members function in SOGoGroup.m can not find the correct SOGoUser record (line 265).
If there is no "description" value defined for the users getLoginForDN does then search the next source which has an UIDField of "samaccountname" and does return the correct value.

The result is that calendars shared for groups can not be subscribed to for users with the "description" attribute defined.

TagsNo tags attached.

Activities

achim71

achim71

2013-02-22 16:43

reporter   ~0005392

Last edited: 2013-02-22 17:04

Both LDAP sources use the same baseDN but i defined filters (objectClass=user) and (objectClass=group).
Debuging LDAPSource abit more those filters are not used in line 215.
The first source that get's searched is the group source and since the filter is not applied to the search returns the user record with objectClass=user.

2013-02-22 18:07

 

qualifier.patch (2,387 bytes)    
diff -ru orig/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m new/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m
--- orig/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m	2013-02-22 18:44:15.815307185 +0100
+++ new/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m	2013-02-22 19:06:28.207297675 +0100
@@ -1207,12 +1207,15 @@
 {
   NGLdapConnection *ldapConnection;
   NGLdapEntry *entry;
+  EOQualifier *qualifier;
   NSString *login;
   
   login = nil;
 
   ldapConnection = [self _ldapConnection];
+  qualifier = [EOQualifier qualifierWithQualifierFormat: _filter];
   entry = [ldapConnection entryAtDN: theDN
+			 qualifier: qualifier
                          attributes: [NSArray arrayWithObject: UIDField]];
   if (entry)
     login = [[entry attributeWithName: UIDField] stringValueAtIndex: 0];
diff -ru orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h
--- orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h	2013-02-22 18:43:34.071318000 +0100
+++ new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h	2013-02-22 18:43:49.123301931 +0100
@@ -102,6 +102,10 @@
   qualifier:(EOQualifier *)_q
   attributes:(NSArray *)_attributes;
 
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn 
+  qualifier:(EOQualifier *)_q
+  attributes:(NSArray *)_attrs;
+  
 - (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs;
 
 /* cache */
diff -ru orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m
--- orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m	2013-02-22 18:43:34.071318000 +0100
+++ new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m	2013-02-22 18:43:49.123301931 +0100
@@ -707,13 +707,15 @@
                attributes:_attributes
                scope:LDAP_SCOPE_BASE];
 }
-
-- (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs {
+  
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn 
+  qualifier:(EOQualifier *)_q
+  attributes:(NSArray *)_attrs {
   NSEnumerator *e;
   NGLdapEntry  *entry;
   
   e = [self _searchAtBaseDN:_dn
-            qualifier:nil
+            qualifier:_q
             attributes:_attrs
             scope:LDAP_SCOPE_BASE];
   
@@ -729,6 +731,10 @@
   return entry;
 }
 
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs {
+  return [self entryAtDN:_dn qualifier:nil attributes:_attrs];
+}
+
 /* cache */
 
 - (void)setCacheTimeout:(NSTimeInterval)_to {
qualifier.patch (2,387 bytes)   
achim71

achim71

2013-02-22 18:10

reporter   ~0005393

Last edited: 2013-02-23 12:48

Uploaded an patch, extended NGLdapConnecton by adding an entryAtDN variant which passes an qualifier.
Also changed LDAPSource to create an EOQualifier for the filter and pass that to entryAtDN.
Seems to work here.

Update: Made an small modification to the previous patch, added an check if _filter is nil.

2013-02-23 12:47

 

qualifier-2.patch (2,434 bytes)    
diff -ur orig/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m new/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m
--- orig/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m	2013-02-22 18:44:15.815307185 +0100
+++ new/sogo-2.0.4b/SoObjects/SOGo/LDAPSource.m	2013-02-23 13:46:18.019303644 +0100
@@ -1207,12 +1207,19 @@
 {
   NGLdapConnection *ldapConnection;
   NGLdapEntry *entry;
+  EOQualifier *qualifier;
   NSString *login;
   
   login = nil;
+  qualifier = nil;
 
   ldapConnection = [self _ldapConnection];
+
+  if (_filter!=nil)
+    qualifier = [EOQualifier qualifierWithQualifierFormat: _filter];
+
   entry = [ldapConnection entryAtDN: theDN
+			 qualifier: qualifier
                          attributes: [NSArray arrayWithObject: UIDField]];
   if (entry)
     login = [[entry attributeWithName: UIDField] stringValueAtIndex: 0];
diff -ur orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h
--- orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h	2013-02-22 18:43:34.071318000 +0100
+++ new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.h	2013-02-22 18:43:49.123301931 +0100
@@ -102,6 +102,10 @@
   qualifier:(EOQualifier *)_q
   attributes:(NSArray *)_attributes;
 
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn 
+  qualifier:(EOQualifier *)_q
+  attributes:(NSArray *)_attrs;
+  
 - (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs;
 
 /* cache */
diff -ur orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m
--- orig/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m	2013-02-22 18:43:34.071318000 +0100
+++ new/sope-4.9/sope-ldap/NGLdap/NGLdapConnection.m	2013-02-22 18:43:49.123301931 +0100
@@ -707,13 +707,15 @@
                attributes:_attributes
                scope:LDAP_SCOPE_BASE];
 }
-
-- (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs {
+  
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn 
+  qualifier:(EOQualifier *)_q
+  attributes:(NSArray *)_attrs {
   NSEnumerator *e;
   NGLdapEntry  *entry;
   
   e = [self _searchAtBaseDN:_dn
-            qualifier:nil
+            qualifier:_q
             attributes:_attrs
             scope:LDAP_SCOPE_BASE];
   
@@ -729,6 +731,10 @@
   return entry;
 }
 
+- (NGLdapEntry *)entryAtDN:(NSString *)_dn attributes:(NSArray *)_attrs {
+  return [self entryAtDN:_dn qualifier:nil attributes:_attrs];
+}
+
 /* cache */
 
 - (void)setCacheTimeout:(NSTimeInterval)_to {
qualifier-2.patch (2,434 bytes)   
achim71

achim71

2013-03-08 13:28

reporter   ~0005414

Since there was no feedback on this issue in the last two weeks. I'll sum up the problem.

On my setup i use Samba4 as an LDAP source. I did an classic-upgrade from samba3/openldap so users and groups both reside under cn=users,dc=example.dc=com.

I use the Windows Domain-Groups to share IMAP-Folders and to controll Calendar access.

Therefore i set the email attribute to "somename@example.com" and the description attribute to "somename".

On the dovecot side i can use the username part of the email address as the uid. At first i had tried to use the cn attribute in sogo as the UID Field for the groups buut back thene it did not work because there was an bug with whitspaces in UIDFiled values. Because of that and to use the same name in dovecot and sogo i decided to use the description attribute to store the username part of the email in the group records and use that attribute as the UIDField in sogo. This is an not so common way i guess but it should work.

During my first tests i had ussed an user with no description attribute set for testing so i did not recognize there was an problem withing sogo already.

Here are the relevant parts of my LDAP sources.

        <dict>
            <key>CNFieldName</key>
            <string>displayName</string>
            <key>IDFieldName</key>
            <string>sAMAccountName</string>
            <key>UIDFieldName</key>
            <string>sAMAccountName</string>
            <key>baseDN</key>
            <string>cn=Users,dc=example,dc=com</string>
            <key>id</key>
            <string>public</string>
            <key>filter</key>
            <string>(objectClass=user) AND (mail='*')</string>
        </dict>
        <dict>
            <key>CNFieldName</key>
            <string>cn</string>
            <key>IDFieldName</key>
            <string>cn</string>
            <key>UIDFieldName</key>
            <string>description</string>
            <key>id</key>
            <string>public2</string>
            <key>baseDN</key>
            <string>cn=Users,dc=example,dc=com</string>
            <key>filter</key>
            <string>(objectClass=group) AND (mail='*')</string>
        </dict>

An user record looks like this (excerpt):

dn: CN=ag,CN=Users,DC=example,DC=com
cn: ag
name: ag
description: achim.gottinger
sAMAccountName: ag
objectClass: top
objectClass: posixAccount
objectClass: person
objectClass: organizationalPerson
objectClass: user
memberOf: CN=DG Email,CN=Users,DC=example,DC=com
mail: achim.gottinger@example.com
displayName: Achim Gottinger
distinguishedName: CN=ag,CN=Users,DC=example,DC=com
....

The E-Mail group looks like this:

DG Email, Users, gsg.local

dn: CN=DG Email,CN=Users,DC=example,DC=com
objectClass: top
objectClass: group
cn: DG Email
name: DG Email
sAMAccountName: DG Email
mail: info@example.com
description: info
member: CN=ag,CN=Users,DC=example,DC=com
distinguishedName: CN=DG Email,CN=Users,DC=example,DC=com
.......

To distiguish groups from users i have to use ldap filters (objectClass=user) and (objectClass=group) but use the same search base for both.

If sogo tries to enumerate the users for an group in [SOGoGroup.m members] it loops over the user dn's (theDN) found in the member attributes of the groups and tries to get the uid's for those users by calling [SOGOUserManager getLoginForDN : the DN].

This functions loops over the source objects. In my case the first source object are the groups. It calls [LDAPSource lookupLoginByDN: theDN] and this function returns the value of the UIDField for that DN in the source.

The function lookupLoginByDN does an search for theDN at the sources base but does not apply filter defined for the source.

So in my case if theDN is CN=ag,CN=Users,DC=example,DC=com which is in the search base of the ldap group source there is an false match in the ldap group source if the user record has the description attribute defined.
lookupLoginByDN then does return the description attribute's value, in above example achim.gottinger.

[SOGoGroupManager members] then tries to find an user record in line 265 but since the wrong attribute's value (description: achim.gotinger instead of samaccountname: ag) is returnd it does not find one and so the user does not get resolved as an memeber of the group.

If the user has no description attribute defined however [SOGOUserManager getLoginForDN : the DN] does not get an result for the dn in the first source and continues to search in the second source (ldap users), which results in the correct attribute (samaccountname) returned and the [SOGOGroup members] does find the correct user record.

To fix the false match i had to extend sope's [NGLdapConnecton entryAtDN] to allow searching for dn's with an ldap filter. Also i had to modify [LDAPSource lookupLoginByDN: theDN] to use that function an pass the sources filter.

Hope this or something similar makes it into 2.0.5.

Related Changesets

sogo: master 94fc5d17

2016-12-22 14:26

ludovic


Details Diff		 (fix) also use the filter when doing DN lookups (fixes 0002253) Affected Issues
0002253
mod - SoObjects/SOGo/LDAPSource.m Diff File

sogo: v2 b7e40776

2016-12-22 14:26

ludovic


Details Diff		 (fix) also use the filter when doing DN lookups (fixes 0002253) Affected Issues
0002253
mod - SoObjects/SOGo/LDAPSource.m Diff File

sogo: maint aba24c05

2016-12-22 14:26

ludovic

Committer: francis


Details Diff		 (fix) also use the filter when doing DN lookups (fixes 0002253) Affected Issues
0002253
mod - SoObjects/SOGo/LDAPSource.m Diff File

Issue History

Date Modified Username Field Change
2013-02-22 16:00 achim71 New Issue
2013-02-22 16:43 achim71 Note Added: 0005392
2013-02-22 16:55 achim71 Note Edited: 0005392
2013-02-22 17:04 achim71 Note Edited: 0005392
2013-02-22 18:07 achim71 File Added: qualifier.patch
2013-02-22 18:10 achim71 Note Added: 0005393
2013-02-22 20:41 achim71 Note Edited: 0005393
2013-02-23 12:47 achim71 File Added: qualifier-2.patch
2013-02-23 12:48 achim71 Note Edited: 0005393
2013-03-08 13:28 achim71 Note Added: 0005414
2016-12-22 19:27 ludovic Changeset attached => sogo master 94fc5d17
2016-12-22 19:27 ludovic Assigned To => ludovic
2016-12-22 19:27 ludovic Resolution open => fixed
2016-12-22 19:27 ludovic Changeset attached => sogo v2 b7e40776
2016-12-22 19:27 ludovic Status new => resolved
2016-12-22 19:27 ludovic Fixed in Version => 3.2.5
2017-01-09 20:49 francis Changeset attached => sogo maint aba24c05