050-V66-SERCMS02 · Question #16
An RSA Authentication Manager deployment must have at least one Authentication Agent record in the database in order to
The correct answer is B. Perform user authentications with an RSA SecurID token. See the full explanation below for the reasoning.
Question
An RSA Authentication Manager deployment must have at least one Authentication Agent record in the database in order to
Options
- AAdd time-restricted user accounts to the database.
- BPerform user authentications with an RSA SecurID token.
- CConfigure a Authentication Sources through the Self-Service Console.
- DEstablish logon policies related to Authentication Agent time restrictions.
How the community answered
(31 responses)- A3% (1)
- B77% (24)
- C13% (4)
- D6% (2)
Community Discussion
4The correct answer is B. An Authentication Agent record has to exist in the RSA Authentication Manager database because the agent is the actual gatekeeper between the user and the protected resource. When a user submits their SecurID token code, the agent intercepts that request and forwards it to Authentication Manager for validation, so without at least one agent record registered, that communication channel does not exist and no token-based authentication can take place. The other options are administrative or policy functions that live in the Security Console or Self-Service Console and do not depend on an agent record being present to operate.
Solid reasoning, Imani, but worth adding that the agent record also carries the node secret used to encrypt communication between the agent and Authentication Manager, so it is not just about registration, it is about that shared secret being in place before any token validation traffic can be trusted.
Makes sense that the agent record has to exist before the manager can actually process a token authentication request, because the agent record is what tells Authentication Manager which hosts are trusted to submit those access requests in the first place. Are you clear on why options A and D seem plausible but ultimately describe administrative configurations that the Security Console handles independently, without requiring an agent record to already be present in the database?
Quick win on this one, do not overthink it. The Authentication Agent record is what ties a protected resource (a VPN concentrator, a web server, whatever device is fronting your users) to the Authentication Manager, so when a user submits a passcode the Manager knows which agent is vouching for that request. Without at least one agent record in the database, the Manager has nothing to authenticate against, so the whole passcode verification flow never gets off the ground. Options A, C, and D are all administrative or policy tasks that live at the server or console level and do not require an agent record to exist first. Here is my question for the group: when you set up your first Authentication Agent record, are you thinking of it as representing the end user, the RSA server itself, or the device that sits between the user and the protected resource? Your answer to that will tell you exactly why B is correct and the others are not.