Hi,
I wrote an article about LDAP configuration in Tomcat on jspwiki.org.
That may be of some help. Take a look at:
http://www.jspwiki.org/wiki/WebContainerAuthenticationViaLDAP
This may be related with how 'userPassword' is encrypted in LDAP. It
seems this configuration(comparison mode) only works for plaintext
passwords. You may not log into JSPWiki or other applications if the
password is encrypted in other digest algorithms like MD5,SHA,SSHA, etc.
I've used LDAP authentication for JSPWiki since 2.6.x. The following is
my configuration fragment:
<Realm className="org.apache.catalina.realm.JNDIRealm" debug="99"
connectionURL="ldap://localhost:389"
userPattern="uid={0}, ou=People,dc=example,dc=com"
roleBase="ou=Groups,dc=example,dc=com"
roleName="cn"
roleSubtree="true"
roleSearch="(uniqueMember={0})"
/>
David Gao ([email protected])
:
Hi Wyllys,
The same problem I faced when I tried for LDAp authentication.
The role name you mentioned in server.xml of Tomcat must match with role
name you specified in web.xml of Jspwiki.
How you are extracting ROLE Name from LDAP
<Realm className="org.apache.catalina.realm.JNDIRealm"
connectionURL="ldap://URL:389"
connectionName="uid=admin,ou=Directory
Administrators,dc=domain,dc=com"
connectionPassword="admin"
userBase="ou=Root,dc=domain,dc=com"
userSubtree="true"
userSearch="(uid={0})"
userRoleName="groups"
/>
Choosing userRoleName is very important.
e.g. User is member of 2 groups
groups= abc
groups=pqr
You can either use abc or pqr in web.xml of Jspwiki for authenticated area
and admin area.
There may be many groups or one common group which include all members.
Just try this out and let us know result.
Regards,
Trupti Patil
Wyllys Ingersoll wrote:
Just following up on my earlier problem with LDAP login using JSPWiki
2.8.1
The problem seems to be in how Login.jsp handles the "redirect" after a
user
successfully authenticates (using container-based LDAP authentication).
The login succeeds and the user is redirected to
"Login.jsp?redirect=Main",
but Login.jsp doesn't want to allow that to happen and does not perform
the redirect, instead it brings up the "/error/Forbidden.html" page.
I can click through on the "Better luck next time" link and get to the
main page and show up as "authenticated" and continue as an authenticated
user, with all of the privileges I would expect.
Login.jsp seems to be broken in some way when combined with LDAP container
auth,
but I'm not enough of a JAAS expert to go in and debug it.
-Wyllys
Wyllys Ingersoll wrote:
I installed JSPWiki 2.8.1 and configured it to use LDAP authentication
with my
corporate LDAP server. User are able to login and authenticate using
their
LDAP name/password combinations correctly, but immediately afterwards
they are
greeted with the "Forbidden" page:
...
Forbidden
Sorry, but you are not allowed to do that.
Usually we block access to something because you do not have the correct
privileges (e.g., read, edit, comment) for the page you are looking for.
In this particular case, it is likely that you are not listed in the
page’s access control list or that your privileges aren’t high enough
(you want to edit, but ACL only allows ‘read’).
It is also possible that JSPWiki cannot find its security policy, or
that the policy is not configured correctly. Either of these cases would
cause JSPWiki to block access, too.
Better luck next time.
...
Also, I see this in the error log upon comletion of the Login form:
...
[21/Mar/2009:06:48:28] security ( 5976): Error while checking role
membership of XXXX in Admin: [NSACL4330] HTTP5094: while trying to
get attribute "user-exists"
[NSACL4330] HTTP5094: while trying to get attribute "userdn"
[NSACL5860] HTTP5113: ldap password check: LDAP error: "Insufficient
access"
...
When I click on the "better luck next time" link, the "G'day" message
shows my username and says I am authenticated and the users seem to have
the necessary privileges (the "Edit"
button is available, etc).
What can be done to fix the issue that is causing the "Forbidden" page
to come up immediately after login?
Any help would be much appreciated.
Thanks,
Wyllys