When using Azure AD as your identity provider (IDP) and when you are extending your on-premise High privileged accounts to different Cloud destinations. It may come on handy to configure CyberArk (when you have this in place) to use Azure AD as your IDP for access to your managed Password Vaults.
The biggest reason to use a tool like CyberArk is that you would like to minimize the attack surface of your highest privileged accounts, or maybe you want to get rid of all the administrative accounts in your environment. And only give access to the people who need it at the time they need it. The High privileged accounts can be in al sorts of different places, spreading from Azure to Active Directory to Unix to AWS and so fort.
Why use Azure AD as your IDP?
When you have Azure AD in place why not use this as your IDP. The total benefit of this is much bigger then when you just use a simple ADFS saml2.0 or the PrivateArk Client which uses plain LDAP as a authentication source.
The four biggest benefits are;
- You are able to use use on-premise managed identity which are completely traceable when using a identity management tool like Okta, OneLogin or Ping Identity.
- You are able to benefit from conditional access from Azure Active Directory.
- You can enforce stuff like MFA, Device authentication, Domain based and Location based authentication.
- You can setup Passwordless authentication based on a token from the Azure authenticator app or a physical token like Yubikey, Titan or Thetis.
How to setup CyberArk with Azure AD
Like i mentioned before CyberArk has the ability to use SAML 2.0 for authentication. So why not use this to connect to Azure AD.
Tips and tricks:
|Assertion||PAS supports only one assertion. Make sure only one assertion is configured in your IdP.|
|Assertion Consuming URL||For SSL v9 – https://<PVWA DNS or IP>/PasswordVault/auth/saml For SSLv10 – https://<PVWA DNS or IP>/PasswordVault/api/auth/saml/logon|
|SAML Identity Location||Make sure that your IdP specifies Identity in the NameIdentifier element of the Subject statement. The user name is located in the <Subject> statement of the assertion.|
|Secure hash algorithm||Use one of the following hash algorithms: SHA256 (recommended) SHA1 This algorithm is used to sign the responses.xml.|
|Signed requests||For sending signed requests configure PAS to send signed requests in the saml.config, as described in To support signed requests:. If signed requests are not configured in the saml.config, make sure the IdP is set to accept non-signed requests.|
|User name||Configure the IdP to return the user name inside the NameID tag. PAS supports the unspecified NameID format.|
|Audience||The value used by the IdP to identify the PVWA as a relying party. The value must be identical to the ServiceProvider Name configures in PAS.|
You will also need access to the webconfig file and App settings. For Azure AD it is best to be Global Administrator or Application administrator.
Next up is to configure a SAML 2.0 application within Azure AD:
1. Go to Azure AD, click Enterprise applications select new application.
2. In the new Application Gallery search for CyberArk, click on CyberArk SAML authentication.
3. There will be a new screen available and give you’re application the name you want to; something like CyberArk SAML Authentication
4. After this we click on the application we have just added to our Azure AD tenant.
5. Click on single Sign on in the left side menu, click on SAML and a new screen will appear.
6. Go To Cyberark
Configure SAML authentication in CyberArk PAS
To configure SAML in PAS, you need to configure the PVWA and the PasswordVault web.config file.
To configure the PVWA:
- Log on to the PVWA.
- Click Administration > Configuration Options > Options.
- In the Options pane, expand Authentication Methods, and click saml.
- In the Properties pane, set the following fields: Enabled Set to Yes. LogoffUrl specify the logoff page of your IdP . In our case this should be the url of our Azure AD application. (https://login.microsoftonline.com/xxxyyy-xxxxyyyy-xxxxyyyy-xxxxyyyyy/saml2
- In the Options pane, right-click Access Restriction, and then select Add AllowedReferrer.
- Go to the Properties pane, in BaseURL, specify the URL of your IdP. (In our case it would be https://sts.windows.net/xxxyyy-xxxxyyyy-xxxxyyyy-xxxxyyyyy/
- Click Apply to save the new configurations.
To edit the configuration file: In version 11.3 and above
- From the PasswordVault installation folder, the default location is \Inetpub\wwwroot\PasswordVault, make a copy of the saml.config.template file, and rename the copy to saml.config.
- Edit the saml.config file as follows: Parameter Description SingleSignOnServiceUrl The login URL of your IdP. Like we did before Certificate The base 64 text representation of the certificate that is configured for your IdP as the SAML response signing certificate. This is used by the PVWA to verify the authenticity of the responses. PartnerIdentityProvider Name Enter the IdP identifier that enables the PVWA to identify the IdP. Also known as the EntityID of the IdP. ServiceProvider Name The Issuer string that enables the PVWA to identify itself to the IdP. Also known as the EntityID. It must be identical to the Audience defined in the IdP.
- To support signed requests:
- Add the following to the ServiceProvider element:
All settings you need to configure are at your service from Azure AD
<LocalCertificates> <Certificate FileName="<local certificate path>" Password="<the password you set for the certificate>" /> </LocalCertificates>
- Add the following attribute to the PartnerIdentityProvider element: SignAuthnRequest=”true”
To support encrypted assertion:
- Add the code following within the ServiceProvider element:
<LocalCertificates> <Certificate FileName="<the exported certificate path>" Password="<the password you set for the certificate>" /> </LocalCertificates>
- Supply the certificate’s public key to the IdP to encrypt the assertion.
To support force authn, add the following attribute to the PartnerIdentityProvider element:
7. Open the web.config file located in the installation folder, and in the app Settings tag, set the UseNewSAMLSolution parameter to Yes.
- Click Block access and click Select.
8. Go back to Azure AD
Finalizing the Azure AD configuration.
Go to the CyberArk Enterprise application and fill in the Identifier and Reply URL as below
This should be it.
If it is not working you can check if the SAML responses are correct. the should look something like on the CyberArk side.
<samlp:AuthnRequest xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_bec424fa5103428909a30ff1e31168327f79474984" Version="2.0" IssueInstant="2007-12-10T11:39:34Z" ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST" AssertionConsumerServiceURL="https://localhost/Passwordvault/auth/saml"> <saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">PasswordVault </saml:Issuer></samlp:AuthnRequest>
And on the IDP side:
samlp:Response ID="_dd89c43c-ac4d-4f11-8215-d72b9b04f465" Version="2.0" IssueInstant="2014-09-18T08:42:38.873Z" Destination="https://localhost/SAMLAPP/Consume.aspx" Consent="urn:oasis:names:tc:SAML:2.0:consent:unspecified" InResponseTo="_d03ece3f-6875-452f-8a81-4e4f498cce8f" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"> <Issuer xmlns="urn:oasis:names:tc:SAML:2.0:assertion">http://www.yourserver.com/adfs/services/trust</Issuer> <samlp:Status> <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success" /> </samlp:Status> <Assertion ID="_a7c66b16-f1cd-4791-8a92-5c05fd879356" IssueInstant="2014-09-18T08:42:38.872Z" Version="2.0" xmlns="urn:oasis:names:tc:SAML:2.0:assertion"> <Issuer>http://www.yourserver.com/adfs/services/trust</Issuer> <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"> <ds:SignedInfo> <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256" /> <ds:Reference URI="#_a7c66b16-f1cd-4791-8a92-5c05fd879356"> <ds:Transforms> <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature" /> <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#" /> </ds:Transforms> <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256" /> <ds:DigestValue>DWu0VvTPAIFkWRcv8jKrrxwYJOY=</ds:DigestValue> </ds:Reference> </ds:SignedInfo> <ds:SignatureValue> </ds:SignatureValue> <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#"> <ds:X509Data> <ds:X509Certificate> </ds:X509Certificate> </ds:X509Data> </KeyInfo> </ds:Signature> <Subject> <NameID>Administrator@mycompanydom.local</NameID> <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer"> <SubjectConfirmationData InResponseTo="_d03ece3f-6875-452f-8a81-4e4f498cce8f" NotOnOrAfter="2014-09-18T08:47:38.873Z" Recipient="https://localhost/SAMLAPP/Consume.aspx" /> </SubjectConfirmation> </Subject> <Conditions NotBefore="2014-09-18T08:42:38.868Z" NotOnOrAfter="2014-09-18T09:42:38.868Z"> <AudienceRestriction> <Audience>PasswordVault</Audience> </AudienceRestriction> </Conditions> <AuthnStatement AuthnInstant="2014-09-18T08:17:57.154Z" SessionIndex="_a7c66b16-f1cd-4791-8a92-5c05fd879356"> <AuthnContext> <AuthnContextClassRef>urn:federation:authentication:windows</AuthnContextClassRef> </AuthnContext> </AuthnStatement> </Assertion> </samlp:Response>
Thanks for reading and also check out my other blogs.