In my companies network looks like there is a +/- 10 minute delay between ACS reading information from AD as well as the ACS caching information instead of reading AD info in real time
We have Cisco ACS
Version : 5.8.1.4
AD domain controller - Windows server 2008
This is a problem because we stage computers anywhere without a proper staging area and we do that by an automatic script that creates a temporary object in AD for MAC address bypass and remove it later after the computer gets a proper certificate, but with this delay staging is failing at the initial steps, we have a work around for the moment.
We checked the AD and object creation and replication between domain controllers is very fast, takes seconds
My question is, is this normal behavior? is there a way to improve it? Like force the ACS to query/update from the AD more often?
Below are the tests performed that proved the symptoms:
Test#1 - 9:37 min to authenticate with MAB successfully
AD object created at 16:38:51
1293659: Jan 30 16:38:53.912 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB38F8D84AF9
1293679: Jan 30 16:41:17.541 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB38F8D84AF9
1293700: Jan 30 16:43:41.103 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB38F8D84AF9
1293719: Jan 30 16:46:04.749 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB38F8D84AF9
MAB Success - 2017-01-30 16:48:28.182
Test#2 - Authenticated with MAB successfully immediately
AD object created 16:58:02
MAb success - 2017-01-30 16:57:40.970 (times did not seem to make sense but it's explained in Test#3)
Test#3 - 12:21 min to authenticate with MAB successfully
AD object created at 17:07:37
1293885: Jan 30 17:08:00.823 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB85F8F983F9
1293893: Jan 30 17:10:24.486 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB85F8F983F9
1293901: Jan 30 17:12:47.948 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB85F8F983F9
1293909: Jan 30 17:15:11.569 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB85F8F983F9
1293917: Jan 30 17:17:35.139 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB85F8F983F9
MAB Success - 2017-01-30 17:19:58.817
Important Note:
MAB successfully authenticated at 17:23:59.799 and again at 17:31:52.278 after object was deleted in AD (Object was deleted around minute 17:22)
Seems to suggest ACS caches information and does not read AD info in real time, explaining what we saw Test#2
Test#4 - 9:43 min to authenticate with MAB successfully
AD object created at 17:40:48
1293949: Jan 30 17:40:57.133 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB90F917B2A2
1293957: Jan 30 17:43:20.619 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB90F917B2A2
1293965: Jan 30 17:45:44.400 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB90F917B2A2
1293973: Jan 30 17:48:07.719 CET: %MAB-5-FAIL: Authentication failed for client (f8ca.b84f.e68d) on Interface Gi1/0/26 AuditSessionID 00000000000ABB90F917B2A2
MAB Success - 2017-01-30 17:50:31.373
