To whom who may help me :)
Problem Description: Mapping IP addresses to users are not happening.
Scenario: Two pairs of ISE 1.2 with patch 7 and using a CDA patch 2 in order to map users that do not directly login into Active Directory. I´m using the CDA as a syslog server, receiving the syslog messages from ISE and trying to populates the mapping table.
Tests that i´ve conducted so far:
- Reload the ISE and CDA.
- Changed the security levels of the syslogs
- Removed the Active Directory Servers from CDA so that I could have only one variable, the syslogs messages, to troubleshoot.
- Reconfigured ISE to send the syslog messages to a Solarwinds server to troubleshoot the messages ( at this point so far so good, I can see the messages sent from ISE to the external syslog server )
- Troubleshooted the ports open at CDA and ISE
- Changed from UDP to TCP , and vice versa, the syslog client protocol
- Followed the "Installation and Configuration Guide for Cisco Context Directory Agent, Release 1.0" doc
but nothing that i´ve done to this point I can see the mappings from users to IP addresses. Does anyone have any clue for this?
I´ve attached a couple of screenshoots for you to see!
It sounds like you're setting it up correctly.
When you had the AD servers integrated were their authentication events mapped by CDA?
Has this been resolved? I have just installed CDA with patches 1, 2, and 3 and have the same issue. I see the username and IP in the syslog parsed by CDA, but don't see it mapped in CDA. The client IP is in FRAMED-IP of the syslog.
I am waiting on TAC to let me know if I should install patch 3 to resolve my issue. So far I am running ACS 5.5 with syslogs to CDA and there is no IP-Mappings happening.
I had the same (or close to the same issue) that CDA was telling me that it couldn't create the mapping because it was in the future. After some hunting it turns out that this issue (CSCun74460) was resolved for ISE in version 1.2 patch 2. I hope that Cisco released a similar update for ACS. It turns out that ISE had an incorrect DST time zone offset.
I also have same problem. In CDA, i recieve syslog from ISE, but log is not include client ip address. Is it same? In log, i receive client name, device ip address (wlc) and other information.
I'm running in to a similar issue. I've verified that both authentication passed and radius accounting packets are being received by CDA from ISE, however, nothing ever gets placed in the mappings table. Something to note: when I put logging in to debug mode it shows that the authentication passed messages are parsed, however, the accounting messages are marked as "Incomplete message received, dropped". Has anyone had any luck getting CDA to parse and map the info correctly from ISE?
I also have the same issue and during tshooting I was pointed to Bug CSCun74460
It means that mapping could not work due to Timezone issue on ISE side. Looks like ISE sends Radius accounting with incorrect timestamp.
Workaround is switch to non-DayLight Savings Timezone
Interesting... I tried changing the timezone and it corrected the daylight savings issue in that both the CDA and ISE Syslog timestamp offset now much... but it's still not creating the mapping. Did the fix work for you?
Hi, I also changed timezone and looked through support bundle logs and everything looks ok but mapping still doesn't work.
Does someone have any luck with mapping?
CDA checks for the Radius passed authentication and accounting logs to create a mapping.
1). Make sure the WLC/Switch is sending the accounting logs:
- radius-server vsa send accounting
- radius-server vsa send authentication
- aaa accounting dot1x default start-stop group radius
- aaa accounting network default start-stop group radius
2). Make sure CDA is added as a syslog and ISE is configured to send passed authentication logs to CDA (as a syslog server).
Do rate if Helpful
A couple of months ago we upgraded to the latest ACS version which directly has a fix for CDA. After the upgrade we were able to see the logs coming and processed correctly on the CDA IP Mappings.
Main issue was that ACS was sending an incorrect time at the syslog message.