Jump to content

Steve D.

Members
  • Content Count

    18
  • Joined

  • Last visited

About Steve D.

  • Rank
    Member

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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.
  3. 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?
  4. 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.
  5. There are, in fact, a couple of additional items I need to ask about. Can I request a trial for the www password change portal as well? We currently use the IISADMPWD replacement tool. I'd like to see if I can replace that and consolidate on PWS. Also... password blacklisting. Is there a way to extend the blacklist function out into the AD environment? IE, make the blacklist universal across all password change mechanisms; www portal, ctrl-alt-del @ a client, etc... This would be a big win for me right now. Thanks again!! You guys have been great. Really appreciate all the help you've given on this. rgds, Steve D.
  6. Gents, I'm back. I have budget approval for a PWS deployment and the infosec team has decided that now is the time do their testing of the demo enviornment i stood up a few months back. Could you provide another demo license so I can reactivate that implementation for them to test against please?
  7. tag (always forget to tick the notify me option)
  8. 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.
  9. It does indeed. Thanks again for your prompt response sir. rgds, Steve D.
  10. Awesome! Thank you. I was hoping you'd say that. This is a big win! 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. 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.
  11. tag. i always see the notify me option after hitting submit...
  12. 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
  13. Gotcha! No splitting tasks and services into separate lists unless the accounts are all unique. thanks!
  14. 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.
  15. 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!!
×
×
  • Create New...