I want to copy the permissions of a user and to another user. I know i can do it by creating a group with required permissions and adding the users will do it. But i dont want to create a group. Is there a way to copy the permissions of a user to another user directly?
NLV
You need to write code that will;
Check if the current site inherits permissions or sets its own
From the site that sets permissions (self or ancestor, depending on 1) go over the RoleAssignments collections
For each role assignment check if your source user is specified
If so, create a role assignment for the target user
This code must run under administrative privileges (RunWithElevatedPrivilegese will suffice if written as web part)
There is no way to copy permissions between users through SharePoint itself, you will have to write a script to do it for you.
There is no OOTB way to clone SharePoint user permissions. You should either use 3rd party tools such as ShareGate, Axceler ControlPont, Boost Solutions's Permission manager or Use this PowerShell script way: Copy Permissions from One User to Another in SharePoint using PowerShell
Copy Permissions from One User to Another in SharePoint using PowerShell
Related
I'm currently using a SharePoint account as a Service account to get files and share them in an application I'm working on using CSOM. I filter the files according to the logged-in user to check if the user has no access to the file, then I hide it, to prevent him from trying to access it and get "Permission Denied" error.
So, I used ListItem.GetUserEffectivePermissions for this issue, but I need to grant the user only the permissions he needs to access and make that check.
I checked the official documentation of ListItem.GetUserEffectivePermissions here but unfortunately, I found no direct clue which permission does the job.
So to recap what this service account needs to do is :
1- Execute Search across all sharepoint files [SearchExecutor].
2- Get Login Name by Email using Utility.ResolvePrincipal (to be used in GetUserEffectivePermissions function).
3- Use GetUserEffectivePermissions to check if the logged-in User has permission to view the file.
I'd really appreciate your help as I'm kind of new to SharePoint and I searched a lot but found no clue about what I need.
I would recommend that you change your architectural approach. Instead of trying to manage what permissions a user has in SharePoint, let SharePoint take care of it like it already does. Instead, have your app use an OBO (On Behalf Of) token which will honor the logged on user's permissions in SharePoint and only return items that the user has access to. For a detailed overview of the OBO flow in MSAL, please refer to this article.
I am wondering if there is a way to add already existing users in an AAD tenant to a different tenant programmatically? I can only see the powershell cmdlet for adding(creating) a new user in the same tenant. Basically this is the workflow that i want to automate:
On the Azure portal. i go to the tenant and then click on Add user
When i click on Add User it asks me to provide Type of User where i choose User in another Microsoft Azure AD directory.
Is there a way to programatically do this using some code in powershell or C# or some other microsoft stack?
Basically i want to achieve automation for steps mentioned in this link: https://azure.microsoft.com/en-us/documentation/articles/active-directory-create-users-external/
No, this is not directly supported. One way to add "O365 Management APIs" application and then use office.com admin portal to import users from a csv file. But this only works if the users on the same tenant.
I am trying to create a Directory in .NET using Directory.CreateDirectory, I followed the directions here to give access permission but I am still getting an UnauthorizedAccessException. Does anyone have any advice? Note, this is a web application that uses the IIS7 server.
In the directory you are attempting to create a new directory, make sure that your app pool user has Read/Write permissions for that directory. You have to specifically do that in addition to adding the user to the user groups.
2 more potential issues (+1 to user959729):
you are creating directory at different place than you think you are (i.e. you building path wrong)
the code runs under impersonated account (user's or anonymous) and such user does not have permissions to create folder (to verify try check System.Environment.UserName before creating directory). To fix you need to run code as process account.
my problem is, I want to create a new folder and make it impossible (or reasonably hard) for the user to change its name or to delete it. The thing is, the user must be able to access the files contained within that folder and change them in any way he pleases. Using the examples I've been finding in the net all I get is making it impossible to change the files INSIDE the folder, and not the folder itself.
Thanks in advance ;)
As long as that folder is created by the user's account (assuming that you're creating the folder programmatically by your application), the user will be able to edit the folder. The best way to protect that folder from tampering would be to write a very small windows service that keeps that folder always open, thus preventing deletion/renaming.
This might be helpful.
http://technet.microsoft.com/en-us/library/cc732880.aspx
It seems you want to allow the "Create Files/Write Data" permission but not allow "control" of the parent folder.
You should be able to set up an ACL to do this. Give them "List folder contents" rights and then selectively give them additional extended rights without giving them modify attributes rights.
The service answer is a bad idea. I might work, but is not the best way to do it. The key with windows directory and folder security is the "owner" of a folder. As an administrator you can always take ownership of a folder or file. BUT if the file has a different owner and that owner has granted you rights you won't have any other rights until you go in and take ownership.
What you want to do is create a special account on the machine (often called a service account) which is the identity the program runs under. This account has admin rights and is the owner of any files it creates. Then it can allow whatever access it wants to grant to users of files and folders it creates.
The admin will always be able to take ownership if they want to, but most users don't even know how to do this.
I am having trouble with setting the secutrity rights for the Media Library of one of our customers. For the "Sitecore Client Authoring" role I have specifed that it has only read access for the entire Media Library. I needed to "unprotect" items to do this but the Access Viewer tells I have succeeded.
Subsequently I wanted to specify access rights for a custom role. That custom role is a member of the following roles:
sitecore\Sitecore Client Forms Author
sitecore\Sitecore Client AccountManaging
sitecore\Sitecore ClientAuthoring
sitecore\Author
sitecore\Sitecore Marketeer Form Author
The problem is that the Access Viewer keeps telling me (when I look at the access rights for that custom role) that my custom role has write rights on Directory A because the sitecore\Sitecore Client Authoring account has been granted the 'item:write' access right for the '/sitecore/media library' item. When I look at the sitecore\Sitecore Client Authoring role in the Access Viewer the system tells me a different story. There the sitecore\Sitecore Client Authoring role only has read rights.
This is the basic structure of the Media Library for this customer.
Media Library
Files
Directory A
Directory B
Directory C
etc.
Images
Directory A'
Directory B'
Directory C'
etc.
Any idea why the write access rights are granted to my custom role?
You could also try to reset the cache(/sitecore/admin/cache.aspx). If it's the 6.X issue, the access result is not resetted in time, so the wrong result keeps available in the cache.
Try iisreset and take a look at Access Viewer again. Does it reflect the situation correctly now?
It seems there was an issue in some older versions of SC 6.X.