Skip to Content

Track system logins historically by authentication mode?

Feb 01 at 10:33 PM


avatar image

Use case: Need to track system logins overtime for trend/sizing

Problem: Our logins are inflated by our support staff who log in as the user's enterprise alias

Workaround: No workaround to the problem as the only way for our support staff to impersonate a user is adding an enterprise alias for the account. Normal users that we want to count use WinAD as authentication method.

I reviewed audit db to see if it captures authentication method for login events 1014, but it doesn't appear this information is captured.

Any suggestions on how to capture the login counts of users who do did not log in using Enterprise?

10 |10000 characters needed characters left characters exceeded
* Please Login or Register to Answer, Follow or Comment.

3 Answers

Best Answer
Brian Kudera Feb 12 at 06:04 PM

For those of you who come across this and are interested in a better solution at tracking the authentication method used, please VOTE UP

10 |10000 characters needed characters left characters exceeded
Joe Peters Feb 02 at 12:30 PM

I don't believe the authentication method is captured in audit.

Couple of thoughts:

You can see this information in real time: in the Sessions view in CMC, the user name is prefixed with the authentication method.

Audit does capture the client's IP address, so if you have the support staffs' IP addresses you could identify their logons.

An enterprise ID can be different than the associated AD ID. So you could create an alias for user "SmithJ" as "SmithJ_ADMIN", then look for logons from "*_ADMIN" users.

Show 7 Share
10 |10000 characters needed characters left characters exceeded

Thanks Joe-

1. Since we are looking for reporting for analysis purposes, real time in CMC sessions is not going to work.

2. I thought about IP address, but unfortunately we run in a clustered environment with a Citrix NetScaler load balancer sitting in front. The only IP that is captured is the LB IP. (This is another question that I could possibly post, does anyone know how to persist the client IP all the way through LB... probably not going to get an answer since I'm asking a NetScaler question in BOE product forums)

3. I thought about this as well! However our Enterprise accounts are currently created automatically from update via 3rd party authentication (AD). We could potentially change this and not create a new enterprise account by switching "New Alias Options" to "Assign each new AD alias to an existing User Account with the same name" then manually creating the enterprise account with the "_ADMIN" name and manually associating the new AD account. Creates extra work at new user set-up time, but currently this seems like the best answer provided.

(unless you have thoughts/resources to point me to in regards to option #2)...


I can't help you on #2... Only possibility I can think of would be to capture the LB logs, and tie the logon request to a audit entry. But that would be messy, especially if it's high traffic.

I don't quite get how you're creating enterprise aliases. But, yes - if you change to "Assign each new AD alias to an existing User Account with the same name", then you would have to create the aliases manually, which would give you the opportunity to add _ADMIN. Not the best scenario, but I hope your folks don't have to do this impersonation all that often to begin with!


We do impersonate a fair enough amount, enough that it throws the stats of.

Our business developers are not the most savvy users, and we have row level security enabled based upon the person logged in. This doesn't generate a lot of impersonation, but...

Next, we recently created an UAT/AQA platform that we replicate a lot of reports over to using replication via federation. The UAT box is always on the next version of SAP BOE, SQL Server, Warehouse ETL, etc. We have AQA running on a regular basis and the current method is for the AQA program to use the enterprise alias and basically does a side by side compare of the reports from PRD to UAT. This generates a lot of false logins if we're only trying to capture actual user usage.


To circle back around on this, the enterprise alias cannot be renamed, so appending the alias with _ADMIN for support staff and AQA to use will not work :(


Hmm - I just did a test in my BI4.2 SP04 test environment; I renamed my own enterprise ID with a "_test" suffix. I was still able to log in to BI launchpad via SSO (which used my Win AD alias), and also manually with my _test ID.


Joe- I see, so you're changing the entire count name to "_test". Which then updates the enterprise alias.

If you did this, and then logged into BI Launchpad via SSO (with Win AD), you will notice in Audit DB that the user that logged in is the "_test" user and not the Win AD alias.

So this still won't allow me to capture an enterprise login vs an AD login.


Yep, you're right. I didn't take it that far in my testing. Sorry.

Tim Ziemba
Feb 05 at 04:53 PM

I don't have any auditing setup to verify but I would imagine something in the logs could be used to identify they type of user logged on. If you follow this KBA you can see the various attributes that differentiate different users in the CMS DB. I'd imagine something must appear in the audit logs or some sort of cross reference could be run to verify...


10 |10000 characters needed characters left characters exceeded