Create a Post
cancel
Showing results for 
Search instead for 
Did you mean: 
David_Won
Contributor
Jump to solution

How do i migrate a large number of users from Radius to SecureID on R77.30

Currently have approx 1000 users using Entrust cards for 2nd factor auth. Want to migrate to RSA.

Is there any way to do this without clicking on each user and changing their auth? We are not authenticated with AD and we are not migrating every dept at once. Probably 100 a day or so once ramped up.

I know you can do a user export and then import but the time to edit the file for each days users would probably take as much time as just editing the users.

Any ideas?

1 Solution

Accepted Solutions
Daniel_Taney
Advisor

You can use the dbedit tool via SSH on the Management Server to make bulk changes in the manner you're suggesting. Make sure to backup your management database first!

I would try something like:

modify users <username> auth_method <auth_type>

So if you are switching to SecureID, I'd do:

modify users john_doe auth_method SecurID

If you have the user names in a spreadsheet, you could auto-assemble the commands for the users being modified each day and then drop them into the dbedit tool.

Hope this helps!

-Dan

R80 CCSA / CCSE

View solution in original post

8 Replies
Daniel_Taney
Advisor

You can use the dbedit tool via SSH on the Management Server to make bulk changes in the manner you're suggesting. Make sure to backup your management database first!

I would try something like:

modify users <username> auth_method <auth_type>

So if you are switching to SecureID, I'd do:

modify users john_doe auth_method SecurID

If you have the user names in a spreadsheet, you could auto-assemble the commands for the users being modified each day and then drop them into the dbedit tool.

Hope this helps!

-Dan

R80 CCSA / CCSE
David_Won
Contributor

UPDATE

This method of editing users did not work. The list would fail when importing about

[Expert@hcmmgt01:0]# fwm dbimport -f ./migratedusers.txt
error in line 1: Invalid attribute name "foreground"
Could not read attribute files
Database import failed, reverting to old database

Used the dbedit method which worked great.

What's the best way to backup the database for this purpose? Snapshot, Backup from Gaia webpage, export or Database Revision Tool from SmartDashboard?

I was also thinking of the following but I still need to know the best database backup first.

Do an export with fwm dbexport

Then make a list of users to migrate to SecureID

Small script to run through the list and do the following.

Grep the users out of the exported file into a temp file.

Then change the users in the temp file to be SecureID with

sed -i -e 's/HMA_Entrust_GridCard_Radius/SecurID/g'

Once done fwm dbimport the user list with the changed users only.

Still need the best method to backup user database though.

0 Kudos
Daniel_Taney
Advisor

The database revision tool should do the trick. A full backup from GAIA would also work. Although, I think the revision would be the easiest to revert back to if you needed to undo your changes. 

R80 CCSA / CCSE
0 Kudos
Daniel_Taney
Advisor

Forgot to mention... if its R77.30, you will need to have all your GUI clients disconnected so the tool can take full write control of your database. 

Also, once you're done running all your "modify users" commands, use the command quit -update_all to exit the tool and save changes to the database. Once the changes are in, you should just have to push policy for it all to take effect. 

R80 CCSA / CCSE
0 Kudos
David_Won
Contributor

Oh oh. A problem has came up. After a successful migration using the dbedit method above it is now time to delete our old Radius servers. Problem is that I can't. Even though all of the users are now on the new SecurID RSA server when I try to delete the old Entrust Radius servers there is still some sort of hook.

test_josh is set to use SecureID though

If I edit the user and change his auth then back again it updates and I can delete the entrust server.

I don't want to edit 1500 users manually though. Restored things into a VM and testing there.

Any ideas?

0 Kudos
David_Won
Contributor

Step closer. I found that there is another place where the radius server is left. Look here in the dbedit of this user. How to I remove or change the value of this one so I can remove the old radius server.

Look at field auth_method which was what I was recommended to change for the migration. It is set to securid as told.

Now look at the other field radius_server. It still has the name of our old server I can't delete.

Help please.

0 Kudos
David_Won
Contributor

I think I found it but would like somebody to verify this is correct or at least pat me on the back for heading in the right direction.

I see the default value for this field is Any in the globals table so I tried this.

modify users test_josh radius_server globals:Any

Seems to have worked and I can now delete the radius server. Anybody see any issues with this before I get out of my lab and perform it on thousands of users on the production box?

0 Kudos
David_Won
Contributor

This final piece allowed me to remove the old radius servers. Ran

modify users test_josh radius_server globals:Any

on all users who still had that hook to the old radius. Pushed policy and everything is working. Thanks to everybody for the help.

Leaderboard

Epsum factorial non deposit quid pro quo hic escorol.

Upcoming Events

    CheckMates Events