Jump to content

Search the Community

Showing results for tags 'password resets'.

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • Essentials
    • Announcements
  • Passwordstate 9.x
    • Community Support
    • General Hints and Tips
    • Known Issues
    • Installing Passwordstate
    • Feature Requests
    • Feature Requests - Completed
    • 3rd Party Hardware/Software Knowledge Forum
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • App Server
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 8.x
    • Community Support

Find results in...

Find results that contain...


Date Created

  • Start

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


Jabber


Google Plus Account


Skype


AIM


Yahoo


ICQ


Website URL


MSN


Interests


Location


Biography


Location


Interests


Occupation

Found 1 result

  1. Issue: We've had a few reports of customers who have not been able to sync AD Security Groups, or possibly not able to add users into the system from Active Directory. Symptoms: Some symptoms you may see is when adding in a AD Security Group, it will not enumerate the members. Or possibly you might be presented with a Error page in Passwordstate saying it cannot query Active Directory. Possible Cause: By default, Passwordstate only requires an account that has "Domain User" privileges in AD to be able to sync objects, however if you have hardened Active Directory to minimize the visibility of containers for certain users, you may need to elevate the permissions for your Privileged Account. How to Test: As a temporary test, add your Passwordstate Privileged Account to the "Domain Administrators" security group in Active Directory. If this resolves the issue, then this indicates it's a permission issue. How to Fix: Unfortunately every AD environment that has been hardened can be different, so it's difficult to say exactly where the issue lies. Normally when companies harden AD they may remove the ability for the "Authenticated Users" on certain containers to hide them, but some applications built with standard .NET code can have issues with this, including some of Microsoft's. We would suggest you check permissions for each container starting with Users and Computers, and confirm whether or not the Authenticated Users has read access, as per below screenshot: Next, you should check any other container that you have computers or user accounts stored in for the same permissions above, and this will include and nested containers, as the problem may be caused at any level. Finally check the top level domain and then depending on the results, you can do one of a few things: Restore the default AD permissions to allow Authenticated users to have read access to all containers where you have users or computers, and also ensure the permissions filter down to all nested objects - We realize this may not be possible. Give your Privileged Account Read access on all containers, and ensure permissions filter down to all nested objects Elevate the permissions of your Privileged Account to one of the built in AD Security Groups. Suggestions are: Account Operators, Administrators, Domain Administrators or Pre-Windows 2000 Compatible Access More Information: You may possibly run into the same sort of issues in Passwordstate, when attempting to let Passwordstate reset a password for an Account in AD. For most accounts in a domain, the privileged account Passwordstate uses should only need to be a member of “Account Operators” built in security group to be able to reset the passwords. However, this won’t allow the account to reset passwords for higher privileged accounts like Domain Administrators, or Enterprise Administrators. To reset passwords for accounts like these, the privileged account must also be a member of one of the Administrator Groups, either “Administrators” or “Domain Administrators”. This is by design from Microsoft, because if you can reset a domain Administrator password, then you effectively can use that account to perform domain admin tasks, so why not just make it a member of the Domain Admins in the first place? There are ways to set granular password reset permissions on account attributes, which will allow an account with less privileges to reset a domain admin password. We would not like to provide advice on this though as you can imagine it could be different for every domain. So summary, your privileged account should be a member of "Account Operators" group for all normal password resets, or “Administrators” to reset passwords for any Administrator type account. To mitigate against the risk of having these high privileges for your account, you can configure your privileged account to reset its own password on a regular basis in Passwordstate. Just link it to a password record from within the Privileged account screen, and set it to reset as often as you like. If you still find you cannot perform sync's/ resets, please contact Click Studios on support@clickstudios.com.au and if we have any more current information about this, we will let you know. Regards, Support.
×
×
  • Create New...