Monday, December 26, 2011

RSA SecurID 130 Appliance Basic Setup

I set up one of these years ago and wrote up a short article describing how to use one of these to authenticate against them from a Cisco ASA. I set another of these up recently and figured I'd cover the basic points to get it running.

Assuming your Active Directory domain is called testad.local and you've named the appliance "rsaappliance.testad.local" in DNS...

1. You'll need to do the base configuration and set up the initial license file. It's important that the following is configured correctly:

  • IP Address (it's probably necessary that you create a PTR record in DNS for the appliance. At the very least, you should have the IP address in DNS with a matching hostname (i.e., rsaappliance.testad.local)

  • NTP/time sources - you should use the same NTP servers that you're using for your Active Directory domain controllers. If you are running VMware ESX/ESXi and are running the domain controllers as VMs, you can use the ESX/ESXi host(s) as NTP time sources.

    2. The next work requires use of the operations-console:


     Under the admin console -> deployment configuration -> Identity sources -> add new ->

    (you'll probably be required to provide administrative credentials to get in)

    provide the:
  • Identity Source Name: descriptive name

  • Type (Microsoft Active Directory)

  • Directory URL
  • directory UL: ldap://dc1.testad.local  (or ldaps://dc1.testad.local, if available)
  • directory failover URL: ldap://dc2.testad.local
  • directory user id: you can create a user for this purpose. Assuming you created a user called "rsaauth" in the default users container in Active directory, you'll construct the entry like so:
       Of course, you might have OUs set up for these sorts of things. If you had an OU in your domain called "utilityusers," the entry would be:
       (for those of you unfamiliar with LDAP, cn should be the full name of the user.)
       2b. click on the "map" tab and set your User Base DN and User Group base DN. If you're not using any OUs, you'll default to the standard cn=users,dc=testad,dc=local... otherwise, put in the appropriate OU. You can fine tune the LDAP search filters and mappings below, but all you need to get started is the User Base DN and User Group DN.
      By the way, if you check "Directory is an Active Directory Global Catalog," you'll likely get an error in a later step:
      "Cannot link the runtime identity source because no administrative identity sources reference this runtime source"
      The easiest way to fix this is to uncheck "Directory is an Active Directory Global Catalog" - or do additional configuration.

    3. You'll want to enable the Radius Server, if you're going to authenticate against this appliance from, say, a Cisco ASA:

     Deployment Configuration -> RAIDUS -> Configure Server -> go ahead and create your RADIUS server... the defaults should be fine.

     4. You'll need to link the newly created Identity Source to a realm (newly created or the default SystemDomain realm.)

     Go to the security console:


     5. From there, go to Administration -> REALMS -> Manage Existing (you can create a new realm, if you have the appropriate licensing)
        select the "SystemDomain" realm (or the realm you created if you chose to create your own.)
        Under Link Identity Source, select the active directory Identity source you created in step one and click the arrow pointing to the right to put it in the linked field. Now, save your entry.
        If you get the dreaded "Cannot link the runtime identity source because no administrative identity sources reference this runtime source," this probably means you set the Active Directory Identity Source in step 1 to be a Global catalog.
     You should be ready to add tokens. To do so under the security console:

     Authentication ->  Manage existing -> New Import SecurID Tokens Job ->

  • name: just a descriptive name
  • Security domain: SystemDomain (unless you've created your own security domain)
  • Import file: (import the xml file from the CD RSA included with the tokens
  • File password: This password was likely on a scratchoff slip of paper in a separate folder

     Provided the tokens import correctly, you should be able to start assigning them to users.

    6. Finally, you'll probably need to add a Radius client if you you enabled the Radius server in step 3. From the Security console ( https://rsaappliance.testad.local:7004/console-am): RADIUS -> RADIUS clients -> add new:
  • Client Name: use a descriptive name
  • IP Address: the IP address of the client
  • Make / Model: Select the appropriate model (i.e., Cisco PIX for Cisco ASA)
  • Shared Secret: choose a long password
  • Go ahead and save without RSA agent.

    Anonymous said...

    Thanks very much for the procedure. It's better than the documentation provided by RSA.

    I have added my tokens and I've configured the RADIUS client. Now I just need to figure out how to configure the Cisco ASA (that already does IPSEC VPN client without 2-factor authentication), and I need to understand how to ensure that users logging in to the VPN are checked against AD to make sure they're in the appropriate "VPN Users" group.

    Do you happen to have written any procedures for these?

    Again, thanks for the help you didn't know you were providing me.

    Rivald said...

    You'd probably want to do that through the RSA manager... I'll have to look at it. I'm pretty sure there were some LDAP filters or attributes one could leverage to require membership in a certain group. In the past when not using two factor, I used LDAP for auth and looked for the remote dial in attribute (I don't remember the exact name.)

    I'm planning on adding several articles, including one on using LDAP attributes to automatically determine vpn-group membership. I'm currently using this at work to determine a user's access rights b certain LDAP attribute values.

    Anonymous said...

    For the RSA to authenticate against AD using Cisco ASA VPN, you need to create a group on the Cisco and add authentication servers as a SDI and point it to the RSA device.

    Rivald said...

    already covered in a much earlier article... hence the "Basic" setup title.

    David-NZ said...

    Hi - We just set up an RSA Auth Manager Appliance, but didn't set up NTP servers. Do we just need to edit the /etc/ntp.conf file, or is there some other important action to take?

    Cheers, David.

    Rivald said...

    I think the NTP configuration is in the initial setup. Unfortunately, I don't have the quick start guide, so I can't tell you the exact port number.

    However, I'm sure you're correct - modifying /etc/ntp.conf and restart the NTP service should suffice. You'll find that the sudo they use has a very short time out. So in order (I suspect you don't need this, but it's for reference):
    1. ssh in as emcsrv
    2. sudo vi /etc/ntp.conf
    3. sudo /sbin/service ntpd restart

    If your time is too far, you may need to run ntpdate...

    1. ssh in as emcsrv
    2. sudo /sbin/service ntpd stop
    3. sudo /usr/bin/ntpdate
    4. sudo /sbin/service ntpd start
    5. sudo /sbin/hwclock --systohc

    Gash said...

    I've got to step 5 however after I move to the linked window and click save I get error "The supplied GUID for the identity source is invalid". Any ideas? I've followed your guide exactly as it is.

    Rivald said...

    that sounds like a problem with the account you're attempting to bind with (in step 2): perhaps the DN string is wrong or the account doesn't have sufficient privileges - likely the former.

    I'd suggest using an LDAP client to bind with that account to one of your ADs, and see if it works.

    The apache directory studio works nicely.

    Alex said...

    Hi Rivald,
    Thank you very much for your post. It was very helpful while migrating from 6.1 to 7.1
    I wonder is you have seen this issue. I migrated from 6.1 to 7.1 test environment, but I want to convert this environment to production, but when I try to import the DB from 6.1 it shows this message "User fwang is already a member of group VPN Users in the read-only identity source BabyCenter."
    BabyCenter is the new Identity Source that uses Active Directory, which is Ready-Only. Why does this happen if the users' token are on the local database?

    littleton co appliances repair said...

    I like reading your post, a nice source for appliance knowledge.

    Hersi said...

    Thanks for the precedure.

    I get the following Error by generate a Replica Package: "Unable to resolve replica fully-qualified domain name to IP ".

    Nslookup resolve the FQDN to the correct IP and the A-Record and PTR are set correctly.

    Does anyone have an idea to solve the problem?

    Rivald said...

    Hmmm - I don't have access to a replica environment. Perhaps one of your two appliances aren't resolving DNS correctly? It might be worth checking /etc/resolv.conf and/or /etc/nsswitch.conf. I'm uncertain as I've never set up replication between RSA appliances.

    developerbrk said...

    thanks for great recommendations
    Appliance Repair Los Angeles

    EAppliance Repair said...
    This comment has been removed by the author.
    EAppliance Repair said...
    This comment has been removed by the author.
    EAppliance Repair said...
    This comment has been removed by the author.
    EAppliance Repair said...

    Thanks you so much for this post. can you please explain how to migrate it.
    Los Angelese Appliance repair

    Anonymous said...

    Thank you for installation guide.

    Richard B. McCall said...

    Thanks a lot.Excellent installation guide and configuration manual for VPN.
    It works good.Great post.

    Anonymous said...

    Against them from a Cisco ASA. I set another of these up recently and figured I'd cover the basic points to get it running.appliance repair

    john smith said...

    thank you for sharing the home appliance inspection detail.
    Heating and Cooling Mississauga
    Heating and Cooling Cambridge