Unfortunately I have a problem with an Forum Based on Domino FP9 Server. Several pages are created with the framework/language xpages. I have created a group and also a category. But the user is unable to get access the content.
My question is: How I can implement the right to an Group inside HCL Admin or Designer to read content on an Page?
Kind Regards
Okan
Access is granted via the Access Control List of the application. In HCL Notes Administrator, find the application on the Files Tab. Right-click and choose Access Control > Manage. IMPORTANT - DO NOT choose Manage Directory ACL in error.
In the dialog that opens up, you should be able to add groups/individuals with appropriate levels of access.
Not exactly sure what the problem is.... i.e. what it has to do with HCL Admin or Designer to do?
However, security in an XPage is exactly the same as with everything else Notes/Domino - so you can use that knowledge to control access rights.
A group in reality works like a single person in terms of access. So you can use it in the ACL of a database and/or in Readers/Authors fields (to control access to specific documents).
If you want to control functions or layout inside your application then I would suggest using Roles as these give an extra abstraction layer and are way easier to use in e.g. hide-when formulas inside your code. And then you just assign the role to a group or person in the ACL of the database.
Remember to set the right type of the entry in the ACL (e.g. Persons for a group that contain persons) - otherwise you can have issues where the server will not grant the expected access ;-)
Related
I have the following scenario:
My Add-In allows to write posts. Any user may "Like" that post. That likes are being saved into a list.
Of course the Add-In needs permission to write that entry into a list. But as (IMHO) I cannot use any elevated privileges inside a SharePoint - hosted Add-In, the user needs to have that permission, right?
So: How can I protect my lists that the user don't just go into the list and modifies the value himself and increases the "likes" for example?
(remark: This is no real-world scenario. I know there are better ways to use a social network-feature. Just wanted to break down my much more complex app)
SharePoint-hosted add-in cannot use App only policy as provider-hosted add-in can to use add-in context with more permissions then user has. SharePoint-hosted add-in is running completely in the context of current user.
I see 3 possible solutions:
Redesigning the add-in to be provider-hosted)
Implement custom web service and calling this web service from your add-in. That web service can store sensitive information in either custom database or list in app web with customized permissions. But remember that SP admin can modify these permissions.
Store semi-sensitive information into extended properties of item. There's no UI allowing user to manipulate with it but this is not as secure as permission. Advantage of this is that this information is directly connected to the "affected" item and you don't need to afraid of loosing connection between item and like storage. Disadvantage is that extended properties can contain only limited amount of data and user must have permission to update item. You can also use this approach combined with your list.
I would make each user's 'like' click create a new item in a list that has the Item-level Permissions set to:
Create items and edit items that were created by the user
That way even if they did somehow get into the back end and start monkeying around with the list they would only be able to change the items they created.
You'd just need to manage how the list grows over time depending on the scale of the app.
You are correct. The user would require the something like "Contribute" permissions to accomplish what you are talking about. Personally, here is what I would do...
1) Ensure the list I want to protect has an obscure name. Remember, the UI is not the same as in the host web (i.e. Site Contents). The user never has to know in what list such data is stored. Taking it a step further, ties between lists could be made by something like a GUID instead of something obvious like "Title", making it more difficult to determine exactly how data relates.
https://sharepoint.stackexchange.com/questions/96360/hide-list-from-browser-site-lists-lisname
2) Delete all views in your sensitive lists. This would prevent navigation in the browser. These lists would be modified through REST or CSOM, so you do not need them.
3)I haven't tested this possible solution, but it may work. You should be able to configure the edit.aspx (or create your own custom one) so that even if the user somehow made it past Steps 1 and 2, there was no available fields to edit anyways...
These methods do not manipulate the permissions to the list in any way and in the end, all of this is permissions through obscurity.
I'm trying to find what is the permission security for allowing visibility of the Alias function in the Presentation tab ribbon.
For the user in question i've browsed to the core database, and under Access viewer, i'm looking that all the items under Applications/Content Editor have read-enabled permissions, specifically the item /sitecore/content/Applications/Content Editor/Ribbons/Strips/Presentation/Page Urls as well as /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Page Urls are read-enabled
However, when login as this user there is no presentation tab.
I've tried resetting the cache and still nothing changes. I'm using sitecore 6.5.0
I think you are almost there, but you still need to give the user sufficient access to the /sitecore/system/Aliases item.
Create a new role(or use an existent one), for example sitecore\Sitecore Client Aliases. Use this role to add the following permissions.
Switch to the Core database and allow Read permission for the /sitecore/content/Applications/Content Editor/Ribbons/Chunks/Page Urls item and its descendants
Switch to the Master database and unprotect the /sitecore/system/Aliases item by using the Unprotect Item checkbox in the Configuration tab.
Allow Read, Write, Create permissions for the /sitecore/system/Aliases item and Read, Write, Create, Delete permissions for its descendants.
Protect the /sitecore/system/Aliases item back.
Add user to the sitecore\Sitecore Client Aliases role.
Found here: http://wiki.evident.nl/Sitecore%20alias%20role.ashx
The easiest way to enable the presentation tab is to use a sitecore standard role.
I'm not totaly sure but i asume it was sitecore\Sitecore Client Designing.
And as far as i know you have to use those standard roles to enable access to certain chunks.
Try using the Access Viewer for the user which doesn't see the Alias Tab. You can manually switch to the core database and then click on the different tabs with the specified user / role to see what causes this behavior. Most of the times you will find out that some role / restriction was set to a higher level item dat denies read rights.
I have a specific requirement where-in I want only the uploader of the document and a specific team to be able to view it in list / library. 1) is it possible? 2) If yes, how...?
Ok. So I was able to resolve my issue with the steps mentioned below. Soon will be documenting it in form of a blog and share it:
Created the document library and modified the default view to only show documents that were created by/modified by [Me].
Added a new web page to the library and gave exclusive rights to access that to a certain set of users.
Restricted all users from creating a view with the help of creating special permission level where user only had access to upload or delete a document but not creating/updating/deleting lists/views. Also disabled private view creation.
Hope this may be helpful to others too who are looking for restricted views / disabling view creation.
You need to set item level permission through event handler:
http://www.chakkaradeep.com/post/SharePoint-ndash3b-Setting-Item-level-permission.aspx
http://msdnvietnam.net/blogs/quang/archive/2009/07/02/sharepoint-eventhandler-set-item-level-permission.aspx
#Ashish, in SharePoint 2007 GUI you cannot make a query that will show documents that belongs to a specific group, however CAML specification supports it (Membership tag), it wasn't documented until SP2010, but it works on SP2007 (i'm using it)
However this involves custom coding and this doesn't assign permissions automatically, it just enables you to filter documents by groups.
For a solution without custom coding you could consider making a seperate folder/list for every person/group and set permissions to folder/list accordingly. This will also help performance - it's better to have permissions set on high-level container than having fine grained permissions (i'm just assuming that, because i read everywhere that mass fine-grained permissions are bad for performance)
You may use current user filter web part to filter the document by whom logged in into the sharepoint site by passing the value Dispaly Name
On the "My site" feature of Sharepoint there is a "memberships" Web part that shows the distribution list that the user is a member of.
This is picking up several groups that we would rather not be shown e.g. some that have been set up for administrative purposes only.
Is there any way to control which groups are shown; ideally this would be using another AD group and setting that only members of this group are shown.
I'm fairly sure this won't be possible without a custom web part that is deployed instead of the official part. The reason the Exchange solution doesn't work is because it's going the wrong way (from group to member instead of member to group).
To deploy it you can look at feature stapling... you would need to update the existing sites as well.
This is not an easy answer. I don't believe there is an easy answer.
The best solution would be to set a Deny Access Right for the distribution lists in Active Directory; follow these steps:
1) Open Active Directory Users & Computers as an admin (any user with access to creating groups and modify distribution list security settings).
2) Go to the View menu and make sure that there's a check-box next to Advanced Features.
Create a new security group in Active Directory (call it HideFromSharePoint or something) and add the SharePoint Content Access account (in my case DOMAIN\sa_spcontent) to that group (has to match the account used in step 4).
3) For all of the distribution lists that you don't want to show up in SharePoint do the following:
3a) Open the distribution list and select the Security tab (Advanced Features must be checked for this tab to be shown).
3b) Click on Add and type in the name of the security group that you created in step 3 (HideFromSharePoint); click Check Names and click Ok.
3c) Under Permissions for HideFromSharePoint; check the Deny box next to Read (it's set to Allow by default) and click Ok and Ok again at the prompt.
You've just denied any members of the HideFromSharePoint group read access to the distribution list.
4) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties; Configure Profile Import and under Specify Account enter the credentials of the account that you added to the HideFromSharePoint-group in step 3. (For some reason if you leave this to using the Default Content Access account SharePoint will use some other account to access Active Directory and thereby being allowed access to the distribution lists. You could experiment with adding other SharePoint service accounts to the HideFromSharePoint group but I think it's safer to specify an account explicitly so that you know which account is accessing AD and importing the data.) Also make sure the "Import Connection" for your Active Directory is set to "Use Default Account" (thereby "inheriting" the account used for Profile Imports).
5) Go to SharePoint Central Administration; SharedServices1; User Profiles and Properties and click on Start full import. (You can't do an incremental import because nothing has changed for the users in terms of group membership; it's just the access rights that have changed.) After completion of the full import (click Refresh until "Import time:" says "Started full import at 11/25/2009 ##:## AM - Ended import at 11/25/2009 ##:## AM")
The distribution lists should now no longer show up under Memberships.
A couple of things to note:
You have to set the Deny Access Right explicitly and individually on all of the distribution lists that you don't want showing up in SharePoint. That's because the special AD-group "Authenticated Users" has read access to every object in the directory by default and explicit Allow Access Rights trump Deny Access Rights set (for example) at the organizational unit level.
While you could skip the step of setting up the HideFromSharePoint-group and set the Deny Access Right directory for the SharePoint Content Access account Active Directory administration best practices is to use a group when configuring security permissions. (Then you can add additional members to that group and have those denied read access too.)
You might have to wait a while (5+ minutes or so) between setting the the Deny Access Rights for the changes to replicate to all of you domain controllers. Otherwise the import might read from a domain controller where the Deny hasn't yet come into effect.
Be careful adding any other accounts to the HideFromSharePoint-group because this might break your distribution lists. For example; if Exchange can't read the groups mail won't work. As long as you just add the SharePoint Content Access Account you're safe.
Also (and this has nothing to do with SharePoint or the solution above) be aware that any user in your domain can fire up ADUC or a LDAP tool and see the members of your distribution lists that way. If you have anything "Top Secret" you need to experiment further with setting access controls in Active Directory.
I assume that your "memberships" web part is using the SharePoint people picker functionality internally.
If that's the case, then the following stsadm command should help you scope your AD lookup the way you want it:
stsadm -o setsiteuseraccountdirectorypath -path <name of OU> -url <URL name>
You could try editing the Distribution List on the Exchange Advanced tab, selecting the "Hide group from Exchange Address lists" check box.
I have not tested this but in theory it would stop the Distribution List from appearing the the list of groups.
Easy fix: add a JavaScript to the page on which those appear that targets and then hides the specific items by applying a CSS style.
I don't have an exact answer, but here's how I would think through the problem. Perhaps you have already answered some of these questions, but it might help to go through them again. I would look at the questions in the following order:
Is there an option in Active Directory to hide a group from SharePoint? (sounds like no)
Is there an option in SharePoint administration (either through stsadm or the actual administration site) to exclude certain users or groups in AD from SharePoint?
Is there a way to configure the web part to exclude certain users or groups from the web part itself?
Is the source code to the web part available such that you can compile the web part to exclude certain groups in the list?
Can you use javascript (as Josh mentioned) in conjunction with the webpart to hide the Distribution Lists from the webpart? (Here's a site with an example of how to use JavaScript to Hide SharePoint's Quick-Launch bar. Maybe that will help).
Those questions are in order from the widest scope and easiest to implement to the narrowest scope that is more difficult to implement. Obviously, you'd like to implement a solution that is easiest to implement, but perhaps you find yourself farther down in the list.
In the last two examples, the solution may appear quite complex, but you may be able to write code that references an XML file of sites to exclude. That way, if your list of Distribution Lists changes, all you have to do is edit the XML file and not edit the source code (of either the javascript or the webpart).
If there's not a simple solution, you'd have to make the painful choice of either 1) letting the problem remain or 2) implementing a hack that adds a dependency to your solution.
I think Distribution Groups that aren't security enabled don't show up in SharePoint. Have you checked AD to see if these groups are security enabled? This may be only for permissions purposes, so I could be wrong.
You will probably need to do a profile import before you see any changes.
You can turn off Distribution Lists entirely, which is what we are doing at my company. This is done by going to the Profile Services Policies in the SSP and disabling the Distribution List feature.
Now if you want to pick and choose the Distribution Lists, it's not that simple, but hopefully this will help someone.
Is there a way to limit the "edit item" permission in WSS 3.0 to only allow a user to edit his own documents or list items? We need the ability for a user to edit only documents/list items he creates - NOT items that someone else created. So, essentially we need a sub-set of the EDIT permission as well as ADD.
Is this possible in Windows Sharepoint Services 3.0? Is there a way to create custom permissions in code or a feature?
WSS has a basic UI for setting item-level permission on list items, but they hide that from the UI for document libraries. If you go into Settings->List Settings->Avanced settings for a list, you'll see the options to do pretty much what you're asking for. However, on document libraries, that UI is not available. The settings it drives, though are avaiable via the object model.
You could set those same properties for a document library like this:
SPDocumentLibrary onlyOwnLib = theWeb.Lists["DocLibName"]
onlyOwnLib.WriteSecurity = 2;
onlyOwnLib.Update();
And that should about do it. However, apparently that doesn't really set permissions; it just controls what the user can do via the UI. If they had another interface to the library (like via WebDAV) or list (like via the web services), it wouldn't prevent them from editing items they didn't create. If you want true item-level permissions, I think you need to go the event handler route.
This post from Matt Morse explains it in more detail, and he even wrote a command line tool to set the property (plus the .ReadSecurity property) for lists and libraries.
If you added an event handler to the document list you should be able to limit edit rights on that item to the user that created the item.
I often have to copy documents from another system into a list in SharePoint, and in that case the edit rights will be assigned to the system user that transfered the document, unless you use the approach suggested by Kirk Liemohn here
Note that item level permissions on large numbers of documents increase the load on your SQL server quite a lot.
here is the solution for your request.
go to the list -> list settings -> Advanced Settings
you will see the section of
Read access: Specify which items users can read
All items
Only their own
Edit access: Specify which items users can edit
All items
Only their own
None
select the options based on requirement. that's it done..
wanna more click on http:// mastermoss.wordpress.com
This is an old question, however the problem still exists.
A way that has worked well for me in the past is to use a workflow to configure the permissions when the library item is added.
See http://www.sharepointusecases.com/index.php/2010/03/configure-item-level-permissions-for-document-libraries-part-2/ for details.
I believe that permissions like that can be created through the user interface. It depends on the scale and number of list items you have, but you could do one of two things. First (without having to create scripts) you could give everyone a custom "Read" permission access which would not allow them to do everything you can in in the Read permission but allow them to Add Items. Then on an item-by-item basis, click the item -> manage permissions -> (Give the specific user Contribute permissions on their document).
If you're creating a SharePoint list that this will not be practical, you can create a script to traverse through all items, and will verify the user has contribute permissions (otherwise it will set the contribute permission to that user).
Additionally, you could just give each person their own folder.
Give everyone read permissions on the SharePoint list/document library, but give each person full control privileges over their own folder. This will allow everyone to read everything in a list, but create/edit their own documents.
If you want the 'Only their own' permission on a document library, it isn't there out of the box. But I've created a solution at CodePlex that adds this for Document Libraries - check it out at http://moresharepoint.codeplex.com.