Steve D.
-
Posts
18 -
Joined
-
Last visited
Posts posted by Steve D.
-
-
On 3/22/2019 at 6:51 PM, support said:
Hi Steve,
At this stage we do not have a SAML auth verification policy - our flawed thinking behind this was a lot of customers use SAML with ADFS, so you could not use SAML in this instance for obviously reasons.
Regards
Click Studios
Yep, I can see this. Obviously not a Red Hat issue... lol. If I tried to foster & promote ADFS around here I'd soon be nailed up on a stake surrounded by kindling.
So... I'm going to need an enterprise license, 6 remote sites (to start with), the pw reset portal and HA. ... as an opener. Have you got a var/support channel in the US I should be speaking to?
Rgds,
Steve D.
-
While I'm asking questions... We had a stage env DC die a bad death. I replaced it, same name, ip, etc... PWS resumed authenticating users when it went operational but it is complaining about not being able to query event logs...
"
An error has occurred executing the call 'PR_EventLogMonitor_Elapsed'. It appears the Domain Controller for domain 'stage.win.........
"
I have poked and poked but I can't find where this is coming from. Any pointers?
-
Thanks for sending the pw reset portal trial key. The I got it implemented and gave a demo of 2 auth methods for infosec; the google auth & temporary pin e-mail methods, and the question I got back was ... is there a saml2 verification policy?
PWS will be tied to RHDS (LDAP) and SAML2 auth, or so the plan stands at present. All employees have a token generator of one kind or another tied to a pin/token combo registered with the saml2 implementation. saml2 will be universally available to all staff. The e-mailed temp pin is acceptable for general staff but anyone with administrative level access infosec wants tied to two factor, preferably via saml; Help desk, ops & engineering...
p.s.
The work I''ve done on this with your invaluable help has been well received and I appreciate it.
Thanks again gents.
Steve D.
-
tag (always forget to tick the notify me option)
-
Gents,
I gave a second demo of the test environment to more of our InfoSec team this week. They continue to be impressed with the product, including a senior resource that is particularly hard to impress. (thanks for that. :)) I'm pretty sure pws is now the front runner for company wide password management tools that are being evaluated by them. I'm busy granting them access to the test environment so they can test configuration and do some pen testing themselves.
They have been reviewing information on the www site and have run across references to CS having outside parties perform pentests on the product. They asked me to see if I could get more detailed information about that. What group/s performed the pentests, on what schedule, and perhaps a summary of results.
They are evaluating how far they want to extend it at this point I suspect. Weather to expose it to the "outside" or contain it to the corporate lan.
There is discussion of doing multiple implementations to break out types of lists and groups so breach of one implementation doesn't expose the entire environment. I'm working to show them the ease and speed which the product provides for correction once such a breach is detected but they may still want to split this into multiple implementations.
They are also asking questions about something I asked previously regarding the ability to implement multiple www servers and filter list type access based on the www access point used. They want to prevent shared lists from being exposed on an access point deployed in the cloud for inet access while giving users access to their personal lists. VPN or secure lan access grants all lists. Can this be slotted as a feature request?
Can you point me at more detailed info about the pentests please?
Thanks,
Steve D.
-
It does indeed. Thanks again for your prompt response sir.
rgds,
Steve D.
-
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.
-
tag.
i always see the notify me option after hitting submit...
-
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
-
Gotcha! No splitting tasks and services into separate lists unless the accounts are all unique.
thanks!
-
Question about account association across multiple systems / password lists here...
Example:
Server A runs an app that has services running under an AD domain account.
Server B has several AT tasks that use the same service account that the services are running under to perform tasks against those services.
If you have set-up password lists that are enabled for password reset for both services and tasks(separate lists), and the same account is used across both password lists, will they work together or fight each other? i.e. will the services password list change the password without updating both the tasks and the services, causing the services to continue to run but the tasks to fail?
OR,Is password state smart enough to pick up on the fact that the same account is hosted across both password lists? Will it change the password in one list and update both the tasks and services across all instances of lists that are configured for password reset that found the account?
OR,
Do you need to keep them in the same password list for this to function?
Thanks,
Steve D.
-
Sorry, I may have been a little vague there. It was 3am for me while we were corresponding...
When I say the administrators personal certificate store, i mean the user who is running the passwordstate administrative interface, i.e. the passwordstate administrator who has rights to see and manipulate the scripts. it's their credentials that would be used to access their certificate store, not the account the services run under. They have full rights to their certificate store and that is where the code signing certificate that is needed is stored.Thanks for your help!!
-
Yes. This is doable. There are only 3 scripts that would need this. local administrators, services and tasks. I'll set this up and test it in our stage environment and test it.
The only way I could see for you to do this is to write into the code for passwordstate a way to sign these scripts using certificates in the administrators personal store. Create a Sign Me button, if you will. Many of the powershell editors i use have signing extensions that tie into the user's certificate store and allow the author the ability to select a certificate to sign the script currently being edited with. Once setup, its a one click operation. PowerGUI (before dell killed it) and Visual Studio Code which is my current editor of choice offer plug-ins that do this.
An option on the powershell scripts tab to sign selected scripts with a pop-up presenting you with available certs from your personal store to sign the selected script with. Only those scripts that run against Windows domain member systems would need to be signed. Those that deal with network devices or other os versions aren't affected by this.
Once in place, we'll have to come back and resign these scripts each time we update the product, then go through all the autoupdate password lists and reassign the correct script again. Correct? -
I'm surprised by this. We are a fairly open environment but with growing security concerns. We want to limit those who can remotely execute powershell scripts. We allow users to write scripts and run them on their local systems but anything that is psremote must be signed using a code signing certificate issued by our CA. These certificates are published to targeted systems to allow those administrators to execute scripts on them using psremote. If a user has rights, they can psremote into the server and execute commands one at a time but they can't execute commands or scripts using Invoke-command. If your going to run batch commands against large numbers of systems in our environment, your script must be reviewed and signed by one of the admins holding a code signing certificate.
There are code signing certificate holders for desktop systems. There are code signing certificate holders from various groups of servers. There are a couple of code signing certificate holders that are environment wide.
This is managed by putting these individuals certificates into the trusted publishers machine certificate store using group policy. There are several group policy objects that put different certificates in the various machine store based on system type and ownership group.
This ties into the powershell script execution policy"RemoteSigned" which is applied to all systems throughout the environment, also using group policy.
There isn't any code to share. Basically, you take your script and execute a command that uses your code signing certificate to sign the script. It adds a block of encrypted txt to the end of the script. Example:
# SIG # Begin signature block# ....# ....# ....# SIG # End signature blockUnless the machine has a matching certificate in it's trusted publisher's certificate store the script will not run.
Also, you can not create a single signature and use it over and over. Each scripts signature is calculated based on it's contents. If the script is altered in any way after being signed, it will not execute.5986.
We also secure psremote using ssl certificates. All systems have SSL certificates issued to them and are configured to use SSL encrypted psremote sessions on port -
Request to add additional user account sync source/s.
in Feature Requests
Posted
The ability to import user accounts from Active Directory, and do so on an automated schedule, is fantastic. Not everyone uses AD as their primary user account information repository however. We, Red Hat, use our own IDM solution:
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/linux_domain_identity_authentication_and_policy_guide/introduction
The ability to connect to additional ldap data sources for user account import would be exceptionally useful for us. Any change this could be added to a future build? It's just another ldap directory basically. All we need to do is read user account information from it for import into PWS.
Thanks,
Steve D.