RSA Auth Mgr 8.1 Privileged help desk role

[LaneFrazier]

Yesterday I had to assist several users who where in Emergency Access mode.

In our environment we do not allow the end user to place themselves there from self-service

All our service desk folks have Auth Mgr Privileged Help Desk Admin role, which gives them the ability to provide both online and offline emergency access help

 Emergency Access mode should be an extremely rare circumstance. I am trying to figure out who set the user up that way. As System Admin I can only think of one time where I've had to enable someone for it in last 3 years.

Here's the question....I have asked the service if they had set anyone in that mode. They claim no.

So how can I find out who may have enabled several users that way using the system reporting tools. These users could have been set that way for some time and I really don't have a time frame to search with.

[EdwardDavis]

You can teach yourself how to mine the logs and make reports for anything...

As an admin yourself, start the real time activity monitor for administration activity, then do 'some action you are interested in' and see what message you get. Then go to the real time monitor and click the message, and it will open up and reveal activity key.

You can run a admin activity report and filter on activity key.

Then you can run a report and see all occurrences that activity occurred and the admin name who did it.

Example: I created a user and watched the log 

I click the date/time hyperlink and get more details, I see Create Principal is the action:

I can now run a report and look for Create Principal and see everyone else who might have done this same action:

Report result:

[JayGuillette]

Run an Admin Activity report.

You might want to try to narrow down the date, or maybe the Activity Key.

[LaneFrazier]

Thanks for your reply

just saw something rather interesting in admin log

A regular user enabled their emergency access via self service

That option is turned off in my setup self  service settings manage authenticators

allow user to place token in emergency access mode box is not checked !

what am I missing here

[EdwardDavis]

What specific version are you running ? 8.x.x.x.x ?

There are two places that may need to be looked at (above)

the first one is manage authenticators, when a user is logged in...what they can do....

the second one is on initial access to the Self Service Console here, before they log into Self Service....

I can navigate down the troubleshoot links and answer my security questions, then I have more options

And if I report my token lost, I can get emergency codes this way:

So, check the settings here which is another way to set a token to lost, and separate from the Manage Authenticators section:

I am using 8.4 patch 10,

and when I go to manage authenticators, and disable emergency codes, but allow it on troubleshoot your token page,

I cannot generate them by going to the SSC troubleshooting link as a user, the option is suppressed.

[LaneFrazier]

I'm running 8.1 SP1 P3

[EdwardDavis]

Oh yes you are on a very old version (no longer supported) and there have been many adjustments/fixes/enhancements made to Self Service features.

I do not have a complete bug list but....this works correctly in the current version.

I suggest upgrade at earliest opportunity to get on the most current version with all fixes.

[LaneFrazier]

OK -

Self Service Settings : Customization

in set display options for Troubleshooting

Display Token is permanently lost or damaged option is checked

I may have to disable that....users really don't understand that when they get a new phone  their token is not lost

they just have to re-import their token

lot of that going on due to folks replacing iphones

the majority of our users use soft tokens on iphones

[LaneFrazier]

I'm aware of being on an old level of code.  Upgrading in the midst of a mild heath crisis is not an option

I may turn that one option off so that end users don't keep doing this.  I usually end up getting involved as a admin when users have issues any way

[EdwardDavis]

I am not the CDC, but this thing may drag on 18 months. I suggest spinning up a lab primary (if you do not already have dev versions running) and make it the same version as your current one, then do a backup/restore to get all your users on the lab machine (this will not interfere with production, the systems won't know about or talk to each other) then practice upgrading to understand how long it takes per patch or update, and any wrinkles or tweaks or problems that may appear. This way you are in a better position to upgrade production if/when any defect or bug or missing feature starts to make your day more difficult, it will be easier to tackle an upgrade if you've done it in the lab. You can even do this lab work, then re-name/re-ip and place the upgraded machines in production in moments (depending on your IT infrastructure and location restrictions), and rename/re-ip the old ones (keep these running so you can get all the reports and logs downloaded, or kept for forensics).

My point is, AM licensing, and having replicas, makes it pretty flexible to upgrade fairly seamlessly if you can set up another primary and replicas, 'backup/restore/make current' and the flip them onto the production network.