« Return to Thread: re. Daisy 2.3 upgrade LDAP issue
Re: re. Daisy 2.3 upgrade LDAP issue
by Karel Vervaeke
::
Rate this Message:
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.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy
>
> 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.html
mail to: daisy@...
list information: http://lists.cocoondev.org/mailman/listinfo/daisy
« Return to Thread: re. Daisy 2.3 upgrade LDAP issue
| Free embeddable forum powered by Nabble | Forum Help |
