Search the Community
Showing results for tags 'passwordstate'.
Found 3 results
maxmw posted a topic in Feature RequestsI've linked 2 password entries to the URL maxdev (a local dns that I use for development). When I use the browser extension context menu to fill in the password, I always get the password for entry that is highest up in the password list. I suspect that it takes the first match for the linked URL, instead of checking further down in the list for the correct match. To summarize: Both entries below (Portal NO and Portal SE) are linked to url http://maxdev. Whichever option I choose in the browser extension context menu, I always get the credentials connected to Portal NO.
I’ve used the new function ”Link Account to Multiple Web Site URLs”. I’ve linked 2 accounts to `localhost`. Now when I use the autofill button on the password fields, I get 2 options, but I don’t which is which. The names of the accounts are the following: (I've removed my personal email from the image) So printing out the title for accounts that are of type “Linked URLs” would solve my problem.
support posted a topic in Known IssuesIssue: 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 email@example.com and if we have any more current information about this, we will let you know. Regards, Support.