Why do reports for all Users exclude certain Users?

[JonathonHanlon]

Hello everyone

I'm trying to run a report for our environment and get an export of every username (which automatically syncs with our Active Directory) in a way that shows the Tokencode. When I configure a report to do exactly that, I get just under 400 results despite having over 500 users.

Users which do show up on the report do not necessarily have unique identifying attributes. Some have been logged into, some have tokens, some are disabled, but not all of them. Some of them have none of these attributes. There are some Users who exhibit these same conditions but do not show on the report. The report has even left out some active and working user accounts with working Tokens assigned.

It's entirely possible I've setup my reports wrong, so I'd like to see:

What is the best way to run a report which will show every user in the console regardless of if they have a token assigned, have logged on before, wether they are active or disabled, etc. and have it show the assigned tokencode(s) when applicable?

Thanks!

[JamesMandelbaum · Accepted solution]

Hello,

First off, a user will not show up in the SecurID system until there has been a record created for them.  The creation of the record occurs when there is an action against that user.  A token creation, a fixed passcode or any other action that creates an authentication possibility for the identity

Until then, Authentication Manager does not know of the existence from LDAP.

[JayGuillette]

What Jim is speaking about used to be called 'registration', and basically means that some action puts an entry into the Internal PGSQL database that points to a location in LDAP (typically ObjectGUID) where that User lives, so that user is known to AM, not just listed in the external Identity Source because they exist in an ou that is in scope.

You can maybe glean some more understanding about this concept of user being 'registered' from this KB

https://community.rsa.com/docs/DOC-45944 

As an example, a College or university might create an Identity source scoped at the top of LDAP or AD, say dc=faber, dc=edu for Faber College.  Several thousand students, as well as staff, professors, and even Deans such as Dean Wormer would show, but Faber might choose to assign tokens only to a few people in IT, such as Douglas 'Stork' Kenney.  Only users who were assigned tokens, or fixed passcodes, or enabled for On Demand or Risk Based Authentication, would be registered.

[JonathonHanlon]

James, thanks for the reply!

This makes a lot of sense, and might be the exact ones I'm missing, I'd have to sift through all of this to find the discrepancies to be sure. My follow up question is about licensing. If I were to say assign a temporary fixed tokencode once, then remove it immediately, that should make that user appear in the initial report, correct? If so, would that consume a license, despite no longer having the ability to sign in?

[EdwardDavis]

If a user has no way to authenticate, it doesn't affect license. If you assign a fixed passcode, that will register the ldap user (create an internal GUID reference), and take 1 off the license. If you clear the fixed passcode, the license frees up by 1, but the user remains registered.