Token LDAP query uses objectClass from New User registration module

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Setup the User Activation module
2. Set the Token settings to use LDAP as storage method
3. Go through the process of User Account activation as an enduser

What is the expected output? What do you see instead?
After entering some LDAP attributes PWM goes to send the token by e-mail/ SMS. 
The validation of that token is done by an LDAP query. The LDAP query uses 
objectClass=inetOrgPerson, but I did not specify that. After further 
investigation it looks like the User objectClass from the New User Registration 
is being used.

In my opinion this is bug, because User activation can also be done on Users 
that are not created by the New User Registration Module (i.e. IDM). Also User 
Activation module can be enabled, without enabling the New User Registration 
Module. There should be a seperate setting for the objectClass under the Token 
Settings that is seperate from the User objectClass from the New User 
Registration module.

What version of PWM are you using?
Daily build (PWM v1.7.0 b1216 (RC1) buildTime=2013.04.02 10:39:59 EDT)

What ldap directory and version are you using?
eDirectory for Linux x86_64 v8.8 SP7 ON SLES11 SP1

Please paste any error log messages below:
2013-04-09 17:59:47, TRACE, pwm.SessionFilter, {y} POST request for: 
/pwm/public/ActivateUser  [127.0.0.1/localhost]
  pwmFormID='Zfu1kwP4GDWPtEu4IUm5XbuwFy042IET13def80f266f04m9k'
  TestAuxuser='mytestaccount'
  TestAuxdateOfBirth='06-05-1978'
  processAction='activate'
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, {y} beginning user 
search process [127.0.0.1/localhost]
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, {y} performing ldap 
search for user, base=ou=users,o=meta filter=SearchHelper: filter: 
(&(objectClass=TestAuxperson)(TestAuxuser=mytestaccount)(TestAuxdateOfBirth=06-0
5-1978)), scope: SUBTREE, attributes: [] [127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, operations.UserSearchEngine, {y} found 1 results in 
context: ou=users,o=meta [127.0.0.1/localhost]
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, {y} completed user 
search process in 4ms, resultSize=1 [127.0.0.1/localhost]
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, {y} found userDN: 
cn=123456,ou=users,o=meta [127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, servlet.ActivateUserServlet, {y} skipping 
validation of ldap value for 'TestAuxuser' because it is in search filter 
[127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, servlet.ActivateUserServlet, {y} skipping 
validation of ldap value for 'TestAuxdateOfBirth' because it is in search 
filter [127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, pwm.Permission, {y} begin check for permission for 
cn=123456,ou=users,o=meta for ACTIVATE_USER using queryMatch: 
(&(loginDisabled=true)(!(employeestatus=activated))) [127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, pwm.Permission, {y} checking ldap to see if 
cn=123456,ou=users,o=meta matches 
'(&(loginDisabled=true)(!(employeestatus=activated)))' [127.0.0.1/localhost]
2013-04-09 17:59:47, DEBUG, pwm.Permission, {y} user cn=123456,ou=users,o=meta 
is a match for '(&(loginDisabled=true)(!(employeestatus=activated)))', granting 
privilege for ACTIVATE_USER [127.0.0.1/localhost]
2013-04-09 17:59:47, TRACE, operations.UserStatusHelper, {y} read last user 
password change timestamp (via chai) as: Tue Apr 09 17:40:56 CEST 2013 
[127.0.0.1/localhost]
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, beginning user search 
process
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, performing ldap search 
for user, base=ou=users,o=meta filter=SearchHelper: filter: 
(&(pwmToken=DC82C560F86EC601A659B1D858CA126E-hash*)(objectClass=inetOrgPerson)),
 scope: SUBTREE, attributes: []
2013-04-09 17:59:47, TRACE, operations.UserSearchEngine, user not found in 
context ou=users,o=meta
2013-04-09 17:59:47, DEBUG, operations.UserSearchEngine, completed user search 
process in 10ms, resultSize=0
2013-04-09 17:59:47, DEBUG, servlet.ActivateUserServlet, {y} generated activate 
user tokenKey code for session [127.0.0.1/localhost]

Original issue reported on code.google.com by sebastia...@gmail.com on 10 Apr 2013 at 8:46

[GoogleCodeExporter]

The bug is that the objectclass setting is in the wrong setting category, it 
should be in the LDAP section. It is used throughout the application.  

Otherwise,is there an issue here?  It seems like its working okay for you?

Original comment by jrivard on 10 Apr 2013 at 12:36

• Changed state: NeedInfo
• Added labels: Type-Defect
• Removed labels: Type-Help

[GoogleCodeExporter]

Moved setting to LDAP section in revision 546.

Original comment by jrivard on 12 Apr 2013 at 11:45

[GoogleCodeExporter]

Ok, thanks for fixing :)

Original comment by sebastia...@gmail.com on 24 Apr 2013 at 6:25

[GoogleCodeExporter]

Original comment by menno.pi...@gmail.com on 29 May 2013 at 6:36

• Changed state: Fixed