[CalendarServer-users] LDAP Authentication fields

Andre LaBranche dre at apple.com
Wed Apr 23 10:47:19 PDT 2014

On Apr 23, 2014, at 6:13 AM, Ulrich Fourier <ulrich.fourier at rockyourlife.de> wrote:

> Hi,
> thank you so far, I really appreciate your help.
> Ok I'm on Debian Squeeze and I think i need to compile the new version
> from source.
> Which version is compatible with squeeze, how can I install them from
> source?


If you have to ask this, it will probably be challenging. I don’t know anything specific about Squeeze, but in general the same process can be used on any viable platform. The high level overview is to install the dependencies required for our bootstrapping code to run, then run that code which fetches more dependencies, then run Calendar Server.

We don’t have much in the way of documentation (consider that we are *also* an open source project, but not *only* an open source project - the primary vehicle for Calendar Server doesn’t require much technical documentation), although I did recently make a start on what will hopefully become a complete document, eventually:


Note that the above applies to trunk and not any prior release, but you should probably use the CalendarServer-5.2 release since trunk is not stable right now. We don’t have anything like ‘porting instructions’ for various platforms, and in general we rely on the native package managers for those platforms to do the porting work.

Perhaps you could contact whoever developed the Calendar Server package you’re using now and ask if they can build a newer one. Very recently, Ubuntu Trusty received a Calendar Server 5.2 package, thanks to Rahul Amaran. I’m sure it was no small amount of work :)


> I can't find the information on the website.
> Thanks
> Uli
> On 20.04.14 22:48, Andre LaBranche wrote:
>> Hi,
>> loginEnabledAttr isn’t what you want for this purpose. This setting designates an LDAP attribute on the user record that can be checked to determine if a user is allowed to log into Calendar Server; along with loginEnabledValue which allows you to define what value of loginEnabledAttr is interpreted to mean the setting is enabled.
>> Also, I’m sorry that I forgot to ask you what version you are using. 2.4 is positively ancient, and after a quick glance I’m not sure that there’s any way to configure 2.4 to do what you want. I heard on the internet that 5.2 was recently packaged for Ubuntu ’Trusty' :)
>> In a more modern version of Calendar Server, I think all you need to edit is
>> rdnSchema —> users —> mapping —> recordName
>> the default value of that setting is ‘uid’, but you can set it to whatever. You might want to be aware of any potential syntax differences between ‘uid’ and your chosen attribute. You can examine this by looking at your LDAP server’s schema. For example, in OS X, you can check in /etc/openldap/schema:
>> grep -r "'initials'" -A 10 /etc/openldap/schema
>> microsoft.std.schema claims the syntax for this attribute is
>>, single value, no specification of case matching.
>> microsoft.ext.schema has a different definition, which may matter if you’re using that schema.
>> According to core.ldif and core.schema, ‘uid’ uses
>>{256}, and ignores case for equality and substring matches.
>> You might also need to check if the LDAP server’s indices for ‘initials’ are similar to the ‘uid’ indices, to make sure the performance and supported search types are the same.
>> Cheers,
>> -dre
>> On Apr 20, 2014, at 12:26 PM, Ulrich Fourier <ulrich.fourier at rockyourlife.de> wrote:
>>> Hi,
>>> thanks for your answer, Andre.
>>> I think the " loginEnabledAttr" - option was the one I was looking for, but I have the calendarserver in version 2.4 and the settings (caldavd.plist) is in the plist format so I needed to convert the loginEnabledAttr option now my ldap settings looks like this: 
>>> <!--  OpenLDAP Directory Service -->
>>>    <key>DirectoryService</key>
>>>    <dict>
>>>      <key>type</key>
>>>      <string>twistedcaldav.directory.ldapdirectory.LdapDirectoryService</string>
>>>      <key>params</key>
>>>      <dict>
>>>        <key>cacheTimeout</key>
>>>        <integer>30</integer>
>>>        <key>realmName</key>
>>>        <string>Test Realm</string>
>>>        <key>uri</key>
>>>        <string>ldap://localhost:389/</string>
>>>        <key>tls</key>
>>>        <false/>
>>>        <key>tlsCACertFile</key>
>>>        <string></string>
>>>        <key>tlsCACertDir</key>
>>>        <string></string>
>>>        <key>tlsRequireCert</key>
>>>        <string>demand</string>
>>>        <key>credentials</key>
>>>        <dict>
>>>          <key>initials</key>
>>>          <string>LDAPUSER</string>
>>>          <key>password</key>
>>>          <string>PASSWORD</string>
>>> </dict>
>>>        <key>authMethod</key>
>>>        <string>LDAP</string>
>>>        <key>rdnSchema</key>
>>>        <dict>
>>>          <key>base</key>
>>>          <string>dc=rockyourlife,dc=de</string>
>>>          <key>guidAttr</key>
>>>          <string>entryUUID</string>
>>>          <key>users</key>
>>>          <dict>
>>>            <key>rdn</key>
>>>            <string>ou=People</string>
>>>            <key>attr</key>
>>>            <string>cn</string>
>>>            <key>emailSuffix</key>
>>>            <string></string>
>>>            <key>filter</key>
>>>            <string>(objectClass=inetOrgPerson)</string>
>>>            <key>loginEnabledAttr</key>
>>>            <string>initials</string>
>>>            <key>loginEnabledValue</key>
>>>            <true/>
>>>          </dict>
>>> I didn't changed the following group setting etc., because I'm not quite sure if I want this feature.
>>> I reinstalled the server, so that I'm sure there are no changes in the source files made by myself. 
>>> Now I'm still getting the LDAP no such Object error message. 
>>> And he logs the wrong filter again: 
>>> (&(&(!(objectClass=organizationalUnit))(objectClass=inetOrgPerson))(|(uid=UlrichFourier)(userid=UlrichFourier)))
>>> I don't want him to look at the uid or userid, I want him to compare the username with a LDAP field called Initials.
>>> Thank you so far
>>> Ulrich Fourier
>>> On Thu Apr 17 19:13:54 2014, Andre LaBranche wrote:
>>>> Hi,
>>>> It would be advisable to attempt to configure the ldap client for your site using caldavd.plist, instead of editing the code. Our ldap client is highly configurable / flexible, and so far I haven't found any reason to need to edit the source code to adapt our ldap client to a wide variety different ldap servers.
>>>> You can look at http://trac.calendarserver.org/browser/CalendarServer/trunk/twistedcaldav/stdconfig.py under twistedcaldav.directory.ldapdirectory.LdapDirectoryService to see all the available settings.
>>>> If the change you need cannot be represented using the plist, kindly let us know exactly what you're doing so we can consider making whatever you are doing configurable.
>>>> -dre
>>>> On Apr 17, 2014, at 8:18 AM, Ulrich Fourier <ulrich.fourier at rockyourlife.de> wrote:
>>>>> So i fixed it by editing the source file so that my custom field got
>>>>> also checked.
>>>>> Now I'm working on another error message, which also appeared earlier:
>>>>> ldap.NO_SUCH_OBJECT: {'desc': 'No such object'}
>>>>> I tested the request he is sending to the server(the filter and the
>>>>> attributes) with the phpldapbrowser and got the correct response.
>>>>> Thanks,
>>>>> Ulrich
>>>>> On 17.04.14 15:09, Ulrich Fourier wrote:
>>>>>> Hi everyone,
>>>>>> A simple and stupid question:
>>>>>> I'm currently working with the calendarserver and a ldap server.
>>>>>> Users should be authenticated with the ldap server, but the uid field
>>>>>> what is used by the calendarserver to look for the right user, is used
>>>>>> for something different in my setup. I have there an integer. So how can
>>>>>> i configure calendarserver to use the 'cn' or any other self defined field?
>>>>>> Thank you
>>>>>> Ulrich Fourier
>>>>>> _______________________________________________
>>>>>> calendarserver-users mailing list
>>>>>> calendarserver-users at lists.macosforge.org
>>>>>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users
>>>>> _______________________________________________
>>>>> calendarserver-users mailing list
>>>>> calendarserver-users at lists.macosforge.org
>>>>> https://lists.macosforge.org/mailman/listinfo/calendarserver-users

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.macosforge.org/pipermail/calendarserver-users/attachments/20140423/cbec0cbd/attachment-0001.html>

More information about the calendarserver-users mailing list