36

I figured it out: it does not work in Mozilla Firefox and Google Chrome. By using the internet-explorer (for entering the central administration and adding the certificate) everything work fine!


22

Use (Get-SPFarm).DefaultServiceAccount.Name should give you the Farm Account


17

You can use Sharepoint Client Object Model for this. Here is how to do it on the current web: function CheckPermissionOnWeb() { context = new SP.ClientContext.get_current(); web = context.get_web(); this._currentUser = web.get_currentUser(); context.load(this._currentUser); context.load(web,'EffectiveBasePermissions'); context....


16

I see two differences one difference: The function SPContext.Current.Site.OpenWeb() creates a new instance of the SPWeb object, and you are responsible to dispose it. However, SPContext.Current.Web gives you access to the current instance of SPWeb, and you must not dispose it. The function SPContext.Current.Site.OpenWeb() (without sending parameters) opens ...


12

It depends on what you need to do. RunWithElevated only runs as the Application Pool Identity, so you might not have access to other web applications, only other site collections in the current web application, but you can be guaranteed that you will be running as a user that exists (the AppPool identity). With UserToken, you need to be sure that the user ...


11

Take a look on msdn foreach (SPUser user in group.Users) { group.RemoveUser(user); } But be aware that you change this group for the whole site collection, if you have other site collections those won't be impacted by the modification of this group.


9

When running inside RunWithElevatedPrivileges, do not use SPContext.Current. Instead create a new SPSite object, passing in SPContext.Current.Site.Url.


8

Resetting the environment with an iisreset did the job.


7

Hope this will help someone because I faced the same issue. The claims based token is refreshed every 10 hours and hence if you make any changes to Active directory group memberships it won't reflect immediately in the token. you need to run the following powershell command to adjust the token life time to a smaller value. $sts = Get-...


7

I'm assuming in the list's Advanced Settings page you set "Specify which items users can read" to "Only their own". You need at least the "Manage Lists" permission which is present in the following roles by default: Manage Hierarchy Design Full Control So... a user would need at least the "Manage Hierarchy" role set in the list's permissions. See also, ...


7

There are few security risks linked to Google Analytics. Your SharePoint site will not be hacked because you use Google Analytics. You cannot be 100% sure, but the only "safe" way is running log processing software on-premise or use built-in Web Analytics. However, I believe the largest risk are concerned with the legal aspect of possibly exposing internal ...


6

I didn't want to take credit for answering my own question so i did it as an edit but the following resolved MY issue: UPDATE: The issue had to do with the fact that the Security Token Service was not functioning properly. I'm still not sure that i'm clear on how to correctly change managed service accounts, passwords, etc. But I DID get it working. I guess ...


6

You could also use the Microsoft Threat Management Gateway 2010 (TMG 2010) to publish your SharePoint intranet in a secure way. It could for instance be published on a Web address like https://intranet.yourcompany.com Now, my suggestion does of course require that you are using the TMG as a firewall between the internet and your internal network. But I can ...


6

This will give you the Farm Administrators: $ca = [Microsoft.SharePoint.Administration.SPWebService]::AdministrationService.WebApplications | Select -First 1 $root = $ca.Sites["/"].RootWeb $grp = $root.SiteGroups["Farm Administrators"] $grp.Users and Get-SPManagedAccount will give you managed accounts There should only be the farm admin common in these ...


6

Another option would be to embed JavaScript code via Content Link property. Steps: 1) Create the following regular text file <script type="text/javascript"> <!-- JS code goes here --> </script> and upload it into Site Assets library 2) Add a reference to a file via via Content Link web part property


6

Elevated privileges is not enough to write to the configuration database. With elevated privileges you will use the the web application app pool’s identitty, which has only read permission to the config db by default. Of course admin user (which runs the central admin should have read and write permissions). See more at: http://joelblogs.co.uk/2010/...


5

EDIT Just like to clear this answer! I've read your question and the answer has to do with the security context that has been put in place for a reason. When using the SPContext.Current.Web or any context appart from .OpenWeb() it is already using the current users security context(read, write,full permissions). Open web is creating a new SPWeb object ...


5

The right way to grant access is to use the SPWebApplication.GrantAccessToProcessIdentity method. It sets up the database permissions for you, but remember to run it again if you add content databases. You can do this with the following PowerShell: $webApp = Get-SPWebApplication TEAM_SITE_URL $webApp.GrantAccessToProcessIdentity("domain\username of MY SITE ...


5

A crawl is never started by anything changing in SharePoint, neither content nor security changes. A crawl is either started manually or according to the specified schedule. If you're using search, then you probably have a crawl schedule set up which does incremental (and sometimes full) crawls. The full crawls with crawl everything and the incremental ...


5

You just need a small change to your PowerShell script. $web = Get-SPWeb http://webUrl $groupOwner = $web.SiteGroups["GroupA"] #this group will own "GroupB" $groupTarget = $web.SiteGroups["GroupB"] $groupTarget.Owner = $groupOwner $groupTarget.Update() For all groups in a web: $web = Get-SPWeb http://webUrl $groupName = "SharePoint Group Name" #this will ...


5

I would look at possibly a workflow that she initiated before she left that had a next step that was triggered in July. I think I have seen this behavior in approval workflows before.


5

Sorry, but there is no way to run at elevated privileges from the client-side, and if there was a way, it would be roughly 0% secure. Depending on what you're trying to achieve, there are some ways that you might be able to work around it. For instance, if you can do it from a workflow, SharePoint 2010 workflows can do an impersonation step which runs as ...


4

There is no such thing as read vs. write access when securing a URL to a web service - You can reference the Web Service URL or you can't. The services themselves are implemented to enforce security just as if you were logged into the site through the browser. Without access to _vti_bin you are pretty much out of luck for any of the SharePoint Web Service ...


4

This mix of AD groups and SharePoint groups is always a problem. You sort of get 2/3 of what you want by using AD groups and 2/3 by using SharePoint groups. It really comes down to what is more important to you. I have a couple of blog posts on this dilemma: http://sympmarc.com/2011/02/16/active-directory-groups-vs-sharepoint-groups-for-user-management-a-...


4

Make the site available over SSL. No point in havign the access to your site in order when anyone can just intercept all the data retrieved by users because the connection to the site they use is not secure. If you don't want to use SSL to access the site from inside your network, you can use SSL offloading (using TMG or a hardware loadbalancer). This ...


4

When you break permission inheritance at library level, all items in the library will have same permissions as your document library. At this point, you are NOT using item level security. When you check the permission of document, it would be "inheriting parent (which in your case is Document Library containing the document)". This is a very valid scenario ...


4

You can set it like this: public static void AssignPermissionsToItem(SPWeb web, SPSecurableObject secObj, SPPrincipal obj, SPRoleType roleType) { if (!secObj.HasUniqueRoleAssignments) { secObj.BreakRoleInheritance(false, true); } SPRoleAssignment roleAssignment = new SPRoleAssignment(obj); SPRoleDefinition roleDefinition = web....


4

Move the UpdateCurrentweb.AllowUnsafeUpdates = true; up before the call to EnsureUser. Maybe even further out depending on what RemoveFromGroup does. There is no need to set it to false unless it's something like SPContext.Current.Web which is passed to other components


4

To remove site permissions for a user, you will have to remove the user from the group to which the user has been given permission to. Sample code would look like this - $site = new-object Microsoft.SharePoint.SPSite("Site URL") $web = $site.OpenWeb() $oSiteGroup = $web.SiteGroups["Group Name"]; $oUsers = $oSiteGroup.Users foreach ($oUser in $oUsers) { ...


4

Well, SPSecurity.RunWithElevatedPrivileges should do the trick. Make sure, you create a new SPSite/SPWeb within the elevated code block: var siteId = SPContext.Current.Site.ID; SPSecurity.RunWithElevatedPrivileges(delegate() { using (SPSite site = new SPSite(siteId)) { //do things on the new site object } });


Only top voted, non community-wiki answers of a minimum length are eligible