Forum Discussion
Greg_130338
Nimbostratus
NimbostratusKerberos Delegation and NTLM auth Exchange 2013
This is related to a previous post about the Exchange iApp. Everything is working for both internal and internal connections except from Outlook Anywhere clients attempting to connect to the external VS and auth via RPC over HTTP. I enabled all debug logs for APM and ECA since that seemed to be where the failure was occuring. I noticed the following and cannot make much sense of it. Any help would be appreciated. Below is the log file comparison between a successful auth though the internal iApp vs the failed auth through the external iApp. This is just a snippet of the full log. Everything before these lines in the log is the same for both internal and external connections. It seems to fail when the BigIP tries to make a call to itself to process the logon request, anyone ever see this before?
Internal success: Aug 12 13:22:12 JHHCF5 debug eca[7237]: 0162000c:7: [Common] 10.1.12.9:46380 (0x09a8b9c8) Server challenge: 24296533D8C59FB4 Aug 12 13:22:12 JHHCF5 debug nlad[8603]: 01620000:7: <0x559058f0> clntsvc: processing 'logon' request on connection[18] from 127.0.0.1:43935 Aug 12 13:22:12 JHHCF5 debug nlad[8603]: 01620000:7: <0x559058f0> client[5]: is ready Aug 12 13:22:12 JHHCF5 debug nlad[8603]: 01620000:7: <0x5624cb90> NLAD_TRACE: nlclnt[53403010a / 01] sending logon = 0xC00000E5 Aug 12 13:22:12 JHHCF5 debug nlad[8603]: 01620000:7: <0x5624cb90> nlclnt[53403010a] logon: entering user GRicketts domain JHHC wksta JHHC04619LT
Failed auth: Aug 12 12:51:10 JHHCF5 debug nlad[8603]: 01620000:7: <0x559058f0> clntsvc: processing 'logon' request on connection[38] from 127.0.0.1:44495 Aug 12 12:51:10 JHHCF5 warning nlad[8603]: 01620000:4: <0x559058f0> clntsvc: no client for id 6 to service request from connection[38] from 127.0.0.1:44495 Aug 12 12:51:10 JHHCF5 debug nlad[8603]: 01620000:7: <0x559058f0> nla_rq: response with status [0xc00000ab,NT_STATUS_INSTANCE_NOT_AVAILABLE] for type 'logon' client 6 context 0x5ab82b90 24 bytes to connection[38] from 127.0.0.1:44495: took 0 milli-seconds Aug 12 12:51:10 JHHCF5 debug eca[7237]: 0162000c:7: [Common] 12.181.141.210:45214 (0x5bf14c28) nla_agent::logon, rc = STATUS_NO_LOGON_SERVERS (3221225566)
kunjanHow about doing
?bigstart restart nlad
Greg_130338well I tried it anyway. It didn't fix the issue and actually now the internal connection fails as well with the same error.- Greg_130338Do you know the impact of this? I see the definition of this service in the documentation, but would this impact communications with other AAA services, for example, for my citrix users that point to back end DC for authentication? Or this is only for access policies where an ntlm profile is assigned?
kunjan_118660Cumulonimbus
How about doing
?bigstart restart nlad- Greg_130338well I tried it anyway. It didn't fix the issue and actually now the internal connection fails as well with the same error.
- Greg_130338Do you know the impact of this? I see the definition of this service in the documentation, but would this impact communications with other AAA services, for example, for my citrix users that point to back end DC for authentication? Or this is only for access policies where an ntlm profile is assigned?
Stanislas_Piro2Hi,
Did you try to renew NTLM machine account password?
It's hard to say what's going on here with the information provided. Do you have solid connectivity to the domain controllers? Do you have different virtuals servers for external and internal, and if so are the APM policies configured the same? Is it the same user trying to logon in both cases? You should probably open a support case with F5 on this. If you post the case here I can track it and try to help wherever I can.
- That is unusual, and this not a use case that we've specifically tested; normally we'd see APM deployed only for the external clients. You've said you created new APM configs for both; are you using the same delegation and machine accounts for both configs? After it stops working, if you run "bigstart restart websso" on the BIG-IP, does it start working again? I looked at your case but couldn't find an iHealth upload for it. If you can post one I will take a look.
- Greg_130338and again the interesting part about this is when I initially configured the iApp everything worked as expected. It wasn't until after a period of time where it would fail. I am at a loss right now.
- Greg_130338hey Mike, thanks for tagging along here. I do have two different iApps configured the exact same way, the only difference being my VS IP is different. One public IP and one internal IP. I did not reuse any profiles while configuring the 2nd iApp, everything was newly created. I am authenticating with my user account in both scenarios. I had the issue before where iRules did not carry over correctly and profiles were in different partition paths but that is not the case currently. I know my DC connectivity is fine because I am using the same domain controllers for both the external and internal iApps, internal works, external does not. The logs almost indicate that the problem is internal to the BigIP since it's using the loopback IP and trying to open a service to respond to the logon request. I do have a case open for this. C1898067. Thanks for the help! I can get you full logs too if you think it will help. That is the fork in the road though between success and failure. everything prior to in the APM log file is exactly the same for that connection.