I want to set up TFS permissions to better reflect the responsibilities and levels of clearance of different roles within my organization; I'm finding that the default Reader and Contributor groups are too coarse-grained for my needs (and too loosely named).
To keep maintenance overheads to a minimum, I'm therefore thinking of replacing the Contributor and Reader groups with my own groups, but... is there any negative side effect of deleting those two groups? Does any part of TFS rely on them being there?
You should be fine. The built-in groups at the project level are for convenience only.
(This is NOT true of some of the server-level groups like TF Valid Users and TF Licensed Users. Maybe TF Service Accounts as well, I forget. These "well known groups" play a specific role in internal TFS operations. Delete them and the system won't work, even if you recreate them exactly as they were, because the GUIDs won't match.)
Just make sure that if you remove the Project Administrators group, you still have admin privileges inheriting from another group (eg TF Admins), otherwise you'll find yourself in a catch-22 situation. If you do get stuck by accident, know that local admins on the application tier machine are "TFS super-admins" who can bypass all security checks and put things back in order.
-EDIT-
One thing you will have to do is manually grant permissions to the new groups in Sharepoint and Reporting Services. I'd recommend downloading the TFS Admin Tool -- makes these tasks much simpler.
Related
I'm exploring options for securing some Azure resources within a subscription from tampering, even by subscription owners.
The intent is to standardize our subscriptions which are used by other teams for their engineering. We've considered giving teams custom RBAC roles similar to Owner and Contributor, but slightly reduced--however we've found this approach to be high friction and not to cover 100% of our scenarios. In some cases excluding a permission is fine--in others we need to grant them those permissions but restrict them from being used on our resources.
Our preferred design is to create a resource group of a known-name in each standardized subscription, place the resources users aren't allowed to modify or delete in the group, and explore options to prevent subscription owners from tampering with that RG or its resources.
So far we've explored most options we're aware of:
excluding the action/permission isn't an option as the users need those actions/permissions to manage other resources of the same type (i.e. denying users the ability create/modify/delete resource groups isn't viable)
defining an Azure Resource Policy to either deny all operations on the RG (which doesn't appear to function)
defining an Azure Resource Policy to require our standard resources -- this still does nothing to prevent deletion
Blueprints (in Preview) to create a locked (with some kind of lock other than a Resource Lock?!?) RG and apply deny assignments
Other options begin to get "sloppy". They leave gaps, or create significant complexity. Such as...
Relying on Policy to report (and possibly redeploy) when required resources were destroyed
These resources are security and compliance related--Policy can eventually detect their absence, but the gap between deletion and detection leads to these subscriptions being potentially tainted
Denying our users the resource lock permissions, so we can exclusively lock our RG and they are unable to unlock it
When the RG is unlocked there is no protection -- so we would need to coordinate unlocking it, applying updates, relocking it, and re-verifying that nothing else snuck in while it was unlocked
Give our teams a single RG per subscription and only grant them permissions at the RG level
This may have merit if RGs could be nested -- and perhaps is one of the few viable options, but taking away Resouce Group management from Azure engineers feels wrong and would likely lead to RGs being 'bloated' with multiple deployments as well as
Blueprints may be an option, but raise similar questions around coordinating the unlocking and relocking of resources
And, Terraform is our IaC platform -- Blueprints are in some ways another layer of IaC, so while we may get this to work it will require some analysis to use Blueprint for just the minimum to create protections and Terraform to continue to do the bulk of the work
After learning more about Azure Policy I'm gaining the understanding that it's not capable of setting policies to prevent deletion. It can define conventions for creating or updating resources, it can create resources if they are absent, but it doesn't trigger during deletion and so resources required by Policy cannot be protected by Policy.
Overall this seems somewhat counter-intuitive--as delete operations are a /write permission just like create and update.
So overall I don't believe Policy is actually a permissions component. It lacks any context of who is performing an action and instead effectively is good for saying "if you do X it needs to meet criteria Y". And not saying "your subscription is required to comply with X".
This is surprising--does Azure not have any way of setting resource-level permissions at the Subscription level or above?
After communicating with our Azure contacts this is a known limitation. Presently there is currently no way to retract permissions once granted. I.e. if you grant a user the ability manage resource groups you can not deny them those permissions to a specific instance.
There are some half-baked abilities in AWS Blueprint, which can deploy a Resource Group with an RBAC Deny Assignment (only available via Blueprints). When assigning the Blueprint the "lock" is actually an RBAC Deny -- not a Resource Lock (confusing?).
Hoever they explicitly block that permission from being inherited. So while the resource group itself is "ReadOnly" nothing within it is. Using ARM templates deployed via Blueprints may support this -- but in our case that would involve rewritting months of work.
Hopefully Microsoft will add Deny Assignments directly to RBAC. They have the API and ability but are keeping it hidden/locked at the moment.
I want a group of people to be able to completely manage a subscription, including managing access to resources within it, except for managing the subscription itself. So (for example) when a new resource group with a storage account is added to the subscription, I want them to be automatically (by inheritance) have all rights to the storage account, including the right to give people roles on that storage account. I just don't want them to be able to give other people roles on the subscription itself, so no adding administrators to the subscription etc.
Is a role (or combination of roles) built-in that I can use for that? Will I have to look into creating a custom role, or is what I'm looking for not possible?
well, I might be wrong, but I dont see how this could be possible:
You want a user to inherit rights from subscription level (only way to get rights to a newly created resource group)
you want rights to assign permissions
you want to block rights to assign permissions on subscription level
so, essentially you are asking for 2 things that conflict. this would not be possible even when using Azure Blueprints, because you cannot block inheritance yet. so you cannot block rights on a specific level, you can only block rights on that level and all "downward" levels
We are a software company so we setup solutions for the other companies. I guess we are not unique in this regards :) so I would like to know if we should create a new subscription each time or just a resource group.
Requirements:
We should be able to bill each customer/project separably
They should be able to take control of their resources easily and move to another company
Managing them should not be a headache
What we have tried
We've tried adding a subscription for each customer. This way, we could just change the admin profile and they could completely move away from us.
The billing is also OK, since we receive a different email for each subscription, but managing them is becoming a real headache.
What I guess could work
From what I read, I guess we could work with resource groups instead of subscriptions and handle the billing part with tags (haven't tried it yet. can we?) but then I'm afraid of not being able to move it to another subscription when they've asked us.
Is it even possible? How easy is that? Does it envolve contacting support?
Has anyone tried it?
I would advise against billing using resource groups and tags. The reports are a real mess and 100% unusable. Also, its a lot of extra work for nothing (seriously, do you care if you have 1 subscription or 10?) and adds no real benefit.
Also, you can move resources across subscriptions of different tenants. Best way of handling this is doing a subscription move. That way you dont have to do anything else. They just link your subscription to another tenant and you are good.
I'm talking from a perspective of administering dozens of subscriptions, and believe me, if you move away from subscriptions to resource groups (as a billing\security boundary) you will get completely devastated by the increased complexity of what you are doing.
In my experience working with organisations that provide similar hosting services to customers, I'd say resource groups is the way to go to avoid too much segregation. It's easier for you to keep control of the resources as well as keeping the cost low if you decide to use shared compute resources such as Application Gateway, DDOS protection, etc.
Bear in mind that depending on what level of permission you're giving to your clients, they might have access to information from other clients, so it's important to come up with a good security and governance plan for the Azure environment and strictly limit what they can access.
Moving things from one subscription to another is easy as long as you're using resources within the supported move list. Check the list below:
https://learn.microsoft.com/en-us/azure/azure-resource-manager/resource-group-move-resources
You don't have to open a ticket with Microsoft to move these resources and the move can be easily done through the portal interface as long as you select all the resources and it's dependencies and you have access to both subscriptions. If your client decides to move their stuff to their own Azure subscription, they will have to give you permission on that. If the resource you're trying to move is not in the supported list, not even Microsoft can move that.
From a billing perspective, I'd say separating by RG and using tags is the way to go as that can be easily filtered in your exported Azure consumption usage report.
I need to build an application that manages users and I thought that it will be nice to follow an existing management model, like the one used by Windows or linux, that has users, groups, permissions etc.
I couldn't find any place on the Internet to get explanations about how to implement this.
My application is a web application, probably asp.Net (less important the technology) that manages users. I have few levels, for now system administrators, power users, group managers and simple users.
Each level offers privileges, like power users may see all the users, may promote a user to be up to group manager, may degrade a user (with less powers than his) etc.
There is any place where I can read about how to implement such system?
Probably using the ASP.NET membership provider will work for you. You can use the SqlMembershipProvider which stores the security information in a Sql Server database. If you need more advanced features (and probably more secure), you can use Active Directory or ADAM with the ActiveDirectoryMembershipProvider. The ASP.NET membership provider model is customizable and you can implement your own provider, but the existing ones are quite powerful.
We are trying to create a SaS based portal using Liferay 6 for multiple (non related) organizations. And we want to go for a approach where we can generate these organization setup automatically based on user information.
We may require to have separate domains/websites for each organization.
As of now I have thought about two options for this
Portal Instance
Organizations
As per my understanding, i think this can be achieved by both of the above approaches. I would like to know your experience on both of these approaches on following points.
Which one would be easy to administer in long run
Which one can be easily programmed to create new setup automatically.
What about data security related to keeping in one portal instance vs multiple instance (is there any such thing?? not sure)
Any other approach to this?
Simple answer would be Portal Instances, since it was built for multi-tenancy.
Benefits to this approach would be that there would be segregation of data. Each instance maintains its own collection of users, communities, blog entries, etc.
Administration wise, there will be 1 account, the omni-admin, that can access all of these instances. On top that, each instance could have its own administrator that admins that particular instance.
Also, I don't believe using organizations will allow you to have separate domains for them.
Also going forward in Liferay 6.1, Organizations don't have pages only Sites have them, though we can mimic the behaviour with Sites.
Hope this helps.
I'm using Organizations for multiple sites, none of them sees each other, each one have their own users, roles, sections and communities.
Apache and Liferay virtual hosts url's makes the proper redirects to each organization home page.
For the admin I think is easier because in one control panel you can manage everything, or just the "scope" you want.
About using Instances, check the procedure to configurate them and see if you find it possible to create new ones automatically. Not very sure about that for organizations either, but having to touch portal-ext.properties may be worse towards automatization.
Regards