Re: Ldap access beeing slow + proposed Patch
hola, well, i dont see myself as the OM Ldap maintainer ;-) i just contributed the basic Ldap Auth... - since the auth does quite exactly what it should for my purposes, i dont have personal plans concering LDAP in OM, but have to keep an eye on compatibility to my AD ;-) concerning the openLdap/AD switch within sourcecode its a simple question of design - @ the moment, the difference isnt too big, but since its an openSource project it will grow ;-) see ya Smoeker On 14 Apr., 20:51, t.lem...@gmail.com t.lem...@gmail.com wrote: smoeker a écrit : nope, the ldapgroup--organization mapping is a requirement of seombody else, just mentioned it... Oh, when I said you need, I meant OM, not you personnaly ;-) My proposal was to add a filter to LDAP settings that would help filtering users, but not mapping them to organizations given their groups. However this sounds as a great idea (though I don't really need this). Adding a group filter is also possible but would require a little more work to the Java code (and I'm not a Java dev). - i also think, the ldap auth shouldn't get too complex within openMeetings , since there is even the possibility to set up the ldap server in a way, that fulfills the requirements (if there's a need to separate users with VideoConfrence rights from the others, it could be realized by adding a additional group within a certain LDAP node - this node can be used as filter option from OM side...). I agree, just by setting ACLs on the server side to only let the ldap_admin_dn defined in OM see a restricted set of users would do the filtering, but also requires that you have a hand on the Ldap directory admin which is not always the case. So, as the LDAP OM maintainer, what do you plan to implement or have implemented exactly in the OM ldap module ? concerning the openLdap switch : i think u r right - that part wasnt added from my side, since i use AD and i am not confident with openLdap btw (but as i know from forum entries it was already possible using the default methods, switching some ldap keys uid -- userPrincipalname) Sure, currently openldap works fine with uid since this is a parameter in OM. I think I haven't understood your point though. In fact the openldap code in OM is mostly the same as the AD code. The difference I see is minor, though you'll always need to setup this in om_ldap.cfg unless OM is able to auto-discover the type of LDAP server (I don't think this is worth adding this to OM). Let's keep it simple. Thibault see ya Smoeker On 14 Apr., 17:54, t.lem...@gmail.com wrote: smoeker a écrit : hola, exactly, the configurable filter could help , not to open OM access to all ldap users, but only the ones in a certain ldap group, e.g Ok, so you would need a complete LDAP filter like the one I implemented in limesurvey. See:http://docs.limesurvey.org/tiki-index.php?page=LDAP+settingsstructur... The problem with Ldap groups is that they may be implemented in different ways: For instance: * a directory can maintain a multivalued memberOf attribute in the user entry having the plain text name of the groups as values (Ex AD groups in memberOf attributes) * or a group can be an entry, containing a multivalued attribute having the users login-name as values (Ex: posixgroups in Ldap) * or a group can be an entry containing a multivalued attribute having the users the users DN as values (Ex: group of names, groups of unique names) Trying to support for all these kind of groups is possible but makes the setup and algrorithm to look for users a little more tricky. Seehttp://limesurvey.svn.sourceforge.net/viewvc/limesurvey/source/limesu... Are you sure this is what you need ? Thibault - of course, this shouldn't only be available for openLdap users, thats why we maybe should try to extend configurability via config, so it wouldn't be necessary to switch/case within code for openLdap compatibility anymore... As far as I can see, the only reason why you're switching in the code for openLdap is that you need the DN to bind to openLdap, whereas it is not required to bind to AD, Am I right ? Thibault see ya Smoeker On 14 Apr., 17:32, t.lem...@gmail.com wrote: smoeker a écrit : hola, Hi, Bonjour, Boa tarde, Buenas tardes, ... ;-) the getUidhashmap part is only relevant for openLdap users and was part of a openLdap compatibility patch... - the Active Directory compatibility should not be concerned, if the filter is only used within the openLdap block (and i think it is) You're right, getUidhashmap is only used for openLdap. - if the additional filter works it should be a great help for the openLdap users to keep performance stable (- this patch could also solve the size limit issue of some openLdap users, see :http://groups.google.com/group/openmeetings-user/
Re: Windows 2008 or Linux?
We have successfully installed on both systems. We prefer using Debian. So its up to you to decide what fits best. A quite good scenario is for example XEN virtualization so that you can dynamically scale your system up. Sebastian 2010/4/15 İbrahim ÖZKASAP iozka...@gmail.com What are the experience and contrubution to run the openmeetings with Windows2008 or Linux? Any of your response would be appreciate, Best Regards, -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Restricted or not ?!?
Hi, testing the actual Source has shown me something tha made me a littel confused. Creating and entering a restricted room as Moderator (and it doesn´t matter if you make the room moderated or not), the Mod wil be shown as User (green Ball), but has full rights on whiteboard etc. When came the change in this Case ? my last download of the repository was from 10.april Or should I post this thing (s) in the Developer Forum ? best regards, -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: Restricted or not ?!?
hi Doyle, you should update your SVN Code to latest, I currently adding permanently fixes to enhance the User List in the Restricted Room. The requirement is to handle 1000 users (at least from a user-list rendering point of view) Therefore I have commited a new Grid Component for the User List that uses some kind of *paging*. That way it does not really matter if you have 15 or 150 or 1500 users in the list, rendering time is the same. It should work now, the only remaining things are: - If you resize the browser the list has to be re-rendered. (You will see if you enlarge the browser that it will really only render the visible items on the list). To prevent this effect the list has to be re-inited every time the browser is resized. - If 100 users enter the room at the same time the list should not re-render it should just update its virtual list [not sure about that point at the moment cause we order alphabetically] - the info text on the bottom is shown to everybody, only moderators should see it. I guess those changes should be ready in the coming days. Sebastian 2010/4/15 doyle do...@nexgo.de Hi, testing the actual Source has shown me something tha made me a littel confused. Creating and entering a restricted room as Moderator (and it doesn´t matter if you make the room moderated or not), the Mod wil be shown as User (green Ball), but has full rights on whiteboard etc. When came the change in this Case ? my last download of the repository was from 10.april Or should I post this thing (s) in the Developer Forum ? best regards, -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
LDAP module and password recording in DB
Hi, While reviewing the ldap authentication module, I found out that once authenticated, OM records and updates the user's password in its internal DB. Why is that ? In LdapLoginManagement.java: in method doLdapLogin // Update password (could have changed in LDAP) u.setPassword(passwd); Since all authentications are done on the LDAP server, I think it is a bad idea to duplicate the password in OM internal DB. Is there another good reason to do this ? The only reason I see so far is that in MainService, the loginUser method fails back to non LDAP authentication if the user has admin privileges. This also means that even if the user changes his password in LDAP, his old password recorded to the OM db must be used... I think it would be better: * to set a random password value in the OM's Users tables for the Ldap users * set a new parameter in om_ldap that will list admin users for which LDAP auth must be bypassed (in order to keep a local admin login even if LDAP is badly configured or unavailable). What do you think ? Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
hola, the original reason for storing the ldap passwd locally (md5 encrypted) within OM is to be able to use openMeetings, even if ldap server is maintained/off/not available... - i remember a post, somebody saying its sometimes hard to keep syncd with the Ldap Directory Admin - i agree with that ;-) - this is also the reason for storing the admins password locally - admin users should always be able to access OM, even if there are compilations with the Ldap Directory Server... Since its always the Ldappassword that has to be correct (in case Ldap is configured) , its not really duplicated, but stored as fallback (this is working without stopping OM Server). The userdata should be updated on every successful login , so the db passwd should also always be in sync with the Ldap server. (The only scenario it would fail would be, if LDAP password changes and ldap server is off/not configured in OM, so the local password wouldn't match the current DB password - but coding the fallback for the fallback is not my flavour ;-)) i dont think i understand the random passowrd bypass via config -how would a OM user authenticate, if Ldap server is off? see ya Smoeker On 15 Apr., 13:51, t.lem...@gmail.com wrote: Hi, While reviewing the ldap authentication module, I found out that once authenticated, OM records and updates the user's password in its internal DB. Why is that ? In LdapLoginManagement.java: in method doLdapLogin // Update password (could have changed in LDAP) u.setPassword(passwd); Since all authentications are done on the LDAP server, I think it is a bad idea to duplicate the password in OM internal DB. Is there another good reason to do this ? The only reason I see so far is that in MainService, the loginUser method fails back to non LDAP authentication if the user has admin privileges. This also means that even if the user changes his password in LDAP, his old password recorded to the OM db must be used... I think it would be better: * to set a random password value in the OM's Users tables for the Ldap users * set a new parameter in om_ldap that will list admin users for which LDAP auth must be bypassed (in order to keep a local admin login even if LDAP is badly configured or unavailable). What do you think ? Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: Restricted or not ?!?
Hi Sebastian, well I updated a few minutes before I wrote my post. Therefore I ´ve made a compare from my with the latest repository. However .. I will reload it this evening again and will see again. One other thing. For Change whishes, should I / we use the Issues- list ? Because there where some changes I´d like to have, otherwise I have to implement it by myself, and i´m not so a good programmer that I can find the whole things in a few minutes, like you do I think. (f.e. Zoomfactor changeable in the Admin, enable/ disable Userlist / Chat for restricted when creating a Romm, the Whiteboard to full- fit on the Size of the Clients-size, Chat function in the Lobby and so on and so on :-) ) best regards, On 15 Apr., 13:10, Sebastian Wagner seba.wag...@gmail.com wrote: hi Doyle, you should update your SVN Code to latest, I currently adding permanently fixes to enhance the User List in the Restricted Room. The requirement is to handle 1000 users (at least from a user-list rendering point of view) Therefore I have commited a new Grid Component for the User List that uses some kind of *paging*. That way it does not really matter if you have 15 or 150 or 1500 users in the list, rendering time is the same. It should work now, the only remaining things are: - If you resize the browser the list has to be re-rendered. (You will see if you enlarge the browser that it will really only render the visible items on the list). To prevent this effect the list has to be re-inited every time the browser is resized. - If 100 users enter the room at the same time the list should not re-render it should just update its virtual list [not sure about that point at the moment cause we order alphabetically] - the info text on the bottom is shown to everybody, only moderators should see it. I guess those changes should be ready in the coming days. Sebastian 2010/4/15 doyle do...@nexgo.de Hi, testing the actual Source has shown me something tha made me a littel confused. Creating and entering a restricted room as Moderator (and it doesn´t matter if you make the room moderated or not), the Mod wil be shown as User (green Ball), but has full rights on whiteboard etc. When came the change in this Case ? my last download of the repository was from 10.april Or should I post this thing (s) in the Developer Forum ? best regards, -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://www.laszlo-forum.de seba.wag...@gmail.com- Zitierten Text ausblenden - - Zitierten Text anzeigen - -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
hi Oliver and Thibault, It would be important to me that the User-Object is the same everytime the User-Logs in. Otherwise some of the functionality does not work like personal folders in the Recordings-UI. But from my point of view that is already done with the code Oliver has done. I would suggest that we write the User-id from LDAP in the field: externalUserId of each user and *ldap* or *openldap* or *ad* in the field externalUserType of each user created via LDAP [if there is any User-id from LDAP only of course] Sebastian 2010/4/15 smoeker o.beche...@medint.de hola, the original reason for storing the ldap passwd locally (md5 encrypted) within OM is to be able to use openMeetings, even if ldap server is maintained/off/not available... - i remember a post, somebody saying its sometimes hard to keep syncd with the Ldap Directory Admin - i agree with that ;-) - this is also the reason for storing the admins password locally - admin users should always be able to access OM, even if there are compilations with the Ldap Directory Server... Since its always the Ldappassword that has to be correct (in case Ldap is configured) , its not really duplicated, but stored as fallback (this is working without stopping OM Server). The userdata should be updated on every successful login , so the db passwd should also always be in sync with the Ldap server. (The only scenario it would fail would be, if LDAP password changes and ldap server is off/not configured in OM, so the local password wouldn't match the current DB password - but coding the fallback for the fallback is not my flavour ;-)) i dont think i understand the random passowrd bypass via config -how would a OM user authenticate, if Ldap server is off? see ya Smoeker On 15 Apr., 13:51, t.lem...@gmail.com wrote: Hi, While reviewing the ldap authentication module, I found out that once authenticated, OM records and updates the user's password in its internal DB. Why is that ? In LdapLoginManagement.java: in method doLdapLogin // Update password (could have changed in LDAP) u.setPassword(passwd); Since all authentications are done on the LDAP server, I think it is a bad idea to duplicate the password in OM internal DB. Is there another good reason to do this ? The only reason I see so far is that in MainService, the loginUser method fails back to non LDAP authentication if the user has admin privileges. This also means that even if the user changes his password in LDAP, his old password recorded to the OM db must be used... I think it would be better: * to set a random password value in the OM's Users tables for the Ldap users * set a new parameter in om_ldap that will list admin users for which LDAP auth must be bypassed (in order to keep a local admin login even if LDAP is badly configured or unavailable). What do you think ? Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
hi, *do you use the user paswword after authentication* = no Sebastian 2010/4/15 t.lem...@gmail.com Sebastian Wagner a écrit : hi Oliver and Thibault, It would be important to me that the User-Object is the same everytime the User-Logs in. Of course, but do you use the user paswword after authentication ? Otherwise some of the functionality does not work like personal folders in the Recordings-UI. But from my point of view that is already done with the code Oliver has done. Sure, it is done, and must remain the same. My concern is only about the user password duplicated on the OM database. I would suggest that we write the User-id from LDAP in the field: externalUserId of each user and *ldap* or *openldap* or *ad* in the field externalUserType of each user created via LDAP [if there is any User-id from LDAP only of course] Yes there is, it's the user DN (Distinguished Name), which is unique per Ldap entry inside a given Ldap directory. That would be great indeed, and should be simple to implement Sebastian 2010/4/15 smoeker o.beche...@medint.de mailto:o.beche...@medint.de hola, the original reason for storing the ldap passwd locally (md5 encrypted) within OM is to be able to use openMeetings, even if ldap server is maintained/off/not available... - i remember a post, somebody saying its sometimes hard to keep syncd with the Ldap Directory Admin - i agree with that ;-) - this is also the reason for storing the admins password locally - admin users should always be able to access OM, even if there are compilations with the Ldap Directory Server... Since its always the Ldappassword that has to be correct (in case Ldap is configured) , its not really duplicated, but stored as fallback (this is working without stopping OM Server). The userdata should be updated on every successful login , so the db passwd should also always be in sync with the Ldap server. (The only scenario it would fail would be, if LDAP password changes and ldap server is off/not configured in OM, so the local password wouldn't match the current DB password - but coding the fallback for the fallback is not my flavour ;-)) i dont think i understand the random passowrd bypass via config -how would a OM user authenticate, if Ldap server is off? see ya Smoeker On 15 Apr., 13:51, t.lem...@gmail.com mailto:t.lem...@gmail.com wrote: Hi, While reviewing the ldap authentication module, I found out that once authenticated, OM records and updates the user's password in its internal DB. Why is that ? In LdapLoginManagement.java: in method doLdapLogin // Update password (could have changed in LDAP) u.setPassword(passwd); Since all authentications are done on the LDAP server, I think it is a bad idea to duplicate the password in OM internal DB. Is there another good reason to do this ? The only reason I see so far is that in MainService, the loginUser method fails back to non LDAP authentication if the user has admin privileges. This also means that even if the user changes his password in LDAP, his old password recorded to the OM db must be used... I think it would be better: * to set a random password value in the OM's Users tables for the Ldap users * set a new parameter in om_ldap that will list admin users for which LDAP auth must be bypassed (in order to keep a local admin login even if LDAP is badly configured or unavailable). What do you think ? Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-user@googlegroups.com mailto:openmeetings-user@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com mailto:openmeetings-user%2bunsubscr...@googlegroups.comopenmeetings-user%252bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com mailto:seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- You received this message because you are subscribed to the
Re: LDAP module and password recording in DB
smoeker a écrit :
hola,
the original reason for storing the ldap passwd locally (md5
encrypted) within OM is to be able to use openMeetings, even if ldap
server is maintained/off/not available...
That is why usually an Ldap client implementation shoud propose to setup
2 Ldap servers definitions, in order to have one as backup.
- i remember a post, somebody saying its sometimes hard to keep syncd
with the Ldap Directory Admin - i agree with that ;-)
I don't understand. What do you mean by this? Can you give an example ?
- this is also the reason for storing the admins password locally -
admin users should always be able to access OM, even if there are
compilations with the Ldap Directory Server...
Let's narrow down the password duplication to admins only then.
Since its always the Ldappassword that has to be correct (in case Ldap
is configured)
Not for Admins. for admins Ldap authentication is always bypassed.
--- in MainService ---
// AdminUser werden auf jeden Fall lokal authentifiziert
if(user != null user.getLevel_id() =3){
log.debug(User + usernameOrEmail + is admin -
local login);
withLdap = false;
}
--- ---
, its not really duplicated, but stored as fallback
(this is working without stopping OM Server).
Well, yes it is duplicated then ;-)
This method has another pb. It supposes that all authentication systems
supported by OM in the future will let OM know the user password which
is not always the case.
Imagine that someone wants to implement an authentication module to
support the Central Authentication Service (CAS). This SSO system works
like this:
* OM gets a request, and is setup to use CAS, so that it checks if a
service ticket (either a cookie or GET param) is set
* OM sees no ticket and redirects the client to the CAS server which
performs authentication, generate a ticket and redirect the client to OM
with teh valid ticket set in URL or cookie
* OM sees the new request with a ticket, it checks the ticket by asking
the CAS server if it is valid, and then accept the client.
== In this protocol, OM never sees the user password.
It would be a pity to prevent future developpements of any kind of
authentication systems, just because the first design was supposing a
valid password is known by OM.
But this is only my opinion.
The userdata should be updated on every successful login , so the db
passwd should also always be in sync with the Ldap server. (The only
scenario it would fail would be, if LDAP password changes and ldap
server is off/not configured in OM, so the local password wouldn't
match the current DB password - but coding the fallback for the
fallback is not my flavour ;-))
This will occur as soon as a Ldap user having admin privileges changes
his LDAP password. I'm sure of this.
i dont think i understand the random passowrd bypass via config -how
would a OM user authenticate, if Ldap server is off?
Ldap server should never be off. at least a backup should be online.
Imigine that a user gets banned from an organization, and the Ldap admin
delete his account on the Ldap server.
This user would only have to run a DOS attack on the Ldap server to keep
his access on the OM system!
So my proposal of a random password was to prevent anyone from login in
with a user imported from Ldap even if the Ldap server is offline.
But I see now that we have 2 differents point of view on the matter.
I think then that this behaviour should be switchable in config: having
a parameter that decides weither or not OM falls back to internal DB
auth if Ldap is offline.
What do you think ?
Thibault
see ya
Smoeker
On 15 Apr., 13:51, t.lem...@gmail.com wrote:
Hi,
While reviewing the ldap authentication module, I found out that once
authenticated, OM records and updates the user's password in its
internal DB.
Why is that ?
In LdapLoginManagement.java: in method doLdapLogin
// Update password (could have changed in LDAP)
u.setPassword(passwd);
Since all authentications are done on the LDAP server, I think it is a
bad idea to duplicate the password in OM internal DB.
Is there another good reason to do this ?
The only reason I see so far is that in MainService, the loginUser
method fails back to non LDAP authentication if the user has admin
privileges. This also means that even if the user changes his password
in LDAP, his old password recorded to the OM db must be used...
I think it would be better:
* to set a random password value in the OM's Users tables for the Ldap users
* set a new parameter in om_ldap that will list admin users for which
LDAP auth must be bypassed (in order to keep a local admin login even if
LDAP is badly configured or unavailable).
What do you think ?
Thibault
--
You received this message because you are subscribed to the Google Groups
OpenMeetings User group.
To post to this group, send email to
Re: LDAP module and password recording in DB
hola,
i agree - if its configurable via config, there should be no further
problems - hands on, Thibault ;-)
hmm, ldap clients using mutliple configurations for fallback safety
are quite new to me, i must confess - i know about scenarios ,
mirroring the Directory Servers, but i dont think, that a ldap client
should contain that logic...
concering the LDAP Auth for OM admins :
This will occur as soon as a Ldap user having admin privileges changes his
LDAP password. I'm sure of this
- nope, i dont think so - this only causes problems, if the OM Admin
himself turns Ldap Auth off for OM and afterwards his password
changes
- since the OM admin is the person turning the Ldap auth off, he is
the only one that can be aware of the problem, that his ldap password
isnt acutalized anymore within OM.
- furthermore the storing of the password is a fallback for a short
time usually - i couldn't think of a scenario setting OM up with Ldap,
then switching back to local auth for ever...
But I see now that we have 2 differents point of view on the matter.
right, i am a fan of modular infrastructure - the Ldap auth was
thought as usability feature for users, that dont want to keep another
stupid password, but it shouldn't prevent them from working, if there
is trouble with the directory server
see ya
Smoeker
On 15 Apr., 15:04, Sebastian Wagner seba.wag...@gmail.com wrote:
hi,
*I think then that this behaviour should be switchable in config: having a
parameter that decides weither or not OM falls back to internal DB auth if
Ldap is offline.*
= adding this param is no problem, you can also make it slightly different:
Still populate the password but if the user has turned off the LDAP Feature
you set the user to status *disabled*. Disabled users are not able to login
via the User-Database of OM.
Sebastian
2010/4/15 t.lem...@gmail.com
smoeker a écrit :
hola,
the original reason for storing the ldap passwd locally (md5
encrypted) within OM is to be able to use openMeetings, even if ldap
server is maintained/off/not available...
That is why usually an Ldap client implementation shoud propose to setup 2
Ldap servers definitions, in order to have one as backup.
- i remember a post, somebody saying its sometimes hard to keep syncd
with the Ldap Directory Admin - i agree with that ;-)
I don't understand. What do you mean by this? Can you give an example ?
- this is also the reason for storing the admins password locally -
admin users should always be able to access OM, even if there are
compilations with the Ldap Directory Server...
Let's narrow down the password duplication to admins only then.
Since its always the Ldappassword that has to be correct (in case Ldap
is configured)
Not for Admins. for admins Ldap authentication is always bypassed.
--- in MainService ---
// AdminUser werden auf jeden Fall lokal authentifiziert
if(user != null user.getLevel_id() =3){
log.debug(User + usernameOrEmail + is admin - local
login);
withLdap = false;
}
--- ---
, its not really duplicated, but stored as fallback
(this is working without stopping OM Server).
Well, yes it is duplicated then ;-)
This method has another pb. It supposes that all authentication systems
supported by OM in the future will let OM know the user password which is
not always the case.
Imagine that someone wants to implement an authentication module to support
the Central Authentication Service (CAS). This SSO system works like this:
* OM gets a request, and is setup to use CAS, so that it checks if a
service ticket (either a cookie or GET param) is set
* OM sees no ticket and redirects the client to the CAS server which
performs authentication, generate a ticket and redirect the client to OM
with teh valid ticket set in URL or cookie
* OM sees the new request with a ticket, it checks the ticket by asking the
CAS server if it is valid, and then accept the client.
== In this protocol, OM never sees the user password.
It would be a pity to prevent future developpements of any kind of
authentication systems, just because the first design was supposing a valid
password is known by OM.
But this is only my opinion.
The userdata should be updated on every successful login , so the db
passwd should also always be in sync with the Ldap server. (The only
scenario it would fail would be, if LDAP password changes and ldap
server is off/not configured in OM, so the local password wouldn't
match the current DB password - but coding the fallback for the
fallback is not my flavour ;-))
This will occur as soon as a Ldap user having admin privileges changes his
LDAP password. I'm sure of this.
i dont think i understand the random passowrd bypass via config -how
would a OM user authenticate, if Ldap server is off?
Ldap server should never be off. at least a backup
Re: LDAP module and password recording in DB
smoeker a écrit :
hola,
i agree - if its configurable via config, there should be no further
problems - hands on, Thibault ;-)
I'm not sure I'm enough skilled in Java, but this is an interresting
challenge ;-)
hmm, ldap clients using mutliple configurations for fallback safety
are quite new to me, i must confess - i know about scenarios ,
mirroring the Directory Servers, but i dont think, that a ldap client
should contain that logic...
Indeed, it is up to the Ldap server to run the sync logic, the client
usually just has 2 ldap servers defined in its setup and then tries the
second one if the first one fails.
It is equivalent to giving 2 DNS servers IP addresses to your IP setup.
Thibault
concering the LDAP Auth for OM admins :
This will occur as soon as a Ldap user having admin privileges changes his LDAP
password. I'm sure of this
- nope, i dont think so - this only causes problems, if the OM Admin
himself turns Ldap Auth off for OM and afterwards his password
changes
- since the OM admin is the person turning the Ldap auth off, he is
the only one that can be aware of the problem, that his ldap password
isnt acutalized anymore within OM.
- furthermore the storing of the password is a fallback for a short
time usually - i couldn't think of a scenario setting OM up with Ldap,
then switching back to local auth for ever...
But I see now that we have 2 differents point of view on the matter.
right, i am a fan of modular infrastructure - the Ldap auth was
thought as usability feature for users, that dont want to keep another
stupid password, but it shouldn't prevent them from working, if there
is trouble with the directory server
see ya
Smoeker
On 15 Apr., 15:04, Sebastian Wagner seba.wag...@gmail.com wrote:
hi,
*I think then that this behaviour should be switchable in config: having a
parameter that decides weither or not OM falls back to internal DB auth if
Ldap is offline.*
= adding this param is no problem, you can also make it slightly different:
Still populate the password but if the user has turned off the LDAP Feature
you set the user to status *disabled*. Disabled users are not able to login
via the User-Database of OM.
Sebastian
2010/4/15 t.lem...@gmail.com
smoeker a écrit :
hola,
the original reason for storing the ldap passwd locally (md5
encrypted) within OM is to be able to use openMeetings, even if ldap
server is maintained/off/not available...
That is why usually an Ldap client implementation shoud propose to setup 2
Ldap servers definitions, in order to have one as backup.
- i remember a post, somebody saying its sometimes hard to keep syncd
with the Ldap Directory Admin - i agree with that ;-)
I don't understand. What do you mean by this? Can you give an example ?
- this is also the reason for storing the admins password locally -
admin users should always be able to access OM, even if there are
compilations with the Ldap Directory Server...
Let's narrow down the password duplication to admins only then.
Since its always the Ldappassword that has to be correct (in case Ldap
is configured)
Not for Admins. for admins Ldap authentication is always bypassed.
--- in MainService ---
// AdminUser werden auf jeden Fall lokal authentifiziert
if(user != null user.getLevel_id() =3){
log.debug(User + usernameOrEmail + is admin - local
login);
withLdap = false;
}
--- ---
, its not really duplicated, but stored as fallback
(this is working without stopping OM Server).
Well, yes it is duplicated then ;-)
This method has another pb. It supposes that all authentication systems
supported by OM in the future will let OM know the user password which is
not always the case.
Imagine that someone wants to implement an authentication module to support
the Central Authentication Service (CAS). This SSO system works like this:
* OM gets a request, and is setup to use CAS, so that it checks if a
service ticket (either a cookie or GET param) is set
* OM sees no ticket and redirects the client to the CAS server which
performs authentication, generate a ticket and redirect the client to OM
with teh valid ticket set in URL or cookie
* OM sees the new request with a ticket, it checks the ticket by asking the
CAS server if it is valid, and then accept the client.
== In this protocol, OM never sees the user password.
It would be a pity to prevent future developpements of any kind of
authentication systems, just because the first design was supposing a valid
password is known by OM.
But this is only my opinion.
The userdata should be updated on every successful login , so the db
passwd should also always be in sync with the Ldap server. (The only
scenario it would fail would be, if LDAP password changes and ldap
server is off/not
Re: LDAP module and password recording in DB
Sebastian Wagner a écrit :
hi,
okay Thibault I will add this to list of Issues, its a minor change if
you are not aware how to add the config key and param I can do it.
This part seems easy ;-)
By the way I've implemented the Failover Ldap support (I mean the fact
that OM can switch to a second ldap server in case the first one is down).
It's simply a matter of adding a comment in the configuration file ;-),
cause i'ts already supported by JNDI.
---
#LDAP URL
# can be a simple URL like: ldap://myldap.myorg.com
# or a list of simple URL separated by a space as in:
ldap://myldap.myorg.com ldap://myldap2.myorg.com
ldap_conn_url=
---
Thibault
http://code.google.com/p/openmeetings/issues/detail?id=1208
Can you please attached your DIFF with the Patch to it and I will
commit it to the SVN.
k, will do when it's ready.
Thibault
Sebastian
2010/4/15 t.lem...@gmail.com mailto:t.lem...@gmail.com
Sebastian Wagner a écrit :
hi,
*I think then that this behaviour should be switchable in
config: having a parameter that decides weither or not OM
falls back to internal DB auth if Ldap is offline.*
= adding this param is no problem, you can also make it
slightly different:
Still populate the password but if the user has turned off the
LDAP Feature you set the user to status *disabled*. Disabled
users are not able to login via the User-Database of OM.
This is possible but not secure. As a security officer I know that
password duplication is a bad thing to do as this can decrease the
Information System overall security level.
For instance, OM is storing the password in a database: so now
it's up to the DB admin to secure the DB access.
== Imagine he just doesn't think it contains confidential
information, this could lead to passwords compromise.
OM stores passwords as MD5 hashes, so it may seem to be secure
anyway... yes and no... because most of the time passwords are
easy to find by small derivations of a passwords dictionary.
Having an MD5 list of passwords is enough to break a good number
of passwords quickly. A way to increase security would be to use
salted MD5 version of the passwords.
However there is a better approach to security: instead of trying
to secure the confidential data an application stores, it is
better to just store only required data. And since passwords are
not required for Ldap users in OM (unless the to be invented
sync-ldap-password-to-om parameter is set), then it would be
better to just not record them.
Thibault
Sebastian
2010/4/15 t.lem...@gmail.com mailto:t.lem...@gmail.com
mailto:t.lem...@gmail.com mailto:t.lem...@gmail.com
smoeker a écrit :
hola,
the original reason for storing the ldap passwd locally
(md5
encrypted) within OM is to be able to use openMeetings,
even
if ldap
server is maintained/off/not available...
That is why usually an Ldap client implementation shoud
propose to
setup 2 Ldap servers definitions, in order to have one as
backup.
- i remember a post, somebody saying its sometimes hard to
keep syncd
with the Ldap Directory Admin - i agree with that ;-)
I don't understand. What do you mean by this? Can you give an
example ?
- this is also the reason for storing the admins password
locally -
admin users should always be able to access OM, even if
there are
compilations with the Ldap Directory Server...
Let's narrow down the password duplication to admins only then.
Since its always the Ldappassword that has to be
correct (in
case Ldap
is configured)
Not for Admins. for admins Ldap authentication is always
bypassed.
--- in MainService ---
// AdminUser werden auf jeden Fall lokal authentifiziert
if(user != null user.getLevel_id() =3){
log.debug(User + usernameOrEmail + is
admin -
local login);
withLdap = false;
}
--- ---
, its not really duplicated, but stored as fallback
(this is working without stopping OM Server).
Well, yes it is duplicated then ;-)
This method has another pb. It supposes that all authentication
systems supported by OM in the future will let OM know the user
password which is not always the case.
Imagine that someone wants to implement an authentication
module
to
JRDesktop and High bandwidth usage
Hi all, i have activated the desktop sharing (JRDesktop) and i have set the screen_viewer to value 4. When i activate the sharing desktop, my upload bandwith go up to 50Kb and the sharing is very slow: i have a delay up to 10 seconds from my desktop to other viewers. How can I limit the outgoing bandwidth? Can I set a compression system for openmeetings? thank you. Giovanni -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: JRDesktop and High bandwidth usage
hi, the ScreenSharing does take around 90KByte of upload at the moment. Problems with bandwidth lead to the described problem = delay in screen update... We have no compression, the re-sampling of images on client side would take too much CPU so for the majority of people that is not possible. Sebastian 2010/4/15 Giovanni giovanni.possem...@gmail.com Hi all, i have activated the desktop sharing (JRDesktop) and i have set the screen_viewer to value 4. When i activate the sharing desktop, my upload bandwith go up to 50Kb and the sharing is very slow: i have a delay up to 10 seconds from my desktop to other viewers. How can I limit the outgoing bandwidth? Can I set a compression system for openmeetings? thank you. Giovanni -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagner http://www.webbase-design.de http://openmeetings.googlecode.com http://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: JRDesktop and High bandwidth usage
m ok Thank you for the answer. Giovanni On 15 Apr, 17:15, Sebastian Wagner seba.wag...@gmail.com wrote: hi, the ScreenSharing does take around 90KByte of upload at the moment. Problems with bandwidth lead to the described problem = delay in screen update... We have no compression, the re-sampling of images on client side would take too much CPU so for the majority of people that is not possible. Sebastian 2010/4/15 Giovanni giovanni.possem...@gmail.com Hi all, i have activated the desktop sharing (JRDesktop) and i have set the screen_viewer to value 4. When i activate the sharing desktop, my upload bandwith go up to 50Kb and the sharing is very slow: i have a delay up to 10 seconds from my desktop to other viewers. How can I limit the outgoing bandwidth? Can I set a compression system for openmeetings? thank you. Giovanni -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.comopenmeetings-user%2Bunsubscr i...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en. -- Sebastian Wagnerhttp://www.webbase-design.dehttp://openmeetings.googlecode.comhttp://www.laszlo-forum.de seba.wag...@gmail.com -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
http://code.google.com/p/openmeetings/issues/detail?id=1208 Can you please attached your DIFF with the Patch to it and I will commit it to the SVN. k, will do when it's ready. Would you mind if I add the following hardcoded CONST as parameters in om_ldap.cfg ? // LDAP KEYS public static final String LDAP_KEY_LASTNAME = sn; public static final String LDAP_KEY_FIRSTNAME = givenName; public static final String LDAP_KEY_MAIL = mail; public static final String LDAP_KEY_STREET = streetAddress; public static final String LDAP_KEY_ADDITIONAL_NAME = description; public static final String LDAP_KEY_FAX = facsimileTelephoneNumber; public static final String LDAP_KEY_ZIP = postalCode; public static final String LDAP_KEY_COUNTRY = co; public static final String LDAP_KEY_TOWN = l; public static final String LDAP_KEY_PHONE = telephoneNumber; I think this will be a little more flexible in case someone has another Ldap schema. Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
Please do not apply the patch yet. Another file needs to be modified so that LDap users set as admin can login. Thibault t.lem...@gmail.com a écrit : t.lem...@gmail.com a écrit : http://code.google.com/p/openmeetings/issues/detail?id=1208 Can you please attached your DIFF with the Patch to it and I will commit it to the SVN. k, will do when it's ready. Would you mind if I add the following hardcoded CONST as parameters in om_ldap.cfg ? // LDAP KEYS public static final String LDAP_KEY_LASTNAME = sn; public static final String LDAP_KEY_FIRSTNAME = givenName; public static final String LDAP_KEY_MAIL = mail; public static final String LDAP_KEY_STREET = streetAddress; public static final String LDAP_KEY_ADDITIONAL_NAME = description; public static final String LDAP_KEY_FAX = facsimileTelephoneNumber; public static final String LDAP_KEY_ZIP = postalCode; public static final String LDAP_KEY_COUNTRY = co; public static final String LDAP_KEY_TOWN = l; public static final String LDAP_KEY_PHONE = telephoneNumber; I think this will be a little more flexible in case someone has another Ldap schema. Done, Please review and comment as I'm no Java coder. Thibault Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
Re: LDAP module and password recording in DB
t.lem...@gmail.com a écrit : smoeker a écrit : This will occur as soon as a Ldap user having admin privileges changes his LDAP password. I'm sure of this - nope, i dont think so - this only causes problems, if the OM Admin himself turns Ldap Auth off for OM and afterwards his password changes I'm sure of what I said because I've tested it and the code is straightforward: if a user has admin rights then he is authenticated to th OM DB and not Ldap. This means that his password will never gets synched again later. This is also something I have to change in my proposed patch - since the OM admin is the person turning the Ldap auth off, he is the only one that can be aware of the problem, that his ldap password isnt acutalized anymore within OM. Not only his own password, but also the passwords of others. When switching ldap config off, the OM should decide wether to go on authenticating users that have externalId set to Ldap or not. Anyway, this might be a very rare case. - furthermore the storing of the password is a fallback for a short time usually - i couldn't think of a scenario setting OM up with Ldap, then switching back to local auth for ever... I agree. But I see now that we have 2 differents point of view on the matter. right, i am a fan of modular infrastructure Yes me too. - the Ldap auth was thought as usability feature for users, that dont want to keep another stupid password, but it shouldn't prevent them from working, if there is trouble with the directory server But there shouldn't be any troubel with the Directory server, at least with 2 openldap servers in synch ;-) Thibault -- You received this message because you are subscribed to the Google Groups OpenMeetings User group. To post to this group, send email to openmeetings-u...@googlegroups.com. To unsubscribe from this group, send email to openmeetings-user+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/openmeetings-user?hl=en.
