Error occurs on any repository named user account.

Error occurs from any machine.

Same behavior after cache cleared.

Same behavior in FireFox and IE10.

Does it work if you type in the "domainname\username" (where "domainname" is the domain and "username" is the actual username of the user) and password for the account when prompted to do so?

This installation of Web Access is on the DMZ and does not have access to active directory :/

Authenticated named repository users to the instance on the DMZ works fine, it's just password management features which bug out and show the errors above.

Authenticating named repository users from the intranet using the Client works just fine.

Password Management for Named Repository users from the intranet using the Client, works fine.

Authenticating from the intranet to a separate Web Access installation works fine for domain accounts.

The noted behavior is for Repository Named User's on a Web Access installation within the DMZ and using custom port 5080 instead of 80 to talk to an internal Laserfiche server.

The behavior should be the same. Does the account work normally internally (i.e. not on the DMZ)?

Did you check your DMZ rules?

Was this changed recently?

Internally logging into web access and manually changing the password from the settings works fine.

Internally logging into web access with the (force user to change pass at next login) works fine.

This is a relatively fresh purchase and installation so I cannot verify if the change password feature ever worked on the DMZ but to my knowledge it hasn't. We did upgrade to 9.2 before validating if this change password feature had worked previously in the LSG installed 9.1.

Which port should I be looking for in the DMZ rules? We specified for it to connect to the Laserfiche Server via 5080 and it does, except when trying to change a password?

In a wireshark session taken from the server on the DMZ and looking only at communication to and from the internal Laserfiche server during this behavior I see many ports attempted before trying our specified custom port of 5080 (23 seconds of waiting).

*picture makes it hard to see but if I'm reading this correct it sends 3 attempts over 23 seconds to port 80 before giving up and trying port 5050, giving up, and then going over 5080, switching to HTTP 5080, then back to TCP 5050 before attempting TCP 135.

Is there a reason why changing the password would attempt to use other ports than our configured 5080 and if so, can we change it to also use 5080?

How did you change the Web Access port exactly?  Did you change the bindings in IIS or change it only at the DMZ?

I should also add, each time this password change is attempted but fails, the following System message is noted in the event viewer on the DMZ server.

DCOM was unable to communicate with the computer 172.18.18.137 using any of the configured protocols.

Error

Source DistributedCOM

Event ID 10009

Web Access connects with external users through IIS at the bindings.

The only place on the DMZ instance of Web Access we have specified the listening port of our internal laserfiche server is at the configuration page:

Please note, everything works with Web Access EXCEPT having the user change their password through the Web Access application. In both methods noted in the original post, a false error message or a true error message are served to the user.

Please open a case with your VAR so we can explore the matter further.

Thanks. Will update the thread if the issue is resolved.