Skip to main content

Notifications

Announcements

No record found.

Community site session details

Community site session details

Session Id :
Microsoft Dynamics GP (Archived)

eConnect service user account clarification / security model

(0) ShareShare
ReportReport
Posted on by


Hello community, I have a couple questions concerning the Integration Manager application and it's relationship with eConnect.

In the GP 2013 eConnectIntallAdminGuide, it explains that the service user account should be given DYNGRP role for each company that will be accessed by the eConnect service. This implies that the service user account will be used to access/modify the company data when applications interface with the eConnect service.
This does not seem to be the case with the Integration Manager application. When running an integration ( that uses the eConnect adapter ) with a user that does not have direct access to the database, connect errors are encountered ( DOC 1 ERROR: System.Data.SqlClient.SqlError: Cannot open database "[Database Name]" requested by the login. The login failed. ). Creating a security login for the user launching the intergration and giving that user permissions to the database allow the integration to run without incident.

So my first question is : am I really expected to give a user access to the back end database in order to achieve this functionality ? ( I'm thinking here of the risk, and the complete disregard for the Dynamics GP security model. )

My second question is more pointed to the functionality of the Integration Manager application. It appears that there are some fields that are available to map to when using the eConnect adapater that are not available when using the Microsoft Dynamics GP adapter. For example : Microsoft Dynamics GP eConnect -> Receivables Management -> Customer allows for mapping to the Addresses -> Internet Information -> "To Address" and "CC address" where those fields do not exist using the equivalent Dynamics GP adapter.
So my second question is : Are there some fields that you are required to use the eConnect adapater inside Integration Manager to be able to update?

Thanks

*This post is locked for comments

  • RE: eConnect service user account clarification / security model

    Thanks for the response, Tim.

    Got it. Integration Manager using eConnect adapter is the new hotness, gives additional functionality, good to know.

    As for the security, here's where it gets even more confusing.

    I have two different Terminal Server installations, both exhibiting different behaviour when it comes to running an IM integration. System 1 running eConnect service as Administrator account returns a failed login error when running an integration as a user with NO database permissions. ( "The login failed." )

    System 1 running eConnect service as Administrator account returns success when running as a user WITH database permissions.

    System 2 running eConnect service as Administrator account returns success whether the user has permissions to the database or not.

    So this goes to my first question about the security model. I'm curious as to why one system (I'm assuming) will use the credentials that the service is running as, and another will not. My preference would be to rely on the logged in users permissions rather than the service credentials so that I can have some measure of security that not everyone that has access to the server can run IM and manipulate the database through eConnect.

    Any information you can provide is much appreciated.

    Thanks!

  • Tim Wappat Profile Picture
    Tim Wappat 5,703 on at
    RE: eConnect service user account clarification / security model

    As no one has answered yet, I'll try but IM is not my specialty so this is more on observation through experience that knowledge.

    Integration manager (IM) has a split personality, as you have discovered. I don't know the full history myself, but I'd hazard a guess that it used to go direct from the application to GP, then when eConnect was invented, IM was updated to use eConnect, but had to retain the old way too, for those that had existing integrations (totally guessing here from what it feels like).

    So when you access using the non-econnect route, you are accessing GP under the IM credentials.  

    When you go through eConnect, it will be going through the eConnect service and hence using those credentials, but (guessing again) I guess even running an econnect integration it direct lookups to GP that still require the GP credentials?

    Your last question, the answer is yes, the old integrations seem to be only there to support legacy integrations, so as new fields were added to GP like the ones you mention, then eConnect supported them but not the direct to GP adapter. So you can only get to some fields through one or the other of the adapters, messy or confusing.

    Tim.

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

Daivat Vartak – Community Spotlight

We are honored to recognize Daivat Vartak as our March 2025 Community…

Announcing Our 2025 Season 1 Super Users!

A new season of Super Users has arrived, and we are so grateful for the daily…

Kudos to the February Top 10 Community Stars!

Thanks for all your good work in the Community!

Leaderboard

#1
André Arnaud de Calavon Profile Picture

André Arnaud de Cal... 292,516 Super User 2025 Season 1

#2
Martin Dráb Profile Picture

Martin Dráb 231,432 Most Valuable Professional

#3
nmaenpaa Profile Picture

nmaenpaa 101,156

Leaderboard

Featured topics

Product updates

Dynamics 365 release plans