Does your group have an email address?

Could you give us an LDIF of your group?

dn: ou=TestGroup,ou=Departments,o=**
departmentChair: Tester
departmentSecretary: Tester
buildingName: Stillman Computing Center
buildingName: Kellas Hall
mail: calendar-noreply@potsdam.edu
member: uid=yacketrj@potsdam.edu,ou=People,o=
gidNumber: 1587
cn: TestGroup
departmentAlias: CTS
departmentMail: cts@potsdam.edu
title: Director
objectClass: top
objectClass: organizationalunit
objectClass: spotdepartment
objectClass: extensibleobject
objectClass: groupofuniquenames
objectClass: posixGroup
ou: TestGroup
telephoneNumber: 6969
url: http://www.potsdam.edu/cts/
memberUid: yacketrj
memberUid: xyacket2
memberUid: xyacket1
facsimileTelephoneNumber: 1234/ 5678
postalAddress: 209 Stillman Hall

Don't use "objectClass: groupOfUniqueNames".
As you don't have the required attribute "uniqueMember" in your object, this is not a valid LDIF according to the schema.

As you use "objectClass: posixGroup" and the corresponding "memberUid" attributes, this is also superfluous.

BTW:
Where does that "member" attribute come from?

I'll speak with our LDAP guy, regardless of the issues mentioned Groups work for searches as well as inviting to meetings but fail when sharing. Something must be different in the way groups are handled for searches, invitations and sharing.

Per 389 Directory Server :

NOTE: There is one very important deviation from the LDAP standard:

there is a bug in the standard definition of groupOfNames and

groupOfUniqueNames - the member/uniqueMember attribute is in the MUST

list, not the MAY list, which means you cannot have an empty group.

Until the LDAP community figures out how to do grouping properly, we

have put the member/uniqueMember attribute into the MAY list, to allow

empty groups.

Any traction on this ticket?
Our Help Desk is asking seeing as they are getting calls regarding sharing to groups.

Normally, with your group definition, it should have worked.

Are you sure this group can actually be found by your SOGoUserSources?

'TestGroup' is returned when doing an Address Book search of Groups (we label them Departments), adding to an event as well as when modifying share aci's.

here is our SOGoUserSource for Departments (groups)

        <dict>
            <key>CNFieldName</key>
            <string>ou</string>
            <key>IDFieldName</key>
            <string>ou</string>
            <key>UIDFieldName</key>
            <string>ou</string>
            <key>baseDN</key>
            <string>ou=Departments,o=*************</string>
            <key>bindDN</key>
            <string>cn=*************</string>
            <key>bindPassword</key>
            <string>*********</string>
            <key>canAuthenticate</key>
            <string>YES</string>
            <key>displayName</key>
            <string>Departments</string>
            <key>hostname</key>
            <string>SOME_LDAP_SERVER</string>
            <key>id</key>
            <string>departments</string>
            <key>isAddressBook</key>
            <string>YES</string>
            <key>port</key>
            <string>389</string>
        </dict>

and ldapsearch results for TestGroup

ldapsearch -x -W -D "cn=*" -b "ou=Departments,o=***" ou=test
Enter LDAP Password:

extended LDIF

#

LDAPv3

base <ou=Departments,o=***> with scope subtree

filter: ou=test

requesting: ALL

#

dn: ou=TestGroup,ou=Departments,o=**
buildingName: TestGroup
departmentSecretary: hardy40
departmentChair: xhardy1
url: asdfg
mail: calendar-noreply@potsdam.edu
gidNumber: 1673
cn: TestGroup
memberUid: hardy40
memberUid: xhardy5
memberUid: xhardy1
departmentMail: asdf
telephoneNumber: sadf
postalAddress: sadf
facsimileTelephoneNumber: 123
objectClass: organizationalunit
objectClass: spotdepartment
objectClass: top
objectClass: extensibleobject
objectClass: posixGroup
ou: TestGroup

I think your group definition is broken.

ou=TestGroup should be an organization unit, but within it, you should have entries that are groups.

For example, I have in my test environment:

dn: ou=groups,dc=inverse,dc=ca
objectClass: organizationalUnit
objectClass: top
ou: groups
structuralObjectClass: organizationalUnit
entryUUID: 211ddaa0-9a1b-102c-9422-4f174b9eaa57
creatorsName: cn=Manager,dc=inverse,dc=ca
createTimestamp: 20080409005336Z
entryCSN: 20080409005336.066795Z#000000#000#000000
modifiersName: cn=Manager,dc=inverse,dc=ca
modifyTimestamp: 20080409005336Z

and:

dn: cn=inverse,ou=groups,dc=inverse,dc=ca
objectClass: groupOfUniqueNames
objectClass: top
objectClass: extensibleObject
uniqueMember: uid=lmarcotte,ou=users,dc=inverse,dc=ca
uniqueMember: uid=jraby,ou=users,dc=inverse,dc=ca
uniqueMember: uid=jrouzier,ou=users,dc=inverse,dc=ca
uniqueMember: uid=lmunro,ou=users,dc=inverse,dc=ca
uniqueMember: uid=flachapelle,ou=users,dc=inverse,dc=ca
cn: inverse
structuralObjectClass: groupOfUniqueNames
entryUUID: 64089d7a-5c27-102f-8db0-afe0408b7e01
creatorsName: cn=ldapadmin,dc=inverse,dc=ca
createTimestamp: 20100924130003Z
mail: inverse@inverse.ca
entryCSN: 20120418162105.471959Z#000000#000#000000
modifiersName: cn=ldapadmin,dc=inverse,dc=ca
modifyTimestamp: 20120418162105Z

Departments in our case are groups, every Department has the following objectclass's

objectClass: top
objectClass: organizationalunit
objectClass: extensibleobject
objectClass: groupofuniquenames
objectClass: posixGroup

according to http://www.sogo.nu/english/support/faq/article/how-are-groups-handled-in-sogo-2.html

If one of the objectClass attribute is equal to group, groupOfNames, groupOfUniqueNames or posixGroup, the entry is considered to be a group.

What confuses me is that groups work perfectly fine when inviting to an event as well as searching the Address Book but fall flat on its face (in our case) when trying to use them for sharing. I mean, if our groups are not configured as you mention then how are they working at all?

Here is one of our 'real' (sanitized) groups from LDAP

ldapsearch -x -W -D "cn=Manager" -b "ou=Departments,o=**" ou='Computing & Technology Services'
Enter LDAP Password:

extended LDIF

#

LDAPv3

base <ou=Departments,o=***> with scope subtree

filter: ou=Computing & Technology Services

requesting: ALL

#

dn: ou=Computing & Technology Services,ou=Departments,o=****
departmentChair: Wilma
departmentSecretary: Janet
buildingName: Stillman Computing Center
buildingName: Kellas Hall
mail: calendar-noreply@potsdam.edu
member: uid=Jane@potsdam.edu,ou=
member: uid=Mindy@potsdam.edu,ou=
gidNumber: 1587
cn: Computing & Technology Services
departmentAlias: CTS
departmentMail: dept_mail@potsdam.edu
title: Director
objectClass: top
objectClass: organizationalunit
objectClass: spotdepartment
objectClass: extensibleobject
objectClass: groupofuniquenames
objectClass: posixGroup
ou: Computing & Technology Services
telephoneNumber: 2089
url: http://www.potsdam.edu/cts/
memberUid: Joe
memberUid: Jill
memberUid: Fred
....

memberUid: Bob
facsimileTelephoneNumber: 3169 / 2868
postalAddress: 209 Stillman Hall

search result

search: 2
result: 0 Success

If I add this group to an event it is parsed out on submit and each memberUid is added to the Event. This group can also be searched via Address Book, just unable to be used for sharing.

Ok, I saw that you've specified:

           <key>IDFieldName</key>
            <string>ou</string>
            <key>UIDFieldName</key>
            <string>ou</string>

which should work with the structure you have, because you have ou= attributes. I guess we would need ssh/gdb access to determine why it fails.

I'll have to speak with my manager and get back to you, might be able to re-configure our pilot (dev) server for such access.

what exactly do you need installed for gdb (SOGo wise that is)?
Do you have a wiki page etc I could follow to ensure the proper SOGo RPM's are installed.

current list of installed RPM's

[root@sogodev ~]# rpm -qa | grep sogo
sogo-2.0.3a-1.centos6.x86_64
sogo-debuginfo-2.0.3a-1.centos6.x86_64
sogo-tool-2.0.3a-1.centos6.x86_64
sogo-devel-2.0.3a-1.centos6.x86_64
[root@sogodev ~]# rpm -qa | grep sope
sope49-gdl1-4.9-20121206_1664.el6.1.x86_64
sope49-mime-4.9-20121206_1664.el6.1.x86_64
sope49-appserver-devel-4.9-20121206_1664.el6.1.x86_64
sope49-gdl1-mysql-4.9-20121206_1664.el6.1.x86_64
sope49-gdl1-contentstore-devel-2.0.3a-1.centos6.x86_64
sope49-core-4.9-20121206_1664.el6.1.x86_64
sope49-ldap-4.9-20121206_1664.el6.1.x86_64
sope49-appserver-4.9-20121206_1664.el6.1.x86_64
sope49-xml-devel-4.9-20121206_1664.el6.1.x86_64
sope49-sbjson-devel-2.3.1-20121206_1664.el6.1.x86_64
sope49-mime-devel-4.9-20121206_1664.el6.1.x86_64
sope49-gdl1-oracle-4.9-20121206_1664.el6.1.x86_64
sope49-gdl1-devel-4.9-20121206_1664.el6.1.x86_64
sope49-core-devel-4.9-20121206_1664.el6.1.x86_64
sope49-cards-2.0.3a-1.centos6.x86_64
sope49-gdl1-contentstore-2.0.3a-1.centos6.x86_64
sope49-xml-4.9-20121206_1664.el6.1.x86_64
sope49-sbjson-2.3.1-20121206_1664.el6.1.x86_64
sope49-ldap-devel-4.9-20121206_1664.el6.1.x86_64
sope49-gdl1-postgresql-4.9-20121206_1664.el6.1.x86_64
sope49-debuginfo-4.9-20121206_1664.el6.1.x86_64
sope49-cards-devel-2.0.3a-1.centos6.x86_64

For us to connect and diagnose in detail, you'll need a proper support contract. Either an incident-based one, or a small timebank.

Okay, filled out the form for a quote. Passed along the info to my manager to see if we can get at least a silver support contract.

I remember i've seen this error as well. On my side it was an problem with how dovecot userdb resolved usernames.

sogo config looked like this at first
...
<dict>
<key>CNFieldName</key>
<string>cn</string>
<key>IDFieldName</key>
<string>cn</string>
<key>UIDFieldName</key>
<string>cn</string>
...

On the dovecot side group userid are resolved as the user part of the e-mail address. But sogo asked to resolve with cn.

An group entry looks like this here:

DG Email, Users, gsg.local

dn: CN=DG Email,CN=Users,DC=gsg,DC=local
objectClass: top
objectClass: group
cn: DG Email
name: DG Email
sAMAccountName: DG Email
mail: info@mydomain.de
member: CN=fh,CN=Users,DC=gsg,DC=local
member: CN=rd,CN=Users,DC=gsg,DC=local
member: CN=ke,CN=Users,DC=gsg,DC=local
member: CN=ag,CN=Users,DC=gsg,DC=local
member: CN=ale,CN=Users,DC=gsg,DC=local

My workaround was to add the user part of the email as description and use this as UIDField in sogo's configuration

description: info

...
<dict>
<key>CNFieldName</key>
<string>cn</string>
<key>IDFieldName</key>
<string>cn</string>
<key>UIDFieldName</key>
<string>description</string>
...

Problem found it's line 804 in SoObjects/SOGo/SOGoUserManager.m

• (NSDictionary ) contactInfosForUserWithUIDorEmail: (NSString ) uid
  inDomain: (NSString ) domain
  {
  NSMutableDictionary currentUser;
  NSString aUID, cacheUid, *jsonUser;
  BOOL newUser;

  / TODO: we need to perform a better validity check on "uid" /

  if ([uid isEqualToString: @"anonymous"])
  currentUser = [self _contactInfosForAnonymous];
  else if ([uid length] > 0
  && [uid rangeOfString: @" "].location == NSNotFound)

If I comment out that last line searching for spaces it works without the above workaround.

This was added relatively recently:

https://github.com/inverse-inc/sogo/commit/37b9aca9408ab3704ae2431bcafdafa7c7b57017

ludovic,

Looks like we now have a Silver Support Agreement. When can we move forward with the investigation of the issue in detail as mentioned on 2013-01-09?

-Ron

Yes, contact me privately so we can setup some time to check this.

Culprit code was removed: https://github.com/inverse-inc/sogo/commit/c066136a06dc0cb63deb3001c4c8db5cdda41f9d

We'll launch the nightly builds shortly.