Hello Christian,
I am one step further. The problem is not the LDAP sorce.
We have the Active Directory as user authentication sorce. Furthermore, we have
several adressbooks that are configured as SQL sources:
{
type=sql;
id=AdrHandwerker;
viewURL = "mysql://user:pw@host:3306/database/tbl_Contacts_Sogo_Handwerker";
canAuthenticate=NO;
displayName="Handwerker";
isAddressBook=YES;
},
This data is exported from an ERP system and then imported by a cronjob into
the tables and thus accessible in Sogo. Works like a charm.
The employees are also in these tables, and they have the - obviously - the
same email address. Now when I try to invite an employee, it mixes up the
adressbook user source and the LDAP user source. If I remove the employees as
adressbook, the invitation works as the mailadress now is unique and points to
the LDAP user source.
One possible solution would be that I can configure an adressbook with a
constraint that it is not searched in the calendar invitation.
Do you see a possibility to solve this problem?
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
