hola John/Abdul, some additional notes about the searchfilter :
1. it sureley wont disturb the login process itself - it is required to retrieve users detail data after succesful login (user record is stored local to keep up referentiall integrity) 2. if the "objectclass person" filter is required for every open ldap installation, we shoul consider, making it configruable within om_ldap.cfg - but we cant take over the patched part into SVN, because it contains hardcoded "uid" - that wont work on Active Directory ;-) -> a vaild solution for further openLdap compatibility would be, making the whole searchfilter configurable via config. ...and some notes about the login process itself : the function LdapAuthBase.authenticateUser creates a DirectoryContext , that is used for every following LDAP Action, so calling this function twice means : the first call was quite senseless... btw : the Softerra Ldap Browser comes along with a trial license and is quite comfortable to checkout a Ldap installation standalone... see ya Smoeker On 17 Okt., 09:31, Abdul Rehman Nizamani <nizaman...@gmail.com> wrote: > Dear John Gisler: > > I am very sorry for unavailability. I have successfully implemented > Openmeetings integration with OpenLDAP in our production environment. > I will send you the detailed document soon most probably in coming > week which will help you in integrating the OpenLDAP with Openmeetings > in your production environments. > > Regards, > > Abdul Rehman Nizamani > Java Software Engineer > Ibn Khaldun Systems > 65-C Second Floor, DHA Commercial Area "A" > DHA Phase 2, Karachi 75500 > Pakistan > Tel: +92-21-35397301 Fax: +92-21-35397302 > Cell: +92-300-8373265 > Skype, GMail: nizamaniar > Email: nizaman...@ibnkhaldun.com.pk > Web:http://www.ibnkhaldun.com.pk > > On Oct 17, 2:34 am, John Gisler <pcm...@gmail.com> wrote: > > > I believe this portion of the code is where the problem might be: > > > //IKS > > > // Attributes to retrieve from ldap > > List<String> attributes1 = new ArrayList<String>(); > > attributes1.add(LDAP_KEY_UID); // UID > > attributes1.add(LDAP_KEY_COMMONNAME); // Comman name > > > lAuth.authenticateUser(ldap_admin_dn, ldap_passwd); > > > HashMap<String, String> uidCnBridge = new HashMap<String, > > String>(); > > > Vector<HashMap<String, String>> usersData = lAuth.getData > > (ldap_search_scope, ldap_search_filter, attributes1); > > for (HashMap<String, String> userData : usersData) { > > log.debug("LDAP UID: " +userData.get(LDAP_KEY_UID) > > + " LDAP CN: > > "+userData.get(LDAP_KEY_COMMONNAME)); > > uidCnBridge.put(userData.get(LDAP_KEY_UID), > > userData.get > > (LDAP_KEY_COMMONNAME)); > > } > > > try{ > > > > if(!lAuth.authenticateUser("cn="+uidCnBridge.get(user) > > +","+ldap_search_scope, passwd)) > > return new Long(-11); > > }catch(Exception e ){ > > log.error("Error on LdapAuth : " + e.getMessage()); > > return null; > > } > > //IKS END > > > Since it is truncated I went through it & changed it to as follows: > > > //IKS > > > // Attributes to retrieve from ldap > > List<String> attributes1 = new ArrayList<String>(); > > attributes1.add(LDAP_KEY_UID); // UID > > attributes1.add(LDAP_KEY_COMMONNAME); // Comman name > > > lAuth.authenticateUser(ldap_admin_dn, ldap_passwd); > > > HashMap<String, String> uidCnBridge = new > > HashMap<String, String>(); > > > Vector<HashMap<String, String>> usersData = > > lAuth.getData(ldap_search_scope, ldap_search_filter, attributes1); > > for (HashMap<String, String> userData : usersData) { > > log.debug("LDAP UID: " > > +userData.get(LDAP_KEY_UID) + " LDAP CN: " > > +userData.get(LDAP_KEY_COMMONNAME)); > > uidCnBridge.put(userData.get(LDAP_KEY_UID), > > userData.get(LDAP_KEY_COMMONNAME)); > > } > > > try{ > > > if(!lAuth.authenticateUser("cn="+uidCnBridge.get(user)+","+ldap_search_scope, > > passwd)) > > return new Long(-11); > > }catch(Exception e ){ > > log.error("Error on LdapAuth : " + e.getMessage()); > > return null; > > } > > //IKS END > > > Since I am by no means a programmer mainly just a hack. I can see the > > logic of how it works & what it's doing but perhaps I have broken it > > trying to fix the broken lines. > > > John- > > > Thanks for the responses Smoeker. ;) > > > On 10/16/2009 12:14 AM, smoeker wrote: > > > > hola, > > > > u r right - the first attempt passes the user authentication itself > > > (including the login on the ldap server itself and also the > > > authentication of the user's credentials). > > > > -> seeing these UID debugmessages , i think u are working with the > > > patch, that is posted within this thread? > > > > i am a little bit confused about the changes within this patch : > > > > here some facts, that can cause trouble : > > > > 1. SearchFilter : > > > > Original = String ldap_search_filter = "(" + > > > ldap_fieldname_user_principal + "=" + user + ")"; > > > Patch = String ldap_search_filter = "(&(objectclass=person)(uid=" + > > > user + > > > "))"; > > > > The patch contains a hardcoded searchfilter (objectclass=person) that > > > might not be available on every LDAP Installation > > > > 2. Authentication > > > > Original : > > > > LdapAuthBase lAuth = new LdapAuthBase(ldap_url, ldap_admin_dn, > > > ldap_passwd, ldap_auth_type); > > > > try{ > > > if(!lAuth.authenticateUser(user, passwd)) > > > return new Long(-11); > > > }catch(Exception e ){ > > > log.error("Error on LdapAuth : " + e.getMessage()); > > > return null; > > > } > > > > -> the Method authenticate user contains functionality for the login > > > on the server itself, so it isnt required to do this twice, as seen in > > > the patch, once for the admin and then for the user himself.... > > > > Patch : > > > > LdapAuthBase lAuth = new LdapAuthBase(ldap_url, ldap_admin_dn, > > > ldap_passwd, ldap_auth_type); > > > > //IKS > > > > // Attributes to retrieve from ldap > > > List<String> attributes1 = new ArrayList<String>(); > > > attributes1.add(LDAP_KEY_UID); // UID > > > attributes1.add(LDAP_KEY_COMMONNAME); // Comman name > > > > lAuth.authenticateUser(ldap_admin_dn, ldap_passwd); > > > > HashMap<String, String> uidCnBridge = new > > > HashMap<String, String>(); > > > > Vector<HashMap<String, String>> usersData = > > > lAuth.getData > > > (ldap_search_scope, ldap_search_filter, attributes1); > > > for (HashMap<String, String> userData : usersData) { > > > log.debug("LDAP UID: " +userData.get > > > (LDAP_KEY_UID) + " LDAP CN: > > > "+userData.get(LDAP_KEY_COMMONNAME)); > > > uidCnBridge.put(userData.get(LDAP_KEY_UID), > > > userData.get > > > (LDAP_KEY_COMMONNAME)); > > > } > > > > try{ > > > if(!lAuth.authenticateUser > > > ("cn="+uidCnBridge.get(user) > > > +","+ldap_search_scope, passwd)) > > > return new Long(-11); > > > }catch(Exception e ){ > > > log.error("Error on LdapAuth : " + e.getMessage > > > ()); > > > return null; > > > } > > > > -> this means : > > > > 1. lAuth.authenticateUser(ldap_admin_dn, ldap_passwd); -> login to > > > server itself with admin dn (automatic within function) and additional > > > login with the same credentials > > > > 2. if(!lAuth.authenticateUser("cn="+uidCnBridge.get(user) ... -> > > > again login to the server itself (automatic within function) and again > > > a login with the users credentials.... > > > > i dont really see the sense in these login cascades, so im not really > > > sure, whether i can help , using this patch, maybe > > > IKS can add some explaining comments to their changes here? > > > > The Debug messages show at least, that your admin credentials from > > > config and even your entered userdata are correct - the first > > > authentication was indeed successful (as far as i am interpreting the > > > debug messages right...). > > > > -> if i were u, i would try these successful credentials once more > > > with the code within current SVN trunk. > > > -> if u already did so, could u please post the log of these attempts? > > > maybe there already were successful logins with the trunk code, and > > > the errors came from the folloowing user search... > > > > see ya > > > > Smoeker > > > > On 15 Okt., 17:19, John Gisler<pcm...@gmail.com> wrote: > > > >> Thanks for the reply. > > > >> In the following paste you will see the 1st login attempt that uses the > > >> correct username& does actually talk to LDAP as it gets the UID& CN > > >> returned to it but the password isn't passing correctly I believe. > > > >> You'll notice in the 2nd attempt it isn't able to get the CN from LDAP > > >> for the UID. > > > >> If you don't have access to an openldap server, I can setup one for you > > >> temporarily within a VM that you can use to test& troubleshoot. > > > >> Again thanks for the help& replies! > > > >> 1st attempt: > > > >> DEBUG 10-15 08:13:57.078 LdapLoginManagement.java 169586 101 > > >> org.openmeetings.app.data.user.Usermanagement [NioProcessor-1] - > > >> LdapLoginmanagement.isLdapConfigured > > >> DEBUG 10-15 08:13:57.081 MainService.java 169589 180 > > >> org.openmeetings.app.remote.MainService [NioProcessor-1] - loginUser > > >> 111: 80ba30738aeac7a1fad1bf760663c11a testme > > >> DEBUG 10-15 08:13:57.081 Usermanagement.java 169589 1229 > > >> org.openmeetings.app.data.user.Usermanagement [NioProcessor-1] - > > >> Usermanagement.getUserByLogin : testme > > >> DEBUG 10-15 08:13:57.087 MainService.java 169595 > > ... > > Erfahren Sie mehr » --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
