Jump to content

Sarge

Members
  • Content count

    42
  • Joined

  • Last visited

  • Days Won

    1

Sarge last won the day on December 8

Sarge had the most liked content!

About Sarge

  • Rank
    Advanced Member
  1. Tagging, flagging, or sharing passwords

    As stated by support, Copy & Link is available between as many lists as desired. Add a custom field, add your 'tags'. Make sure the field isn't encrypted so that it is searchable. We've done this to make it easy to find passwords related to applications or services; and another custom field so we can search by server name. It'd be wonderful to link security items through to hosts that exist in the system rather than using a custom field for it, but it's not a big deal. A drop down field with a simply 'True' 'False' or 'Yes' 'No' values would achieve this. The first value you set in the field is the default value when creating new security items. Radio buttons would also achieve this - you can only select one radio button at a time, so its either true or false.
  2. Bulk Password Resets

    Supports method is the best method for your situation. Just be sure to set the parent OU containing all the computer objects in your AD environment carefully so that it only searches within OUs with computers in them, and not servers. (Since I'm assuming you don't want to reset local admin password on the servers). I'm not sure if Passwordstate does this, I've never had to care since I only reset server passwords, however I'd assume it does. The security item in the password list won't change until it's been successfully reset, however the expiry date would have still passed - so it'd be a safe bet that it would try again the next day on the hour/minute you've specified for resets to take place (Which is a password list setting which inherits downwards to the security items) If it doesn't, then it would be easy enough to achieve via the API.
  3. Hi Grant, Yes its possible. The way we did it was simply to use the "Import Passwords" function on a password list which gives you the ability to export a template. Then export the Password Safe database to a CSV, and update the headings in the exported CSV with those that are marked as required in the exported template. Another method is to export from Password Safe to CSV, then import into a new KeePass 1.x database from that CSV. Then use the KeePass method (link provided by support in the post above) to import. That should work around any messing with the CSV column names etc.
  4. SSH Keys

    That shows how often I've used RSL....Precisely zero times Oh well, glad I could jog your memory!
  5. SSH Keys

    A bit convoluted and would require significant rework of the remote session launcher, but you could always use a script to pull the keys from passwordstate via API store them locally for the duration of the putty session, start and then wait for the putty session and when it session terminates clean up the ssh keys. Or move away from Putty. Perhaps Cygwin or a putty fork like Kitty would do it?
  6. Approval requests to security group

    Correct me if I'm wrong, but password list admins get the approval requests for access to password lists. So assign a security group as the password list admins, and all members of that group should get the approval requests. The same applies for individual passwords, the administrators of the passwords parent password list get the approval or deny requests. This comes down to how you setup the permissions. Create a Junior Admins group, that group has no permission to any lists - they must "request access", the admins of that group then approve the access. Senior Admins group get permissions (view or modify) to your development password lists, but must request access to your production lists. Our passwordstate is setup with environment folders which then contain password lists - Dev, Prod, QA, Test etc. Password lists permissions (using your example) would mean Senior Admins can see and access the passwords/password lists in the dev folder, but not in prod, qa, test without requesting that access first. Junior Admins wouldn't see anything besides those they've been granted access to that they've requested.
  7. PS C:\Windows\system32> $NET45Value = (Get-ItemProperty -Path 'HKLM:\SOFTWARE\Microsoft\NET Framework Setup\NDP\v4\Full' | Select-Object -ExpandProperty 'version').Substring(0,3) PS C:\Windows\system32> [decimal]$DecNum = [convert]::ToDecimal($NET45Value) PS C:\Windows\system32> Write-Host "$DecNum" 4.6 PS C:\Windows\system32>
  8. Reset root password with different account

    Really depends how your sudoers is setup, out of the box RHEL, CentOS and Mint don't require the above change. Shucks. Thanks guys.
  9. Reset root password with different account

    Hi, Yes, it's possible. It's far easier if you use LDAP or IPA. You'll need to add the following lines to sudoers. Where <username> is the username of the priv account to handle the resets. Next... Create a linux host which can be used to reset the Priv Account credentials when they expire. (Assuming they do expire, ours do, so we reset our priv account creds 10 days prior to it's actual expiration date) Create the credentials for the priv account in a Password List enabled for password resets, link the creds to the host created above, and enable resets. Make sure validation and reset status have worked. Assuming they have, keep going with step 4. Create a priv account in Passwordstate > Administration > Privileged Account Credentials, and link it to existing credentials. (Created step 2) Create the host for which you want to reset root password. In a Password List enabled for resets, create the current root users credentials; enable them for validation and resets. On the reset options tab ensure you select the Priv Account you created previously. On the heartbeat options tab ensure you tick "Use the Privileged Account Credential selected on the 'Reset Options' tab to perform the authentication for this validation (only used for Linux root accounts if required): " As soon as you click save it will go off and reset the root password, assuming you've done everything correctly it'll go through without an issue. Details can also be found in the user manual. Make sure you've test against your dev environment prior to implementing in production.
  10. Improve Bad Passwords feature

    ClickStudios could use a noSQL database just for bad passwords. That's largely what gives Azure Tables its performance.
  11. Domains and Privilege Accounts

    Get-ADDomain will tell you the functional level of the domain. It would work as a solution in Matts case. Obviously it wouldn't work if the DCs are Server 2003 though.
  12. Reports in Administration Menu

    Looks like regardless of the resolution, its an issue if the window is resized. Even at 1920 * 1200, if I resize the window no scroll bars appear in the content pane. (Safari, Chrome, Firefox)
  13. Discovered Issues/Bugs...

    How would your idea work if the user has the same UPN in multiple AD environments? How will the Passwordstate know that Joe@subdomain.domain.com.au wants to reset his production password, if Joe@subdomain.domain.com.au (which is his UPN / email address as you mentioned) is the same in development, production, uat, sit, prac etc? When having multiple AD environments there is no need to ensure each users data within that environment isn't the same; however there is a requirement to ensure the NetBIOS name / FQDN of the domain is unique on the network. Therefore it's easy to imagine multiple reasons where multiple AD domains would have the same user data with the only unique factor being the FQDN of the domain. Just for clarity, this isn't about authenticating users to one domain. This is about authenticating users to multiple domains - particularly a development or production instances - where company standards dictate that usernames should be the same. We can easily add a suffix to our AD environments, and then update a few thousand users to use that new suffix - there for forming a UPN of "user@production.domain.com.au" or "user@development.domain.com.au" but that doesn't solve anything. Users shouldn't have to remember the suffix (Or NetBIOS name). We could add the email subdomain (lets assume its 'staff.domain.com.au') to our AD environments, then update the users to use that new suffix, but then we have the same UPN between multiple AD environments where it's "user@staff.domain.com.au" to authenticate to production or development - how would Passwordstate know which one to reset? The best way to solve it would be to use data you know will be unique - which is the FQDN (or NetBIOS name) of the domain itself, rather than assuming users UPNs will be unique.
  14. Discovered Issues/Bugs...

    That wouldn't work for us. That assumes the users know what the domain is - if they know what the domain is then they know the NetBIOS name and can just use domain\user. However our users don't know what the domain is (nor do they need to) - they just know they want to reset their "Production" or "Development" password. Being able to have a drop down, where they choose "Production Environment" or "Development" or "UAT", and enter their username (which is the same format between environments) is far easier than expecting users to remember or enter the UPN or prepend with NetBIOS. Let the users do the easy lifting and the program do the harder lifting by prepending (or appending) the required information. Since Passwordstate is aware of the NetBIOS name, it shouldn't be hard for it to interpret that a drop down box selection means it should prepend the NetBIOS name of the chosen domain to the username field. You could possibly go further, and add a "Local" option to the drop down, whereby Passwordstate would interpret this to mean the user wants to reset their credentials for Passwordstate application itself (If using forms). Currently if a user doesn't remember their password they need to see a Passwordstate administrator to resend the welcome email.
  15. Discovered Issues/Bugs...

    We sure do. It's for wider business use - sys admins, developers, 'average joes' doing app testing etc, networks team etc. They know they want to reset for development or production environment, but not know (nor remember) what the NetBios domain portion is.
×