I don't know why Microsoft made it such a pain in the ass to get the url for most of the proxy objects on the SharePoint server object model, but in Office 365 it is even worse. Here is an example of how to get a ListItem actual URL and the modified date of the item. Following I will throw the values into a dictionary.
Dictionary urlDict = new Dictionary();
foreach (List list in ListsToProcess)
ListItemCollection items = list.GetItems(CamlQuery.CreateAllItemsQuery());
foreach (SharePointListItem item in items)
list.Context.Load(item, x => x["FileRef"], x => x["Modified"]);
string startUrl = list.Context.Url;
string fullUrl = startUrl + item["FileRef"];
string lastModified = item["Modified"].ToString();
I ran into this issue really recently working at a client with a new, pretty basic ADFS environment that was acting as the identity provider, through an ADFS proxy server relay. I couldn’t wrap my head around why it wasn’t working, the groups themselves were resolving correctly, and even showing up in the identity data sources in the people picker. However, members of the AD securitygroup, (NOT the SharePoint group) were still being denied access to the SharePoint site.
To fix this issue follow these steps:
- Open the federation server box.
- Open the ADFS management console.
- Edit the claim rules for the relaying party trust
- Select the tab Issuance Transform Rules
- Edit the Send LDAP Attributes as Claims
- This should have:
- Claim Rule Name : Pass-through LDAP Claims
- Attribute Store : Active Directory
- Set: Token Groups unqualified names (Don’t Use: Token Groups – Qualified by domain name) | Outgoing ClaimType: Role
- Set: User-Principal-Name | Outgoing Claim Type : UPN
- Open the SharePoint management shell, run the following PowerShell script to create the issuer. If you have an issuer already made, remove it or execute the coordinating update commands. Make sure you replace the $certPath, $realm, and any of the string literals within $ap.
$certPath = your certification path
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“$certPath”)
$map1 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” -IncomingClaimTypeDisplayName “EmailAddress” -SameAsIncoming
$map2 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname” -IncomingClaimTypeDisplayName “Login” â€“SameAsIncoming
$map3 = New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” â€“SameAsIncoming
$map4 = New-SPClaimTypeMapping “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn” -IncomingClaimTypeDisplayName “Account ID” â€“SameAsIncoming
$realm = “urn:” + $env:ComputerName + “:adfs”
$signinurl = “https://yoursigninurl”
$ap = New-SPTrustedIdentityTokenIssuer -Name “ADFS” -Description ADFS 2.0 -Realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map1, $map2, $map3, $map4 -SignInUrl $signinurl -IdentifierClaim $map1.InputClaimType
If you are curious about the way to update, rather than create a new issuer, you can use the following. In the above, you may or may not need all those assertion mappings depending on how your trusted relay issuance rule setup:
$issuer = Get-SPTrustedIdentityTokenIssuer
$map=New-SPClaimTypeMapping “http://schemas.microsoft.com/ws/2008/06/identity/claims/role” -IncomingClaimTypeDisplayName “Role” â€“SameAsIncoming
Now you HAVE to apply KB hotfix 2536591 located here: http://support.microsoft.com/kb/2536591/en-us
Boom! Groups will work.
Just want to the app?
Download here: http://spsecurityscanner.codeplex.com
I recently was at a client doing an audit on the SharePoint environment, and the question of how to do continual scanning on the site for possible system/ web service / and list WebForm exposure. Mimicking and automating this behavior is no big deal, since you are essentially just dispatching requests to various static URLs. The SPList object SPFormCollections can be exposed through the SPList.Forms property, and via web services rather than using the Forms web service you are sorta relegated learning on the SPList content type methods to get access to all customized forms. The SPWeb related ones are better to keep in a mutable file that can be managed.
So da da da! Here is a simple SharePoint security scanner. The composition of the application is actually pretty straightforward; it’s only about three forms. To abstract SharePoint explicit reference requirements the OM and web service assemblies are dynamically loaded at runtime so that SharePoint references are only required when doing OM connection types. Web service ones it shouldn’t really matter.
There are about three steps to get it going:
Start the application:
Click Open Connection:
And choose the connection type, and credential specifications:
When done hit connect, and you will return to the main form. Fill in whether you want to iterate SPList objects:
You can manage the web related urls, since the SPFormCollections are automated, through the Manage Web Inclusion List:
Scan the site, then you can view the results:
So it’s not very fancy, but gets the job done. Have hacky SharePoint fun!