Back to Blog
Ischedule srv record6/22/2023 The AD guys in my group put the FQDN of the Domain Controller in the Target field. You'll have one of these records for each DC. ![]() For example, if you have a SRV record for _ldap._tcp.dc._, it will have entries for Priority, Weight, Port, and Target, the Target being one of the Domain Controllers in your domain. If you look up a name, and you get another name, you then need to look up that second name to get an IP.Īssuming that SRV records exist in your DNS for each of your AD Domain controllers, you need to look at the actual data in the records. A forward DNS query looks up a name, in this case, the name of a particular SRV record, and it expects to get an IP address as the response. Look at what the error says: It says it could not find an IP, and that a second query would need to be run to find it. I have had this issue in multiple versions of ISE, and I've essentially ignored it for at least 4 years. per se, but it is an inefficiency perhaps. I will take your advice and try again with TAC - though I am certain they will point to the truncation issue again and I will try to fight my way through it. I was guessing that this issue was somewhat prevalent - given that we are using DNS default settings - so I was wondering if anybody else might know a strategy for suppressing 1/15th of a diagnostic routine that I could not find. The false warning significantly reduces the value of the diagnostic routine, in that it requires human analysis to decide upon whether the alert means that an error condition actually exists or if the false positive is the only issue being reported.Īlso note: I am not trying to use this forum as a replacement for TAC.A single step of an ISE 15 steps diagnostic routine is assuming that a valid and expected response form a DNS query is an error condition - and it is generating a false warning alert - not just for that subset - but for the ENTIRE diagnostic routine.It was nice to get a refresher on the AD connector - though it really has nothing to do with the issue here. Is there anything else I can do here? Can I somehow remove this test from the schedule, change the test, etc.? I could just “not run” a scheduled AD diagnostic test – but then I lose the ability to ensure that the ISE AD connection is healthy.I could reduce the severity of the “ Active Directory Diagnostics tests failed” alert but then I will not be alerted if one of the other 14 diagnostic tests fail. ![]() The only mitigation steps I can think of both seem to be unacceptable: So now – we have a situation where an expected response during a schedule diagnostic test – generates a “failed” alert to our operations staff of a significance that would typically generate an incident report (and possible page-out). The rather innocuous warning message above in 1 out of 15 diagnostic tests generates a system-wide “Warning” level alert to be generated – stating:Īctive directory diagnostic tool found issues - One or more Active Directory diagnostic tests failed during a scheduled run. A quick Google search of DNS and “Minimal Responses” shows that “True” is the default setting in Infoblox and Bind – and it seems to be a standard practice to maintain that setting. This limits the response to the ISE query so it does not include the IP addresses of the AD domain controllers. Our DNS Servers have the “Minimal-Responses” option set to “True” (see ). Not all SRV records have IP, will need to run additional query for get IP. Tests executed during this diagnostic routine are as follows:Īll tests come back as successful – except the “DNS SRV record query” test: I have scheduled my ISE servers to run Active Directory diagnostics every night to ensure that the connection to Active Directory is healthy. I have brought my case to TAC, and they cannot seem to get the above mentioned truncation issue out of their head - so I am looking for some assistance here. I do not have too many domain controllers or SRV records and the response is not getting truncated. First of all, this post has nothing to do with.
0 Comments
Read More
Leave a Reply. |