Recommended practice for asp.net/c# application logins?

(0) Share

Report

Posted on by Community Member

We have quite a few external (asp.net/c#) applications(10+) connecting to AX. Some are public facing, some internal.

Since each login requires a license, we'd like to limit the login accounts.

I'm thinking:

1. Create a public facing account and an internal account (both are not sys admin accounts, and grant only what's required by these applications)

2. Encrypt the web.config login

My concern is that, if we create a non sys admin account, it may be challenging to manage the account (update rights for every new application we build) and also makes development more difficult. (So much easier to have a sys admin account and develop and deploy).

In writing this, this makes me think.. use a sys admin account for development, but for production, use limited access accounts -- one for public and one internal facing applications.

What security measure do you recommend? What do you actually practice? Would love to hear your thoughts/recommendations.

Thanks in advance!

*This post is locked for comments

I have the same question (0)

All responses (14)

Answers (2)

Vilmos Kintera 46,149 on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

Yes, you are correct. This is exactly what I have explained and how we use it. The account under which you execute the request/service is the trusted intermediary user, in our case the "API account".

Was this reply helpful? Yes No
Verified answer

Community Member on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

The answer: you need both LogonAsUser, Windows Login, and create access to the Services and Tables in the AOT

holdClient.ClientCredentials.Windows.ClientCredential.Domain = ConfigurationManager.AppSettings["Domain"];

holdClient.ClientCredentials.Windows.ClientCredential.UserName = ConfigurationManager.AppSettings["UserName"];

holdClient.ClientCredentials.Windows.ClientCredential.Password = ConfigurationManager.AppSettings["Password"];

holdCC.LogonAsUser = ConfigurationManager.AppSettings["LogonAsUser"];

None of the account needs admin access, the Active Directory account needs to be in the trusted intermediary list (not the claims user) for the service.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

Do you just have holdCC.LogonAsUser = ConfigurationManager.AppSettings["LogonAsUser"]; where you specify the user?

I've unchecked trusted intermediary and the AD & Claims user account still isn't working.

I'll need to step through the code to see what's happening, the error messages vary and is quite vague.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

The example works for me fine, which means you must be doing something incorrectly.

Try using the debugger and see where/what does go wrong, what is the Exception, what is the message. If the trusted intermediary does not work, you could try to temporarily deactivate it, which means all authenticated regular AX users could connect, while you troubleshoot what is wrong.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
RE: Recommended practice for asp.net/c# application logins?

Can you provide the c# login code? I tried the link you've provided including variations of:

1.

holdClient.ClientCredentials.Windows.ClientCredential.Domain = ConfigurationManager.AppSettings["Domain"]; holdClient.ClientCredentials.Windows.ClientCredential.UserName = ConfigurationManager.AppSettings["UserName"]; holdClient.ClientCredentials.Windows.ClientCredential.Password = ConfigurationManager.AppSettings["Password"];

2.

holdClient.ClientCredentials.UserName.UserName = ConfigurationManager.AppSettings["UserName"]; holdClient.ClientCredentials.UserName.Password = ConfigurationManager.AppSettings["Password"];

3.

holdCC.Company = ConfigurationManager.AppSettings["Company"]; holdCC.LogonAsUser = ConfigurationManager.AppSettings["LogonAsUser"];

But it's not working for some reason.

Was this reply helpful? Yes No
Suggested answer

Vilmos Kintera 46,149 on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

You are not doing it like I said. You need a valid AX user account (we call it API account), that will act as your trusted intermediary and can establish a connection to AX and is NOT a claims user (referred as calling user in the Documentation).

When you do it from C#, you can provide additional details in the "context", like which company do you want to connect to AND under what user account's credentials (claims user, just needs correct security access to perform the task, no direct interaction with the client, just the AOS) do you want to carry out your task. That is the bit which you are confused about I believe.

technet.microsoft.com/.../hh582244.aspx

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

I've just tested the claims user account on a test server and AX rejected the account, it will only work with an AX sys admin account it seems. (apparently the app running locally was using my windows login to get to the service) I've rejected my answer above.

Still not sure how to get a claims user account working with the app and AX.. I've added the claims user as a trusted intermediary as well.

Was this reply helpful? Yes No
Vilmos Kintera 46,149 on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

Claims users are also domain users, but we use a separate domain for them.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report
RE: Recommended practice for asp.net/c# application logins?

**UPDATE: below is not a solution **

For future visitors, what that means is use a non AD account.

1. Create a "Claims" user in AX

2. Add the user as a trusted intermediary for the inbound port

3. Apply the related service operation

4. Activate the inbound port

5. Your .net/c# code login should look like so:

Client.ClientCredentials.UserName.UserName = "Username";

(note there's no .windows., password, and and no domain needed in the code)

Was this reply helpful? Yes No
Verified answer

Vilmos Kintera 46,149 on at

Like (0)

Report

RE: Recommended practice for asp.net/c# application logins?

To answer your question, in practice we have created separate accounts for each AIF inbound port that we would like to expose. Those users are set as Trusted intermediary users on the inbound port, so noone else could consume it, only the intended audience. Those are our API users, exchanging information between AX and our web site / drivers' delivery application / inventory counting devices etc. Each has its' own license obviously for the previously mentioned reasons. That is only used to establish connection with AX from the API, after which we use runAs() to impersonate specific users and their security access to carry out tasks, like raise a sales order. Those web users are of User type Claims-based, because they do not need interactive logins within the AX client.

I hope the above scenario sheds some more light on what can and should you do.

Was this reply helpful? Yes No

Community site session details

Recommended practice for asp.net/c# application logins?

Helpful resources

News and Announcements

Quick Links

Responsible AI policies

Andrés Arias – Community Spotlight

Congratulations to the August Top 10 Community Leaders!

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

Featured topics

Product updates

Community site session details

Recommended practice for asp.net/c# application logins?

Helpful resources

News and Announcements

Quick Links

Responsible AI policies

Andrés Arias – Community Spotlight

Congratulations to the August Top 10 Community Leaders!

Subscribe to this forum!

Select categories

Leaderboard > 🔒一 Microsoft Dynamics AX (Archived)

Featured topics

Product updates