Jump to content

RobMiller

Members
  • Posts

    47
  • Joined

  • Last visited

Everything posted by RobMiller

  1. Got it. When I deleted the proxy, I discovered that my SSO wouldn't work even without it. Changing the Reply URL (Assertion Consumer Service URL) in Azure to default to https://pws.mycompany.com/logins/saml/default.aspx fixed it for me. Everything else is the same as I posted above.
  2. Hello all! I am trying to get PWS working with Azure App Proxy and SSO. We have the proxy working, albeit a bit slow with grumbling from the herd about performance and timeouts, but enabling SSO is just not working out. It seems I am always in a SAML loop where it just keeps refreshing every second or two with a slightly different string in the URL and fails. Here are the sanitized details of the configuration. PWS Server URL: https://pws.mycompany.com Server IP: Public IP in a DMZ, we’ll just call it 123.123.123.123, so no NAT is in play Access: Although it has a public IP in a DMZ, it’s actually restricted via ACL, and it’s not externally accessible except via VPN, or other hosts at the facility For Phase 1 here I added the Enterprise App to Azure, and installed a connector close to the pws server. I adjusted the host file on the Azure Connector server so that it continues to resolve pws.mycompany.com to 123.123.123.123 regardless of public DNS. I changed public DNS for pws.mycompany.com to a CNAME pointing to pws-mycompany.msappproxy.net as per the Proxy config in Azure. Proxy config: Internal URL: https://pws.mycompany.com External URL: https://pws.mycompany.com Pre-authentication: Passthrough (for now until I get it working) Backend Timeout: Long Use HTTP-Only Cookie: No Use Secure Cookie: Yes Use Persistent Cookie: Yes Translate URLS: Headers and Body set to No Success!! Proxy works. It’s definitely slower than going direct. If you let it sit on a password list for maybe 30 minutes, then try to grab something, it fails. You have to click to another folder and back. Seems like the session dies or something and then you need to kick start it. It is functional, but people grumble about lost time as it takes them longer. Anyways, I’m thinking maybe SSO would help with some of the timeouts and such. So let’s get that going. Phase 2: SSO I followed the clickstudios guide for SSO, but that doesn’t include proxy stuff, so I am not sure if anything should be different for that.   Azure SAML Config: Identifier (Entity ID): https://pws.mycompany.com Reply URL (Assertion Consumer Service URL) 1: https://pws.mycompany.com (Default checked) Reply URL (Assertion Consumer Service URL) 2: https://pws.mycompany.com/logins/saml/default.aspx Sign on URL: https://pws.mycompany.com Relay State (Optional): https://pws.mycompany.com/logins/saml/default.aspx Logout Url (Optional): https://pws.mycompany.com/?appproxy=logout Attributes & Claims Givenname: user.givenname Surname: user.surname Emailaddress: user.mail Name: user.userprincipalname Unique User Identifier: user.mail Then in PWS: I copied in the Base64 cert from MS, set it to SHA256, and copied in the 3 links from Azure for the app. IDP Target URL: https://login.microsoftonline.com/37******************* IDP Issuer URL: https://sts.windows.net/37******************* Audience Restriction: https://pws.mycompany.com Single Logout URL: https://login.microsoftonline.com/37******************* I also set: Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier – NameID: To Email Address This config just doesn’t work. When I test from Azure, it starts looping, it’s like it keeps trying to authenticate but can’t. I have tried all kinds of combos. Spent several hours trying different things, changing out pws.mycompany.com for pws-mycompany.msappproxy.net in spots. I don’t know. No combo I have tried allows for PWS to authenticate via SSO. So I imagine I have something wrong, and I suspect it’s due to the proxy. I have previously set up SAML to Okta before with PWS, was easy. My next step I guess is to remove the proxy, and try SSO alone. The proxy works fine without SSO, so I need to see if SSO works without the proxy. But ultimately I would like them both to work together. If anyone has any experience with this, and can point out any issues they see, I sure would appreciate it. TIA!
  3. I just completed our migration to V9 with an App Server for self destruct and mobile access. Passwordstate itself is now blocked from offsite access. I guess we are going to setup a 2nd Passwordstate server and move our own critical infrastructure creds to this 2nd one and it will not have mobile access, self destruct, or external access. It seems we aren't allowed however to setup a 2nd instance per the licensing so we will be limited to 5 free user accounts on this second deployment. But in the end, the risk was too great for us to have both client passes, as well as our own infrastructure passes for our private cloud services in the same basket. I wish Passwordstate would allow us to deploy a second instance for the same users we already pay for.
  4. That would be far too difficult to use an IP based ACL on the self destruct portal for us. MSPs are getting hit left and right. We have to do all we can to plan for a breach via a compromised system and one with open inbound access from the internet is certainly a candidate to be compromised. I'll have to carefully consider our options here since there is no way to disallow communication from the self destruct portal.
  5. I understand that I can enable or disable mobile access. I am still concerned that the app server is not isolated like the previous self destruct portal and if compromised, has full access to passwordstate. Specifying different URLs in the config doesn't actually disable the app servers ability to access password state if it's compromised via a vulnerability. Our requirements: 1. An App Server for Self Destruct open to the internet. This server should have zero ability to access passwordstate, even if compromised and an attacker has bypassed authentication in some way. We would like to block this servers ability to even initiate connections to passwordstate at the network level. 2. A Mobile Access App server behind a VPN that does allow access to passwords via passwordstate Can you provide guidance on how we achieve #1 so that if an attacker somehow bypassed auth and fully compromised the app server for self destruct that they wouldn't have access to passwords in passwordstate? Can the App Server still work for Self Destruct if it's firewalled off from the passwordstate server like was previously possible with self destruct portal?
  6. So I can have one app server that only works for mobile access, and nothing else. And then I can have another one for self destruct and nothing else? The self destruct portal will be unable to be exploited and then used to access passwords? My goal is to have self destruct for clients without a VPN, and then no ability to access passwords without a VPN. Meaning that self destruct portal simply cannot be used in any way, even if breached, to attack the passwordstate server. That's still possible? The post above leads me to believe it's not possible. To be clear, we want mobile access, but we want to require a VPN for it, and we want the self destruct portal to have no ability to access passwords that aren't currently on it waiting to self destruct.
  7. We were just about to migrate to a separate self destruct portal and VPN only access to the passwords via mobile. I just upgraded to V9 in prep and was reading about the changes and see that is apparently no longer possible in V9. What a huge disappointment. So now if we want to use self destruct, and if we want mobile access, we have no choices. Open it up to the internet and don't use a VPN. I sure would like to understand the rationale behind greatly limiting our ability to secure this sensitive data. This forces us to simply trust that Click Studios won't have any vulnerabilities in their code. Not sure I even understand the point of a self destruct portal anymore since it also handles mobile access to Passwordstate.
×
×
  • Create New...