02-08-2017 11:23 PM
Hi Everyone,
We are testing a Microsoft endpoint which belongs to the customer's domain network to authenticate via ISE. The authentication work fine but during the posture analysis the endpoint doesn't redirect to the ISE portal for downloading the NAC.( Note: An MS endpoint which is not in domain i.e not part of AD does't have this problem).
After contacting TAC and running several packet captures we found that the Microsoft direct access is causing the problem. Because of it we are not able to resolve the intranet DNS queries.
Please find the below link for reference:
https://technet.microsoft.com/en-us/library/ee844142(v=ws.10).aspx
The option of disabling the Microsoft direct access is ruled out for now. Would be great if someone could give me a solution .
Solved! Go to Solution.
08-06-2017 12:28 AM
This issue was resolved when we added the Microsoft Direct Access server's IP to the permit IP address of DACL.
Since the endpoint was not able to reach the MDA server during the initial phase of posturing it assumes that it's outside the corporate network and tries to connect to the network when it is actually inside. When we allowed the MDA's IP address in DACL everything started to work fine.
02-09-2017 12:55 PM
I'm glad the TAC was able to troubleshoot and find the problem.
ISE cannot control/override the endpoints' DNS behavior if the Microsoft Admin has provisioned it not to resolve certain DNS queries.
02-10-2017 12:38 AM
to expand, would recommend Microsoft DA is disabled from auto start. Let client do its thing needed and then can then launch DA.
Keep in mind anytime the device is required to posture then DA will need to be stopped so it can talk to ISE. Unless allowed through the tunnel?
Or perhaps static DNS entries on the devices for each ISE node
ISE 2.2 with the removal of the need for URL redirection might help as well. Anyconnect posture can talk to
You could push out the agent through a management tool or force them to go to static PSN URL (such as getpostureagent.domain.com)
Anyways will need valuation in the lab to understand how to approach
08-06-2017 12:28 AM
This issue was resolved when we added the Microsoft Direct Access server's IP to the permit IP address of DACL.
Since the endpoint was not able to reach the MDA server during the initial phase of posturing it assumes that it's outside the corporate network and tries to connect to the network when it is actually inside. When we allowed the MDA's IP address in DACL everything started to work fine.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide