Modify Guest User

[GoogleCodeExporter]

What steps will reproduce the problem?
1.Search for a guest user (any one will do)
2.Bam

What is the expected output? What do you see instead?
Unknown error has occurred blah blah.

What version of PWM are you using?
v1.6.4

What ldap directory and version are you using?
MS 2008R2 AD

Please paste any error log messages below:
5015 ERROR_UNKNOWN (error searching for guest user: invalid attribute 
description)

Is there a way I can trace what attribute is causing the error or anything?  I 
have the username attribute set to sAMAccountName
This is literally the only thing that does not work in my PWM installation.
I'm a Java-savvy, if it helps! :)

Original issue reported on code.google.com by bscha...@gmail.com on 29 Jan 2013 at 2:05

[GoogleCodeExporter]

Config attached.

Original comment by bscha...@gmail.com on 29 Jan 2013 at 2:12

Attachments:

• PwmConfiguration.xml

[GoogleCodeExporter]

And yes, I did try removing the description field haha

Original comment by bscha...@gmail.com on 29 Jan 2013 at 8:14

[GoogleCodeExporter]

A few remarks:

* Try removing some of the attributes of the guest update form. See if that 
helps.

* Make sure you have attribute pwmExpirationTime in AD, otherwise remove the 
attribute name from "Attribute Used To Store Account Expiration Date"

Use a TRACE level log to see what happens. If you still have no clue which 
attribute(s) is/are causing trouble, post the log here.

Original comment by menno.pi...@gmail.com on 31 Jan 2013 at 6:56

• Changed state: NeedInfo

[GoogleCodeExporter]

*Removed all attributes except for one, which I tried different values on 
(name:name:text:1:30:false:false).  Tried increasing minimum, setting it to 
zero, increasing max, different attributes (all confirmed existence), etc.
*Removed pwmExpirationTime (also confirmed it was in the schema, and was even 
set for some users from me registering them)
*Set log level to TRACE, enabled LDAP wire-trace.
*Tried searching a known user (multiple, actually) by sAMAccountName, cn, etc. 
(same error happened)
*Read log from TRACE.  Only things seen are my POST request and immediately 
after, the same error, then after that PWMMacro replacing with my username on 
the webpage, then the POST request for me hitting "cancel" to go back to the 
main menu.

I'm pretty dumbfounded by this.

Original comment by bscha...@gmail.com on 1 Feb 2013 at 3:18

[GoogleCodeExporter]

As requested, the actual TRACE-level log is attached.

Original comment by bscha...@gmail.com on 5 Mar 2013 at 4:06

Attachments:

• log.txt

[GoogleCodeExporter]

That is not the log I'm looking for... This looks like an access log, but does 
not look familiar. What application server are you running? Tomcat's 
catalina.out at TRACE level looks quite different and is much more verbose.

Original comment by menno.pi...@gmail.com on 5 Mar 2013 at 9:31

[GoogleCodeExporter]

It may be related to a badly configured searchfilter... The error is mentioned 
in OpenJDK's LDAP sources: 
http://hg.openjdk.java.net/jdk7/build/jdk/raw-diff/9929203a8b98/src/share/classe
s/com/sun/jndi/ldap/Filter.java

Original comment by menno.pi...@gmail.com on 5 Mar 2013 at 9:38

[GoogleCodeExporter]

Sorry about that, wasn't aware that you wanted the catalina log!  I had posted 
the log from the PWM Admin/Event Log page.
I'm using the latest version of PWM, latest version of Tomcat, all on Windows 
Server 2012 (was running on Server 2008 R2).

Tomcat just decided that it doesn't want to stay running, I'll update once I 
get it back up.  The log looks like it searching for cn=sadmin instead of the 
username attribute.  Regardless, I'll try doing it by cn AGAIN once I get it up 
again.

Original comment by bscha...@gmail.com on 5 Mar 2013 at 10:09

Attachments:

• log.txt

[GoogleCodeExporter]

Yep, tried to search with the following, and it all returned the same...
CN=Server Admin,cn=users,dc=brookss,dc=net
Server Admin,cn=users,dc=brookss,dc=net
Server Admin
'Server Admin'
(This is the object that corresponds to sAMAccountName=sadmin)

Original comment by bscha...@gmail.com on 5 Mar 2013 at 10:47

[GoogleCodeExporter]

Your search filter is '((cn=%USERNAME%))' according to the logs. Try just 
'(cn=%USERNAME%)' or only 'cn=%USERNAME%'.

- Menno

Original comment by menno.pi...@gmail.com on 10 Mar 2013 at 8:49

[GoogleCodeExporter]

I'm not seeing where I can change that in the configuration interface (or the 
config file itself).  I have advanced settings shown and all.  Am I crazy?

Original comment by bscha...@gmail.com on 11 Mar 2013 at 1:07

[GoogleCodeExporter]

I am using 1.6.4 and I am having the same problem.

I think I have tracked the source down to one of two chunks of code:
REF (works): HelpdeskServlet.processSearchRequest
REF (fails): GuestRegistrationServlet.handleSearchRequest

Both use UserSearchEngine.SearchConfiguration().
However I think the searches use two different filters. Though I am having 
trouble tracking both of them down.

The HelpdeskServlet.processSearchRequest appears to use:
searchConfiguration.setFilter(pwmApplication.getConfig().readSettingAsString(Pwm
Setting.HELPDESK_SEARCH_FILTER));
  However in my PwmConfiguration.xml I do not have that value defined! (and it appears to actually be using ldap.usernameSearchFilter. Which I have customized to be '(&(objectClass=person)(|(samAccountName=%USERNAME%)(cn=%USERNAME%)(sn=%USERNAME%)(givenName=%USERNAME%)(mail=%USERNAME%)))'

I do not understand why that value is being used, but that is what I see in the 
logs.)

While the GuestRegistrationServlet.handleSearchRequest uses a very trivial (and 
broken syntax) filter of just "((cn=%USERNAME%))". I do not have anything in my 
configuration file that looks like that. (So I am guessing it is a hardcoded 
default somewhere that I have not tracked down in the code.)

Original comment by matt.bl...@redheadtech.com on 23 Aug 2013 at 3:28

[GoogleCodeExporter]

Could you try 1.7.0 RC 3, or a nightly build? I cannot reproduce in the current 
version and remember fixing some similar issue at a global level. This issue 
has probably been fixed too.

I'm closing this issue now. If it persists, please reopen.

Original comment by menno.pi...@gmail.com on 25 Aug 2013 at 9:17

• Changed state: Fixed