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.
Related
I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
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.
We are implementing a Liferay 6. 2 solution, everything was set but then we had a problem. Thing is, we are importing all the users from AD using LDAP with their group information. So, in liferay, we will have users and users' group. We planned to follow organization->sub-organization structure but the customer does not want to assign all the users(no option to assign user groups to organization which i know why and it totally make sense ) to the organization manually which, kind of, makes sense. So, then we had to change our design, now what we are doing is actually creating a department-wise site then assigning user groups to the site and then linking site to organization. So two questions.
Does it make any sense to have organization? if so then what advantages will I have in this particular case.
Do you see any drawbacks in our approach or should we follow a better approach which we are not aware of.
I have scenario as, I have say 5 branches for example Branch A, Branch B, Branch C etc. All branches have different set of users and different set of data(in liferay portlets). My requirement is like, Whenever user from Branch A logs in he should not able to logged in to other branch. In short he should not have any permission to view, login to Branch B (other than his own branch).
All 5 branches has two sub-sites.
Eg. Branch A has sub sites Site A1 and Site A2. separate users are associated to the site.
My Question is what should I use to develop such system.
As of now I had created one Organisation and created Location Sub organisation.
How can I restrict user to log in himself into his own organisation and not anyone else.
How can I restrict user to view the contents on his own site and not other site.
Do I need to create User Groups.
Any Pointers would be helpful. Thanks in advance.
First of all: You don't need Locations. They're just like Organizations, but can't have any more suborganizations. This is a limitation that you don't need to impose on your branche offices. You can, but don't need to.
You always log in to your account, not into an organization. When there's content in an organization's site that must not be seen by non-members of that organization, just make the pages private - this restricts them to be seen only by members of the organization.
Membership of organizations is centralized anyways - thus nobody can become member of another organization without an administrator making the connection.
If you need user groups depends on what your overall structure is. If you interface with LDAP, I like to use user groups as the importing target for LDAP groups. If you don't, it still might make sense to group users into User Groups - just to keep an overview over the different memberships and permissions that you give. It's a lot easier if you restrict yourself to not grant any roles and permissions to individual users, only to User Groups - at least once you have a certain number of users.
I am looking to set up a new security group called Head Company which will include existing security groups on my SharePoint like Child Company 1, Child Company 2 etc. This is to allow say the Company Group CEO manager access to all the Companies the Head Company owns.
Unfortunately SharePoint does not seem to allow it ?
Error: SharePoint Groups cannot contain other SharePoint Groups. Remove the SharePoint Group from the Users box and try again.
Is this something you guys have done on SharePoint, or something perhaps you have been able to work round?
This problem messes up my master plan in terms of how I was going to set this up ! Double drat !
SHAREPOINT 2010
If you could switch to using AD groups then you can put AD groups within each other however this also has drawbacks trying to manage it all.
A restructure may be time consuming but would make it easier to manage in the future. And i am sure you can move sites within subsite fairly easily now Check this out
http://movesites.codeplex.com/