I'm trying to get Kerberos authentication work between the AX client and the AOS in 2012 R3 CU 10 or so.
I found the following blog post that describes it.
https://blogs.msdn.microsoft.com/axsupport/2015/03/20/enhanced-security-with-kerberos-only-authentication-in-microsoft-dynamics-ax/
Implementing it would seem straightforward, i.e. just put authn_service 16 in the AOS registry key and authn_service,Text,16 in the configuration file, and indeed if you do both the client can connect to the server. But, I'm not seeing a cached ticket using KLIST TICKETS | FIND "2712" as expected (at least not reliably, sometimes but not always).
I'm stumped trying to figure out if the AX client is ACTUALLY using Kerberos authentication over RPC to the AOS or not. If anyone knows of a way to determine this for certain, I'd tremendously appreciate a push in the right direction.
I've already tried all 9 combinations of the authn_service settings (empty, 9, or 16 on the client and empty, 9, or 16 on the server), and what I've found is that ALL combinations work EXCEPT when the server's authn_service is 16 (Kerberos only) and the client's authn_service is missing or 9 (negotiate). I find that odd, in particular that the client could be set to authn_service of 16 (Kerberos only) and the server set to missing (NTLM only), and for reasons I cannot explain the client connects to the server anyway.
It appears from testing that authn_service missing and authn_service 9 behave identically for both server and client. This suggests to me, since I cannot see whether NTML or Kerberos is ACTUALLY being used, that negotiate prefers NTLM over Kerberos as implemented by AX. I've never seen a Microsoft product where NTLM was preferred over Kerberos when both were available. Most Microsoft documentation suggests moving away from NTLM and to Kerberos wherever possible, and not just for reasons for delegation.
After a while I landed on the idea that I could just configured the server's authn_service as 9 (negotiate) and the client's authn_service as 9 (negotiate) and I expect Kerberos to be used wherever the server (subject to SPN registration, which I do have working) and client both support it, but would fall back to NTLM otherwise, which is not ideal but a useful compromise in a production environment. I'm not convinced at all that 9 and 9 ever actually use Kerberos at all.
Finally, and probably worst of all, if you set the server's authn_service as 16 (Kerberos only), it becomes impossible to install the AX client with reference to that AOS. The installation wizard, for better or for worse, actually connects to the AOS using the information supplied, and since you CANNOT interject an authn_service of 16 during the installation process, the installer cannot possible connect to a server with authn_service at 16 (Kerberos only). Thus, negotiate would seem even more useful in that light.
What was Microsoft thinking? None of this appears to work as documented, and worse it doesn't appear to work in a way that can be made useful. Are we supposed to be unable to install the client software without reverting the AOS back to NTLM only, which of course requires an AOS restart? How does anyone actually use Kerberos between the AX client and AOS?
I can tell from SQL Server quite easily which connects are Kerberos and which are NTLM, i.e. select * from sys.dm_exec_connections, so I can know positively that Kerberos is working. What means do we have with AX to inspect what authentication was actually used for client connections?
