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.
Best answer by Michael Woodward
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!
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.
@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.
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.
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!).
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.
@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.
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.
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
After making that change, export the Federation Metadata XML
Import to Metallic
upload the SP metadatafile to the Azure app
edit the Metallic Attributes to look for user.groups
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
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.
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.
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!
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!
We use 3 different kinds of cookies. You can choose which cookies you want to accept. We need basic cookies to make this site work, therefore these are the minimum you can select. Learn more about our cookies.