How do you enable an external identity source (AD) user that is disabled in RSA AM.
Turns out in the AD there were permission on a group that were not inherited.... All good now
To enable/disable an Active Directory domain user account, please follow the below steps :
1. open the Active Directory Users and Computers MMC snap-in,
2. right click the user object and select “Properties” from the context menu.
3. Click the Account tab.
4. To enable the account, uncheck the "Account is disabled" check box.
Hope the above steps answer your question
Weird thing is the AD admin did that... but the the account wasn't disabled, but did create a new password and in RSA the account is still disabled.
Please open the Operations console and go to
Maintenance > Flush Cache > Flush all objects,
If the above steps didn't resolve the issue , please Check the article below 000031420 - Users show as disabled after enabling them from dashboard or by editing them in RSA Authentication Manager 8.x
Please open a Securid case if the above workaround didn't work, as we might need to check further the logs to resolve the issue
I will pass this on to my ad team
OK, AD Admin says the AD user account isn't disabled and account seems fine, and I flushed the cache anyway and in RSA AM the user account is still disabled.
So should I ask the AD Admin to disable the account and then enable in AD?
a) make sure the account is not used somewhere other than 'ordinary user' on AM system
(such as a robotic login or 'keepalive' that keeps failing and the account disables in moments)
b) create two test users in AD, and make one disabled in AD
c) register both accounts (in security console just find user, edit,make a note and save it on edit user screen, thiswill register the user)
d) are the flags correct for these new accounts ?
---if everything is correct but this one account: you may need to flush it out of the AM system and bring it back
(not ideal long term but good for troubleshooting odd issues with one account)
this will unassign any tokens, so be aware token needs to be reassigned
How to flush one specific user to eliminate possible stuck database issues on that account
e) make the operations console, identity source, user search filter exclude this user account
modify to ! samaccountname
f) save that then run an identity source cleanup job in security console, this account should show upas a cleanup item (orphaned account)...go ahead and clean it out
g) undo the filter in operations console, save that, user should now appear as a new user
in security console with nothing assigned, is the status good ?
h) register the user or assign a token, is the status still good ?
--NOTE: all this depends on the whole system not having problems with ldap, and your domain controllers also being in sync. So, check each replica operations console, identity sources, and TEST connection to all LDAP/AD to be sure everything is communicating, and replication is also showing NORMAL. Primary can test it's connections but only a replica can check it's own connections. Testing from the primary only tests the primary ability to reach the ldap urls the replicas might have.
Also, go check each replica security console, and list users, and check for consistency in the disabled flag.
I don't have the admin rights for the AD, and as for everything else you
have listed for troubleshooting I have tried on the RSA AM and still the
accounts are disabled.
I now have an RSA tech and case, we will be troubleshooting it today.
IBM Security, MSSD Canada
one more tip. Find another system and use ldapsearch or other tool that can view AD accounts (sysinternals ad explorer perhaps), and probe the account from every domain controller, and verify what the account disabled state is, independent of Authentication Manager. This will nail down domain sync issues, or internal problem in Authentication Manager.
Thanks Edward.... I don't have another system, I'm just the RSA person
here.... and RSA tech will be troubleshooting this soon.
Plus, this is a purely AD issue for I have two RSA environments and it is
only happening in one and to a specific AD group.
So... after some testing with AD Admin and RSA Tech... we found that it is in fact something in the AD... the weird thing is this
1. When a user is move out of the Group or OU to Users the disabled check mark/Flag goes away
2. When the user is put back in to the original Group or OU the disable check mark/flag comes back.
My question is do i have to put in an objectclass for OU's in the Identity Sourse LDAP query map?
start with: simplify connection as a test
1) set top level domain as the base (dc=domain,dc=com) for users and groups
(you may see a lot more in the security console if not already top level, but this is usually irrelevant for a test
unless you have many thousands of objects...then the security console may take some minutes to catch up)
2) make sure to use the full domain admin account and password to bind, this will sort out any permissions issues,
if it works with the top admin, then the service account you may be using might not have the correct permission scope
buffy is not my top level admin, it is a service account, so I would change that.
If you are already using this, then of course this advice is moot.
Retrieving data ...