Jump to content

Several questions & a request.


Steve D.

Recommended Posts

I'll start with the request. I need to extend the evaluation period. I set up passwordstate in our stage environment and spent the better part of a week tinkering together the components I had a direct interest in for demo to our InfoSec team. I gave that demo this past Friday to a subset of the group I intended to participate because of a number of conflicts not least of which being the upcoming Thanksgiving holiday.

 

Those that did attend shared a document the team had been working on that laid out a list of requirements for password management solutions they had been evaluating internally, outside my knowledge until this time. The demo I gave of passwordstate blew them away basically. It checked all the boxes they had laid out and a few they hadn't considered as options. None of the other products on their document had done that and there was a relatively long list of candidates there.

 

They have requested that I schedule a second demo which they assure me the entire team will be present for. They also requested access to the stage environment deployment I have done. Also requesting access for testing is our desktop engineering team. I also expect the other, InfoSec team members to request testing access to the deployment in stage. In short, I'm going to need to allow a dozen or more individuals access for testing and security validation of the solution.

 

To that end, I'd like to ask if I can get an extension of our evaluation license to facilitate their access. I think it's likely that pwstate will win the competition currently taking place for password management solutions based on the response of those that attended last weeks demo, unless they find some glaring problem in their testing. Is it possible to extend the eval license period please?

 

 

------

 

Question 1:

 

We are a big splunk shop. InfoSec has a lot of their alerting and monitoring tied into splunk. They wish to know if there are any tie-ins for splunk integration with pwstate. I'm going to talk to our splunk administrators as well. It may be possible to query the audit log data directly from the dB. Or perhaps a stored procedure executed on a schedule to export the content to log files for pickup by the splunk forwarder. If pwstate won't feed splunk forwarder, what tables/fields do I need to export/query from splunk to collect audit logs and feed them into the splunk system? Splunk integration is critical for InfoSec acceptance. The two are inseparable.

 

 

Question 2:

 

Is it possible to deploy multiple active www interfaces, one internal that grants access to all password lists the user has access to, personal and shared. The other in the cloud that we can filter which lists the www access point will serve to the end user? We're thinking that this interface should only allow access to personal pw lists to facilitate smart phone / browser plug-in access from outside the corporate lan for personal data. We can do a little alias magic internally to direct the clients to the correct access point depending on if they are corporate lan connected or not.

 

 

Thanks for your help gents!

 

Rgds,

 

Steven DiGiuseppe

Link to comment
Share on other sites

Hi Steve,

 

Thanks very much for the feedback, and we're glad your demo went well :)

 

You can extend the Enterprise trial for another 30 days by going to the screen Administration -> Passwordstate Administration -> License Information, click on the 'Client Access Licenses' record, and then enter the key below into the 'Enterprise Trial Key' textbox:
 

F8er8AO14x2w1jX5vpXGrDo8h5L+N4lmc+1F4vNTsHY=

 

2 hours ago, Steve D. said:

We are a big splunk shop

Yes, we can send all auditing data to Splunk, and it's something we use internally as well. Just go to the screen Administration -> System Settings -> Proxy & Syslog Servers tab, and you can specify your Splunk server details here.

 

2 hours ago, Steve D. said:

Is it possible to deploy multiple active www interfaces

I'm not really sure this sort of "filtering" would be possible for a separate deployment like this - once you've granted a user/security group access to credentials, we don't really have any additional filtering on top of this. The only thing I can think of, but I doubt this is what you want, is the use of our Mobile Client web site. This web site can be deployed separately from your main Passwordstate instance, and then you can retrieve your passwords on your phone - it looks and behaves like a native App. When looking at your permissions on Password Lists as well, you will notice you can enable/disable Mobile access for each Password List as well - it's enabled by default.

 

Unless you want a completely separate instance with different data, used primarily for personal information - this would be possible. On the screen Administration -> Feature Access -> Menu Access tab, you can change permissions on the main menus for creating Private and Shared Password Lists. So in one instance you could allow only Shared Password Lists, and in the other only allow Private Password Lists.

 

Hopefully one of these suggestions would work?

Regards

Click Studios

Link to comment
Share on other sites

14 hours ago, support said:

Hi Steve,

 

Thanks very much for the feedback, and we're glad your demo went well :)

 

You can extend the Enterprise trial for another 30 days by going to the screen Administration -> Passwordstate Administration -> License Information, click on the 'Client Access Licenses' record, and then enter the key below into the 'Enterprise Trial Key' textbox:
 

F8er8AO14x2w1jX5vpXGrDo8h5L+N4lmc+1F4vNTsHY=

 

Awesome! Thank you.

 

 

14 hours ago, support said:

Yes, we can send all auditing data to Splunk, and it's something we use internally as well. Just go to the screen Administration -> System Settings -> Proxy & Syslog Servers tab, and you can specify your Splunk server details here.

 

I was hoping you'd say that. This is a big win!

 

14 hours ago, support said:

I'm not really sure this sort of "filtering" would be possible for a separate deployment like this - once you've granted a user/security group access to credentials, we don't really have any additional filtering on top of this. The only thing I can think of, but I doubt this is what you want, is the use of our Mobile Client web site. This web site can be deployed separately from your main Passwordstate instance, and then you can retrieve your passwords on your phone - it looks and behaves like a native App. When looking at your permissions on Password Lists as well, you will notice you can enable/disable Mobile access for each Password List as well - it's enabled by default. 

 

Unless you want a completely separate instance with different data, used primarily for personal information - this would be possible. On the screen Administration -> Feature Access -> Menu Access tab, you can change permissions on the main menus for creating Private and Shared Password Lists. So in one instance you could allow only Shared Password Lists, and in the other only allow Private Password Lists.

 

Hopefully one of these suggestions would work?

 

This is not one of InfoSec's requirements. There is ongoing debate about whether to expose it to the outside world. I suspect the answer will be no in the end but it's good to know what your options are. It may be that we choose the mobile site option if it comes to this.

 

14 hours ago, support said:

Regards

Click Studios

 

 

One additional question.

 

Is it possible to deploy the www access points with different authentication mechanisms? i.e. deploy an www instance in the cloud that uses saml and one internally that uses ldap/kerb auth? I don't think so given these requirements are set at the user account / list level. I don't see anything to allow multiple auth mechanisms and restrictions on where they can be used.

 

 

Thanks again for your quick responses!!

 

Rgds,

 

Steve D.

Link to comment
Share on other sites

Hey Steve,

 

Thanks for the feedback, and we have multiple options here for authentication:

  • On the screen Administration -> System Settings -> Authentication Options tab, you can set it site wide for all users
  • On the screen Preferences -> Authentication Options tab, users can override the setting above
  • On the screen Administration -> User Account Policies, you can create a policy with different authentication options, and then apply permissions for which users it applies to
  • On the screen Administration -> System Settings -> Allowed IP Ranges. You can specify trusted network ranges here, and then specify an alternate authentication option if accessing outside of this range

The only caveat to all of this is SAML - generally if you configure SAML Authentication in option 1 above, then it will apply to all users. The only way to get around this is to disable 'Anonymous Authentication' for the site in IIS, so they we know who the user is and can apply a different authentication option. You may not want to do this though, as it does cause issues with logging in from Linux/Macs - your browser would prompt you for domain credentials when you first browse to the site. Saying that, later this week we will release a new build where the 'Allowed IP Ranges' will allow you to pick a different Auth option, if the System Wide one is set to SAML.

I hope this helps.

Regards

Click Studios

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...