Right, got it working. Our config is now:
<environment>
<property name="java.naming.factory.initial" value="com.sun.jndi.ldap.LdapCtxFactory"/>
<property name="java.naming.provider.url" value="ldap://myserver.mydomain.local:389"/>
<property name="java.naming.security.authentication" value="simple"/>
<property name="java.naming.security.principal" value="cn=myaccount,ou=Service Accounts,ou=Users,ou=mydepartment
,dc=mydomain,dc=local"/>
<property name="java.naming.security.credentials" value="mypassword"/>
</environment>
<searchBase>dc=mydomain,dc=local</searchBase>
<filter>sAMAccountName=$daisyLogin</filter>
<cache enabled="true" maxCacheSize="3000" maxCacheDuration="1800000"/>
...
Our users in Active Directory are organized in departments directly under the root. Hence the generic <searchBase>.
Mario.
-----Original Message-----
From:
daisy-bounces@... [mailto:
daisy-bounces@...] On Behalf Of Karel Vervaeke
Sent: donderdag 2 juli 2009 13:49
To: Daisy: open source CMS - general mailinglist
Subject: Re: [daisy] re. Daisy 2.3 upgrade LDAP issue
On Thu, Jul 2, 2009 at 1:21 PM, <
Kevin_Walsh@...> wrote:
>
> Dear list,
>
> we continue having the problems described on the list after setting up 2.3
> on a clean, new machine. When exporting from the 2.2 machine and importing
> on the new one, the ldap authentication continues to fail.
>
> From Karel's mail I learned that we need the searchBase (the repository will
> not start without) and that 2.3 uses a two step authentication: First
> finding the user's path and then authenticating him/her. I would love this
> to work, because up to now every user group had to have their own
> authentication scheme.
>
> What I do not get is (config lines taken from Karel's answer):
>
> - <searchBase>cn=Users,dc=server,dc=domain,dc=be</searchBase>
> Why do I need to provide a qualified searchBase? Shouldn't this be
> exactly what daisy requests from the ldap server? What if the user sits on
> dc=Server2?
You can have multiple <scheme> elements in your ldap configuration.
You can have one with
<searchBase>cn=Users,dc=server,dc=domain,dc=be</searchBase>
and one with
<searchBase>cn=Users,dc=server2,dc=domain,dc=be</searchBase>
A wildcard approach (cn=Users,dc=*,dc=domain,dc=be) is not possible here.
>
> - <filter>cn=$daisyLogin</filter>
> Which filter options are there other than the $daisyLogin (and the
> userPrincipalName Karel used in his example). Must we use a filter? What
> does it pass to the ldap-server?
$daisyLogin is the only parameter there. The filter is required,
because this is the used to find the actual user in ldap.
> - <property name="java.naming.security.principal"
> value="cn=daisyauth,cn=Users,dc=server,dc=domain,dc=be"/>
> Is this a daisy user, or a user that was set up for the purpose of
> getting ldap-tree infos? Our server accepts an anonymous bind, so we
> shouldn't need this, nor the security credentials?
If your server accepts an anonymous bind, leave out the
java.naming.security.principal & java.naming.security.credentials
parameters
> Thanks in advance,
> Kevin
>
HTH,
Karel
_______________________________________________
daisy community mailing list
Professional Daisy support:
http://outerthought.org/en/services/daisy/support.htmlmail to:
daisy@...
list information:
http://lists.cocoondev.org/mailman/listinfo/daisy_______________________________________________
daisy community mailing list
Professional Daisy support:
http://outerthought.org/en/services/daisy/support.htmlmail to:
daisy@...
list information:
http://lists.cocoondev.org/mailman/listinfo/daisy