Hello Christian sorry for the bad formatting, I was working ona remote station and by copy&pasting the file it must somehow have added the , either in Webmail or whatever. Exporting the config in the console with sogo-tool it looks good.
As you say, lukas.kamber is the identification. With this setup, it is possible to invite an attendee with Thunderbird/Lightning/Integrator. But we would like to get rid of Thunderbird and only use SOGo/Firefox. To replace TB, the invitations have to work. It obviously is just a missing mapping username<->userid. All the rest works fine with the setting "sAMAccountName". I do not know whether this is a configuration issue or a bug. Thanks, Lukas Am Donnerstag, 28. Februar 2013 11:58 CET, Christian Mack <[email protected]> schrieb: > Hello Lukas Kamber > > > Am 2013-02-27 14:45, schrieb Lukas Kamber: > > > > Am Mittwoch, 27. Februar 2013 10:56 CET, Christian Mack > > <[email protected]> schrieb: > >> > >> Am 2013-02-26 16:23, schrieb Lukas Kamber: > >> > > >> > we have a problem that we can't invite attendees to an event anymore. > >> > The problem is the AJAX call that queries the free/busy times of the > >> > attendee. In the URL it uses a numeric id instead of a username: > >> > Wrong URL: > >> > https://[SOGO > >> > host]/SOGo/so/2020/freebusy.ifb/ajaxRead?sday=20130217&eday=20130309 > >> > > >> > Correct URL: > >> > https://[SOGO > >> > > >> host]/SOGo/so/lukas.kamber/freebusy.ifb/ajaxRead?sday=20130217&eday=20130309 > >> > > >> > This used to work in earlier 2.0.x versions. We have our users stored in > >> > an Active Directory. Is this a known issue or does anyone have a hint if > >> > I have to change the user data in the Active Directory? > >> > > >> > >> You have to provide some additional info for us. > >> What does your configuration look like? > >> Especially your SOGoUserSources? > >> > > > > we are running the latest version of SOGo, User Sources: > > > > <key>SOGoUserSources</key> > > <array> > > <dict> > > <key>CNFieldName</key> > > <string>cn</string> > > <key>IDFieldName</key> > > <string>sAMAccountName</string> > > <key>UIDFieldName</key> > > &nbs p; <string>sAMAccountName</string> > > <key>baseDN</key> > > <string>DC=intranet,DC=domain,DC=ch</string> > > <key>bindDN</key> > > > > <string>CN=account,OU=group,OU=company,DC=intranet,DC=domain,DC=ch</string> > > <key>bindFields</key> > > <array> > > <string>sAMAccountName</string> > > </array> > > <key>bindPassword</key> > > <string>*****</string> > > <key>canAuthenticate</key> > > <string>YES</string> > > <key>displayName</key> > > &n bsp; <string>Active Directory</string> > > <key>hostname</key> > > <string>****</string> > > <key>id</key> > > <string>ActiveDirectory</string> > > <key>isAddressBook</key> > > <string>No</string> > > <key>port</key> > > &nb sp; <string>389</string> > > <key>scope</key> > > <string>sub</string> > > <key>type</key> > > <string>ldap</string> > > </dict> > > <dict> > > > > Is this useful to you? > > > > Yes, it shows, that you always use "sAMAccountName" to identify the user. > I assume you use "lukas.kamber" in sAMAccountName for your tests. > > > Where do these " " come from? > They shouldn't be there. > > > Kind regards, > Christian Mack > > -- > Christian Mack > Gruppe Informationsdienste > Rechenzentrum Universität Konstanz > -- > [email protected] > https://inverse.ca/sogo/lists > -- [email protected] https://inverse.ca/sogo/lists
