commvault.com commvault.com
Solved

Metallic Azure AD SAML

Michael Woodward
Rank
Userlevel 3
Badge +9

Hi everyone,

I’m looking to setup SAML for a customer using Azure AD as the identity provider.
I’ve set it up in my lab (Metallic Subscription plus Azure AD), the default mapping of users works to a role that’s specified General Tab of the Identity Server.  

Is there a way to have Azure AD detect the group membership and apply it to a Metallic User Group? I’ve Tested based on what I understand the documentation to be, but I’m probably missing something fairly fundamental.  

Do I have to set a custom SAML attribute to map the groups through or is there another way?

Thanks in advance.

icon

Best answer by Michael Woodward 5 September 2022, 05:28

View original

16 replies

Ryan Carr
Rank
Userlevel 2
Badge +5

Hi Michael 

I think this document would be the winner for you 

https://docs.metallic.io/metallic/97758_mapping_saml_attributes.html

As its states, by default Metallic is waiting to get the NameID element from the IdP response to match and allow access. 

You can use a SAML tracer tool as a Chrome add on or look for another tool to see what I’m showing below. 

Here is the XML of what Metallic received when i logged into a lab 

you can see the NameID is the top one sent (I’ve X’d some info). Below you have the other attributes 

 

  <Subject>
   <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">ryanc@XXXXXXXXXX.com</NameID>
   <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="cv_8edbbb83-2e4f-45df-af47-eecfa9ea789a" NotOnOrAfter="2022-08-11T10:12:55.369Z" Recipient="https://mXXXX.metallic.io:443/webconsole/samlAcsIdpInitCallback.do?samlAppKey=M0VGRjUyMEI4OUFFNDNB"></SubjectConfirmationData>
   </SubjectConfirmation>
  </Subject>
  <Conditions NotBefore="2022-08-11T09:07:55.369Z" NotOnOrAfter="2022-08-11T10:12:55.369Z">
   <AudienceRestriction>
    <Audience>https://m100.metallic.io:443/webconsole</Audience>
   </AudienceRestriction>
  </Conditions>
  <AttributeStatement>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
    <AttributeValue>4a3e45f6-c53e-42d3-94a3-6fb78898deea</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
    <AttributeValue>b6aa32d8-2d86-4067-8915-dc4a26889531</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
    <AttributeValue>https://sts.windows.net/4a3e45f6-c53e-42d3-94a3-6fb78898deea/</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
    <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
    <AttributeValue>Ryan</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
    <AttributeValue>Carr</AttributeValue>
   </Attribute>
   <Attribute Name="user.displayname">
    <AttributeValue>Ryan Carr</AttributeValue>
   </Attribute>
   <Attribute Name="user.groups">
    <AttributeValue>0baccd9d-2f0b-45df-a6ce-2e828bcd857b</AttributeValue>
   </Attribute>
   <Attribute Name="user.fullname">
    <AttributeValue>Ryan Carr</AttributeValue>


As a required claim the SAML app needs to have the NameID
 

 


Following the document and changing the attribute to look for groups in your case and validate against that would give you the functionality you need. 

Speaking personally. If your adding the groups and users yourself to the app to allow access., unless they are all from different domains then looking for the email address of users to log in would be a simpler system. 


Let me know if that helps 


Ryan 

Onno van den Berg
Rank
Userlevel 7
Badge +19

@Michael Woodward not sure if this is what you are looking for but you push AD groups into the SAML claim. We use OKTA so it might work a little bit different but you can use the group membership that is taken out of the claim and for example connect roles to a Commvault group which is mapped to the group that is part of the SAML claim during user logon. 

Michael Woodward
Rank
Userlevel 3
Badge +9

 

Thanks Ryan,

I think I'm on the right track, in my lab I've added the claim for groups (user.groups) to the SAML request which as your sample below then displays as the Object ID of the group in AzureAD.

What I’m struggling with is how to map the attributes in Metallic to a group.

 

My SAML response is below.

       <Subject>
            <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">XXXX@XXXXXXX.onmicrosoft.com</NameID>
            <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
                <SubjectConfirmationData InResponseTo="cv_d9e2cac0-0acc-45e9-9a67-31cb68fefb6b"
                                         NotOnOrAfter="2022-08-11T13:45:24.836Z"
                                         Recipient="https://m4.metallic.io:443/webconsole/samlAcsIdpInitCallback.do?samlAppKey=NzI3QUM0NDYwM0YxNDA0"
                                         />
            </SubjectConfirmation>
        </Subject>
        <Conditions NotBefore="2022-08-11T12:40:24.836Z"
                    NotOnOrAfter="2022-08-11T13:45:24.836Z"
                    >
            <AudienceRestriction>
                <Audience>https://m4.metallic.io:443/webconsole</Audience>
            </AudienceRestriction>
        </Conditions>
        <AttributeStatement>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>c5d4827a-674f-49d9-a731-8c4b0b4a0855</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>7cff689c-739f-4e4c-a8a8-e315819b1b32</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
                <AttributeValue>Metallic Test</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/ws/2008/06/identity/claims/groups">
                <AttributeValue>495cb3ee-b446-4620-a570-bdddae3a8811</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/c5d4827a-674f-49d9-a731-8c4b0b4a0855/</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
                <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
                <AttributeValue>Metallic</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
                <AttributeValue>Test</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>xxxxxx@xxxxx.onmicrosoft.com</AttributeValue>
            </Attribute>
        </AttributeStatement>

To map this to the group, do I add a attribute for the user group in the attribute mappings to make it valid?
 

 

As an example, I have 3 Groups assigned to the App each with a different desired Role in Metallic

 

I’ve got the corresponding groups setup in Metallic but I can’t make the last link in how to get the SAML group field to map to a group in Metallic (but I've never done this before either!).

 

Michael

 

 

Hi Michael 

I think this document would be the winner for you 

https://docs.metallic.io/metallic/97758_mapping_saml_attributes.html

As its states, by default Metallic is waiting to get the NameID element from the IdP response to match and allow access. 

You can use a SAML tracer tool as a Chrome add on or look for another tool to see what I’m showing below. 

Here is the XML of what Metallic received when i logged into a lab 

you can see the NameID is the top one sent (I’ve X’d some info). Below you have the other attributes 

 

  <Subject>
   <NameID Format="urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress">ryanc@XXXXXXXXXX.com</NameID>
   <SubjectConfirmation Method="urn:oasis:names:tc:SAML:2.0:cm:bearer">
    <SubjectConfirmationData InResponseTo="cv_8edbbb83-2e4f-45df-af47-eecfa9ea789a" NotOnOrAfter="2022-08-11T10:12:55.369Z" Recipient="https://mXXXX.metallic.io:443/webconsole/samlAcsIdpInitCallback.do?samlAppKey=M0VGRjUyMEI4OUFFNDNB"></SubjectConfirmationData>
   </SubjectConfirmation>
  </Subject>
  <Conditions NotBefore="2022-08-11T09:07:55.369Z" NotOnOrAfter="2022-08-11T10:12:55.369Z">
   <AudienceRestriction>
    <Audience>https://m100.metallic.io:443/webconsole</Audience>
   </AudienceRestriction>
  </Conditions>
  <AttributeStatement>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
    <AttributeValue>4a3e45f6-c53e-42d3-94a3-6fb78898deea</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
    <AttributeValue>b6aa32d8-2d86-4067-8915-dc4a26889531</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
    <AttributeValue>https://sts.windows.net/4a3e45f6-c53e-42d3-94a3-6fb78898deea/</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
    <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
    <AttributeValue>Ryan</AttributeValue>
   </Attribute>
   <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
    <AttributeValue>Carr</AttributeValue>
   </Attribute>
   <Attribute Name="user.displayname">
    <AttributeValue>Ryan Carr</AttributeValue>
   </Attribute>
   <Attribute Name="user.groups">
    <AttributeValue>0baccd9d-2f0b-45df-a6ce-2e828bcd857b</AttributeValue>
   </Attribute>
   <Attribute Name="user.fullname">
    <AttributeValue>Ryan Carr</AttributeValue>


As a required claim the SAML app needs to have the NameID
 

 


Following the document and changing the attribute to look for groups in your case and validate against that would give you the functionality you need. 

Speaking personally. If your adding the groups and users yourself to the app to allow access., unless they are all from different domains then looking for the email address of users to log in would be a simpler system. 


Let me know if that helps 


Ryan 

 

Michael Woodward
Rank
Userlevel 3
Badge +9

@Michael Woodward not sure if this is what you are looking for but you push AD groups into the SAML claim. We use OKTA so it might work a little bit different but you can use the group membership that is taken out of the claim and for example connect roles to a Commvault group which is mapped to the group that is part of the SAML claim during user logon. 

Thanks for the reply Onno,
I’ve got the groups claim added to the app, but I can’t for the life of me figure out that last piece to map it to a Commvault (or in this case Metallic) user group.

Onno van den Berg
Rank
Userlevel 7
Badge +19

We configured the OKTA to pull groups into the claim carrying a specific name. Within the identify configuration we enabled.
 

 

The remaining piece was to create the Commvault local group with the exact name that is used on the other side. This makes sure the user is provisioned within Commvault and is added to the right local group who is coupled to a specific role. 

Ryan Carr
Rank
Userlevel 2
Badge +5

Hi Michael 

Yeah Onno is on the right track. After speaking to my (much smarter) colleague @Mark Penny. he’s advised on the additional claims info.

Note the attributes and claims its only asking for user.groups as the value so you can remove the url stuff mentioned in the documentation (I’ll get a ticket raised to have it reviewed)



So going forward 


1.  edit the additional claims and user.groups. In there you can define to allow all groups or “Groups assigned to the application” so we’ll only use the 3 groups you’ve added to your app

 

  1. After making that change, export the Federation Metadata XML 
  2. Import to Metallic 
  3. upload the SP metadatafile to the Azure app
  4. edit the Metallic Attributes to look for user.groups
     

     

  1. Finally you want to create groups that match the Azure AD Groups associated with the App
    Open the AD group properties and copy the Object ID. Then use that name ID to create a new User Group in Metallic


you can then assign roles to those groups. 

Let me know how you get along with phase II

Ryan 

Michael Woodward
Rank
Userlevel 3
Badge +9

Thanks @Ryan Carr  and @Onno van den Berg for the comments,

I’ve been through and followed the steps and recreated the identity provider in Metallic, added the attribute mapping

Then created the groups with the object ID’s as the name.  These are local groups with the company\ before:

 SAML attributes are here:

<AttributeStatement>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/tenantid">
                <AttributeValue>c5d4827a-674f-49d9-a731-8c4b0b4a0855</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/objectidentifier">
                <AttributeValue>91b0fe62-f88e-4df0-ab1d-8d3f1d48fa5a</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/displayname">
                <AttributeValue>Metallic DBA</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/identity/claims/identityprovider">
                <AttributeValue>https://sts.windows.net/c5d4827a-674f-49d9-a731-8c4b0b4a0855/</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.microsoft.com/claims/authnmethodsreferences">
                <AttributeValue>http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname">
                <AttributeValue>Metallic</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname">
                <AttributeValue>DBA</AttributeValue>
            </Attribute>
            <Attribute Name="http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name">
                <AttributeValue>metallic3@XXXXXXXXX.onmicrosoft.com</AttributeValue>
            </Attribute>
            <Attribute Name="user.groups">
                <AttributeValue>e3855f9a-1e0a-43d2-b6e0-afc357e1b7cc</AttributeValue>
            </Attribute>
        </AttributeStatement>

Looking at one of the users that has authenticated via SAML it only shows the default group for the identity provider (Tenant Users):
 

 

Really appreciate the help so far. 

Michael

Ryan Carr
Rank
Userlevel 2
Badge +5

Hi Michael 

I was out on Friday for a wedding but as they we’re cutting the cake I was thinking about your issue 😁

so we know SAML works, its picking the users 

Reading the documentation can you delete the user that was succesful and change the name of that group from the app ID to the name and just see if it works or not. 

https://docs.metallic.io/metallic/95955_using_azure_active_directory_as_your_identity_provider.html

 

  • Verify that groups in Azure AD have the exact name as the Metallic user groups you want to map them to. If an Azure AD group does not have the exact name as the group you want to map it to in Metallic, complete one of the following:

    • Create a new user group in Metallic that has the exact name as the group in Azure AD.

    • Rename the Azure AD group to match the user group in Metallic.

 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Hi Michael 

I was out on Friday for a wedding but as they we’re cutting the cake I was thinking about your issue 😁

 

That’s some dedication!

https://www.linkedin.com/in/michael-struening
Michael Woodward
Rank
Userlevel 3
Badge +9

I agree @Mike Struening that is some dedication! I hope you didn’t spend too long thinking about SAM auth / mapping instead of enjoying yourself at the wedding @Ryan Carr !

Have followed the above and deleted all users that authenticated via AzureAD SAML and renamed all groups in Metallic to the same Display Name as the group in Azure AD

 

The user is still only being mapped through to the Tenant Users group  which is the default group defined on the identity provider.  
 

Thinking about the “exact” same name part of the link, I updated the name of one of my groups to have the same company\group (as below) but it still didn’t map through.
 

 

I have a support ticket open for my customer implementation of this, when I pointed Support to this community post they said they’d be in touch! 

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Sweet!  Can you share the case number so I can track it?

https://www.linkedin.com/in/michael-struening
Michael Woodward
Rank
Userlevel 3
Badge +9

Sweet!  Can you share the case number so I can track it?

Sure thing @Mike Struening 220803-35

Mike Struening RETIRED
Rank
Userlevel 7
Badge +23

Great, thanks!!

https://www.linkedin.com/in/michael-struening
Michael Woodward
Rank
Userlevel 3
Badge +9

To close this issue out, I had a session with support and a backend engineer late last week and we’ve now mapped everything out that we need, tested and implemented in production and it’s all working. I’ll put the key steps below as I know I'll end up searching for this again at some point.

  • The group claim in the SAML configuration in Azure AD needs to use the source attribute sAMAccountName

    You “could” customise the name of the group claim, but as we’ve got things working with the defaults I'm happy not to change it!

  • In Metallic the Identity Provider name should match the tenant name in Metallic and not anything else like domain names etc.
  • The custom attribute for the user group mapping should to be the URL for the claim name (if you change the claim name to a custom name then it would need to perhaps be different here)

  • Pre-create the user groups using the object ID of the group in Azure AD:

  • Users log in, they get mapped to the groups:  

     

  • When delegating the roles / permissions it’s easiest to delegate at the company level for each role so permissions get inherited down to the clients but you can be as granular as you like.

Then sit back and admire the beauty of it all working!

 

 

Damian Andre
Rank
Userlevel 7
Badge +23

Thanks for the follow-up @Michael Woodward - really useful information!

Michael Woodward
Rank
Userlevel 3
Badge +9

Thanks for the follow-up @Michael Woodward - really useful information!

No worries @Damian Andre, there is always something to learn!

Reply


Terms & ConditionsCookie settings