General discussion on installation and configuration of SOGo

Text archives Help


Re: [SOGo] Problem with Calendars shared for LDAP Groups since 2.0.4b.


Chronological Thread 
  • From: Achim Gottinger < >
  • To:
  • Subject: Re: [SOGo] Problem with Calendars shared for LDAP Groups since 2.0.4b.
  • Date: Fri, 22 Feb 2013 17:00:55 +0100

http://www.sogo.nu/bugs/view.php?id=2253

Am 22.02.2013 16:39, schrieb Achim Gottinger:
" type="cite">
Am 22.02.2013 15:50, schrieb Achim Gottinger:
" type="cite">
Am 22.02.2013 13:21, schrieb Achim Gottinger:
" type="cite">Am 19.02.2013 13:01, schrieb Achim Gottinger:
Am 19.02.2013 12:16, schrieb Achim Gottinger:
Am 17.02.2013 14:59, schrieb Achim Gottinger:
Since I upgraded to SOGo 2.0.4b the Calendars I had shared for LDAP Groups before are no longer visible for the members of these groups. Also they do not show up if i try to readd them manually via the web fronted calendar abo. Fortunately sharing these calendars for autheticated users works again so i shared these calendars for all authenticated users meanwhile.
Looking at the git commits i guess some change in sope caused that different behaviour. I have abit of spare time to add a few debugging lines to the source and try to detect where it went wrong but i'd be glad for an pointer into the right direction.

achim~
Getting lost in the source code here. I can not find the place where the ACL's for LDAP Groups get resolved.
To specify my issue abit more. I created an user to share a few google calendars for users here. I can add the ACL for my LDAP Groups via Thunderbird and SOGo-Web, edit them and they get still stored proper in the mysql db. I did the configuration with 2.0.3a and at that time the calendars showed up for all members of the assigned LDAP Group. For some reason this is no longer the case with 2.0.4b, i'm unsure if i tested it with 2.0.4a. And now even if i downggrade to 2.0.3a the calendars do not appear and can neighter be manually subscribed.
The sogo logs are not helpfull and debugging samba4 LDAP queries is abit painfull so i thought it's easier to add a bit more verbosity to logging output in the source if i could only find an good point to start.

Thanks in advance
achim~
So far this is the memcached log when I hit the plus sign at the subscriptions dialog for the user google whom shares the calendars for the group info. jg is the current user.

<27 get jg+settings
>27 sending key jg+settings
>27 END
<27 get google/Calendar/personal+acl
>27 END
<27 get google/Calendar/personal+acl
>27 END
<27 set google/Calendar/personal+acl 0 300 10
>27 STORED
<27 set google/Calendar/personal+acl 0 300 27
>27 STORED
<27 get google/Calendar/7C2F-510A6D80-1-62488280+acl
>27 END
<27 get info+
>27 END
.........
<27 get jxxxx.gxxxx+attributes
>27 END
<27 set jxxxx.gxxxx+attributes 0 300 4
>27 STORED
..........
<27 set info+ 0 300 39
>27 STORED
<27 get info+
>27 sending key info+
>27 END

To me that memcached log looked like the group acls get inspected and the assigned users are enumerated but then the acls are not mapped correct to the current user. I tried to debug what's going on with gdb and inspecting objects with the po command but i'm still struggling to find the correct place for an breakpoint and i'm unsure if the problem is located inside sope or sogo. I'd really appreciate any input on how to figure out the cause of the problem.

achim~

K, an good point for an breakpoint was [SOGOGroup _member]

In line 264

login = [um getLoginForDN: [dn lowercaseString]


If the inspected user dn has the description attribute set login=description otherwise login=sAMAccountName.
If description is returned the next line
user = [SOGoUser userWithLogin: login roles:nil]
returns nil.

For my LDAP Group's (Samba4 AD) I use

CNFieldsName: cn
IDFieldName: cn
UIDFieldName: description

For the Users these are all sAMAccountName.

So as an quick workaround i removed the description attribute values for the users i do not need em anyway and the calendars can be subscribed again.
Inspecting things abit further:

SOGoUserManager.m getLoginForDN

does call currentSource lookupLoginByDN in line 972.

currentSource is LDAPSource.m

And in that function the UIDFiled variable has the value "description" coming from my LDAP Group definitions if the User has "description" defined in hist ldap entry.
And so that value is returned instead of the attribue samaccountname's value.

This looks like an bug to me, i'll try to describe that in an bug report.

cheers,
achim~





Archive powered by MHonArc 2.6.18.

Top of page