Next tokencode Mode and New Pin Issue(Secureid)

[munit_si@yahoo.com]

Sometimes when I try to login to checkpoint(which is configured to authenticate from RSA-Radius), it falls to new token code . Is their anyway that when authenticating to checkpoint , that next token code message is dsplayed. Currently it doesn't promp me for the next token code. Searched on google and everywhere(all old posts) I can , but was not able to find appropriate solution .


Does checkpoint supports Next token code ?

any suggestions/comments

[zencoder]

Originally Posted by munit_si@yahoo.com

Sometimes when I try to login to checkpoint(which is configured to authenticate from RSA-Radius), it falls to new token code . Is their anyway that when authenticating to checkpoint , that next token code message is dsplayed. Currently it doesn't promp me for the next token code. Searched on google and everywhere(all old posts) I can , but was not able to find appropriate solution .


Does checkpoint supports Next token code ?

any suggestions/comments

Do you have to use RSA Radius? VPN-1 natively supports the RSA API. You'll have to look up specific doco on your versions (you didn't tell us what you use), but I use it in this exact manner all the time. As a radius client, you may lose a lot of that functionality with RSA.

SecureClient has a fairly ugly response screen, prior to R56, but it works.

Screen shot of my XP Pro virtual machine being prompted, after I put my token into Next Tokencode Mode. Note the mis-labeling of the information being asked for. Specifically, in the RSA doco, PASSCODE = PIN + Tokencode, where TOKENCODE = 6 digits on the screen (or whatever your device supports...maybe more or less than 6...but I doubt it.) In this instance, RSA is asking for the next TOKENCODE, not the next PASSCODE...but it is such a minor difference that its not worth it to make a fuss.

[munit_si@yahoo.com]

Originally Posted by zencoder

Do you have to use RSA Radius? VPN-1 natively supports the RSA API. You'll have to look up specific doco on your versions (you didn't tell us what you use), but I use it in this exact manner all the time. As a radius client, you may lose a lot of that functionality with RSA.

SecureClient has a fairly ugly response screen, prior to R56, but it works.

Screen shot of my XP Pro virtual machine being prompted, after I put my token into Next Tokencode Mode. Note the mis-labeling of the information being asked for. Specifically, in the RSA doco, PASSCODE = PIN + Tokencode, where TOKENCODE = 6 digits on the screen (or whatever your device supports...maybe more or less than 6...but I doubt it.) In this instance, RSA is asking for the next TOKENCODE, not the next PASSCODE...but it is such a minor difference that its not worth it to make a fuss.

Hi Zencoder,

Thanks a lot for the inf. In my test enviornment I am using RSA ACE server radius, not the one natively supported by VPN-1. I am having checkpoint R55.
I know secureId client prompts, but my problem is related to Admin logging to any CMA(launch SmartDashBoard, etc...) that time will the checkpoint promt for next tokencode mode if rsa falls for next token code mode for that user.

any suggestions/ideas on the same


You are rt , secureclient should prompt for tokencode rather then pass code, it could be GUI bug.

[zencoder]

Ok, but I think you are *still* having the same problem. SmartCenter/SmartConsole/Smart-whatever may not properly support the diffrent RSA control codes from a RADIUS authentication session.

Unless you have a compelling reason to NOT use the built in functionality, it doesn't make sense to use RADIUS for SecurID to authenticate users to an application that supports RSA natively.

[munit_si@yahoo.com]

Thanks, I was just looking on google to find solution for this issue

Got refrence for sdopts.rec file, will defining an interface IP from where the secure id packets will be sent , will solve the issue.


posted by phonenoy

<The ACE AGENT inside of VPN-1/FireWall1 embeds a hash of its IP Address in the authentication request packet before passing it to the ACE Server. The ACE Server will run a hash on the expected Source IP of the ACE AGENT and compare it to the received hash. The ACE Server uses the defined Primary Host Agent IP to derive this hash. If the two hashes do not match, the authentication request will be denied.

This method is problematic when an ACE AGENT is multihomed. The ACE AGENT may derive a hash from one of its other IP addresses. When this behavior occurs, it will be necessary to create a sdopts.rec file in the /var/ace directory. The sdopts.rec file will force the ACE AGENT to use a specific IP address to derive its hash.

To resolve the issue do the following:


create the sdopts.rec file in the /var/ace directory
Using VI, edit the sdopts.rec file and insert the line: CLIENT_IP=IP address of the ACE AGENT
restart FW-1 using cpstop;cpstart
Note it has been reported this will also correct issues using SecurID on Secure Platform.>


am i facing the same issue ?


any comments

[chillyjim]

This is only is you are using the native SecureID support. You should not use ACE RADIUS with Check Point. To activate the SDI support, copy the sdconf.rec to your /var/ace directory on the SmartCenter and VPN gateways and do a "cprestart"

[munit_si@yahoo.com]

Thanks a lot , we already have copied sdconf.rec on the var/cae dierctory. not sure why it falls to next token code mode. may be we need to switch to inbuit radius as you guys have specified


Munit

[rrudrapathi]

Basic things only...

Did you check the Time/Time Zone for Agent and Server ?
Both should be same.

[chillyjim]

Also in the /var/ace directory create a file sdopts.rec with the entry:

CLIENT_IP=<ip address closest to the RSA server>

That will fix several strange problems

[munit_si@yahoo.com]

Originally Posted by chillyjim

Also in the /var/ace directory create a file sdopts.rec with the entry:

CLIENT_IP=<ip address closest to the RSA server>

That will fix several strange problems

CLIENT_IP=<ip address closest to the RSA server> We have placed this entry and it seems this is resolving the issues. We are not facing the problem now , very rarely it occurs .Also , I am wondering it could be time sync issue, as we are not using NTP etc.

Would Like to thank everyone for their help and support