User “testuser” attempted to authenticate using authenticator “SecurID_Native”. The user belongs to security domain “SecurID_Native”
reason
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
I tried resetting the secret getting same result.
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.
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
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
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.
Regards,
Erica
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.
Also one other question once logging in the user can not run cphaprob or cpview sort of commands. Is there a right or login script issue if the user can run certain cmds?
Don't those commands run from the CheckPoint command prompt, which is kind of a CheckPoint Admin Access thing?
The Authentication Manager, AM Security Console is the web admin interface to manage AM users, tokens, agent, and logs.
The AM implementation Guides for CheckPoint typically involve configuring 2factor for VPN users coming through a CheckPoint, you could search from RSA Link for partner implementation checkpoint
and find links to implementation guides like the NGX R65 and other models
Check Point VPN-1 NGX R65 - RSA SecurID Access Standard Agent Implementation Guide
But protecting access to the CheckPoint Admin with RSA would probably involve a PAM agent to protect SSH to the Admin Shell, where you would run those cp* commands
yes they run on the cli which is where we want our admins to access using rsa ace server I did follow the configuration similar to what you attached for my version of firewall 77.30 and same issue. Is two factor authentication actually needed.
Brandon Mohammed,
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.
Regards,
Erica