You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@openmeetings.apache.org by "Thibault Le Meur (Created) (JIRA)" <ji...@apache.org> on 2012/04/08 09:04:25 UTC
[jira] [Created] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Key: OPENMEETINGS-144
URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
Project: Openmeetings
Issue Type: Bug
Affects Versions: 2.0 Apache Incubator Release
Environment: ldap authentication
Reporter: Thibault Le Meur
Priority: Minor
When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "Maxim Solodovnik (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Maxim Solodovnik closed OPENMEETINGS-144.
-----------------------------------------
Assignee: Maxim Solodovnik
Closing all old 'Resolved' issues
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Assignee: Maxim Solodovnik
> Priority: Minor
> Labels: ldap
> Fix For: 2.0 Apache Incubator Release
>
> Attachments: UidCnHash.diff
>
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "Thibault Le Meur (Updated) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Thibault Le Meur updated OPENMEETINGS-144:
------------------------------------------
Attachment: UidCnHash.diff
This fixes the hardcoded 'uid' attribute used to map the loginname to the user DN.
It now uses the field_user_principal parameter from the ldap configuration file.
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Priority: Minor
> Labels: ldap
> Attachments: UidCnHash.diff
>
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "Thibault Le Meur (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249501#comment-13249501 ]
Thibault Le Meur commented on OPENMEETINGS-144:
-----------------------------------------------
I think this will be backward compatible since in the past only 'openldap' directories using the 'uid' attribute to store the user login were working. this means that they were working by setting field_user_principal to 'uid'. Thus even if we use the field_user_principal attribute name instead of the hardcoded 'uid', this will work with previous ldap configurations "that were working in the past".
I will provide a patch if you want me to.
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Priority: Minor
> Labels: ldap
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "SebastianWagner (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13249499#comment-13249499 ]
SebastianWagner commented on OPENMEETINGS-144:
----------------------------------------------
Sounds good. I would prefer if the default settings for a making this configurable is smae as it has been in the past. So that we are backwards compatible.
But it would be good if changing the hardcoded UID to some other string is possible via the configuration file.
We are happy to receive patches for the same :))
Thanks!
Sebastian
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Priority: Minor
> Labels: ldap
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "SebastianWagner (Resolved) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
SebastianWagner resolved OPENMEETINGS-144.
------------------------------------------
Resolution: Fixed
Fix Version/s: 2.0 Apache Incubator Release
Fix is committed. Thanks for the patch!
Could you please verify results together with us with one of the next Nightly Builds?
Thanks!
Sebastian
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Priority: Minor
> Labels: ldap
> Fix For: 2.0 Apache Incubator Release
>
> Attachments: UidCnHash.diff
>
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (OPENMEETINGS-144) When using openLDAP
authentication, the source code uses the hardcoded 'uid' attribute to map
logins and user DNs instead of the field_user_principal parameter
Posted by "Thibault Le Meur (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/OPENMEETINGS-144?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13250555#comment-13250555 ]
Thibault Le Meur commented on OPENMEETINGS-144:
-----------------------------------------------
Tested on a private build yesterday (from SVN trunk + my patch):
* works ok for my standard OpenLDAP setup
* I've sent the build to user Vieri on the mailinglist and he reported a successful test on Active Directory login (using OpenLdap directory Type).
> When using openLDAP authentication, the source code uses the hardcoded 'uid' attribute to map logins and user DNs instead of the field_user_principal parameter
> ---------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: OPENMEETINGS-144
> URL: https://issues.apache.org/jira/browse/OPENMEETINGS-144
> Project: Openmeetings
> Issue Type: Bug
> Affects Versions: 2.0 Apache Incubator Release
> Environment: ldap authentication
> Reporter: Thibault Le Meur
> Priority: Minor
> Labels: ldap
> Fix For: 2.0 Apache Incubator Release
>
> Attachments: UidCnHash.diff
>
>
> When using openLdap authentication, the LdapLoginManagent.java class first do a search in the directory to find the user given its login. the filter is using the attribute name given in configuration filed_user_principal and the user login provided to openmeetings as value. ( doLdapLogin:358).
> The search is done in LdapAuthBase.java, in method getUidCnHashMap (line 229). Then the results are mapped in a HashMap with the user login as key.
> This user login is assumed to be in the 'uid' attribute of the ldap entries retrieved by the query. This is hardcoded in line 234. Though 'uid' is the usual way to store the user login when since openldap, it may not be always the case. There are openldap directories where the uid contains a numerical id (so that it will never be reused over time), and users have a 'login alias' they can choose to ease login to applications.
> This means that we should in fact use the attribute defined in field_user_principal parameter to retrieve the user login.
> Also note that using a search and bind (used by openldap), may be very useful in some AD installations, so making this feature a little more generic could help AD users as well.
> What do you think ?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira