Resetting a users account within active roles just hangs

Hello,

We are having an issue when we log in to active roles console and attempt to reset a users password where upon clicking ok after setting the password it just hangs indefinitely. Other operations within AR still work fine but not password resets and I have tested that the svc account does have the permissions to perform the password reset and it can change it fine when launching ADUC as the svc account.

Can anyone provide any avenues to go down?

Thanks. 

Parents
  • Do you use Smart Cards in your environment?

    If so, this may be relevant:

    Title: Best Practices: Using Active Roles Server in Smart Card Authentication Environment
    Solution: 116902
    URL: https://support.oneidentity.com/kb/116902 

  • Thank you for your reply, on some accounts we do have SC required but not for any of the accounts we are trying to reset the pw for or the svc account for AR. Our AR environment and all actions we have needed to do in it has been working fine, this just started happening recently and there have not been any group policy changes or any updates that I can see would have caused this issue.

  • Is it possible that you have a change workflow that is firing a script that is in turn, going into some kind of loop?

    Likewise, do you have any attribute change driven policy scripts (associated with provisioning policies) that could be doing the same - i.e. triggeredby OnPreModify or OnPostModify events?

    What, if anything do you see in the AR windows event log - does the password change event get registered at all or is there perhaps some kind of error getting thrown?

  • Hey so the issue / solution described by Terrance isn't referencing smart cards on the accounts being reset, but rather someone may have logged into the ARS server as the ARS service account with their own personal smart card inserted, which would cause the issue you are describing.

    For kicks, take a look at the workaround in that KB. Log into the ARS server as the ARS service account (ensure no smart cards are inserted). Check the local certificate store for a cached certificate, and delete it.

    Detailed guidance can be found in the KB workaround: support.oneidentity.com/.../

  • In the ARAS log it shows the 2691 operation being submitted but it never logs the 2692 as I would expect to see for the operation being successfully performed. No change WF or any other scripts we have configured to be triggered by the PW reset operation.

  • I feel it is related to the ldap call and tls/ssl because from what I am gathering the only variable that has been changed since it has started working properly is the fact the the sql team has disabled all tls/ssl protocols other than TLS 1.2. Trying to prove this before going to them though.

  • Have you ruled out the service account having a cached smart card certificate? This is a common issue we see, and the symptoms are exactly as what you are describing. 

Reply Children
  • The service account has never had the smart card required option set on it or a SC associated with it. I went ahead and cleared the cache anyway, same result.

  • If there was something there to delete, then there was a cached certificate which would cause the issue.

    The issue occurs when another user logs in using the service account, with their own personal card inserted. The certificate is then cached and breaks the password setting functionality. It is not a result of the actual service account having a smart card required.

    Did you stop the service before deleting it, and then restart the service afterwards?

  • My apologies, I worded it wrong above. It should have stated that when I logged onto the server as the svc account, I verified there was no cert listed in its personal store.

  • Thank you for checking. What version of Active Roles are you on currently? Everything after 7.2 should fully support TLS 1.2.

  • So the quest admin failed to tell me he uses a separate account for database connection and after launching the cert store as that account there was in fact a certificate there not belonging to the svc account and of course when I removed it and restarted the service the operation then completed. If he would have told me it in the begining this thread would not have been needed, LOL.

    Thank you for all your assistance though!