web
You’re offline. This is a read only version of the page.
close
Skip to main content

Announcements

No record found.

News and Announcements icon
Community site session details

Community site session details

Session Id :
Dynamics 365 Community / Forums / Microsoft Dynamics GP (Archived) / New Userid cannot login
Microsoft Dynamics GP (Archived)

New Userid cannot login

(0) ShareShare
ReportReport
Posted on by Community Member

Has anyone experienced having made new userid/passwords for a client on the server or one particular workstation and then those userid/passwords combination cannot login from any other workstation? The only way we have found to resolve this is to reset the password for the userid at the workstation they will use, then they can login, but again not from anywhere else. SA of course can login from everywhere.

*This post is locked for comments

I have the same question (0)
  • Suggested answer
    Bill Campbell Profile Picture
    Bill Campbell 12 on at

    One thing that you might want to check into is the ODBC connection you are using.  You should attempt to keep them all configured the same - all configured to use the same user account to connect with - all have the same name convention.

    When you did the installation of the software did you use the same user id - or did you do it with Admin for each of the computers?   We have found that the best installation is again, using the Domain Admin.

    Just a few thoughts.  Hope something helps.

  • Community Member Profile Picture
    Community Member on at

    This is a possibility that I will pursue thank you for the idea. Do you think it matters if it is just any user in domain admin group or specifically the 'real' Domain Admin? I had the client doing some installs so really not sure who they were logged in as and what group they would be a part of. Another question: since this seems to be a 'new' problem for us do you think there is a newer security setting or 'feature' that would affect this?

  • Suggested answer
    Bill Campbell Profile Picture
    Bill Campbell 12 on at

    If a user can log on to a computer then the security is working.  When you change the password on a workstation and then it works, it suggests that the issue is related to how the computer / application is talking with the SQL Server.

    The passwords are encrypted at the SQL Server and the only user that should / can create a user is SA - it should be consist from machine to machine as SQL does not (normally) care what computer the user is connecting from.

    Sorry to not have a clearer answer.

  • Community Member Profile Picture
    Community Member on at

    Your issue is almost certainly the ODBC issue that Bill pointed out. As he mentioned, the GP application actually takes the value you enter and hashes it using the SQL server name in the ODBC connection to produce the final password actually associated with the user in SQL. This is to prevent someone from opening up another tool (like SQL Server Management Studio or even Excel) and connecting directly to the database using their regular GP login.

    The thing to note is that this name is *case sensitive*, so if you configure the ODBC connection on one machine with "my-server" and on another with "MY-SERVER" then setting a user's password on either one of those computers will result in the user being unable to log into GP from the other. This is probably pretty obvious at this point, but it will also treat "my-server.my-domain.local" as being different from "my-server" even though they will both route to the same place.

    As for doing the install, it definitely does not require you to be "the" domain admin or even "a" domain admin. You need to be a local admin, but that's it.

    In general, I would highly advocate that you use the Create a Client Installer tool on the installation media (the option just below Install Microsoft Dynamics GP), as that will allow you to specify the server name to be used for the connection and 100% guarantee it will be exactly the same on all machines, regardless of who does the install. It will also make sure you have the correct additional products installed in all places.

  • Community Member Profile Picture
    Community Member on at

    Thank you as well, this certainly sounds like it could be the issue. If I wanted to check and see if the server name was "my-server" vs "MY-SERVER" where can I do that. When I go to the 32bit odbc datasources you can't really see the properties, it just has Add, Remove or Configure, configure has the server name there but it is all caps like they all are in the list if you drop it down so I'm not sure if that is really how it was typed in or not. Thanks

  • Community Member Profile Picture
    Community Member on at

    When you click Configure, there is a Name field, which is the name of the ODBC source and is what you will see in the sign-in drop-down in GP. There is a second field for Server, which is the actual name of the server and the value GP is using to hash the passwords.

  • Bill Campbell Profile Picture
    Bill Campbell 12 on at

    Paul, this is a great catch - forgot the *case sensitive* issue and the ODBC conection are related.

    This should resolve the problem, but of course continue to post as you need assistance.

  • Derek Albaugh Profile Picture
    Derek Albaugh Microsoft Employee on at

    Hello all....

    I was just going to add, that the ODBC is definitely what causes this type of issue and it is due to all GP user's passwords getting encrypted, with the exception of the 'sa' login, as 'sa' is actually a SQL System Administrator.

    If the ODBC DSN connections on all of the servers and workstations are not identical as far as the server name (where the SQL Server instance name is written), to include upper case and lower case letters, users will be able to login to one machine but not another.

    After resetting their password on machine B, which re-encrypts the password, they then can login to machine B but not machine A, where they previously could login.

    We recommend making sure that each ODBC DSN is setup identically on all machines, as well as per KB 870416.

    Thank you,

  • Cindy Joseph-Sandau Profile Picture
    Cindy Joseph-Sandau 2 on at

    We just ran into this same issue with a workstation that only one user could log into.  The ODBC had the domain.local so I switched it to the server name from the drop down and had to reset her password but we could login as either user after that.

  • Derek Albaugh Profile Picture
    Derek Albaugh Microsoft Employee on at

    Thank you Cindy for the information.

Under review

Thank you for your reply! To ensure a great experience for everyone, your content is awaiting approval by our Community Managers. Please check back later.

Helpful resources

Quick Links

Introducing the 2026 Season 1 community Super Users

Congratulations to our 2026 Super Stars!

Congratulations to our 2025 Community Spotlights

Thanks to all of our 2025 Community Spotlight stars!

Congratulations to the February Top 10 Community Leaders

These are the community rock stars!

Leaderboard > 🔒一 Microsoft Dynamics GP (Archived)

Last 30 days Overall leaderboard

Featured topics

Product updates

Dynamics 365 release plans