topic Hi Falk, in Network Access Control

ISE -> Warning: SRV record found.Not all SRV records have IP, will need to run additional query for get IP.

Andreas Falk — Mon, 11 Mar 2019 07:07:04 GMT

Hi,

Our ISE servers today uses bind dns servers, but as a test we try to use our Active Directory DNS's as ISE dns servers.
In our test everything "works", but when doing a diag in Active Directory > ADM-AD > Active Directory Diagnostic Tool we get a warning from:

DNS SRV record query :

Test Name :DNS SRV record query
Description :Query for DNS SRV record using resolv.conf configuration and gethostbyaddr
Instance :ADM-AD
Status :Warning
Start Time :10:46:37 29.09.2016 CEST
End Time :10:46:37 29.09.2016 CEST
Duration :<1 sec
Result and Remedy...
SRV record found.Not all SRV records have IP, will need to run additional query for get IP.

Do you guys know what that warning really does behind the ui screen?
There are really not much my googlefu returns with this search..

ISE:
Version: 1.4.0.253
Patch Information: 4

AD:
Forest domain level 2008
On windows 2012 and 2008

BIND:
Bind 9.10.3

And the only thing we see with a tcpdump differs is that the BIND dns returns AUTHORITY SECTION and the AD dns does not?

Answer from a newly setup test bind as a slave to the DC dns returns:

falk@broekn ~$ dig _ldap._tcp.dc._msdcs.domain.local. SRV @10.8.10.105
; <<>> DiG 9.10.3-P4-Ubuntu <<>> _ldap._tcp.dc._msdcs.domain.local. SRV @10.8.10.105
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 10442
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4096
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.domain.local. IN SRV

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 WIN-QE31DOEGABT.domain.local.

;; AUTHORITY SECTION:
_msdcs.domain.local. 3600 IN NS win-qe31doegabt.domain.local.

;; ADDITIONAL SECTION:
win-qe31doegabt.domain.local. 3600 IN A 10.8.10.108
;; Query time: 2 msec
;; SERVER: 10.8.10.105#53(10.8.10.105)
;; WHEN: Thu Sep 29 11:49:53 CEST 2016
;; MSG SIZE rcvd: 156

And this is the same question directly from the newly setup AD test dns server:

falk@broekn ~$ dig _ldap._tcp.dc._msdcs.domain.local. SRV @10.8.10.108 1
; <<>> DiG 9.10.3-P4-Ubuntu <<>> _ldap._tcp.dc._msdcs.domain.local. SRV @10.8.10.108
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 44694
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.domain.local. IN SRV

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 WIN-QE31DOEGABT.domain.local.

;; ADDITIONAL SECTION:
WIN-QE31DOEGABT.domain.local. 3600 IN A 10.8.10.108
;; Query time: 1 msec
;; SERVER: 10.8.10.108#53(10.8.10.108)
;; WHEN: Thu Sep 29 11:51:40 CEST 2016
;; MSG SIZE rcvd: 126

Regards Falk

Hi Falk,

Gagandeep Singh — Thu, 29 Sep 2016 15:22:25 GMT

Hi Falk,

Is AD connector status operational.

Is it impacting any authentications in the network.

Put ad_agent to DEBUG level and then look for this error message in the

"show acs-logs filename ACSADAgent.log | in LW_ERROR_TOKEN_GROUPS_INSUFFICIENT_PERMISSIONS"

It might leads to permission issue for ISE as a computer account on AD.

Here is the documentation that shows more detailed information about AD Connector on ISE and the internal operations it takes which may help to understand what the DNS SRV records are used for and help us troubleshoot the issue. This document will have all useful information that shows what is required with ISE and AD integration as well.

The document is found at: Cisco ISE > Active Directory Integration with Cisco ISE 1.3 > AD Connector Internal Operations< http://www.cisco.com/c/en/us/td/docs/security/ise/1-3/ISE-ADIntegrationDoc/b_ISE-ADIntegration.html#reference_EA017E71F25145C9A1374373ABFA102E

Regards

Gagan

Hi,

Andreas Falk — Fri, 30 Sep 2016 15:05:08 GMT

Hi,

tnx for the debug tips.
After some debugging with dig, wireshark and lots of coffee we have located the problem (/me thinks)

We can reproduce the problem with dig and +noedns option.

The problem seems to be that we have 8 domain controller (we are migrating from 2008 to 2012) and the answer from the debug query get's "truncated" without edns. (no truncated flag in the .pcap)

For us the diagnose warning probably goes away when we only have 5 domain controllers left after the migration is done. Then the query answer should be smaller than 512 bytes, and no "truncation" should occur.

The anonymised dig's below, and the debug log is attached:

vanilla:

falk@broekn ~$ dig _ldap._tcp.dc._msdcs.domain.local SRV @192.168.9.127 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> _ldap._tcp.dc._msdcs.domain.local SRV @192.168.9.127
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 54522
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 9

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 4000
;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.domain.local. IN SRV

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-12.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-05.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-08.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-10.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-07.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-09.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-11.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-06.domain.local.

;; ADDITIONAL SECTION:
dc-12.domain.local. 3600 IN A 192.168.1.14
dc-05.domain.local. 3600 IN A 192.168.9.127
dc-08.domain.local. 3600 IN A 192.168.1.10
dc-10.domain.local. 3600 IN A 192.168.1.12
dc-07.domain.local. 3600 IN A 192.168.9.129
dc-09.domain.local. 3600 IN A 192.168.1.11
dc-11.domain.local. 3600 IN A 192.168.1.13
dc-06.domain.local. 3600 IN A 192.168.9.128

;; Query time: 0 msec
;; SERVER: 192.168.9.127#53(192.168.9.127)
;; WHEN: Fri Sep 30 16:01:21 CEST 2016
;; MSG SIZE rcvd: 524

+noedns:

falk@broekn ~$ dig +noedns _ldap._tcp.dc._msdcs.domain.local SRV @192.168.9.127 

; <<>> DiG 9.10.3-P4-Ubuntu <<>> +noedns _ldap._tcp.dc._msdcs.domain.local SRV @192.168.9.127
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 35413
;; flags: qr aa rd ra; QUERY: 1, ANSWER: 8, AUTHORITY: 0, ADDITIONAL: 7

;; QUESTION SECTION:
;_ldap._tcp.dc._msdcs.domain.local. IN SRV

;; ANSWER SECTION:
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-05.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-08.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-10.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-07.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-09.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-11.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-06.domain.local.
_ldap._tcp.dc._msdcs.domain.local. 600 IN SRV 0 100 389 dc-12.domain.local.

;; ADDITIONAL SECTION:
dc-05.domain.local. 3600 IN A 192.168.9.127
dc-08.domain.local. 3600 IN A 192.168.1.10
dc-10.domain.local. 3600 IN A 192.168.1.12
dc-07.domain.local. 3600 IN A 192.168.9.129
dc-09.domain.local. 3600 IN A 192.168.1.11
dc-11.domain.local. 3600 IN A 192.168.1.13
dc-06.domain.local. 3600 IN A 192.168.9.128

;; Query time: 0 msec
;; SERVER: 192.168.9.127#53(192.168.9.127)
;; WHEN: Fri Sep 30 16:01:50 CEST 2016
;; MSG SIZE rcvd: 497

So I guess that we have our usual bad luck with both the names and number of servers so this can happen 🙂

From my little dns knowledge the answer should be flagged as truncated and the question should be re-queried on tcp.
But the answer from the dc's is flagged with "Message is not truncated".

Regards Falk

Hi Falk,

Gagandeep Singh — Fri, 30 Sep 2016 15:32:15 GMT

Hi Falk,

You are correct about DNS resolution in terms of packet length.

TCP < 512

UDP > 512

Also it's recommended if you do an upgrade on DC side, you need to rejoin ISE with AD for best practices.

Regards

Gagan

ps: rate if it helps!!!!