GP2013 Users passwords are not saving

This question has suggested answer(s)

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.

All Replies
  • 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.

    Frank E. Hamelly, MCP, MCITP, MCT, MVP

    http://gp2themax.blogspot.com/

  • 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.

  • 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.

  • 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.

  • 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.

  • 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?

  • 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
    1 Kings Manor, Newcastle upon Tyne, NE1 6PA, United Kingdom