Update on AX 2012 R3 AOS Service Principal Name (SPN)

I wrote about this back in June 2014 and based on the experience gained since this and the fact that Microsoft just published some relevant information, it's necessary with an update to this subject.

First of all, this is all about securing RPC Connections requiring Kerberos Authentication. RPC Connections are connections through the AX Windows Client or the .NET Business Connector. Not all AX Environments will require Kerberos Authentication, but the AOS Binary will by default try to  register (and de-register) a Service Principal Name (SPN) at Service Start up (and Shutdown) to support "a Kerberos and NTLM mix" (see URL for corresponding Microsoft Blog post below).

Secondly, this has nothing to do with the installer confusing a Standard Service Account with a Managed Service Account in AD. The number part of the SPN is in fact the reference to the Service Class for the AOS instance.

And finally, Microsoft recently (March 20 2015) published information on their Microsoft Dynamics AX Support Blog titled Enhanced security with Kerberos only authentication in Microsoft Dynamics AX. This is the only information I have found covering this subject and it contains very valuable information to understand the new behavior. And most importantly it reveals that this is now the default behavior for all Binaries released after AX 2012 R2 CU7 covering AX 2009, AX 2012 R2 and AX 2012 R3.

If not already described as a requirement by the customer, you should ask your customer if they require Kerberos or not. If they require Kerberos, you need to approach this as a separate configuration task since it requires more that the AOS successfully registering the SPN in AD. If the customer does not require Kerberos (can live with NTLM) Authentication and you want to get rid of the Error logged at AOS Instance Start and Stop, all you have to do is

1. Regedit - Add a new String Value to the Current AOS Configuration with the name authn_regspn
2. Enter 0 (zero) as the value of authn_regspn

This will disable automatic registration and de-registration of the SPN, and avoid the message from being logged to the Event Log every time the AOS Instance starts and stops. And it will possibly also shave off some seconds from the start and stop sequence.

Additional information can be found in the Dynamics AX Community Forum.

I will try to write about a possible approach to configure AX for Kerberos Authentication in a separate post.

AX 2012 R3 AOS Service Principal Name (SPN)

March 26 2015 - please also read my Update on this subject.

After working my way through both a new installation and upgrades from AX 2012 R2 (CU7), I find at least one glitch that 1) logs an Error in Event Log - Application when stopping and starting the AOS Service  and 2) that possibly increases the time to start the AOS Service.

I notice the following events beeing logged:

• Start of AOS Service > Object Server 01:  RPC error: Failed to register service principal name (SPN): '<GUID>/<server>.<FQDN>:<AOS RPC Port#>' 
• Stop of AOS Service > Object Server 01:  RPC error: Failed to unregister service principal name (SPN): <GUID>/<server>.<FQDN>:<AOS RPC Port#>' 

This seems to be related to utilizing Managed Service Accounts (an option when specifying the AOS Service Account) or not, where it seems like the AOS Service operates like it's always hosted by a Managed Service Account. In all installations I have used "Use the following account" and not the "Use a managed service account", but despite this deliberate choice, the messages are beeing logged.

Maybe it's difficult or even impossible to separate the different types of Service Accounts, but it should be possible to have this as a property for the Service (registry). The time it takes to start the AOS Service seems to increase in each release of AX 2012 due to the increased number of processes the AOS Service must handle and possible time consuming tasks like this, should indeed be avoided.

Bottom line - I'm supprised to see SPN errors beeing logged like this even when not utilizing a Managed Service Account (which requires a SPN and new requirements regarding integration to objecst in Active Directory).