Jump to content

Search the Community

Showing results for tags 'bug'.



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 6 results

  1. Hey guys, I'm still running an older version in my DEV environment, 8180. After defining a dependency for one of my password objects, I discover that I cannot edit the created dep. I can only add a new one and remove the existing one. That feels really sloppy. Was this fixed in a newer version, or is this a "FIXME" for a future release? EDIT: Here's another one! Instead of asking us to select both a script AND a dependency type, could you please make this an implicit action? Either you choose the "Reset Scheduled Task Password" script, or you choose the "Scheduled Task" dependency type. It's too easy to forget to change one of these and it leads to messy situations. Especially if you can't edit defined dependencies EDIT 2: Could you also consider renaming the "Reset Scheduled Task Password" script to "Reset Windows Scheduled Task Password"? Similar for the IIS app pool and the COM+ components. That will neatly group the four related scripts together in the pulldown menus. Cheers, Thomas
  2. 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
  3. Hiya, I was poking around the API and WINAPi documentation at https://passwordstate/api and https://passwordstate/winapi. First up: big kudos for your work over there! It's an awesome resource, very useful! I noticed a small detail that's off: at /winapi, all the URL and code examples still refer to /api instead of to /winapi. I realize it's such a small silly thing, but it may at some point throw off someone who's trying to use the Windows-integrated authentication instead of the API keys. Cheers, Thomas
  4. Hi again. As you have seen in today's other thread, I'm working on getting the password resetting for Windows to work without using local admin privileges. Whilst doing so, I've stumbled upon an error in the Windows local account password reset script "Set-WindowsPassword.ps1". I'm working with build 8180. After reducing the Powershell code to its bare essentials and running it on one of my test boxen, I've found that the relevant ScriptBlock contains a Write-Output that it really shouldn't, or that the test is written badly. Its current state leads to false positives. REPRODUCTION: Expire a local admin account's password on a Windows box. A few minutes later, the reset status lights up green as does the heartbeat. However, running another heartbeat attempt sets the HB status to red. Upon closer inspection I also find that the password has NOT been changed. No errors are reported by the reset script, which is recorded as successful in the audit log. DEBUGGING: I've reduced the relevant Powershell code to the bare minimum. I'm running it in Powershell ISE on the target host, with the privileged user account. Running things manually clearly shows an "access denied" message which is not getting caught by the test. EXAMPLE CODE: $HostName = "myhost" $TargetUser = "administrator" $NewPassword = "supersecrettotallynotit-1234" function ScriptBlock () { $account = [ADSI]"WinNT://$HostName/$TargetUser,user" $account.psbase.invoke("SetPassword", $NewPassword) $account.psbase.CommitChanges() Write-Output "Success" # THIS IS YOUR SMOKING GUN } $resultsarray = scriptblock 2>&1 if ($resultsarray -eq "Success") { Write-Output "Success" } else { Write-Output "Failboat" } PROOF: Run the code above ultimately leads to the output "Success", even if the psbase commands fail. In my case, I'm given an "access denied". Taking out the Write-Output from the function makes it exit with "Failboat". Now, if I swap the final IF-THEN-ELSE test with the actual code from the original PS1 (which includes the Switch statement for various error messages), then we see the same pattern. Making ScriptBlock output "Success" always leads to an exit of the script with "Success". Taking out that Write-Output line however, will correctly display the "access denied" error message. FIX: You'll need some error handling in your codeblock, to verify if there's any failures on the remote end and to indicate at which step. function ScriptBlock () { $account = [ADSI]"WinNT://$HostName/$TargetUser,user" $account.psbase.invoke("SetPassword", $NewPassword) if ($?) { $account.psbase.CommitChanges() if ($?) { Write-Output "Success" } else { Write-Output "Failure on commit"} } else { Write-Output "Failure on invoke" } }
  5. Hey again. Poking around the System Settings section of the Administration panel I saw something that deserves a spot on /r/mildlyinfuriating Please refer to the attached screenshot: the two "disable" options switched sides. If you're careless and want to disable accounts in both cases, you may be tempted to click the right-hand option both times (because the first time that's "disable"). In the long run that may lead to inadvertently deleted accounts. So yeah, please make the delete/disable pairs line up
  6. Hi, I found a bug on the Administer Bulk Permissions for Password Lists page. When you apply a filter to the Available Password list box you cannot add a selected list to a Permission box. The Available Password List box and filter resets and the lists isn't added to the permission box. I have checked Chrome and Edge and the bug occurs on both browsers. Steps to reproduce: Go to the Administer Bulk Permissions for Password Lists page Search for a user. Select User. Apply a filter to the Available Password Lists box Select a list from the filtered box. Press >> at the View Permissions box. Available Password Lists box resets. On another note, something really really small The password field on the active directory authentication login form seems to have a different border than the username box .
×