000015170 - 6.1 - 7.1 Migration  user <username> activation on agent has been dropped due to absent user restriction times

Document created by RSA Customer Support Employee on Jun 14, 2016Last modified by RSA Customer Support Employee on Apr 21, 2017
Version 2Show Document
  • View in full screen mode

Article Content

Article Number000015170
IssueNeed to migrate 6.1 users to 7.1 database
errors during migration: some users with no time restrictions were not activated on open agents. associations were dropped.
errors during migration: user activation on agent has been dropped due to absent user restriction times
Cause

This is caused by an agent host setting in 6.1, but are technically not compatible in 7.1:

an agent with directly activated users, who have no access times selected, and the agent is open to all locally known users. This is the setting that 7.1 will not allow.

Resolution

Pre-migration: Go to the affected agent host entry in 6.1, uncheck open to all locally known users...or, deactivate the users on that agent, or give the users access times, or create one user

with access times, and activate them on that agent.

Post migration: Find your users in 7.1 and create the associations necessary to restrict them to agents via groups.

Notes

These are some possible 6.1 agent scenarios and the results in 7.1 (described more completely in auth_manager_migration_guide.pdf page 26-28 )

1)  6.1 agent host, open to all locally known, no user activations. An agent host is created in 7.1 as open and no errors.

2)  6.1 agent host, not open to all locally known, and has user activations, and none of those users in user activations have access times set.  A restricted agent host is created in 7.1, as well as groups,

and the users will belong to those groups and the agent will be restricted to those groups. No access times involved.

3)  6.1 agent host, open to all locally known, and has user activations, and none of those users in user activations have access times setThis will cause the error as described above, as this

setting technically isn't needed since there is no purpose to having the combination of 'open to all' and 'user activations' where 'no users have access times set up'. The users will be put into a group but the agent is not restricted to this group.

This is the 'association' that was dropped.

4) 6.1 agent host, open to all locally known, and has user activations, and those users in user activations have access times set. A restricted agent host is created in 7.1,

as well as groups with restricted access times. The 7.1 agent is restricted to that group, and those users are also members of that group.

5)  6.1 agent host, open to all locally known, and has user activations, and those users in user activations have access times set. But at least one user doesn't

have any access times, yet is still under user activations  (this one user would appear to be a problem as described in item (3), but 7.1 will handle this)

A restricted agent host is created in 7.1, as well as groups with restricted access times. And also, a group is also created for that one user

who technically shouldn't have been on the agent user activations. The 7.1 agent is restricted to those groups, and those users are also members of those groups.

 

In these cases above, if the agent host already exists in 7.1, and the migration will bring over settings which require a restricted agent, 7.1 will transform an open agent into a restricted agent and assign groups

accordingly. But not in the case of item 3.

 

 


Please refer to the auth_manager_migration_guide.pdf page 26-28 for more complete information about how 6.1 agents and activation settings are migrated to 7.1.
Legacy Article IDa44329

Attachments

    Outcomes