One of the biggest mistakes that people make when setting up LDAP is trying to mirror the corporate structure as directories in LDAP. It doesn't work well, and when people move around, it's a real pain for maintenance.
So my LDAP directory is organized more like this:
ou=employees,dc=mousetech,dc=com
[ list of CNs of employees, with uid and password attributes]
ou=users,ou=tomcat,ou=services,dc=mousetech,dc=com
[ list of memberUids corresponding to employee uids]
ou=groups,ou=tomcat,ou=services,dc=mousetech,dc=com
ou=administrators,ou=groups,ou=tomcat,ou=services,dc=mousetech,dc=com
[ list of memberUids of authorized administrators ]
ou=auditors,ou=groups,ou=tomcat,ou=services,dc=mousetech,dc=com
[ list of memberUids of authorized auditors ]
There are also 2 different ways to
test authorization using the LDAP realm. One is to configure it so that the Realm will attempt to connect to the LDAP server using the user-supplied id and password from the login form. Successful connection means successful login.
The other way to test authorization is to use a general query connection userid/password to connect to LDAP and have the LDAP server do searches for the actual userid/password. You must provide the search query.
The search query under the scheme I outlined above would be more like this:
I didn't have a working example handy, so this isn't a full and authoritative solution, but it's the basic plan that I use. The Tomcat LDAP Realm docs are more complete and accurate.
Note that if your "LDAP" is actually Active Directory and you want to use the user's Windows login credentials, they have their own particular format.