Can not authenticate one windows 7 box.

[JayRoberts]

I have two windows boxes that have seemingly identical setups in my RSA security console and the operations console.  One machine will authenticate and one will not.  I have compared the two login events from both systems in the real time monitoring event logs and can see that failed event does not have Arguments 8 or 9 when compared with the successful login event (see attached image).  Is this an indicator of a specific problem?  If so what else can I learn from the "arguments" entries?  If not, what troubleshooting technique might I try to get to the root of the problem.  Any guidance would be greatly appreciated.  Thanks

Running RSA AM 8.1 from the appliance, RSA CC 8.4.1.93, &  RSA AA 7.2.1.93

[HusseinElBaz]

Hello J Roberts,

Kindly be advised that this could be a lot of issues causing that authentication failure.

1) We need to confirm that the RSA server is getting the correct IP from the agent and we can do that from packet captures.

2) We can check if there is any node secret created or not on both sides.

3) Check if there is no user issue in entering the correct passcode or not, which is unlikely in your situation as you already were able to login with the same user on the other machine.

It will be better if you can open a support ticket with RSA in order to check and troubleshoot the matter.

So kindly check and advise us back if there is any assistance needed from our side.

Best Regards,

[JayGuillette · Accepted solution]

Great analysis J, I like the classic approach, good trace vs. bad trace, all you need is a little SecurID speak.  The two authentication requests differ in their failure (from 192.168.112.150) and success (from 192.168.112.10) and argument 9, token SN and argument 8, probably the internal Identifier for the Token SN.

What's going on is that 192.168.112.150 still does not have a node secret while 192.168.112.10 has created its node secret after its initial successful authentication.  A Node secret is a symmetric key used to encrypt Traffic from an Authentication Agent host like a Windows Server/VPN or laptop, and the RSA SecurID AM server.

The first question is, if this is a new agent that has never successfully authenticated with anyone, even a know good user (2537) and token (000159123255), True, then there is a problem with the initial encryption, the encryption before the node secret is created.  This initial non-node secret encryption is based in part on an algorithm that uses the primary IP address of the agent.

So the quick fix is to enter the Agent IP address (which you used to create the Authentication Agent in the Security Console or possibly with auto-registration) into the IP address Override box on the windows Agent.  This example assumes your Authentication Agent has IP address 192.168.112.150.  Note: this is the Client Agent IP, not the Server IP.

It’s under advanced Tools in the RSA Control Center agent software.

Other agents could use a file called sdopts.rec, with a line

                CLIENT_IP=192.168.112.150

This has got to be the single hardest initial problem for any new Auth Manager Admin, because the failure message is so vague.  You are now RSA SecurID certified!

[JayRoberts]

Jay,

Right on!  The machine that was failing had a virtual interface that was created after loading VMware.  After overriding the IP address everything worked correctly!

Thanks for the help.

Tocayo

[JayGuillette]

and I learned something today too Tocayo.  Being unfamiliar with the word Tocayo, I looked it up.  While mis hermanos may use it in Spanish to signify that you and I are name-havers, I found its etymological roots might come from the Classical Nahuatl language.  Now I have a word that Juan Diego himself may have used up on Tepeyac Hill.  Thanks.