Kerberos Delegation and NTLM auth Exchange 2013

I have tried both, by leaving the FQDN blank and specifying a specific domain controller fqdn, fails both ways. Here are the logs for enumerating KDC's via DNS, which it is able to do successfully. Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 01490175:5: Prefer resolving hostname with IPv4 address Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: Using the following server settings: Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: domain name = 'JHHC.COM' Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: domain controller = '' Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: admin name = 'gricketts1' Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: admin password = ****** Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: PADATA encryption type = Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: none Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: Other settings specified for the test: Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: test type: AD Domain Join Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: userName: Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: concurrency: 1 Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: CCache file root: /var/run/krb5cc Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: output file: Aug 14 08:49:10 JHHCF5 notice adutil[32504]: 0149019f:5: urlDecoded: 0 Aug 14 08:49:10 JHHCF5 err adutil[32504]: 01490200:3: thread 0 started Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: verifyKrb5Cache(): Credentials cache file '/var/run/krb5cc/ADTest/krb5cc_0_apmd' not found, func=krb5_cc_set_flag(0), ticket cache FILE:/var/run/krb5cc/ADTest/krb5cc_0_apmd Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Domain Controller is not specified for domain 'JHHC.COM', KDCs will be discovered using DNS Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'vmdc03.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'jhhcdc02.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'jhhcdc01.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 01490000:7: Utils/Sys.cpp func: "getIpv6Preference()" line: 46 Msg: Prefer IPv6: false Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Using '127.0.0.1' as a Name Server Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: authenticate with 'gricketts1' successfully Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Domain Controller is not specified for domain 'JHHC.COM', KDCs will be discovered using DNS Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'vmdc03.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'jhhcdc01.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Adding 'jhhcdc02.jhhc.com' to KDC list Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 01490000:7: Utils/Sys.cpp func: "getIpv6Preference()" line: 46 Msg: Prefer IPv6: false Aug 14 08:49:10 JHHCF5 debug adutil[32504]: 0149019d:7: Using '127.0.0.1' as a Name Server Aug 14 08:49:20 JHHCF5 err adutil[32504]: 01490200:3: ERROR: Could not connect to domain domain controller of realm 'JHHC.COM' Aug 14 08:49:20 JHHCF5 debug adutil[32504]: 0149019d:7: do_connect: error = -1 Aug 14 08:49:20 JHHCF5 err adutil[32504]: 01490200:3: ERROR: domain join for 'JHHC-BIGIP' failed: Can't contact LDAP server (-1) Aug 14 08:49:20 JHHCF5 debug adutil[32504]: 0149019d:7: ldap_sasl_interactive_bind_s(): Can't contact LDAP server (-1) Aug 14 08:49:20 JHHCF5 debug adutil[32504]: 0149019d:7: Aug 14 08:49:20 JHHCF5 notice adutil[32504]: 0149019f:5: thrd_id[0]: succ_cnt=0, fail_cnt=1 I can dig all the DC's from the BigIP as well, no issues with DNS doesn;t seem like. And a packet capture shows a successful LDAP bind response from the DC

OK really weird. I just kept retrying joining the BigIP to the domain and it finally worked. No idea how that happened. This happened to me prior when configuring the machine account originally. I tried a few times and it failed. Opened a case, tried again and it finally worked. All the same config. OK, now to try to reconfigure iApps to use new NTLM config. Keep you posted.

OK. With the machine account recreated and NTLM auth config redone, I am able to successfully authenticate to both internal and external iApps. I guess I can only chalk this up to something was busted with the initial machine account perhaps? I am not sure. I did notice in the ECA debug logs, I am actually sending NTLMv2 auth requests. In the appendix for the echange 2013 iApp there is a manual process for replacing the NTLM profile with an NTLMv2 profile. How is this working if NTLMv2 is being sent but the iApp is configured to accept NTLM? Is it necessary for me to follow the NTLMv2 config procedure at this time?

Great! NTLMv2 mentioned is for SSO, not for NTLM Auth. Not relevant for OA here, as Kerberos is used for SSO.

Got it, I noticed it was created but never actually selected as an SSO profile used in the exchange policy. When would it be used? If exchange did not support kerberos auth?