Does acetest have a functional purpose beyond just testing?

[BENJAMINMORRIS]

Hi RSA,

We're in the process of automating some of our new deployments of RSA. Currently, we're looking at installing the Authentication Agent on RHEL (RSA Authentication Agent 7.1 for PAM Installation and Configuration Guide for RHEL ) as part of our Linux VM spinup steps.

Our Linux team has told me that the current barrier to full automation is running the acetest program, which performs a test authentication. Our Linux team has told me that running acetest causes the client to register with the console. However, it also requires a 2FA authentication, and getting the RSA passcode is basically impossible to automate.

So I have a few questions and proposed solutions I wanted to run by you guys:

1. Does acetest have a functional purpose other than just testing authentication? Does something special happen in that first connection? If so, are there alternative ways of registering the client with the console?

2. Does it matter what account is used as part of the acetest program? Could I test it using a very locked-down account that has a fixed RSA passcode on it?

[EdwardDavis]

1) it has no special function, it is an independent application...however, it can get the node secret file established, an sdstatus.12 file, and prove-out basic communication to primary and replicas...

If acetest works and PAM login won't, you can narrow down where the problem lies.

2) the account used does not matter, it is 'acetest vs the RSA server' and has nothing to do with any user account

on the system you are running acetest from.

Any userid will work as long as the RSA server allows it on it's configuration for that agent name and IP...

(either all users allowed to access that agent, or users in specific groups)

[BENJAMINMORRIS]

Ok, that all sounds good. Last couple of questions:

1. Is establishing the node secret as soon as the agent is deployed a best practice? (eg. security benefits) Would there be a problem in waiting for end users to authenticate to the agent "organically"? (I'd assume the only problem is trying to troubleshoot the problem in production vs. on a test run)

2. Perhaps a dumb question, but are there any ways to establish the node secret without using log-in credentials?

[EdwardDavis]

1) no need to do it ahead of time..the first user trying to log in can establish the node secret if the name and code is good.

it is just a pain to hand over a system to users and have it not work for some other reason. And also sometimes a node secret gets set up, but the permissions are wrong and the next user who tries fails because the node secret is not readable...so getting this ironed out before handing over to users can reduce admin pain.

First good auth is a 'freebie' and the node secret does not need to exist yet... this first auth gets the file set up after the user already gets logged in.

The next auth and all others... the node secret must work.

So if you do this and see systems that allow the first auth, but the second one and all others fail...check the RSA server logs if there are node secret problems.

2) you can establish node secrets ahead of time. On the RSA server, you manage the agent node secret and generate a new random node secret in a zip file and download it, and in that zip is nodesecret.rec.

Get nodesecret.rec on the target system, and use an RSA tool called agent_nsload to input that file and output the 'securid' file which is the actual ready-to-go node secret. Put this in the /var/ace directory or whatever the 'agent working directory is' where the sdconf.rec also lives.