Jump to content

Search the Community

Showing results for tags 'active directory'.



More search options

  • Search By Tags

    Type tags separated by commas.
  • Search By Author

Content Type


Forums

  • 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

    End


Last Updated

  • Start

    End


Filter by number of...

Joined

  • Start

    End


Group


AIM


MSN


Website URL


ICQ


Yahoo


Jabber


Skype


Google Plus Account


Location


Interests


Biography


Location


Interests


Occupation

Found 10 results

  1. Hiya, I've been struggling with a few things in our ACC and PROD environments; thought it'd be better to ask for your help. For starters, there's this one: I've defined a privileged account that's used to expire both local Windows passwords and passwords in AD. Conforming to the manuals I've set up the account to be local admin on the Win boxen and to have delegated password management rights on the AD domain. The latter is done through ADUC (Basically like this article describes): Right-click the domain's top / root, choose "Delegate control". Add the privileged account as the user that gets delegated control. Choose the task "Reset user passwords and force password change at next logon". Click Finish. In many cases this works just fine. But not with a number of break-glass accounts that we've built in AD; they're accounts with elevated privileges. In their case I find myself having to edit the Security settings of the account in question, adding the PasswordState privileged user and giving it both "change password" and "reset password" privs. Did I foul things up with the delegation at the AD-level? I thought this'd be enough. Cheers, Thomas
  2. Hello, currently it is not possible to use wildcards in the "Administration -> Security Groups -> Add AD Security Group" screen for the "Security Group Name". But if you want to import all groups in a specific OU, it would be nice to use a wildcard for the name, if you have specified a valid value in the "LDAP Filter" field. Is there a possibility to provide such a feature? Best regards, Tina
  3. 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
  4. 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.
  5. Hi, Now it's a hassle to create both the account, and add it to passwordstate. It would be nice if the account could be created instantly from Passwordstate. F.e. having a tab "account creation" where you can select the OU for AD accounts with a button "Create".
  6. This post describes how to set up an Active Directory account in Passwordstate, configured for Automatic Resets: Powershell Script: $PasswordstateAPIURL = "https://fabrikam.com/api/passwords" $jsonString = ' { "PasswordListID":"9914", "Title":"SCCM Service Account", "Username":"sccm_admin", "GeneratePassword":"False", "Password":"Welcome01", "APIKey":"63fca2537db89e4fb329546d7e83cab6", "ValidatewithPrivAccount":"False", "AllowExport":"True", "PasswordResetEnabled":"True", "EnablePasswordResetSchedule":"True", "PasswordResetSchedule":"23:00", "AccountTypeID":"82", "ADDomainNetBIOS":"fabrikam", "PrivilegedAccountID":"2", "HeartbeatEnabled":"True", "ValidationScriptID":"9", "HeartbeatSchedule":"10:00" } ' Invoke-Restmethod -Method POST -Uri $PasswordstateAPIURL -ContentType "application/json" -Body $jsonString Pre-Requisites to get this script working: An API key needs to be set on a Password List. This can be achieved when adding or editing a Password List: You'll need to find the PasswordListID value, by toggling the Visibility of the Web API IDs: Next you'll need to find the AccountTypeID for Active Directory under Administration -> Images and Account Types: Next find the Validation ScriptID for Active Directory Accounts under Administration -> Powershell Scripts -> Password Validation: And the ID of your Privileged account, which has permissions in AD to reset Accounts: If you insert these values into your script, along with any other string values like the Title or username, it will add a record in to the system as expected.
  7. We are just in the early trial phase of PasswordState and I'm beginning to look into the reset functionality. One of our use cases is that we use AD Accounts for application services (not the new AD Service accounts yet, just standard user accounts). If I set up an automated password reset for that service account, is there a way to automatically update, or at least link it, to the service account as well? If I select 'Active Directory Account' then I can only enter a Domain, not a list of hosts or anything. Am I getting far afield here or am I missing something obvious?
  8. 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
  9. Step 1: Ensure you have prerequisites set up for your web server, as per this forum post (Once off process) Step 2: Add new Password Record configured as follows: Screen 1: Ensure you configure the below 5 options correctly and enter in the AD password for the account. If you configure an Expiry Date it will automatically change the password when that date is reached. Screen 2: Select the appropriate Privileged Account. Also confirm the Password Reset Schedule is enabled if you want the password to automatically change when the Expiry Date occurs Screen 3: Confirm the Validate Password for Active Directory Account validation script is selected
  10. Hi, from reading other messages, it appears there may be a document to assist with converting from Forms-Based Authentication to AD Authentication. At the time that PasswordState was originally installed, we were not an AD shop. But now we are slowly and surely moving that way. Let me know if you have any ideas. Thanks much.
×