Jump to content

Search the Community

Showing results for tags 'ad'.

More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


  • Essentials
    • Announcements
  • Passwordstate 8.x
    • General Support
    • Feature Requests
    • Feature Requests - Completed
    • Known Issues
    • Installing Passwordstate
  • Knowledge Base
    • General FAQs
    • Password Resets
    • Remote Session Launcher
    • Mobile Client
    • Passwordstate API
    • Browser Extensions
    • Password Reset Portal
  • Passwordstate 7.x
    • General Support
    • Known Issues

Find results in...

Find results that contain...

Date Created

  • Start


Last Updated

  • Start


Filter by number of...


  • Start





Website URL





Google Plus Account







Found 6 results

  1. Hi, Is it possible to sync Active Directory with Passwordstate? If I create a Service Account with a specific name like svc_[SERVERNAME] or if the service account is in a specific group in AD, then automatically add a entry in passwordstate with the accountname, password and other information? Or do anyone know how to add entries via script (Powershell, TSQL) ? Regards Hakan
  2. 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.
  3. Hoya! Another day, another thread I'm in the process of setting up our privileged accounts for Windows and Linux management. Linux is easy in this case, as we'll limit the user through SUDO rules. Fine and dandy. It's Windows that's throwing me off (it's not really my field of expertise). I'm loathe of making a user account that's simply given access to the local "Administrators" group on each host. That feels damn dangerous to me. So I'm trying to hammer down things and make it work with the least possible privileges. Unfortunately I can't get it to work: I'm stuck at the last step. On the AD-level, the Windows privileged user was given delegated password management rights for AD users. That was also easy, so onwards to the local password management! The priv. user was added to AD-group "powershell-remote". I've set up a global policy that's enforced on the target Windows boxen, which adds the members of AD-group "powershell-remote" to these local groups: * Account Operators * Distributed COM Users * Remote Management Users * WinRMRemoteWMIUsers__ This ensures that the priv user can Invoke-Command and Enter-PSSession. But the remote hosts still balk at letting the user interact with things like win32_group through WMI or Get-CIM*. There's also the local WMI Control tool, which can be used to provide access to WMI components to specific users (see here). That's a bummer though, because that would require local changes on all boxen. Apparently you cannot set these permissions through a global policy, so you will need to resort to manual changes, or a script (see the EDIT below). Opening up the ROOT namespace for the privileged account appears to be sufficient for discovery. Will let you know about password changes Suggestions would be more than welcome! EDIT: At least there are scripts available that will help you set the WMI namespace access permissions through Powershell. See here. That's still not ideal though, but that's down to Windows' design. EDIT 2: One workaround that could be very useful, would be if PasswordState would support JEA: Just Enough Admin, a rather new extension for Powershell which allows you to delegate certain (local) tasks to another non-admin user. That would however require an adjusted set of scripts for discovery / validations / resetting. Thanks to my brother-in-law for suggesting JEA.
  4. simpletireman

    Active Directory Unvailable

    From what we've read, we believe the "emergency access" feature is to be used for instances where users are unable to login, such as when AD is not accessible. We were wondering if this is the method that other people are utilizing for such instances, or if anyone has found a different means of doing so. Our particular use case that we are trying to prepare for is AD being unavailable. Thanks in advance, Jason
  5. On a Windows server or desktop OS, it is possible to configure a Service, IIS Application Pool, Scheduled Task or COM+ Component to have its "Identity" run as an Active Directory Account. We call these Dependencies in Passwordstate. This post shows how to configure a Password Record to manage this dependency. Step 1: Ensure you have prerequisites set up for your web server and hosts, as per this forum post (Once off process) Step 2: Ensure you configure a password record as per this Form Post. This should contain the Active Directory account you intend to set up on your dependency Step 3: Add a dependency to your Password Record. Screen 1: Adding a dependency can be achieved from two places - Either from the Actions Menu or click the Dependencies link in the Password Grid: Screen 2: Click the Link to Password Reset Script button Screen 3: Select the options as appropriate: The correct Password Reset Script that should match your dependency type Enter the name of the dependency as it is shown on the remote host - ie the display name of the service on my server is called Passwordstate Service The dependency type Search for and assign the correct Host that the dependency is configured on
  6. p.dulski

    AD Sync error

    Hello, We've got problem. Our passwordstate build version is 7551 (the newest one). Some AD security groups with disabled AD user accounts doesn't want sync with Passwordstate. During sync in Application log we see below error: An error has occurred executing the call 'QuerySecurityGroupsMembership_AD'. Security Groups Details are: Security Group = Test, Domain = domain, FQDN = domain.local, and error message = The specified directory service attribute or value does not exist. &stacktrace= at System.DirectoryServices.AccountManagement.ADStoreCtx.LoadDirectoryEntryAttributes(DirectoryEntry de) at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.MoveNextMemberEnum() at System.DirectoryServices.AccountManagement.ADDNLinkedAttrSet.MoveNext() at System.DirectoryServices.AccountManagement.FindResultEnumerator`1.MoveNext() at PasswordstateService.PasswordstateService.QuerySecurityGroupsMembership_AD(Int32 intSecurityGroupID, String strSecurityGroup, String strDomainName, String ObjectSID, String FQDN, String PrivilegedAccountUserName, String PrivilegedAccountPassword) Additionally, when we cannot enumarate AD security group with disabled acccounts. When we remove disabled account from this security group we can enumerate it. These security groups contain only AD user accounts. There are no computer accounts. Thank you for your help.