Jump to content

geeks

Members
  • Content Count

    4
  • Joined

  • Last visited

Everything posted by geeks

  1. We initially installed Passwordstate with AD integration but now we've decided that we want to "unhook" AD integration so that in the event of a disaster, we will be able to login and access our passwords in Passwordstate without first having to restore an Active Directory server. What do we have to do to unhook AD integration without losing all of our data?
  2. I'm new to Passwordstate, so please forgive me if I'm missing something here, but I've looked everywhere I can think of in the Passwordstate interface, and throughout the Users and Security Administrators manuals, and I can't seem to find any information indicating that changes made in the Administration area (and especially in the System Settings section) are tracked so that they can be viewed and monitored under the Auditing section of Administration. When we first mentioned to our users that this new system was coming, our HR person became extremely alarmed - she doesn't want System Administrators to have access to just anyone's passwords. I need to be able to show her that we can lock that down and prove through auditing that us System Administrators aren't circumventing security policies. Can someone tell me if Administration level changes are audited, and if so, how to view them, or how to enable auditing of these changes? And if not, please consider this a request for enhancement to Passwordstate. Thank you, Rochelle Adsitt IT Director evergreenDIRECT Credit Union
  3. geeks

    Audit Administration Settings Changes

    I get your point about circumventing security by changing a user's password, but it's a lot more obvious to a user when their password is changed than when a critical Administration or System Setting is changed in Passwordstate, especially if the Auditing log can be purged. I think enhancing a combination of: - auditing, - reporting, and - email templates would go a long way towards being able to secure Passwordstate at a level which would satisfy the pickiest of auditors (because in the long run it's not just my HR manager I need to assure, but it's our financial and security auditors we have to answer to). Also, how about requiring two people to authenticate in order to change the emergency access password? I'd like to see: - auditing added for changes made to Administration settings, and especially for every System Setting, - additional reports, especially reports for all current Administration and System Settings, - the ability to schedule reports to be sent to individuals or groups of individuals (like sending a daily audit report containing selected types of activities), and - additional email templates so that someone (or a group) in the organization would immediately be notified if any System Setting or other critical Administration settings were changed Ideally at the moment, in order to get this up and running for us, I'm thinking I will: 1. ask a group of key management personnel to assist in deciding how certain critical settings should be configured (System Settings and other Administration configuration settings reports would help here - to give them something to review for planning purposes - besides a 111 page Security Administrators manual; and then provide them with a final report of what the settings are after they've been configured) 2. lock down the settings by having Security Administrators remove access to System Settings for each other 3. configure "alerting" by assigning email templates to security groups which include multiple management level individuals 4. insuring key personnel have access to review the full audit list (increasing the types of events which are audited and having the ability to send them daily audit reports would be helpful here) Thank you for your consideration. Rochelle
  4. geeks

    Audit Administration Settings Changes

    The main concern of our HR person is that a System/Security Administrator not be able to access a private list that doesn't belong to them. And if there are options under System Settings that appear to allow someone with that role the ability to override potentially risky settings (i.e. "Allow Security Administrators to convert Private Password Lists to Shared ones", "When administering Password List permissions...prevent Security Administrators from granting themselves permissions to passwords", and "Enable option for purging of Auditing records"), what's to keep a Security Administrator from converting a Private Password List to a Shared one, changing the permissions on it, and then hiding their actions by purging the Auditing records? As my manager put it - by the time someone figures out what the Security Administrator has done, the damage has been done because they've already gained access to a system they shouldn't have. How do other organizations deal with this? Do they lock down the System Settings and then take that role away from the Security Administrators (relying on the "emergency" access to work with System Settings if they need to be adjusted)? Thanks, Rochelle
×