Dynamics Community Forum Thread Details

Hi All,

I've inherited a legacy where users in our custom CRM can click a button, GP 10 opens and 'automatically' logs them in. All is working in our current environment, however servers need replacing and I have to move the GP databases to a new SQL Cluster.

Some quick points:

I have tested the migration of databases to the new server, updated the GP ODBC details, migrated users (as per kb918992) and reset passwords. Those financial user accounts who would log into GP directly can log in without issue using new passwords.

The method used to 'automatically' log onto GP is as follows:

Passwords in the CRM are stored in an encrypted 15 character string
The CRM passes across a companyid (to log into a specific GP database), the userid and the password to a method in a custom GP integration dll.
The method checks if GP is running, if not opens the GP application, waits for initial startup then sets GP as the active target.
Continuing in the method, the following is called, which (no GP development experience) sends the user credentials to the GP interface for authentication and automatic login.

...

try

{

string strCode;

string strCompileError;

short shrResult;

shrResult = GPApplication.SetDataValue("'User ID' of window Login of form Login", pUserID);

shrResult = GPApplication.SetDataValue("Password of window Login of form Login", pPassword);

strCode = "run script field 'OK Button' of window Login of form Login;";

GPApplication.ExecuteSanscript(strCode, out strCompileError);

System.Threading.Thread.Sleep(2000);

shrResult = gpApp.SetDataValueEx("'(L) Company Names' of window 'Switch Company' of form 'Switch Company'", RetrieveXMLValue("CONSTANT_LOGIN"), 1);

strCode = "run script field 'OK Button' of window 'Switch Company' of form 'Switch Company';";

GPApplication.ExecuteSanscript(strCode, out strCompileError);

I can see on the SQL Server logs that 4 attempts are made for the specific login in accessing the database, all failured attempts.

Now I know what your going to say, "When you moved over the logins and SQL accounts from the old SQL Server and modified the passwords you put them out of sync, so of course authentication will fail!"

Within the CRM a password can be reset by an administrator, when the sa account is also logged into GP the integration code, updates (don't completely understand how with all the different encryptions) the GP password. Therefore the next time a CRM use attempts to open GP through the CRM the credentials should be in sync.

Any ideas, assistance would be of great help.

Questions:

Can I find out in GP what password is being passed across, or where some relevant data may be stored?
Does anyone have a similar solution, as a workaround, or experienced similar problems?
I'm assuming that the data passed from the integration code goes to the GP login user interface and not some backend code initially? This would help understand what password is actually being passed across, the CRM one or one which maps to GP by the UserId in someway.
I'm not sure I'm attacking this issue from the right angle, GP encryption and authentication appear initially to be where I think my issue arises. Could clearing out any tables assist? Note, i've about 500 CRM and GP users, so once i figure it out i'll aim to automate the update of user accounts/passwords, if its at all possible.

I've followed the following articles to assist with getting me this far:

Cheers,

Dave

GP Authentication - Validating the pass-through of credentials from another application?

Helpful resources

News and Announcements

Quick Links

November Spotlight Star - Khushbu Rajvi

Forum Structure Changes Complete!

Dynamics 365 Community Platform update – Oct 28

Leaderboard

Featured topics

Product updates