SecurID ACE Server

Most Recent Version: 6.0 (as of: 1/17/2005)

Questions:

1) How to set up SecurID Authentication with FW1 NG & LDAP (AD) backend?
2) How do I backup & restore my configuration?
3) "PASSCODE incorrect" error
4) How to migrate from 5.1 to 5.2?
5) I upgraded to 5.2 and now remote administration does not work?
6) Unable to get Security Block Key (1)
7) How do I enable and configure RADIUS capabilities?
8) "node verification failed" error
9) Once I have ACE server installed, how do I test authentication to make sure it is working?
10) How do I change the IP of my ACE server?

 

Answers:

1) How to set up SecurID Authentication with FW1 NG & LDAP (AD) backend?

Requires:

  1. Install ACE Server software on a app server.  Let's assume W2K, but this could also be several variants of UNIX.  By default, ACE will install on %SystemDrive%\ace.  Reboot the server.
  2. Sync clocks.  The agent and the ACE server should agree on the time to within about a minute.  Don't forget to check day, month, year, AM vs PM, etc.
  3. Perform basic configuration.  Start\Programs\RSA ACE Server\Config Tools\Configuration Management
    1. verify IPs and hosts
    2. check the box "Resolve Hosts..." or else you will get an error like "cannot determine if this server is primary or replica (19)"
  4. If any changes are made in previous step, stop and start RSA services.  This can be done in the Control Panel\RSA/ACE Server.  This actually stops and starts several RSA services.
  5. Next, we want to add tokens to out database.  Start\Programs\RSA ACE Server\Database Administration - Host Mode
  6. In the menu, go to Token\Import Tokens.  Follow the prompts.  You will be asked to provide a token floppy disk.  This disk should have come with your tokens.  Make sure you have a backup of this data.  Now the ACE server will be able to recognize your hardware tokens.
  7. Create users.  This can be done manually to create a local database, OR we can sync with an LDAP database like Active Directory (AD).  We will do the latter.
  8. User\LDAP Users\Add Synchronization

    notice that we are running the job every 24 hours.  This keeps the database up to date.  We also are using SSL to encrypt the LDAP communications, but more on that in a minute.
       Base DN is your company's domain name.  Usually, this is written as "c=us, o=company.com", but Microsoft does things a little differently by using "DC" for everything.  You MUST use MS syntax!  The Query Filter allows you to filter on objects within the LDAP structure.  "objectclass=*" just matches everything.  If your LDAP stucture is very large, the synchronization may fail.  In order to limit what gets synced, try "objectclass=User" for AD.  This grabs only the User container.
      Binding DN is the login information for the Schema Administrator.  Again, pay attention to the syntax:  cn=<userid>,cn=Users,dc=<company>,dc=<com>
      Additionally, you can go into "Options..." and set additional sync parameters, like checking for removed or disabled users.
  9. In order to make SSL work, you must do a couple of things:
    1. Enable SSL and use port 636 as described above for the sync job.
    2. make sure you have imported the AD server's certificate.  First of all, the domain MUST have Certificate Services running, preferably as an Enterprise CA.  Verify this piece is working correctly (I had a problem with permissions on the key folder Docs & Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys - see MS KB 295162)
    3. Assuming certs are working, import the <server>.cer file to the ACE server hard drive (often, you can get this file by going to https://<ADserver>, and selecting view\import).
    4. Once you have the .cer file, convert it to ACE openSSL format with the included certutil.exe utility.  Be CAREFUL!  certutil.exe is in c:\ace\utils\toolkit!  Win2000 ALSO has a certutil.exe which will NOT work, so make sure you execute from the correct directory:

      c:\ace\utils\toolkit\certutil -A -n <certname> -t P -i <.cer file> -d c:\ace\data\ldapjobs\sslcerts
      option description
      -A add to database (-D would delete) 
      -n <certname> assign an arbitrary name to the cert
      -t P type=peer
      -i <.cer file> path to the imported .cer file
      -d <path> path to dump created database files (cert7.db, key3.db, secmod.db)
    5. Start and stop the RSA server
  10. You should be able to run the sync job now.  User\LDAP Users\Run Sync...  This should kick off the job within 60 seconds.  Go back into User\LDAP Users\Edit Sync... and you should see status=RUNNING or OK.
  11. Now that you have LDAP users in your database, you can assign users to tokens.  Go to Token\Edit Token, and "Select from List" pick the relevant serial number (these numbers are pressed on the back of the hardware tokens).
  12. select the following options:
    1. Enabled = checked
    2. New PIN Mode = checked (should be greyed out for new tokens)
    3. run through the "Resync Token" procedure.  Follow prompts.
    4. "Assign Token" - pick a user
  13. Add imported users to a group.  Group\Add Group.
  14. Add the firewall as an Agent Host.  If you are dealing with a cluster, add each cluster member as a separate agent.  "Agent Host\Add Agent Host":
    1. name = DNS resolvable name of the IP the ACE server will see!  Very important!  The firewall has 2 or more NICs.  You only want to identify the IP address facing the ACE server, since any other IP will be unrecognized!  If this is not correct, you may get a PASSCODE error.
    2. DNS resolution - the firewall should be able to resolve the ACE server and visa versa.  You can use hosts table.
    3. -DES
    4. Assign/Change Encryption Key - set an encryption password
    5. Assign Acting Servers - define ACE server as master.
    6. Group Activation - active group from previous step
    7. Type = Communication Server
  15. Once the firewall is properly defined to the ACE server, generate the sdconf.rec file.  "Agent Host\Generate Configuration Files".  This will create sdconf.rec in c:\ace\data\config_files\...  Copy this file to your firewall (/var/ace for UNIX firewalls, winnt\system32 for windows).  The firewall must be stopped and started.
  16. Firewall config:
    1. create FW1 users.  This can be either userids with the same name as LDAP accounts, or if you have the LDAP license, create an External LDAP Group with the relevant SecurID users in the group (LDAP authentication can be found in the Check Point FAQ). Users or templates should be set to SecurID under Authentication tab.
    2. build a normal authentication rule with above users/groups.
    3. Make sure Firewall1 object has SecurID checked under Authentication tab.
    4. NO CLIENT AGENT needs to be installed on ANY platform!  You used to have to load the agent on Windows versions, but agent support is now built into FW1.
  17. If the NAS agent is a Cisco VPN 3000 Concentrator, agent configuration is different (obviously).  You must define the ACE server in two locations: under authentication servers, and under group management.  If you fail to define the ACE server twice, authentication tests on the concentrator will work fine, but VPN tunnels through the VPN will not work, and you will see nothing in the ACE log.  I do NOT believe importing the sdconf.rec file manually is required.

     

2) How do I backup & restore my configuration?

Make sure you back up the following files:

sdbkup online c:\ace\data\sdserv <outfile>
sdbkup online c:\ace\data\sdlog <outfile2>

To restore, stop the ACE server in the Control Panel, and use "sdrest" command:

sdrest c:\ace\data\sdserv <infile>
sdrest c:\ace\data\sdlog <infile2>

And finally restart the ACE server.

3) "PASSCODE incorrect" error

Well, I suppose you could have botched the passcode, but if you are looking this up, you probably have a real problem.  First of all, make sure you have synchronized your token (see above).  If that doesn't help, and you have a multi-homed authentication agent (like FW1), then your firewall most likely is not using the same IP address as you defined in the sdconf.rec file.  When you defined the agent on the ACE server, you put the agent IP in the config and shipped it to the firewall.  The firewall uses its IP address to compare to the sdconf.rec.  If it is not using the same address, you will get this error.
  One way to fix this is to try and guess the correct interface.  On the ACE server, try each address of the firewall in turn as the primary address, and make all other addresses secondary node addresses.  Then, generate and export the sdconf.rec.  The problem, of course, is this is VERY time consuming!!
  A simpler way to do this is to create a file on the agent in the /var/ace (or system32 directory on Windows) called sdopts.rec.  In the file, type:

CLIENT_IP=<IP address of the agent>

Stop and start FW1.  This will cause FW1 to use the designated IP address as the IP it compares to sdconf.rec.  And in answer to your second question, no, this could not be any lamer.

4) How to migrate from 5.1 to 5.2?

5) I upgraded to 5.2 and now remote administration does not work?

Like the instructions mention you must upgrade remote clients and from ace/data on server have sdrec.conf and server.cer on a floppy. If you still have a problem take the server.cer floppy and replace server.cer on the remote machine.

6) Unable to get Security Block Key (1)

Restoring your configuration from backup overwrote the the license.rec file.  Cut and paste license.rec from lic floppy to ace\data\ directory. 

7) How do I enable and configure RADIUS capabilities?

To enable RADIUS on the Primary Server, use the command "sdsetup -config".  Use "sdsetup - radius" on a Replica. The "-radius" option on the Primary will allow administrator to configure users & clients.

8) "node verification failed" error

This may have a number of causes, and may also be caused by something as simple as typing the incorrect userid (you should also see a "no user at agent" error in the logs).  If validating credentials doesn't work, try:

9) Once I have ACE server installed, how do I test authentication to make sure it is working?

You can obviously test authentication via whatever agent device you are using, but that often introduces lots of variables (is the agent communicating, is the network working, is DNS working, etc.), so a simpler alternative is to load the RSA client agent, available for free download from the RSA site.  Once the agent software is installed on your ACE server, you can go to Start > Programs > ACE agent > Test Authentication.

10) How do I change the IP of my ACE server?

Well, obviously, you have to change the IP of the box, but when you do, the NAS (authentication server) no longer trusts the server, since the incorrect IP is in the sdconf.rec.  So, we must update the server database, regenerate sdconf.rec, and distribute to the NAS devices.
   First, stop the ACE server.  If you do not, you will not have write access to the database.  Now, go into the Configuration Management utility, hit "Edit", and change the relevant IPs.  This would include the red circled IPs below:

Next, hit "Replica" button, and then "Details" for the Primary server.  You need to change the IP here as well.  Finally, reboot the server.  A stop and start of the service will probably suffice, but a reboot will "nuke from orbit"!
   Now go in to the "Database Administration" tool, go to "Agent Host > Generate Configuration Files > All Agent Hosts".  In \ace\data\config_files, there will be a subfolder with the new IP address in the name.  Distribute that sdconf.rec file as described in question 1.

 

DISCLAIMER: This support site is provided as a FREE service to our customers. Every effort is made to ensure it is complete and accurate. However, due to changing versions, typos, different environments, etc. information may be inaccurate for your site. Note that we do not assume responsibility for any problems you might encounter using information provided in these pages. Please inform us of any problems you encounter we will make every effort to correct this information. Thank you.

Home | Services | Training | Support | Contact Us | Search

Copyright 2006, Security Evolution, Inc.