I'm trying to build some use cases that will make use of string normalisation. Specifically I want to have the Username for a privileged user and then have Aliases for all the other Usernames that this user has across a number of domains. I'm running into the following issues:
The various usernames appear in events in all possible upper/lower case combinations. Whilst I can specify that the primary username be treated in a case insensitive manner the aliases seem to be always treated in a case sensitive manner, i.e. enter the primary name in the View filter then select Aa and the string normalisation icons and refresh the Events returned include all variants for the primary name but only the exact matches for the alias names.
I can specify a watchlist in the Source Username filter field and select the string normalisation but string normalisation does not get applied to the aliased username.
Is this expected behaviour? Do I have to enter every possible way a username can appear in an Event in the aliases table? So abc,Abc,ABc,ABC,aBc,aBC,abC,...
The handling of case sensitivity with watchlists entries and string normalisation has now been fixed in both 9.2 and 9.3.
Message was edited by: acommons on 15/12/13 5:37:10 PM
You mentioned in the update that this has been fixed in 9.2 and 9.3, I thought I might also update this thread for the wider audience that in 9.3.2 we added the capability to filter data using regex, which is useful in this scenario.
Using the dashboard filters in the example above, you could enter into the source or destination user field
which would return all the variances mentioned above in a quick and simple way.
Don't forget, when your helpful posts earn a kudos or get accepted as a solution you can unlock perks and badges. Those aren't the only badges, either. How many can you collect? Click here to learn more.
Community Help Hub
New to the forums or need help finding your way around the forums? There's a whole hub of community resources to help you.