Passwordstate with Azure Application Proxy and SAML SSO

[Roman]

Hope someone can help me out with an issue I'm having with setting this up.

I installed and configured Passwordstate 9 and confirmed it's all working internally. Great.

Then I configured the Azure Application Proxy with SAML SSO, based on this Click Studios Blog article: https://blog.clickstudios.com.au/saml-authentication-with-azure-ad/, using the Azure Application Proxy URL (https://<blabla>.msappproxy.net/logins/saml/default.aspx) as "Your Passwordstate URL". That did not work out: "AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application"

Ok then. So I added the internal URL (i.e. keeping the above one in the list of reply URLs) as reply URL as 'default reply URL' (so the full https://<internalFQDN>/logins/saml/default.aspx). That didn't work either.

Still keeping both but changing to the Azure App Proxy one as default: same lack of success.

Using only the internal one: also not working.

 

I'm hoping someone that is more fluent in SAML may have worked out how to configure this properly and might be able to provide some guidance? 😐

 

I thought I had gotten this to work last night as I could login/logout using SAML. But when I tried to connect again this morning, I was greeted with that reply URL error message again?!

 

Would be grateful for any assistance.

[Roman]

Hi all,

 

I got this to work in our lab environment and thought I'd share some of that setup.
We have not setup the app service yet, so I can't comment on that.

This isn't a full guide on how to configure Azure AD, Enterprise Applications, the Azure App Proxy Connector or anything like that. It's just the settings that worked for us to make the Passwordstate web interface accessible to external users via the Azure Application Proxy with SAML SSO and Conditional Access policies.

 

As "<BaseURL>" we'll be using "https://passwordstate-<account>.msappproxy.net" where <account> is whatever Microsoft is using for your account there. Obviously you can change 'passwordstate' to something else as well.

 

Azure - Application Proxy configuration

We configured the Azure Application Proxy with identical domain names for internal and external users to ensure links sent our by Passwordstate will just work:

Internal Passwordstate URL: <BaseURL>

External Passwordstate URL: <BaseURL>

 

Pre Authentication is set to Azure Active Directory. We want SAML SSO, after all.

We enabled HTTP-Only, Secure and Persistent Cookies in our lab environment. However, when it comes to Persistent Cookies, you may want to change that to No for a production environment.

 

As we're using the same URLs for internal and external there's no need for URL translation, so we disabled it for Header and Application Body.

 

Azure - Single sign-on configuration

Basic SAML Configuration

Identifier (Entity ID): <BaseURL>

Reply URL (Assertion Consumer Service URL):

1. <BaseURL> Tick the Default checkbox on this one
2. <BaseURL>/logins/saml/default.aspx

Sign on URL: <BaseURL>

Relay State: <BaseURL>/logins/saml/default.aspx

Logout URL: <BaseURL>/?appproxy=logout

 

Attributes & Claims

Unique User Identifier: user.userprincipalname

We didn't change any of the other ones.

Note that you can use user.mail, as per Clickstudio's own Blog. We switched to userprincipalname as we are testing with accounts without email addresses, so this made more sense for us.

Using userprincipalname also requires you to reconfigure Passwordstate and under System Settings -> Authentication Options check the UserPrincipalName option under "Select which field in Passwordstate you want to compare against the SAML Response's Name Identifier - NameID".

 

For the remainder of the Azure (and Passwordstate SAML) configuration, just follow Clickstudio's guide: https://blog.clickstudios.com.au/saml-authentication-with-azure-ad/

Ensure to reconfigure your Base URL in Passwordstate under System Settings -> Miscellaneous to match your <BaseURL>.

 

Certificates

We created a certificate for our internal server using our existing, internal CA.
Doesn't cost anything and we have more control over certificate lifetime and auto-renewal.

 

If you go with a 'proper' custom domain setup (e.g. using https://passwordstate.<domain> for internal and external URL) for the App Proxy, you'll need a public CA certificate to be imported into the App Proxy.

 

Internal DNS

We created a DNS Zone on our internal DNS server to ensure internal systems resolve passwordstate-<account>.msappproxy.net to the internal IP of the Passwordstate server. You can probably force internal users through the Azure App Proxy as well, but at the very least the Azure App Proxy (and the internal Passwordstate server itself) needs to be able to resolve the name to the internal IP of the server or it won't be able to connect.

 

IIS

Ensure to configure your IIS Bindings to use the passwordstate-<account>.msappproxy.net FQDN and assign the correct certificate.

We also disabled Windows Authentication for the passwordstate site as it's not required.

 

 

That's it, SAML SSO should work and you can configure your Conditional Access policies as required.

As mentioned, this isn't a full guide. You need to have your Azure Application Proxy Connector setup and operational, it needs to be able to access the Passwordstate server, the relevant outbound ports/IPs/FQDNs need to be allowed on the firewall, etc.

 

I hope this helps someone else to get their setup working.

[Jayson]

@Roman

 

Appreciate you posting your specifics. We're currently trying to get pre-auth to work behind AAP and have been unsuccessful, we keep getting stuck in a SAML auth loop. We have SAML and AAP working fine without pre-auth though.

 

Would you mind posting your contents of the following. Azure Active Directory -> App Registrations -> Passwordstate -> Authentication -> Web Redirect URIs

 

Our setup is identical to yours from what I can tell, only difference being we're using a custom domain name w/ a CNAME/cert so I'm starting to run out of ideas.