[
https://issues.apache.org/jira/browse/OPENMEETINGS-943?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13934936#comment-13934936
]
Thibault Le Meur commented on OPENMEETINGS-943:
-----------------------------------------------
Hi Maxim,
My patch was described in ticket 1208/Google-Code
http://code.google.com/p/openmeetings/issues/detail?id=1208
Interresting parts of this patch:
* Add the "ldap_sync_password_to_om" to om_ldap.cfg to optionnaly disable
syncing
Ldap passwords to OM DB
* When authenticating a user, OM checks if the user already exists in its
internal
DB, and if yes, read the ExternalUserType. If this value is NULL or not LDAP,
authentication is done on the internal DB. If authentication Type is LDAP, and
user
is admin and Ldap Passwords are Synchronized to OM DB, then authentication is
done
locally (same as before).
- However if ExternalUserType is LDAP and user is not admin, then
authentication
is done on the LDAP server (even if the LDAP server is down): Note that I think
this
is the same behaviour as before because haven't seen where the code was
supposed to
fallback to Internal DB auth when LDAP server is down.
When LDAP users are authenticated for the first time, they are created into the
OM db (possibily with random passwords if ldap_sync_password_to_om is not
enabled for security reasons). In this case, we must ensure that the LDAP user
can't login into OM by using the 'internal-DB' and the 'random password'.
Because this would mean that any flaw in the random password generator could
lead to identity-spoofing. In order to achieve this we need the ExternalUserType
> 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)
