It is based on token serial number, and userid.
a) The authentication activity report will show the last time offline days were requested: it is no guarantee offline days still exist on the end user system, but it is the best way to check for the last time they were pulled. You then need to know what the policy is for the user to know when they are expected to run out.
b) In the database, using psql, the am_token table will also show the last time offline days were sent and what the last day is in the codes that were downloaded:
select serial_number,last_da_code_time from am_token where last_da_code_time is not null;
I just pulled offline days for that token in (a) above, on April 5th, the database shows my offline days will
end on April 20th. This may be the best way to see the final day for any token serial number.
db=# select serial_number,last_da_code_time from am_token where last_da_code_time is not null;
serial_number | last_da_code_time
---------------+---------------------
000132251679 | 2016-09-16 00:00:00
000159871817 | 2019-04-20 00:00:00
000020735713 | 2017-09-22 00:00:00
000116033741 | 2018-09-29 00:00:00
000132251665 | 2016-10-26 00:00:00
000132251667 | 2016-03-16 00:00:00
000132251677 | 2016-03-17 00:00:00
(7 rows)
c) a more complete query to put loginuid to the token serial might be like this
SELECT
am_token.serial_number,
am_token.last_da_code_time,
ims_principal_data.loginuid
FROM
rsa_rep.am_token,
rsa_rep.ims_principal_data
WHERE
am_token.principal_id = ims_principal_data.id
ORDER BY last_da_code_time ASC;
serial_number | last_da_code_time | loginuid
---------------+---------------------+---------------
000132251667 | 2016-03-16 00:00:00 | aaaat
000132251677 | 2016-03-17 00:00:00 | 23003
000132251679 | 2016-09-16 00:00:00 | 23005
000116033741 | 2018-09-29 00:00:00 | davise3
000159871817 | 2019-04-20 00:00:00 | davise3
000132251911 | | 23236
While Ed's SQL query certainly will assist you in finding out who does not have enough offline days, the concept of offline days is that they should be there, you should not have to run a report to check on them. To be clear, there have been several issues with offline days over the last three years, issues with invalid proof, issues with time offset differences between the agent (especially when it's offline and cannot get time from its own Domain Controllers) and the AM servers, issues with false flag that offline days are not needed, and even a Microsoft encryption change that caused a 30+ second delay in offline authentication. But for the last year Windows agent ver. 7.3.3[126] and now Windows agent in Ver. 7.4.2[122] are rock solid, you want to be updating your agents that are older than this.
So in line with making Ed's report less necessary, you could train your users to check for themselves and to try a few things to kind of technically "slap offline days upside the head" if they do not see a full complement of offline days after a successful logon.
1. Have them View offline days in RSA Control Center on Windows
You should see if your Policy allows them, and if you have a full complement as set by their Offline Day Policy
Offline days should top off after every successful authentication, and with the latest agent, that includes the UseCase where they authenticate offline at home, then connect to a VPN, even one not protected by SecurID, but the VPN connection, as long as it allows the PC to connect to an Authentication Manager Server over TCP port 5580, that PC should be able to update their offline days.
If the user does not see a full complement of offline days, they should try at least one of the following before they call the Help Desk;
1. Perform a Test Authentication with their UserID and Token from the RSA Control Center
2. Unlock their PC with a Passcode, not a Quick unlock with just Password or PIN
3 Try [Refresh] offline days from the RSA Control Center - I place this 3rd because the first two are typically the best and surest fix, but if your user tries this first and it fails, they should try the first two approaches before calling Help Desk, it could save them a call and a lot of time.
Your Help Desk people should try these steps if the user has not, or if they suspect the user did not do them correctly. Help Desk Admins can watch the Real Time Authentication Monitor while this is happening.
Help Desk can also check Policy settings if user not authorized for offline days
But Help Desk should not try assigning new tokens for this type of problem, they should stick to Resynchronizing a Token
or setting verbose logging on the Agent and analyzing those logs, with or without Help from Support depending on what you find or are familiar with
