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?
- <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?
- <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?
Thanks in advance,
Kevin
Hi,
I experimented with Daisy + ldap (on a local windows
2008 active
directory) today; First off, my earlier suggestion was not complete
-
as you may have guessed by comparing with Matthias' suggestions...
Here's what changed between Daisiy 2.2 and Daisy 2.3.
In Daisy 2.2, the authentication check was nothing more than a simple
authentication check (a 'bind' in ldap terminology), using the
credentials entered in the daisy login screen as the user's DN and
password.
In Daisy 2.3, the authentication check has two phases:
First user
object is searched (hence the searchBase and filter) (in order to find
the user's DN) and only then the password is checked.
The main use case for the new approach is when an organisation's users
are not all in the same unit (e.g. dc=unit1users,dc=example,dc=com &
dc=unit2users,dc=example,dc=com)
Hence, this configuration snippet should work:
<scheme name="secret" description="LDAP
Secret">
<environment>
<property name="java.naming.factory.initial"
value="com.sun.jndi.ldap.LdapCtxFactory"/>
<property name="java.naming.provider.url"
value="ldap://server.domain.be:389"/>
<property name="java.naming.security.authentication"
value="simple"/>
<property name="java.naming.security.principal"
value="cn=daisyauth,cn=Users,dc=server,dc=domain,dc=be"/>
<property name="java.naming.security.credentials" value="xxverysecretxx"/>
</environment>
<searchBase>cn=Users,dc=server,dc=domain,dc=be</searchBase>
<filter>cn=$daisyLogin</filter>
<cache enabled="true" maxCacheSize="3000" maxCacheDuration="1800000"/>
<autoCreateUser>...</autoCreateUser>
</scheme>
One gotcha that I ran into: You have to be careful
about the user
names, because the windows logon name
may be different from the cn in the ldap directory - for example I
have a user which looks like this:
LDAP DN: cn=Karel Vervaeke,cn=Users,...
User logon name: karel@...
User logon name (pre-Windows 2000): KRB\karel
With the configuration snippet above, I have to use
"Karel Vervaeke"
when logging in to daisy. "karel" is not the correct Daisy
user name.
If you need the Daisy user name to be "karel", try using the
following filter:
<filter>sAMAccountName=$daisyLogin</filter>
or
<filter>userPrincipalName=$daisyLogin@...</filter>
HTH,
Karel
On Thu, Jun 25, 2009 at 2:31 PM, Bruno Dumon<bruno@...>
wrote:
> If the LDAP authentication failed, whatever the reason, you should
see
> a line in the log starting with the text "Failed to authenticate
user
> with following environment:" followed by the settings and the
> exception, if any.
>
> This is logged to the repository log on DEBUG level, thus to the file
> {repodata}/logs/daisy
>
> The LDAP exception is not forwarded to the client in order not to
> reveal any sensitive information.
>
> On Thu, Jun 25, 2009 at 1:38 PM, Mario
> Brackeva<Mario.Brackeva@...> wrote:
>> I changed the log entry like you advised, but it doesn't make
a difference.
>>
>> I cleaned up the test server and restored the production backup
from last night. I then started daisy (2.2) and all is well.
>> I then upgraded (link to the 2.3 directory instead of 2.2 and
run the upgrade sql script) and applied your "searchBase" patch
to the myconfig.xml file. Started again, but can't log in anymore with
LDAP users.
>>
>> I then replaced the file lib/daisy/jars/daisy-auth-ldap-2.3.jar
with the old one from 2.2, and ...
>> ... it works fine now!
>>
>> Some other issues:
>> - When I edit a document, I don't get the WYSIWYG editor, just
the plain text editor
>> - I don't see the "search&replace" option
>>
>>
>> Mario.
Heinrich Deichmann-Schuhe GmbH & Co. KG, Deichmannweg 9, 45359 Essen
Registergericht Essen HRA 3564, Umsatzsteueridentifikations-Nr.: DE 119663402
Persönlich haftende Gesellschafterin ist die Deichmann Verwaltungs- und
Handelsgesellschaft mbH mit Sitz in Essen, Registergericht Essen HRB 2279.
Geschäftsführer:
Dr. Heinz-Horst Deichmann * Heinrich Otto Deichmann (Geschäftsführende Gesellschafter)
Martin Fischer * Bjørn Gulden * Martin Heynen * Walter Neuroth
Karsten Schütt * Wolfgang Wislsperger_______________________________________________
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