Jump to content

Buckit

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Buckit

  1. Yup! You will find the menu-bar configuration under Administration > Feature Access > Menu Access. There, you can define permissions for menu-blocks (Tools, Reports, Preferences, Help), but also per-item in each menu-block. In my case, I've set up the menus in such a way that my default users cannot see anything besides the "Request access..." items in the Passwords menu. All the other options are reserved to administrators and senior users.
  2. Nope, not seeing that because we have zero email capabilities, hence why I'd like to have more built-in logging capabilities.
  3. Would you believe that the API documentation is actually tremendously well done? It hands-down beats the online documentation you guys have been showing in the screenshots! Just visit your PasswordState's API URL, for example: https://passwordstate/api or https://passwordstate/winapi The same URL you call with API calls also includes the full documentation with code examples! How sweet is that?!
  4. And sometimes the user will try to actively hide what they've done. So yeah, especially in high security environments, a detailed audit track would be recommended.
  5. 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
  6. Actually, that setting is not part of the account discovery configuration. It's part of the host discovery config. The account discovery will simply login to all found hosts and try to find local administrator accounts. If you feel iffy about having PasswordState run the account discovery for you, you could also create the user+password objects through the API. It's pretty darn wonderful! Assuming that you have some way of generating a list of hostnames from your CMDB (or other registration), it's a simple matter of a ForEach loop to create the required host and password objects. That's exactly what I'm doing right now for a few hundred IOT devices.
  7. Yes all of our Windows boxen should have a local admin account, but sometimes the privileged account used for discovery cannot login (due to AD policies). Right now, the discovery jobs do not seem to provide logging about these kinds of errors, which is why I'm asking for the report: this allows me to trace which hosts may have had login issues for the discovery account. Of course, I'd much rather also have a report or log about the recent discovery runs That would help me troubleshoot even better! The error console does not show these kinds of issues.
  8. Hi again! I've been dutifully adding hosts into PasswordState and I've also ran discoveries against them. However, only 60% of them reported local admin accounts. Figuring out which hosts don't have password objects yet is becoming a bit of a hassle. I'd love to have a report or two which tell me which hosts don't have password objects associated with'm. And the other way around, it'd be great if there's a report for orphaned password objects, where the host has gone missing or "unmanaged". Did I perhaps overlook an option that already allows this? Cheers!
  9. That's a very thorough reply Support Thanks!
  10. Aye, I'll poke around some more in our global policies and settings. It's an interesting situation. In another test, I use the same commands with a proper admin account and while the password changing went off without errors, the validation still fails (suggesting that the change wasn't made). I'll report back when I've had the chance to poke around some more.
  11. Hi, thanks for your help. Everything you need to know is in my first post in this thread: reproduction, code analysis and a suggested fix. One easy way of reproducing the situation is by manually removing the Windows privileged user from the administrators group on the target host. This will ensure that the password change request fails. But as I showed, the itself will still report a success and will thus not report any errors. Of course... removing administrator rights form the account means you'll have to ensure that the account gets Powershell Remoting access in another way (see my other thread). Funnily enough, my Windows privileged account -DOES- have full admin rights and it still gets "access denied" on the $account.psbase.invoke. That's a WIP on my side, which led to the discovery of this bug. EDIT: I have just tested my suggested fix in my sandbox environment. The password script now correctly sets "reset status" to RED, with the correct error message as reported by the failing $account.psbase.invoke. Of course, that leaves all the other scripts to double-check for similar bugs
  12. No worries We've all been in those kinds of situations. Best of luck! Right. Given the sensitive nature of this data, that's far from ideal. But I guess they have their reasons for it. If I manage to find some time, I'll poke and prod some more into the code. See what I can figure out.
  13. In the mean time, I'll keep on prodding and poking. I'll update you guys when I've got things sorted. Hang on... I just realized. I really hope you mean -local- admin rights, as opposed to domain admin. Right?! Just to make sure...
  14. Well, the fun part is that it even occurred when the account is member of the local admin group. So even with admin rights the command fails, but the Powershell script does not handle it correctly. So to sum it up: if someone were to accidentally strip rights of the privileged Windows account, the Powerstate script in its current incarnation would not alert you about failed password changes. That could seriously mess up someone's production environment. Thus I would sincerely suggest that this bug is fixed quickly. It is detrimental that false positives can be reported for password changes.
  15. *shudder* Which takes me back to wondering how your network is laid out, because that seems like such an odd setup to me. But as I said: no need to disclose sensitive info like that Also, I have to wonder what kind of magic that extension does, insofar that a specific certificate is required on the server-side. I'm assuming the browser simply speaks to your load balancer, meaning that SSL is terminated from there and then the rest is simply http or https between the LB and Passwordstate. Normally this would work without much issues, unless the extension does some very strict handshake with the PS server wherein the PS server explicitly states what certificate the extension should expect. That would be a way to protect against man-in-the-middle attacks (which your situation is, to some degree). Time to see if we can dig up documentation on that extension
  16. 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" } }
  17. 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.
  18. Hi again, Poking around the Administration-section of the web interface I decided to set up automated backups for Passwordstate. I was quite surprised to find that we need to hard-code the password for the backup account. I mean, the whole point of Passwordstate is to have managed accounts Could you possibly update the automated backups in such a way that they can use a known username+password object from the Passwordstate database? That way, if the password gets changed, we won't have to manually edit the backup settings.
  19. Understood! It makes sense when explained that way and it also answers my question about dueling-host-lists: both lists get the host Cheers!
  20. Hey Matt, Of course we can't ask you to provide too many details about your network setup; we wouldn't want you to disclose any important information. But let's see what we can of this Based on what you describe, I expect that you also get certificate errors when using PasswordState's web interface. Correct? If so, then it seems that your load balancer's certificate does not include your PowerState server's hostname in the SAN (subject alternative name) list. That's what is needed in this case: a certificate must always list the subjects that it was assigned to. If however, you do not get certificate errors in your browser, then there's something else going on. We'd need to poke a little further
  21. Yup that helps a lot! That's exactly what I was looking for. Except (going back to consistency like in my other thread) I was expecting to find it elsewhere. With account discovery this mechanism is a push mechanism: you tell the discovery job where to put the accounts it finds. On the other hand with the hosts discovery, it's a pull: you tell each host list (folder) which hosts to grab when they're added or discovered. So... Personally I'm a fan of consistent design: making two similar things work in the same way. But I can understand that it's not easily changed afterwards Also I can't help but wonder, what happens when two host folders both want to grab a discovered host? Thanks for your help!
  22. Hiya! I realize they're two different things. My issue is one of UI consistency. The equivalent of the current situation is having two multiple choice questions with identical answers, where with Q1 they're listed as A, B, C, but with Q2 they're listed as B, A, C.
  23. 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
  24. Hi guys, Many thanks for all your quick replies and help so far! Sorry for seemingly spamming the boards with my questions I'd like it very much, if the host discovery jobs offered a feature similar to the account discovery jobs: automatically adding the discovered objects to a specific list. For example, I'm working with something like an "Unprocessed" list for newly discovered accounts, so we can have some form of queue for our administrators. I'd like something similar for the hosts. Along other lines, the hosts menu right now only shows hostnames when they're part of a list. Hosts that are not yet in a list don't show up in the menu-bar. Hence why I also would like the option to auto-add to a list. It's not a world-shaking feature and I'm sure my wants stem from an as-of-yet-sub-optimal workflow... But heck, if you can fit it on the backlog somewhere near the bottom, that'd be great
×
×
  • Create New...