Inbound AIF: Logon Failure

(0) Share

Report

Posted on by Community Member

Hello,

I have a custom service I use to import data. I'm having difficulties since its throwing the following error in the Queue Manager:

The request failed with the following error: Failed to logon to Microsoft Dynamics AX.
View the exception log for more details.

I tried Refreshing the WCF Configuration in the Configuration Utility, but no luck.

Any ideas?

Thanks,

Lyka Tasis

*This post is locked for comments

I have the same question (0)

All responses (9)

Answers (1)

MukeshHirwani 1,180 on at

Like (0)

Report

Are u sending user id to create the record.. Make user the User you provide has correct set of permissions.

Was this reply helpful? Yes No
Community Member on at

Like (0)

Report

Hi Mukesh,

I only identify the Action for my custom service. The Message Id, SourceEndpoint, DestinationEndpoint, and SourceEndpointUser - I did not specify. Plus, I am only testing my service via Job.

Was this reply helpful? Yes No
MukeshHirwani 1,180 on at

Like (0)

Report

which adapter u r using??

Was this reply helpful? Yes No
Tommy Skaue Moderator on at

Like (0)

Report

Is this a custom service you intend to use outside the local network domain?

Was this reply helpful? Yes No
Verified answer

Community Member on at

Like (0)

Report

Hi Mukesh,

I am using File System Adapter.

Hi Tommy Skaue,

No, I don't intend to use this outside the local network domain. But thanks to the question, it serves as my lead.

I have a standalone AX 2012 in my laptop, I am not connected to our domain in the time of testing and I guess that's the reason why the BC service account cannot logon that time.

Was this reply helpful? Yes No
Suggested answer

MukeshHirwani 1,180 on at

Like (0)

Report

Next to adapter field there is a configure button, Adapter configuration form will come up. Check Use default owner for Administrators group and select Admin in the field list. Reactivate port n try..

Was this reply helpful? Yes No
Suggested answer

Community Member on at

Like (0)

Report

I had the same issue where the services had a logon failure. I tried to restart the AOS service and it failed so I updated the account logon and it fixed AIF.

Was this reply helpful? Yes No
psined on at

Like (0)

Report
I got the same issue, except when calling a custom service on Basic inbound net.tcp port from outside the local domain. It used to work great cross-domain for several months until about a few weeks ago, when it stopped with the dreaded "Failed to logon to Microsoft Dynamics AX" error. So now it only appears to work (with exactly same binding settings in the client app.config) from within the local domain. All this takes place in AX 2012 R2.

What are the implications of calling an AIF inbound port from outside the local network domain and what considerations should be made while setting such inbound port up?

P.S. The stack trace on the client is as follows:

System.ServiceModel.FaultException: Failed to logon to Microsoft Dynamics AX. Server stack trace: at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc) at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout) at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation) at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Was this reply helpful? Yes No
psined on at

Like (0)

Report

I was able to fix my issue with cross-environment access. For those who are interested the issue had nothing to do with AX AIF; it rather had to do with SIDs of the accounts being out of sync. In other words while the login/domain/password for the account have appeared the same between the environments, the SIDs turned to be different. From what I understand WCF RSA-encrypts messages with SID being part of the key hash. This explains why it has worked for a little while until lately - as turns out someone has dropped the service account from the AD in the target environment and recreated it from scratch. As soon as we matched the SIDs between the environments the issue was no longer.

Was this reply helpful? Yes No