[
https://issues.apache.org/jira/browse/OPENMEETINGS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13935216#comment-13935216
]
Thibault Le Meur commented on OPENMEETINGS-943:
-----------------------------------------------
@solomax,
No it is not ok to expose the LDAP datat to everyone. but why do you ask ? May
you be a little more specific on this ?
I understand LDAP, but I'm not a Java expert... maybe we can end up with
something ;-)
I'm not happy with the current LDAP authentication code. It's rather weird !
Basically here is what is done:
* read LDAP config
* create an LDAP connection with LdapAuthBase using admin_dn / admin_password
- this authenticates the admin user twice ! because it calls
loginToLdapServer first (which uses ldap admin credentials), then does the user
authentication with the ldap admin again! (ldapAuthBase.java 119 and 121)
* in case of "OPENLDAP", it does a search-and-bind: meaning it uses the
ldap_admin LDAP connection to retrieve the userDN from the username, then it
authenticates the userDN against the directory
* in case of AD, it does a DIRECT bind givin only the username and password
without giving the userDN
note:
- There is no SIMPLE-bind implemented: in simple bind you give the attribute
holding the username (for instance uid or cn), then userBase (for instance
ou=people,dc=mydom,dc=com), and the application tries to authenticate the DN
"uid=<username>,userBase" with teh given password
- There seems to be a confusion with the NONE ldap security setup. in OM it is
intended as using the LDAP directory as a simple database without using it's
authentication feature. In Java NONE means that there is an anonymous bind to
the directory, but this would be used to search for a userDN and then perfom
authentication.
The correct way to handle this:
* First:
- if bind_dn and bind_pwd are set, first conect to the LDAP directory with
these credentials
- if empty, then just use an nonymous bind to the directory
* Then
- if OM is set to AuthLDAP=NONE, just use the connection to retrieve
informations from the directory
-if OM is set to AuthLDAP=OPENLDAP (should be SEARCHANDBIND actually),
search for the userDN and then perform a bind to the directory with
userDN/provided PWD
- if OM is set to AuthLDAP=SIMPLEBIND, construct the userDN from the
username, the user attribute (for instance cn or uid), and the userBase, and
then perform a bind with userDN and provided PWD
- if OM is set to AuthLDAP=SIMPLE (to be backward compliant), let's try a
bind with the provided user/password
> OM3.0: login with LDAP user not working
> ---------------------------------------
>
> Key: OPENMEETINGS-943
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-943
> Project: Openmeetings
> Issue Type: Bug
> Components: UI
> Affects Versions: 3.0.0
> Environment: Linux
> Reporter: Thibault Le Meur
> Assignee: Maxim Solodovnik
> Priority: Blocker
> Fix For: 3.1.0, 3.0.1
>
>
> With OM3.0 login with an LDAP user fails:
> * bind to the LDAP directory is successful
> * new user are created into DB
> * no error message such as invalid password is sent, but the user is
> redirected to the signin page
> Example debug log (in this case the user has alredy been created inside OM
> DB):
> -----------------------------------
> DEBUG 03-12 10:56:51.098 o.a.o.l.LdapLoginManagement:235
> [http-nio-0.0.0.0-5080-exec-1] - LdapLoginmanagement.doLdapLogin
> DEBUG 03-12 10:56:51.098 o.a.o.l.LdapLoginManagement:199
> [http-nio-0.0.0.0-5080-exec-1] - LdapLoginmanagement.getLdapConfigData
> DEBUG 03-12 10:56:51.098 o.a.o.l.LdapLoginManagement:212
> [http-nio-0.0.0.0-5080-exec-1] - LdapLoginmanagement.readConfig :
> /opt/openmeetings-red5/webapps/openmeetings/conf/ldap-myorg.conf
> DEBUG 03-12 10:56:51.099 o.a.o.l.LdapLoginManagement:139
> [http-nio-0.0.0.0-5080-exec-1] - isValidAuthType
> DEBUG 03-12 10:56:51.099 o.a.o.l.LdapLoginManagement:371
> [http-nio-0.0.0.0-5080-exec-1] - Searching userdata with LDAP Search Filter
> :(uid=myuserid)
> DEBUG 03-12 10:56:51.099 o.a.o.l.LdapAuthBase:84
> [http-nio-0.0.0.0-5080-exec-1] - LdapAuthBase
> DEBUG 03-12 10:56:51.100 o.a.o.l.LdapLoginManagement:380
> [http-nio-0.0.0.0-5080-exec-1] - authenticating admin...
> DEBUG 03-12 10:56:51.100 o.a.o.l.LdapAuthBase:101
> [http-nio-0.0.0.0-5080-exec-1] - authenticateUser
> DEBUG 03-12 10:56:51.100 o.a.o.l.LdapAuthBase:117
> [http-nio-0.0.0.0-5080-exec-1] -
> Authentification to LDAP - Server start
> DEBUG 03-12 10:56:51.100 o.a.o.l.LdapAuthBase:151
> [http-nio-0.0.0.0-5080-exec-1] - loginToLdapServer
> DEBUG 03-12 10:56:51.214 o.a.o.l.LdapLoginManagement:383
> [http-nio-0.0.0.0-5080-exec-1] - Checking server type...
> DEBUG 03-12 10:56:51.214 o.a.o.l.LdapLoginManagement:387
> [http-nio-0.0.0.0-5080-exec-1] - LDAP server is OpenLDAP
> DEBUG 03-12 10:56:51.215 o.a.o.l.LdapLoginManagement:388
> [http-nio-0.0.0.0-5080-exec-1] - LDAP search base: DC=myorg,DC=fr
> DEBUG 03-12 10:56:51.245 o.a.o.l.LdapLoginManagement:393
> [http-nio-0.0.0.0-5080-exec-1] - Authentication with DN:
> uid=myuserid,ou=people,dc=subdom,DC=myorg,DC=fr
> DEBUG 03-12 10:56:51.246 o.a.o.l.LdapAuthBase:101
> [http-nio-0.0.0.0-5080-exec-1] - authenticateUser
> DEBUG 03-12 10:56:51.246 o.a.o.l.LdapAuthBase:117
> [http-nio-0.0.0.0-5080-exec-1] -
> Authentification to LDAP - Server start
> DEBUG 03-12 10:56:51.246 o.a.o.l.LdapAuthBase:151
> [http-nio-0.0.0.0-5080-exec-1] - loginToLdapServer
> DEBUG 03-12 10:56:51.344 o.a.o.d.u.UserManager:1036
> [http-nio-0.0.0.0-5080-exec-1] - Usermanagement.getUserByLogin : myuserid
> DEBUG 03-12 10:56:51.350 o.a.o.l.LdapAuthBase:174
> [http-nio-0.0.0.0-5080-exec-1] - getData
> DEBUG 03-12 10:56:51.354 o.a.o.l.LdapLoginManagement:534
> [http-nio-0.0.0.0-5080-exec-1] - User already exists -> Update of current
> passwd
> DEBUG 03-12 10:56:51.355 o.a.o.d.d.s.SessiondataDao:158
> [http-nio-0.0.0.0-5080-exec-1] - updateUser User: 3 ||
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> DEBUG 03-12 10:56:51.357 o.a.o.d.d.s.SessiondataDao:174
> [http-nio-0.0.0.0-5080-exec-1] - Found session to update:
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx userId: 3
> DEBUG 03-12 10:56:51.362 o.a.o.l.LdapLoginManagement:728
> [http-nio-0.0.0.0-5080-exec-1] - LdapLoginmanagement.createUserFromLdapData
> DEBUG 03-12 10:56:51.375 o.a.w.u.c.CookieUtils:266
> [http-nio-0.0.0.0-5080-exec-1] - Unable to find Cookie with name=LoggedIn and
> request URI=signin?0-1.IBehaviorListener.2-signin
> DEBUG 03-12 10:56:51.376 o.a.wicket.Page:871 [http-nio-0.0.0.0-5080-exec-1] -
> ending request for page [Page class =
> org.apache.openmeetings.web.pages.auth.SignInPage, id = 0, render count = 1],
> request org.apache.wicket.protocol.http.servlet.ServletWebRequest@55084cc9
> -----------------------------------
> While checking with Firebug, one can notice that no Cookie named LoggedIn is
> set (which is also true when a local-DB user is logged in).
--
This message was sent by Atlassian JIRA
(v6.2#6252)
