With the new Update Rollup 7 of Windows Azure Pack, we have a new feature that has been one of the top asks for the core services in our User Voice page.
This feature is best described as “Plan filtering based on AD Security Groups”. Before UR7, a Plan can have 2 visibility states: Public and Private.
A Public Plan is something that is visible to the tenants and is available for Subscription creation from the Tenant Portal.
A Private Plan is not visible to tenants. It can only be seen from the Admin Portal and only admin users can create subscriptions for tenants.
The limitations of this design is that a plan is either visible to all tenant users if public, or not visible to any tenant users at all if private. The ability for a user to have self-service is constrained by this mechanism since, if a Plan is Private, only an admin can create subscriptions from them.
We’ve been receiving a lot of feedback from customers and partners that there needs to exist a way wherein an administrator can target a set of users and provide them a plan without them losing this self-service subscription creation capability i.e. the admin shouldn’t have to manage every subscription creation process just because they don’t want certain users accessing certain plans.
We’ve also been receiving a ton of feedback about ACL’ing the WAP Tenant Portal such that not all authenticated users can use it. That means to say that the administrator can close that instance of WAP only to a specified group of users.
We’ve addressed both these requests in UR7 by tying Plan visibility to Active Directory Security Groups. With this update, an Administrator can specify which Security Groups a Public Plan should be visible to. Only members of that security Group(s) can see the plan in their tenant portal.
Note that I’ve marked two words in bold in the paragraph above. These are important points to note about this feature.
Plans are filtered by using the ‘groups’ claim in a user’s token. This means that this feature is applicable to instances that have Identity systems that can issue group claims as a part of the token. AD FS is my personal favorite and trusted enterprise Identity system, but this in general is enabled for any system that can issue group claims.
Regardless of if a plan has Security Groups associated with it, the feature will take effect only when the plan is made Public. Private plans will behave the same way as before with or without Security Groups associated with them.
Public plans that don’t have any Security Groups associated with them, will be visible to all users i.e. the same way as before this update.
So in short, the list of plans that will be available to the tenant user for subscription creation is sum of a list of plans that are public having no security groups associated with them and the ones that have Security Groups tied to them of which the user is a member of.
Neat! added functionality with existing ones not broken Let’s take a look at a scenario where this can be useful.
Let’s consider an organization where WAP with UR7 is stood up by the IT department to provide private cloud services. The organization has a HR and a Finance department that are both consuming the cloud. The IT department would like to provide a few dedicated plans to the HR department and a few dedicated plans to the Finance department so that users from either of these departments can login to the portal and can subscribe to the plans. There is a security Group for the HR department with a set of users in it. John is from Finance Department and Jane is from HR.
The IT administrators can now go into the Admin portal, and pick a Plan from the Plans table
In the Settings tab of the plan, they will see a section called ‘security group based filtering’ where they can enter a provide a list of Security Groups that can be associated with the plan.
They can go in and add a security group that for which this plan should be visible for, say in this case, the finance SG. Now, note that there are other Public Plans in the system as seen in the screenshot below.
So what anyone belonging to these Security Groups will be seeing, is a list with all these Public plans in addition to the filtered plans for their Security Group.
Now when, John logs in to the tenant side, he can see the Finance Plan as he is a member of the Finance SG but not the HR Plan.
Jane on the other hand can only see the HR Plan and not the Finance Plan.
When a neutral user, who is not a member of ANY of these security groups logs in, they will see all the Public plans, but not the HR or the Finance Plans.
So there you have it! you can now use this feature to provide the appropriate level of access to users for subscribing to plans!
If you’d like more information about configuring Security Groups with AD FS for users, please refer to my blog series at
And as always, keep that feedback coming through our User Voice page!