Jump to content

Buckit

Members
  • Content Count

    134
  • Joined

  • Last visited

  • Days Won

    2

Everything posted by Buckit

  1. You'll find all previous releases on the Archive page -> https://clickstudios.com.au/previous-builds.aspx It's under the Downloads option on the main menubar of the site, just hover and it'll appear.
  2. It's seems that Az has the same issue with SUDO that I was struggling with weeks ago. The constant struggle between PasswordState's demand that SUDO rules are given the "rootpw" flag, versus default behaviour of SUDO to ask a user's own password, versus the various SUDO-calls in the Linux password-reset script. My case made things even more interesting because I'm using SUDO-rules stored in AD/LDAP, which has different possibilities from having SUDO-rules in /etc/sudoers.
  3. ... Which is a snap once you have the cert available. A simple matter of importing it on the host in question and then telling IIS to use it. Of course, where you procure the cert is a different matter That fully depends on how your company's chosen to tackle this matter.
  4. I'd love to pitch in and help figure this stuff out, but right now my workload's a bit too much. Studying for my next exam, which is where I learned about Swagger and OpenAPI
  5. Hi guys, Isn't it great how you can just keep on learning new things in IT? I've been working myself through all manner of interesting topics and only now I've started learning about tools such as Swagger. Imagine my mirth upon learning that I don't necessarily have to hand-code a Powershell module (or another lib for a different lang), by having Swagger CodeGen make one for me! All that's required is an OpenAPI compatible documentation of your API! (as if that's a small matter...) Either way, I'd love it if you could put this on your long-term backlog. I imagine more people could find this useful!
  6. That's great! I love that you've added this!
  7. Awesome sauce! But does this also mean that PasswordState will hold onto any messages it could not send because the host was down?
  8. Yup! Definitely make it selectable. As I said, in some cases we'll even see TLS-encrypted syslog, which you certainly won't find everywhere. Then again, with audit logging like this? Maybe it'd pay off to make it an option because the logs contain a treasuretrove of useful info.
  9. Thanks for considering this feature guys. On the Linux-side of things, we've been doing centralized syslog with both TCP and TLS for quite some time now. It'd be great if that finds its way into PState.
  10. Hi guys, I'm very happy that Passwordstate offers external log forwarding! This allows us to send our audit logs into a syslog box that cannot be tampered with. Today we discovered that Passwordstate does not buffer messages if the syslog target goes down. Funnily enough it does buffer all the logs if you've never configured Syslog before, thus barfing thousands of entries into the newly minted target. But if you've already configured Syslog and the box goes down, then you'll never receive any of the logs between the down and up of the host. Would you please consider adding buffering to the external Syslog connection? Don't rely on UDP, make it TCP with connection-testing. And if the connection fails, mark the moment where you'll need to start buffering. Cheers, Thomas
  11. Well, for starters it looks like you've left all filters blank, so there won't be any matches EDIT: Disregard this. I'm wrong One thing you can do though, is take a gander at the contents of the actual discovery script and then run the important parts of the script manually on one of the target hosts. That way you can troubleshoot the issue step-by-step.
  12. Huh, well I'll be. I didn't know that feature exists. Thing is, the user in question is not a security admin permanently, as we've linked our access rights to an IAM solution where access privs are activated on-demand for specific cases. So even if I were to impersonate the user, I'd not have access to the hosts because their rights were dropped when they went on holiday. And given the nature of our environment I really do not want to set a precedent by resetting the user's password and actually using their account. That certainly would not fly here. So: a big floppy trout it is! Next time I'll see'm *slap!*.
  13. I'd like to second Sarge's request. Great idea for the future!
  14. Hi again! in the Administration tab, you'll find menu options like Password Lists and Password Folders. These are awesome, because it sometimes happens that somebody does lots of work, then leaves after locking all other users out of these objects. These options in the admin-section allow you to manually fix broken access permissions. Now... If only the Hosts and Hosts Folders had the same feature! We're currently in a bind because colleague X set up the auto-discovery jobs and target folders, but set them exclusively to their account. And now they're on a holiday! Yikes! I really don't want to hack these lists through MSSQL, so could you guys add a management feature to the admin-panel that allows us to fix permissions on Hosts Folders? Cheers, Thomas
  15. Personally, I'd never expose it through the web, but that's me. I'd go for yet another option: VPN! Setup a VPN server so you can connect to the internal network from anywhere in the world, in a safe and secure manner.
  16. Alternatively @GeoffO, you could consider building a Powershell script that talks to the API: a script to make a new password object and, if it detects the host does not exist yet, it will ask you for the requisite details.
  17. Good morning! While working with PasswordState in our ACC-environment I realized that I'm needlessly hopping back and forth between screens and tabs, trying to get information. I would like to request that you extend the information on a host's page with the following: List of password objects related to this host, similar to the results screen of a normal search for password objects. Right now, all it says is "Linked credentials: N matching credentials". That's not very useful. Audit history for the host in question, e.g. discovery / manual add / manual remove / config change / heartbeat / password change etc. Right now, the hosts tab feels a bit disconnected from the whole: it looks like it only manages hosts' information, while in fact it's an integral part of managing the password objects. Cheers, Thomas
  18. Like Sarge, we've got our Passwordstate API working just fine with a cert from our internal CA. Don't have much time to spare to help in troubleshooting, but if you have specific questions you know where to reach me through email.
  19. Well, either that, or you ensure that your PasswordState server is provided official certificates by your in-house PKI. That would make life a lot easier and cheaper (assuming you have many in-house servers that need certs).
  20. Agreed. Without trying to sound offensive, here's a few basic questions: When you are on-site, wired into the network, are you using your own PC/Laptop or are you using your customer's equipment? I assume that with VPN you are always coming from your own systems, correct? When using your own system, have you adjusted your network configuration to use the customer's DNS servers? I reckon some VPN software may tackle this for you, but I'm sure that not all does. Can you perform DNS lookups for any of the customer's other systems? If so, there may be a matter of multiple domains with their own DNS, but without reference information for eachother. Please verify that your workstation actually uses the DNS servers of your customer to resolve the PasswordState server's address.
  21. Judging by this screenshot of eWallet on the PC, I'd say you can treat the whole of PasswordState as a user's wallet Inside PasswordState, users may access folder and list structures that are either A] mandated by the administrator, or B] created by themselves (if permissions allow it). If you consider PasswordState to be the top-level "wallet", then you can have a whole tree of folders where each folder may contain N amount of password lists. Take the screenshot I linked to: Wallet would be the PasswordState Passwords tab, Personal Info would be a folder and Credit Cards, Accounts and Passwords would be password lists.
  22. Right... to summarize everything in this thread. FEATURE REQUESTS: After a password expiry/change, automatically perform a heartbeat validation. This double-checks the outcome of the password change and hopefully alerts you to false positives on the change. Case in point: I have one root account where the password validation goes green, but password reset goes red with "It appears the password for the root account being reset is incorrect". That should be impossible, right?! Expand the PasswordState manual, with regards to Linux/Unix privileged users and Sudo rules. Perhaps add some more clarification of the current situation and if possible add explanation on how sudoers.ldap would change things. Further expand the outcome verification of password changes (not just on Linux, but also Windows as evidenced in the other thread). I still need to test the modifications you suggested, but this is already in progress. Again, to prevent false positives. For instance, also look at password change times/dates, changes to relevant files/resources, etc.
  23. That's what a good risk assessment is for Well, not just the assessment, but also the steps undertaken based on the outcomes. To be fair, how much different would this pstate account be from the privileged user account that's used on the Windows side? The Windows privileged account is given full password management rights on a whole AD-domain, which includes all normal user accounts, service accounts and the local admin accounts. The only thing not in there is the AD recovery account Besides, since moving to LDAP for SSH+SUDO, there won't be many local accounts to begin with I'd say the following are needed: Strict access permissions. On Unix/Linux you unfortunately cannot specify the who+from+to+times+protocol without the use of additional tools *, but you can certainly come a long way. Strong authentcation. Use proper passwords for the privileged accounts or use SSH keys (which seems like a really good idea) **. Proper logging. Keep track of the activities undertaken by the privileged accounts. Proper auditing. It'd be great if we could plonk all the activity logs into something like Splunk, or a SIEM, where you can discern patterns as well as behavior that falls outside of it. The fact that we can manage the privileged accounts centrally is a bonus: you can quickly lock or change them if you suspect foul play. Either way, by taking mitigating actions like the ones described, I feel that the risk can be brought to an acceptable level. *: FoxT's BoKS is one of those products and there are others out there as well. They're neat to have in high-security environments, but they also add another layer of complexity (and money). Which reminds me that I'll add building a set of PasswordState scripts for BoKS onto my ToDo List. That way you can manage the passwords of BoKS-managed accounts **: A little searching and five minutes of prodding rendered a nice success! It's easy to configure SSH and SSD to grab public keys from the altSecurityIdentities field of a user CN. That's pretty sick! I'll make YABP (yet another blog post) about it.
  24. Actually, @Sarge, there's one thing I'm unclear about. You indicate that "Defaults:pstate rootpw" is needed in the sudoers ruleset. I now understand why and how. What I don't get, is why the password changing command $ResetCmd for "normal" user accounts does not get called with the root password. In the Powershell script you're calling sudo passwd while piping in "$PrivilegedAccountPassword\n$NewPassword\n$NewPassword". See below. if ($PrivilegedAccountUserName -ne "") { # Skip MacOS and VMWare else { if ($UserName -eq 'root') { $ResetCmd = "echo -e $'$OldPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName" } else { $ResetCmd = "echo -e $'$PrivilegedAccountPassword\n$NewPassword\n$NewPassword' | sudo -S passwd $UserName" } } } The fact that the sudoers ruleset is setup to demand "rootpw" for the privileged account, means that the latter should fail. Unless you specify two SUDO rules: sudo passwd root, with the rootpw flag and sudo passwd * without the rootpw flag. That would introduce a need for proper SUDO rule ordering though... EDIT: Ha, never mind! The manual that @support linked to explicitly states this! The great thing is that I can work around this limitation with SUDO+LDAP! Putting together what I've learned today, the following SUDO rules will allow me to 1) use the default scripts from PasswordState, 2) use just one privileged account for Unix hosts! CN=pstate-ECHO,OU=sudoers,OU=domain,OU=local: sudoHost = ALL sudoCommand = /usr/bin/echo sudoOption = rootpw sudoUser = pstate CN=pstate-PASSWDROOT,OU=sudoers,OU=domain,OU=local: sudoHost = ALL sudoCommand = /usr/bin/passwd root sudoOption = rootpw sudoOrder = 10 sudoUser = pstate CN=pstate-PASSWD,OU=sudoers,OU=domain,OU=local: sudoHost = ALL sudoCommand = /usr/bin/passwd * sudoUser = pstate EDIT 2: CONFIRMED! The SUDO rules shown above, when put into LDAP, work wonderfully! One privileged account can manage both root and normal users using the default PasswordState scripts. Feature request: put this example into the manual, same chapter as linked to before (CH14).
×
×
  • Create New...