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:
2. The next work requires use of the operations-console:
https://rsaappliance.testad.local:7072/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:
cn=rsaauth,cn=Users,dc=testad,dc=local
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:
cn=rsaauth,ou=utilityusers,dc=testad,dc=local
(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:
https://rsaappliance.testad.local:7004/console-am
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 ->
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:
21 comments:
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.
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.
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.
already covered in a much earlier article... hence the "Basic" setup title.
http://rivald.blogspot.com/2009/09/cisco-asa-vpn-and-rsa-secureid.html
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.
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.2.2.2
4. sudo /sbin/service ntpd start
Optional:
5. sudo /sbin/hwclock --systohc
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.
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.
http://directory.apache.org/studio/
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?
thanks,
Alex.
I like reading your post, a nice source for appliance knowledge.
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?
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.
thanks for great recommendations
Appliance Repair Los Angeles
Thanks you so much for this post. can you please explain how to migrate it.
Los Angelese Appliance repair
Thank you for installation guide.
top10-bestvpn.com
Thanks a lot.Excellent installation guide and configuration manual for VPN.
It works good.Great post.
http://10webhostingservice.com/
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
thank you for sharing the home appliance inspection detail.
Heating and Cooling Mississauga
Heating and Cooling Cambridge
Post a Comment