Overview
Users/Groups shown under Configuration > Objects > Users&Groups are showing the wrong User/IP mapping. Either a user is assigned with too many IPs when only one of them is being used, or the IP assigned to a User should be assigned to another user who is the one currently using it.Cause
There is a misunderstanding as to why there can be more than one IP attached to a single user:Exinda software integrates with AD by grabbing the information depicted on the Logon Events (4624 for Windows 2008/2012 and 528/540 for Windows 2003). This being said, the software was designed to not make any own decisions with regards to what IP belongs to what username, instead the Exinda only listens to what the Domain Controller has to say. If a user in IP (A) logs into the domain, that logon event should have produced a respective log, and that is what the exinda grabs from the domain controller. When the Exinda sees a new 4624 event from the Domain Controller (or 528 and 540 for Windows 2003) it inspects what username logged in with what IP, then the Exinda adds that IP to the respective username but it does not delete the previous records . Exinda will only delete a previous record if and when that old IP is used to login by another username, in which case ExindaÕs software removes the old IP from the old username and adds it to the new one.
One or some IPs should no longer belong to that user, Exinda shouldÕve removed it already and added it to another user that is currently using it/them
Once again, Exinda is designed to comply with the Logon Events coming from the domain controller. If it is believed that an IP/Username mapping is wrong, then the domain controller is most likely not logging the latest user that is using that IP, this is the reason why the Exinda has not decided yet to swap the IP from User A to User B. Sometimes, what happens is that User B used another domain controller to access the network and that domain controller is not installed or configured with an Exinda AD Connector. Exinda recommends installing AD Connector on ALL domain controllers.
In order to prove that the domain controller is the one not logging the incoming users/IP properly, please follow the procedure in the "Workaround" section.
Workaround
If it is believed that an IP/Username mapping is wrong, examine that the Active Directory is providing the correct logs:1. Take note of the IP in question
2. Go to the domain controller or domain controllers where the AD connector is installed and go to the Event Viewer by clicking on Start > Administrative Tools > Event Viewer.
3. The AD Audit logs are located under Windows Logs--->Security but they are too many to find the right one. Create a custom view for only the specific ones we want.
4. Right click on "Custom Views" and click on ÒCreate Custom ViewÓ:
5. A window will come up; click on the XML tab, and accept the "Edit" option (A warning about not being able to edit this script will show up, just agree with it).
6. Use the following script and change the IP after ÒDATAÓ to search the IP you wrote down on step ÔaÕ:
<QueryList>
<Query Id="0">
<Select Path="Security">
*[EventData[Data[@Name='IpAddress'] and ( Data='10.10.10.10' )]]
</Select>
</Query>
</QueryList>
This script is telling the event viewer: Filter every Security log that is related to the IP 10.10.10.10. After you accept you will just have to put a name and description on the Custom Query.
7. Expect to see some logs with the event id #4624 (or 528/540 for Windows Servers 2003). The latest log will show what was the last username that logged in with the respective IP (or at least what is the last username that logged into the AD for which the DC is reporting it). If this username is not what the Exinda is showing, please communicate this to Exinda TAC so they can have a look at it. If the last username/IP mapping complies with what the Exinda is reporting, then the DC is not auditing the events correctly which is why the Exinda cannot report as expected.
This could occur for many reasons, one of them could be that the username is logging to another Domain Controller for which the AD Connector has not been installed yet, in this case it is recommended to install the AD Connector on all the Domain Controllers.
Another possible reason is that some of the logging tasks are being taken care of by a third party product that unfortunately does not make the DC generate a respective security log or the security log generated does not contain the appropriate information. In this case, the Exinda AD connector cannot work as desired as this is a not supported scenario.