I want to create a "global" group, which I can use to grant access to different site collections.
I.e.: I can give readers rights to collections 1 and 3 and no rights to collection 2.
Is it somehow possible?
I tried to create the group in CA, but I can't see it in the groups management.
You can not create such groups as SharePoint groups have site collection scope. When your create the same group (with the same name) in two site collections they are still different (have different IDs). Only AD groups can be used across several different site collections.
Related
I have a O365 Group and a Team site but not Teams enabled.
In that site I have a list called Portfolio. I have a bunch of users added as owners and members of the O365 group and they are added in to SharePoint online groups respectively.
We are managing permissions for users on individual lists and libraries which seem to be working. However when I try to have unique permissions with Owners and Members Read only access on the list, they still have full control on the list.
As shown in the image here:
Permissions
The Part I don't understand is that it says "The following factors also affect the level of access for Ashar Khan"
Where are these policies set and how do I change them?
By default, O365 group owners would have site collection admin access to the team site. Site collection administrators are given full control over all Web sites in the site collection.
To remove the group owners from site collection administrators, go to site permission settings->Site Collection Administrators:
I am creating an application that uses Azure AD user groups to grant permissions to specific resources. For example, a particular set of documents can only be accessed by users in specific groups. The application receives the group ids as claims on the JWT and ensures that only documents assigned to groups in the claims are visible.
Now, the question is how to manage groups correctly in Azure AD. When users are assigned to a group become a member of that group and any groups that group is nested in. This seems to imply that my group nesting should be the reverse of the tree structure I would like. Something like this:
Admin --> member of --> Group with most access --> member of --> group with less access --> member of --> group with least access.
To me this seems backwards but it provides the correct access rights to users added to each group.
Am I way off base here or is this a reasonable way to manage access rights with AD groups?
#JoyWang already covered some good points in answer above. Here are some additional considerations. Disclaimer: Due to nature of question, my answer here is mostly opinion and learning from some cases. Idea is to share how I have seen groups getting used along with some related info.
Are the groups specific to your application or more general purpose? Group membership and nested groups are usually used to organize users & groups logically/intuitively rather than design permissions for specific application
Many times Azure AD Groups are used by more than one application and may have a lifetime longer than any one specific application you're developing.
The way you are thinking about nesting groups based on which one has more access v/s less access you're probably concerned about only one particular application that you're developing and thinking about a group's access to this application. This approach will work out if the groups you plan to create are also very application specific and will NOT be used for any other purpose.
Example1: Your application is a blogging app and groups you create in Azure AD are Viewer, Contributor and Admin. (Admin > Contributor > Viewer)
Example2: You have an enterprise using Azure AD and groups organize users logically, say deparatment wise Marketing, Human Resources, Engineering etc.
So, the way you describe nested groups based on lower access permissions to higher, it will technically work out for a simpler scenario like in Example1 but not for Example2 where groups are more general purpose.
Many times general purpose groups already exist and you're expected to reuse them rather than create new ones for your application which require new assignments/membership all over again, but this may or may not be applicable in your specific case.
Also, there can be multiple people managing these groups and their membership so any design/organization pattern you come up with should give importance to intuitiveness even if you have to sacrifice minor application specific efficiency sometimes.
In my opinion, you can look at both flat or nested groups.. if it makes sense from an organization of users and groups standpoint, not just access permissions. Another fictious example: Marketing Group can have a member group like Marketing Content Approvers because it's a subset of Marketing people.
Do consider Application Roles.
They are specific to an application, tied to it's manifest and can be available to you as part of claims in token.
There can be situations like individual resource based access where you want to give permissions to a specific resource where Application Roles may or may not make sense and you still need to rely on groups or users directly. In any case, it's another helpful option available to you.
Managing Groups (as you've asked about this in comments)
Take a look at Self Service Group Management Scenarios (Delegated v/s Self-service) and also Dynamic Groups for dynamic membership rules based on attributes (requires Premium license though).
In AAD, the permissions of a member in the groups depend on the biggest permission of the group which he is a member of. For example, group A can access a resource and group B can't access it, the man is both in group A and B, then he will be able to access the resource.
To me this seems backwards but it provides the correct access rights to users added to each group.
Let we call the three groups as A,B,C, the permission of them is A > B >C. Obviously, if you add A to B, the permissions of A and B both have not been affected. But if you add B to A, the members in A or B will both have the biggest permission, it is no what you want. The same with B and C. This is why it provides the correct access rights to users added to each group as you said.
So in my personal opinion, seems no need to use nested groups, just use three groups with different permissions, it's enough.
Is there a way to combine access rights for a Sitecore item?
For example, I have a page that I would like to lock down to users who are a member of two different roles rather than just just one, and a user who has just one of the roles should be denied access.
I know you can have roles within roles but wondering if there was a simpler way to achieve this?
I'm using Sitecore 7.2.
If you are trying to check this in code, you can easily do so using
var user = AuthenticationManager.GetActiveUser();
return user.IsInRole("Role1") && user.IsInRole("Role2") ? "Granted":"Denied";
But if you are trying to achieve this in Sitecore Security on an item, then an AND of those 2 roles will be assigned. Ex: If I allow access to an item in Role1 but deny in Role2, the user with Roles 1 and 2 will have his/her access denied.
The simplest way to approach this is to define a new role with appropriate access rights and assign the relevant users to it, either manually or by script. That keeps your access rights transparent. You could code your way around the issue, but you could end up creating an admin nightmare, where it's near to impossible to see which roles and users have access to which items. E.g. what would you expect to see in the Access Viewer when looking at one of the roles, or at a user with one or both of the roles? There's a big difference between assigning access rights programmatically and evaluating them programmatically.
One way that you could achieve it via the Security Editor is by utilising Sitecore's Roles in Roles functionality.
Essentially you will want to create a New Role in the Role Manager that will contain the two roles, Role A and Role B. Select your New Role in the Role Manager and click Member Of button. In the modal click Add and select the two roles this New Role needs to contain.
In the Security Editor select the New Role and assign the read, write, create etc permissions to the required Items.
Now when users access those Items they must have Role A and Role B before given access - they will not need the New Role assigned to their account.
If you have a large number of roles to manage and combinations of those it will be very time consuming to manually create those combinations.
I am working on a project in which a task needs to be assigned to users that potentially belong to two groups. For example - users which belong to Company A and also are User Type B. Is it possible to have two columns in the task list and require the workflow to assign the task only to users which are members of groups in both columns?
I don't think this can be achieved with OOTB approval workflow since you have to get intersection of users from both the groups. The simplest way will be create another group which will contain only users which belong to Company A and also are User Type B.
You can maintain this group manually or in SP2013 create a SPGroup User added event receiver which will automate this process.
http://www.c-sharpcorner.com/UploadFile/anavijai/create-groupuseradded-event-receiver-in-sharepoint-2013/
Not sure if this belongs here or on Serverfault.
I have a Sharepoint installation and several Active directory domains. In each domain, I have some Security groups.
I need to create Sharepoint groups that contain those Active Directory groups, but I need to inlude the actual users instead of just the security group. (So in I have Group G1 with Users U1 and U2, my Sharepoint group needs to contain U1 and U2 instead of G1).
Before I build something like this myself (which is rather straight-forward with a Timer Job and some Management forms), I just wonder if something like this is already built in to Sharepoint 2007? Or if they are existing solutions?
Googling brought only results about the normal AD<>SP Profile import, which works fine, but nothing about Security Groups.
This definitely isn't built into SharePoint. It may be available in a third party solution, however my guess is it would be an uncommon requirement so unlikely.
I would probably develop the solution myself. It shouldn't take long.
I would write a timer job for this (if you want to keep the AD groups and SP groups in sync).
Make sure all your groups are in 1 OU (to make for an asy stsrting point for an LDAP query), then iterate through all the security group objects with Directory Services in the TimerJob execute method. Then, iterate through all user objects in the group and add them to the corresponding SP group, remove users that are removed from the AD group from the SP group too.