- Access exclusive content
- Connect with peers
- Share your expertise
- Find support resources
02-23-2018 01:36 AM
Hello together,
Is it possible to ignore a group of users with the User-ID Agent, and also on the firewall without the agent?
I tryed to add a group ( example\Ignore User-ID ) to the ignore_user_list.txt for the Agent. But it seemed not to work.
I also tryed:
example\Ignore User-ID
Ignore User-ID
"example\Ignore User-ID"
"Ignore User-ID"
'example\Ignore User-ID'
'Ignore User-ID'
Maybe it is only prossible for singe user accounts and not for groups? But I think this would be a really good feature.
It would be nice if anyone can give me a hint on this
Best Regards
Marco
02-23-2018 02:49 AM
You can't ignore a user group
The user-id agent records user ID's as they come in through events and then simply matches the user ID to the ignore list to see if it needs to be ignored, there is no group membership lookup
There is a feature request, however. So you can reach out to your local sales team and have them add your vote to FR ID: 1172
02-23-2018 02:03 AM
i cant see how this would be possible as user-ip mappings are per user not group.
I can't see why you would want to ignore a group of users... if its for a security policy then just use the group information in the policy and deny it...
02-23-2018 02:49 AM
You can't ignore a user group
The user-id agent records user ID's as they come in through events and then simply matches the user ID to the ignore list to see if it needs to be ignored, there is no group membership lookup
There is a feature request, however. So you can reach out to your local sales team and have them add your vote to FR ID: 1172
02-23-2018 04:25 AM
Thank you vermy much for your replay.
I want to ignore a group of users to prevent the "normal" accounts of the administrators to be overwritten by the administrative account of that user.
For example there is a rule for Internet traffic with User-ID. Traffic is allowed for all normal users. Not for administrative accounts.
I'm working on my computer with my normal account "marco". Then I connect to a Server via RDP using my administrative account "marco-admin". Sometimes User-ID then thinks my computer is assigned to "marco-admin" and i can not access the internet.
02-23-2018 04:29 AM
hi @Clermont
This is very unfortunate!
Do you have a lot of admins? You can use wildcards in usernames in the ignore list, but only as the last character
so if you could change your usernames, you would be able to ignore all admin-*
02-23-2018 04:40 AM
wow... how odd... i can understand the "server ip" to marco-admin but was not aware that the "clent device ip" could also be associated to the username used to logon to the server...
is this because of some network level authentication?
I'll need to watch out for that.....
cheers for the info.
02-23-2018 04:55 AM
ok just rdp'd with my test account and client ip mapping also changed to test account.
I can now see how this could be useful...
thanks again for the info/explanation.
02-23-2018 05:07 AM
Thanks for your fast reply.
Unfortunatelly our admins end with "*adm" 😕
I have about 30 accounts. I think I will add them manuelly.
Just to make sure: Do I have to add them with the domain prefix "domain\marco-admin" or is the username "marco-admin" enough?
Have a nice weekend
02-23-2018 05:12 AM
Is this a bug or a feature? We are just getting started with user-ID, and I can see this being an issue for us working in the IT dept. We use RDP a lot.
02-23-2018 05:27 AM
Maybe something of both, because the RDP-Logon on a Server is linked for your local machine in User-ID. So we decided to ignore the administrative accounts for User-ID. Which would be much easier with a group.
02-23-2018 05:37 AM
@TerjeLundbo, not sure if I would class this as a bug, more of a feature with some annoying aspects.
I have used user-id for some time now and have never had this issue, but only because my user logon also has server admin rights.
I have only become aware of this via this post, love this site....
if you use a different account for RDP then it will/could be an issue.
02-23-2018 05:41 AM
@Clermont I'd recommend adding the domain while you're at it (not sure if mandatory but have always done it that way)
@TerjeLundbo which part are you referring to exactly? 🙂 the rdp anamoly is kinda how microsoft handles authentications (it passes along your source IP with the auth so the user-id agent gets the log and sees your admin pc's ip even though you're logging in remotely)
The ignore user list is there to help prevent this issue, and also in case there are automated scripts running on a workstation that could trigger after a user has logged on and cause a new authentication log for the workstation's ip, with a service account
02-23-2018 05:56 AM
If we want to have user-ID based rules also for admin accounts, to grant access to management systems etc, that won't work of course if we filter out those accounts in user-ID agents.
02-23-2018 06:04 AM
that's correct, depending on the scenario:
when RDPing into a remote system, the ip mapping of the source will be affected, to which the admin is already logged in
If the admin then starts performing locat tasks "as administrator" there'll be a secondary authetication that affects the remoted system
You can also enable probes (netbios or WMI) which will periodically poll workstations for their actually 'logged in' user, so if the ip is hijacked by an admin or service account, the probe will correct that mapping also
02-23-2018 09:32 AM
Hello,
So I ran into a similar situation and found that using exchange logs instead of a domain controllers security logs refreshed faster since outlook is constantly authenticating to exchange. Not sure if that will work in you environment.
Regards,
Click Accept as Solution to acknowledge that the answer to your question has been provided.
The button appears next to the replies on topics you’ve started. The member who gave the solution and all future visitors to this topic will appreciate it!
These simple actions take just seconds of your time, but go a long way in showing appreciation for community members and the LIVEcommunity as a whole!
The LIVEcommunity thanks you for your participation!