Question Status

Suggested Answer
thewaffle asked a question on 11 Jul 2013 2:00 PM

We have a GP2013 Test Environment running on SQL2012 and Windows 2012. While we are attempting to do testing on such, we have discovered that the user's passwords keep getting reset.

The most recent that happened was on July 2nd, the users were unable to log into GP with the error message popping up stating "The login failed. Attempt to log in again or contact your system Administrator" When we check the SQL Log, it states that "Login failed for user '*'. Reason: Password did not match that for login provided. [CLIENT: IP]"

I can't seem to find any reason for this to be happening, but we haven't changed any of the passwords so I'm not sure why SQL would be denying the login for a password mismatch.

Hopefully someone can give us a bit of insight here.

Reply
Frank Hamelly responded on 11 Jul 2013 2:35 PM

Are you accessing GP from multiple workstations?  If so, the server name used to setup the ODBC connection must be EXACTLY the same for each workstation.  If not, credentials that work on one workstation will not work on work on the other(s).  Same applies if you're accessing from multiple terminal or Citrix servers.

** Please, if this answers your question, mark it as 'Answered' so others experiencing the same will know it resolved your issue. **

Frank E. Hamelly, MCP-GP, MCP-AX, MCITP, MCT, MVP

http://gp2themax.blogspot.com/

Reply
thewaffle responded on 11 Jul 2013 7:11 PM

Our GP environment is hosted on an Remote Desktop Application Server and all users connect through RDWeb. I've tested all these accounts through my own user on the server. They report to me that they can't connect when they could a couple days prior for testing, so I log in with my account to confirm. I see their account no longer works, and log in to GP as SA to reset their password and give them the new password. Password Expiration is turned off on our Test Environment so that shouldn't factor in. The moment I reset their password, their user can log in through my account in the server as well as their own.

Reply
thewaffle responded on 11 Jul 2013 7:11 PM

Our GP environment is hosted on an Remote Desktop Application Server and all users connect through RDWeb. I've tested all these accounts through my own user on the server. They report to me that they can't connect when they could a couple days prior for testing, so I log in with my account to confirm. I see their account no longer works, and log in to GP as SA to reset their password and give them the new password. Password Expiration is turned off on our Test Environment so that shouldn't factor in. The moment I reset their password, their user can log in through my account in the server as well as their own.

Reply
Suggested Answer
Howard Swerdloff responded on 12 Jul 2013 5:58 AM

If you are restoring any databases in the test environment, that will also cause the passwords to require being reset. This is due to SQL storing the security ids separately from the Dynamics database.

 If this answers your question, please verify the answer. Thanks.

Howard Swerdloff
Microsoft - ERP Technical Solution Professional

GPUG All Star

http://www.linkedin.com/in/hswerdloff/
Twitter: @hcswerdloff

http://alldynamicsgp.com
http://erp4finance.com

 The views expressed on this post are my own and do not reflect the views of my employer.

Reply
ssuire responded on 12 Jul 2013 8:59 AM

I'm having the same issue on GP2010 and SQL2008 Server.  Constantly having to reset the passwords.  I have a case open with GP Support but they have yet to know the fix or what is causing it.

Reply
Prem Mirpuri responded on 7 Jan 2014 10:32 AM

I am coming across the same type of issue. We have GP installed on Server 2008 R2 and others using accessing it via GP Clients on each workstation. If I log in with the sa account on the server and reset the password for users, users are still unable to log in.

However if I log in with the sa account on the users desktop (GP Client) and reset the password from there and then have the user try to access - that works.

#1 Not sure why the user accounts have to be reset intermittantly

#2 Not sure why I have to log into the user desktop (GP Client) with sa account first to reset the password instead of being able to log into the server hosting GP and reset it from there.

Anyone ideas or updates from the last post?

Reply
Ian Grieve responded on 7 Jan 2014 11:40 PM

Premm, your point 2 about needing to do it on the user's PC strongly suggests that the ODBC contains a different server name on the client PC than the server. It needs to match exactly (e.g. SQLServer1 is different from SQLSERVER1).


Author of azurecurve|Ramblings of a Dynamics GP Consultant
Senior Consultant at Perfect Image Ltd

Perfect Image/ Dynamics GP
Tel: +44 (0) 843 289 2656
Equinox House, Cobalt 3.2, Silver Fox Lane, Silverlink, North Tyneside, NE27 0QJ, United Kingdom

Reply
Suggested Answer
Howard Swerdloff responded on 12 Jul 2013 5:58 AM

If you are restoring any databases in the test environment, that will also cause the passwords to require being reset. This is due to SQL storing the security ids separately from the Dynamics database.

 If this answers your question, please verify the answer. Thanks.

Howard Swerdloff
Microsoft - ERP Technical Solution Professional

GPUG All Star

http://www.linkedin.com/in/hswerdloff/
Twitter: @hcswerdloff

http://alldynamicsgp.com
http://erp4finance.com

 The views expressed on this post are my own and do not reflect the views of my employer.

Reply