Issue authenticating to rsa ace server radius from checkpoint firewall
User “testuser” attempted to authenticate using authenticator “SecurID_Native”. The user belongs to security domain “SecurID_Native”
I am not using any tokens yet only the local password and fixed passcode for the user in ace.
I also followed the implementation guide for my version of checkpoint. Any clues or help would be appreciated. Cheers
The authentication method failed message with RADIUS is typically a mismatch in the shared secret between the RADIUS client and the Authentication Manager server. Resetting it should resolve the issue.
Please take a look at 000028896 - Troubleshooting RSA Authentication Manager 8.1 native SecurID and RADIUS authentication issues for more information.
First, verify the user can login somewhere else with the fixed passcode, like the self-service console page.
Auth method failed usually means the digits or passcode received are the correct number of characters, but the system could not figure out the tokencode or pin from them, but shared secret is usually correct. If the shared secret was incorrect you would get passcode format error instead of auth method failed, and the passcode would actually decrypt into a huge string the system could not understand, [and would be 20 characters or more]...
To prove/deny the shared secret and isolate the issue, get on command line as root and run tcpdump and make a packet capture of the login attempt. Then load the pcap file into wireshark sniffer, and edit wireshark radius protocol section and put the shared secret there. Now when you look at the packet in wireshark the passcode/password field will be decrypted and you will see if that is your fixed passcode, something else, or garbage characters.
example: if using radius port 1812 (or change to 1645)
a) access command line as rsaadmin
b) become root with
sudo su -
and rsaadmin password again
c) tcpdump -i eth0 udp port 1812 -nn -s 0 -w /tmp/radcap.pcap
d) do your login attempt
e) stop tcpdump with ctrl-c
f) use winscp or filezilla or any sftp program, and log in and copy the pcap file out of /tmp
and load it up in wireshark
g) edit wireshark preferences and edit the protocols, radius section, and put in the shared secret it should be using
if correct, under the username will be the passcode or fixed passcode that got transmitted,
if incorrect it will be a long string of garbage
example: the correct shared secret in wireshark and in the setup, [my fixed passcode for user zaz is 4444]
if this was the wrong code but correct digits long
(the length matches the expected length of any of the fixed passcode or authenticators the user owns)
it would say auth method failed, and anyhow you would see clearly if somehow the code is
getting changed in the transmission somewhere.
example: incorrect shared secret, same user and fixed passcode
Bunch of garbage instead of 4444, and this would fire a passcode format error as it is definitely longer than any possible passcode.
sorry didn't have time to try to tcpdump yet. I actual created the user account on the management server with authentication method of radius and that allowed me to connect directly to the gateway with the account on rsa using a fixed passcode only once. After I login that first time it does not allow that account to login with the fixed passcode again until I completely reset that fixed passcode again. And when I uncheck the fixed passcode option on the user account it gives me an error in activity monitor that one of the authenticators are missing. We really just want to use the accounts actual set password only for now until we buy tokens.
A newly created fixed passcode is like an RSA SecurID token in New PIN Mode and needs to go through the new PIN process. Let's say an RSA admin named Alice defines a fixed passcode for a user named Bob as 87654321. Alice provides Bob the fixed passcode and he tries to authenticate with it to the firewall. He enters his user ID and for the passcode enters 87654321, which gets passed to the Authentication Manager server.
The Authentication Manager server does not know if Bob is using a token or a fixed passcode. It sees a flag in it's database that this authenticator is new and will pass a prompt back to Bob, asking him to create a PIN. What Bob should do here is create a new fixed passcode and, for example, enter 12345678. The interface should then request that he wait for the tokencode on his hardware or software token to change and enter the passcode again. Since he is working with a fixed passcode, all Bob needs to do is enter 12345678 again and he should get a successful authentication. For subsequent authentications, Bob enters 12345678 as his passcode.
ok ran a tcpdump and put the secret into wireshark and I do see the fixed passcode shown.
So after it works with the first try a second login attempt fails. See all screenshots
so Erica it seems like that is what is happening but how can I set the passcode if im not prompted on the remote device? Can I use the ssc or the oc to set this passcode after first initial use.
ok I tried the security console with my test user and got prompted to create a new passcode. Thanks to your response Erica. Appreciate all of your help here all of you.
that is because the fixed passcode is asking to be changed on it's first use, using the
new pin prompting process...
all new fixed passcodes allow the user to change it on first use, so only the user knows
what it is, even the admin won't know it (unless you are the admin too)
-give a user a new fixed passcode (again) uncheck and recheck it...and set it
-next, go log into the self service console as that user and use the fixed passcode
-the self service will ask you to change the fixed passcode, so please change it to a new fixed passcode
-Now, after going though that 'first use of a new fixed passcode change procedure',
the fixed passcode is permanent (more or less) and doesn't need a change any more (unless policy requires it)
and now try using the new permanent fixed passcode on your radius agent. it should consistently work