I have two reports that I need to build. One that has a dozen or so columns. The other has the same columns + 2 extra. The first one is aimed at employees the second with the additional columns is aimed at Sr. Management.
I have a windows group set up for the proper Sr. Mgt users.
I am using SQL 2012.
I've done some SSRS stuff, but not enough to say I'm competent to do more difficult reports.
The problem I'm having is that we do not want the employees to see the sensitive information in those two columns. Frankly, we don't even want them to know the existence of a different report.
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Option 2: I was thinking that I can use the UserID condition to hide the columns in the report and just create one report that differs depending on who was viewing. There are two issues that surfaced in my research. First, there is no facility for using Windows Groups instead of userid. That would mean I have to maintain the list of people inside the report and boy would that be a pain. And second, my understanding is that the export facility does not respect the column actions -- like hiding.
Am I making this too complicated? Is there an easier way to do this? With no other solution, so I need to put up another instance of SSRS for management and make them go back and forth?
Thanks for your time
Option1: You should not be able to 'browse' for folders unless the 'parent' level permission has an 'everyone' user set up to browse on the higher level. Set up a test account and RDP to a box you can use the test account on. Generally under 'Folder Settings' you set up permission and it cascades down until interupted. If you have a parent permission to browse and a lower one not to, they may be able to browse directories. You can ensure that the directory has ONLY dedicated users and the inherited settings are removed manually.
Option2: I would NOT do this. You will have a maintenance nightmare on your hands as you would have to determine in code who was what and update a list that would probably need to be updated somewhere in SQL or a service. As far as I know SSRS does not work with getting parameters and such directly from AD so you would have to code this time and again. For this reason and security context I would avoid this.
Option3: Set up a 'Subscription' to save the report to a file format(excel, pdf, word, etc) or email on a scedule and turn off permission for everyone but admins. If someone can still see the report or directory there is most likely a security context issue.
Option4: You can do a cheapy 'Hide in tile view' move that for most users will hide the directory unless they go to the URL directly and have access. Click on a folder then choose 'Folder Settings' then check 'hide in tile view' and hit okay. Directory is now gone for most part for regular users browsing in default mode.
I think we can just fix your problem, and avoid inventing a complicated and unnecessary solution:
Option 1: I was thinking I can just create a folder in SSRS and add the report there and hide the folder. I created it and applied the security but it seems that everyone can see the folder. Maybe they can't edit anything in it or even maybe they can't read anything in it, but this solution, if unchanged, will not meet the goal of having them not even see it exists.
Chances are that either you set up the security settings wrong, or there's a bigger configuration nightmare to worry about. What you should do is create the folder, go into the settings of the folder, and edit the security (thus breaking inheritance from the parent folder). Before even adding groups, you need to remove anyone that doesn't belong - namely entries like "YOU\Domain Users" - that gives access to anyone on your domain. Once you've cleaned out whomever shouldn't have access, you can add the users/groups that should. Problem solved.
Now, if that doesn't work, then it would seem to me that your SSRS instance is somehow granting everyone sysadmin access - check the Site Settings to see what users and groups are in the System Administrator role. Investigate any groups thoroughly - is BUILTIN\Administrators a sysadmin in SSRS? Check the group locally on the computer - is there another blanket domain group shown there?
If everyone on your domain has complete access to the SSRS instance, then your goal of "hiding" things is impossible.
Related
Our users have access to certain subsites, and they can add the address of these subsites in Harmon.ie and navigate inside. Also, all checkboxes "Hide subsites with limited or no access" are unchecked. Therefore, we would expect that when adding the address of the "higher level" site in Harmon.ie, that we would visualise the names of the subsites below: but we don't. What can it be?
Please read carefully our KB at http://harmon.ie/KB/sharepointrequirements Browsing subsites, it details the needed permission when working through web services like Harmon.ie.
If it does not help please re-do the security, but for on individual (for the concerned users), check whether one of the permissions didn't have the Browse Directories enabled.
We have, however, seen few situations in the past, where despite all the proper settings, such as ‘Browse Directories’, people were unable to see sub-sites or directories. Unfortunately, we were never able to reproduce such a situation inside our Labs to properly analyze that. We believe that it may be related to precedence of security settings applied to SharePoint user account. For instance, if there is a ‘Read’ and ‘Manage’ access levels – it may be that one of those has ‘Browse Directory’ while the other one doesn’t.
In the few situations that we have come across where similar issue occurred – it was resolved some times by remove the ‘Browse Directories’ setting and then applying it again.
---- Jean
Currently i generated excel file from TFS 2013.
I want to disable editing this file for some specific users.
I tried to add these users in the group Reader only, but they can modify the excel file then publish it.
On the other side, i want to give them the ability to refresh the excel file and get the latest status.
By "publish" I assume you mean the Check In permission. Readers don't have an explicit Deny on Check In by default, so you may find that people who can still Check In are members of another group with permissions. The usual group being the Contributors group.
To force the matter you can go to the file in question in Source Control Explorer, right click it and select Advanced -> Security and then explicitly set the Reader group to Deny for the Check In right.
I assume that you mean "publishing work items". If you do then people in the readers group will not be able to publish unless they also have contributed rights. So while they can click "publish" they will not be able to make changes on TFS, and they will be able to refresh.
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.
In our Sharepoint implementation users have been granted site collection admin rights. On a few occasions they've managed to delete a subsite or even the entire site collection. I'd like to be able to block this but not being a developer I'm finding it pretty tricky.
I've had a look at the MSIT site delete capture tool to try to understand how that's working and it seams fairly straight forward. I want to override the delete function and either block it entirely or have the user type a password. What I can't see is any way to fully override the default behavior as it looks like the MSIT tool simply adds some functionality (backs up the site) then falls back into the default behavior.
So my question is, can I prevent the default behavior or can I only add actions before or after it fires?
Thanks in advance
Change the user permissions may be the best way to go. site collection admin is a crazy level of access for normal users.
Two answers:
You cannot prevent site deletes without either coding up something yourself, or buying a product to help you with "site lifecycle management" or "site governance" or some other vague term they use to describe this sort of thing.
The Site Delete Capture Tool may be good enough for you. It doesn't prevent any kind of deletions, but it does take a crude backup that (hopefully) allows you to restore anything they delete. We're using this tool in production and it works.
You could try to edit the site settings aspx file and comment out the delete site link, don't have a setup around to try that. While users could delete the site in other ways it would prevent the most common method.
Other option for important sites would be to make sure the site has a sub-site, if one does not already exist create one and don't user any access. The site would not be seen by the users and it would prevent them from deleting the parent site.
As for programming, in the before behavior you can return a false to stop the action. Just be sure to place a work around so you can delete a site.
A Site Collection administrator has the permission to delete sites and it should stay that way. We have modified MSIT to do additional stuff
The best way to limit user privileges is to put users in the right SharePoint group (ie) Owners, Members, Visitors or you could create a new group with right permission/permission levels.
What is the general feeling amongst developers regarding the changing of files in the 12 hive.
For example if you were asked to remove the sign is a different user menu item, you would need to modify the relevent user control on the filesystem. Now if you just go and modify it via notepad or copy over and then if you go and bring a new server into the farm you will need to remember to do the same on the new server.
Obvouisly you could deploy the changed file as a solution and have that done automatically, but I'm just wondering if people are hesitant to make changes to the default installed files?
I have done a bit of SharePoint development, and I must tell you that messing with the 12-hive is a ticket to a world of pain if you ever want to move the app.
I'd rather hack up some javascript to hide it, at least that can be bound to the master page, which is much more portable.
And remember, you never know when the next service pack comes around and nukes your changes :)
I agree with Lars. Sometimes you will not be able to avoid it, depending on your needs. But, in general the best policy is to avoid modification if at all possible.
I know that some of the other menu items in the current user menu (change login, my settings, etc) can be changed by removing permissions from the user. Under Users and Groups there is an option for permissions. I can't remember the exact setting (develop at work, not at home), but there are reasonable descriptions next to each of the 30+ permissions. Remove it and you start hiding menu options. No modifications to the 12-hive needed.
There is a very simple rule: if you want to keep official support from Microsoft, don't change any of the files in the 12 hive that are installed by SharePoint.
I've never encountered a situation where the only solution was to change such a file. For example if you want to change an out-of-the-box user control of SharePoint, you can do so by making use of the DelegateControl, and overriding it in a feature.
More info:
http://msdn.microsoft.com/en-us/library/ms463169.aspx
http://www.devx.com/enterprise/Article/36628
I know it's tempting to quickly change a file, and I have to admit sometimes I just do that on a DEV box, but don't go there on a production server!
Not sure if there is much use pitching in, as everyone else pretty much has it covered, but I would also say don't do it. As tempting as it is, its just impossible to know the full impact of that little change you have made.
From a support perspective you will make it difficult for Microsoft support (patches/hotfixes).
From a maintenance perspective you are also opening yourself up to long term costs.
Go the javascript route.
The way to go about it is to use a Sharepoint Solution (WSP) file.
To change the user control, create a new Sharepoint feature with the new functionality.
Include this feature in your solution.
Deploy the solution either using the stsadm command line, or through Central Site Admin.
This will then get automatically deployed to all the servers in your farm, and it avoids you overwriting anything default sharepoint files.
For more info, check out Sharepoint Nuts and Bolts blog on http://www.sharepointnutsandbolts.com/ which give an introduction to WSP and Sharepoint Features.
I've done this many times and I will speak from experience: Never ever touch the onet.xml files within the 12 hive under any circumstance. Any error that you make in there, and to make the CAML even more complex the file is largely whitespace sensitive, will have an impact on every part of SharePoint.
You should also consider that aside from the substantial risk to the installation, you may well be building in dependencies upon your changes that are then over-written in a future patch or service pack.
Most of the time, you can accomplish everything you want to using features and solution packages without modifying the files. However, there are a few (rather annoying) rare cases where your only option would be to modify a file on the system. I have used it for two particular cases so far. One was to add the PDF iFilter to the docicon.xml file, and the other was to add a theme to the themes.xml file. In both cases, it seemed to be the only way to achieve the goal. Still, we used a solution package to write those files out to all the servers in the farm.