This post is just for me. I want to find this piece of information again whenever I might need it:

The problem: we wanted to avoid creating 20  App-V packages or entries in SCCM just because there’s groups of people having different connection URLs. For now we’d like to have this URL as a property of the AD group we use to assign the App-V application with.

The solution: create a pre-execute script which performs an LDAP query to retrieve the property of the group the user is a member of and set that URL as a user variable. Within the App-V package you can then simply reference that user variable (%APP_URL% for example).

The clarification: It seems to be by design that you can successfully set user variables with a pre-execute script, but you can’t read them within that bubble! Here’s the official answer: KB959452

The solution: we dropped the user variable idea and changed or pre-execute script to generate the application its config files.

One of the things which pops up quite fast when working with SharePoint and claims based authentication is the weird identifiers you find throughout SharePoint. In one of my troubleshooting sessions I stumbled upon this post which provides a nice picture of the meaning of several parts of an encoded claim.

The post : How Claims encoding works in SharePoint 2010

The picture: Link to original picture (larger)

One thing I came across as well is that when you encode a principal in PowerShell, the shell isn’t capable of showing all encoded strings. Especially the 6th character is often displayed as a ? while in reality it’s some exotic character. The following lines of PowerShell code should print the SharePoint representation of the given claim (with it’s type and value)

• $mgr = Get-SPClaimProviderManager
• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType http://schemas.customer.com/claims/technicalrole -TrustedIdentityTokenIssuer $tp
• $mgr.EncodeClaim($claim)

However if you want to see how the encoded claim really looks, I advise you to capture the output of $mgr.EncodeClaim($claim) and pipe it to Out-File claim.txt E.g.

• $mgr.EncodeClaim($claim) | out-file claim.txt

To conclude this post, I would advise to never hardcode any encoded claims in your scripts or code. After all the 4th character is generated on a per farm base and could very well be different in another SharePoint environment. As long as you keep encoding the claim based upon the actual input (claim value, type & provide), you should be safe though.

Due to me being creative with the FIM 2010 R2 Password Reset feature, I had to change some of the strings which are displayed during a password reset action on the password reset site. Luckily the FIM product team has foreseen this and allows you to customize whatever string you like. They’ve got it detailed over here: TechNet: FIM 2010 R2 Portal Customization

I stumbled across some things though:

In the guide they seem to suggest that you have to name resources files as Strings.<country>-<locale>.resources. To be honest I never tested naming the files like this. From what I could see from other files (like the DLLs in the folder) I could see that there’s no need to add the <country>. I simply named them Strings.<language>.resources and I can confirm that this works. This makes supporting different locales a lot easier. It’s also consistent with the DLLs (their filenames) the language packs add.

Conclusion #1: if you are having troubles getting your customizations work, try dropping the <country> from the filename.

However, once I got my files in place my customizations weren’t visible in IE. Luckily the event log showed me an error I could continue with:

In words:

I opened a file and tripple checked the XML syntax. All seemed fine. Then I saw this:

After some googling and thinking I came to the conclusion the encoding of the XML file was the problem. Using Notepad++ (a great utility btw!) you can simply open the file, change the encoding and save the file.

Conclusion #2: if you are having troubles, make sure your encoding of your resource files is set to UTF-8?

And some bonus information: If you want to copy paste the default values for some of the strings you can reverse engineer the DLL’s provided by the product. I had some troubles finding ALL strings.

Some of them are located here: C:\Program Files\Microsoft Forefront Identity Manager\2010\Password Reset Portal\bin

But there’s also strings which are in DLL’s which are not in the product folder but in the GAC: c:\Windows\assembly\GAC_MSIL\Microsoft.IdentityManagement.CredentialManagement.Portal.Gates.resources

I have a colleague who wrote a Custom Claim Provider for a SharePoint deployment which uses ADFS as its authentication provider. The goal of the custom claim provider was to ensure that the people picker would resolve things by searching our Active Directory. One of the other things we were working on was to set permissions on certain sites from within .NET code. Online we found several ways to get this task done, but my colleague kept running into an ArgumentException error.

I tried to simulate what he was doing in PowerShell. Our troubleshooting would benefit from this as a typical refresh of the custom code on SharePoint takes several minutes. One thing we quickly found out that it was working for a claim type we’ve had available in SharePoint and which was also specified in the claims provider. However lately we registered a new claim type in SharePoint, and for some reason this was not being accepted. Here’s how we registered it:

From a SharePoint PowerShell prompt:

• $claimType = http://schemas.customer.com/claims/entity
• $claimTypeSPS = "Entity"
• $ti = Get-SPTrustedIdentityTokenIssuer "Cust ADFS Provider"
• $ti.ClaimTypes.Add($claimType)
• $ti.Update()
• $map = New-SPClaimTypeMapping –IncomingClaimType "$claimType" –IncomingClaimTypeDisplayName "$claimTypeSPS" –SameAsIncoming
• Add-SPClaimTypeMapping –Identity $map –TrustedIdentityTokenIssuer $ti

Typically this should be enough to start using the claim type “Entity” in SharePoint. However when we executed the following lines:

• $mgr = Get-SPClaimProviderManager
• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType http://schemas.customer.com/claims/technicalrole -TrustedIdentityTokenIssuer $tp
• $mgr.EncodeClaim($claim)

We stumbled upon this error:

In words: Exception calling "EncodeClaim" with "1" argument(s): "Exception of type 'System.ArgumentException' was thrown.
Parameter name: claimType"
At line:1 char:194
+ $claim = New-SPClaimsPrincipal -ClaimValue "readPermission" -ClaimType "http://schemas.customer.com/claims/entity" -TrustedIdentity
TokenIssuer $tp -IdentifierClaim:$false;$mgr.EncodeClaim <<<< ($claim)
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : DotNetMethodException

So we started digging into it. Long story short, as far as we can tell, from the moment you specify a custom claim provider on your Security Token Issuer, you must include all claims of the security token issuer in the custom claim provider. You can easily check which claim types are currently visible to SharePoint by executing the following lines:

• $cp = Get-SPClaimProvider -Identity "ADFSClaimsProvider"
• $cp.ClaimProvider.ClaimTypes()

Remark:

1. Don’t confuse the Get-SPTrustedIdentityTokenIssuer and the Get-SPClaimProvider.
2. Often the name of the custom claim provider is the same as it’s proper name, but without spaces. This property is also called the internal name.

Here’s a screenshot, I could clearly see that Entity was not included:

And here’s a small code snippet:

Now after adding the claim type in the code, and redeploying the necessary assemblies, things still didn’t work. As far as we can tell the following actions are also required:

1. Restart your SharePoint PowerShell shell
2. Run the Update() method on the Claim Provider Manager ($mgr = Get-SPClaimProviderManager and $mgr.Update() )

And now we can see that we can successfully encode the claim:

Conclusion #1: whenever you write a custom claim provider, make sure to include all the claim types you want to use for that Token Issuer. It doesn’t matter whether you only want to add them programmatically or if you want them to be available for regular users through the graphical interface.

However, after this we were still having issues. We were trying to add the encoded claim as a member of a SharePoint group. This would allow people having the specified claim to access the site we are securing. Here’s the command we executed:

• $tp = Get-SPTrustedIdentityTokenIssuer -Identity "Cust ADFS Provider"
• $url = https://sharepoint.customer.com
• $group = "Visitors"
• $claimType = http://schemas.customer.com/claims/entity
• $claimValue = "DepartmentX"
• $web = Get-SPWeb $url
• $SPgroup = $web.SiteGroups["$group"]
• $principal = New-SPClaimsPrincipal -ClaimValue $claimValue -ClaimType $claimType -TrustedIdentityTokenIssuer $tp
• $SPprincipal = New-SPUser -UserAlias $principal.ToEncodedString() -Web $web
• $SPgroup.AddUser($SPprincipal)

So we are still having issues with the claim types we added. The error makes me suspect the resolving capabilities of the custom claim provider. After some googling I finally found this post: Adding users and claims to a site from PowerShell Here’s the relevant part:

Conclusion #2: whenever you write a custom claim provider, make sure to provide fillResolve capabilities for your custom claim types. I don’t think you are obliged to add them to the fillResolve method which takes a string as value to resolve, but you have to add them to the fillResolve method which takes an SPclaim as value to resolve. You can then simply put an if statement to auto-resolve everything of the claimtypes you don’t want to be looked up.

you can add this in the protected override void FillResolve(Uri context, string[] entityTypes, SPClaim resolveInput, List<Microsoft.SharePoint.WebControls.PickerEntity> resolved) method

if (resolveInput.ClaimType == CustClaimType.Entity)
{
    resolved.Add(GetPickerEntity(resolveInput.Value, resolveInput.Value, resolveInput.ClaimType));                   
    return;
}

Some more background reading:

• MSDN: Claims Walkthrough: Writing Claims Providers for SharePoint 2010
• Custom Claims Providers: Hierarchical Claims - Part 3, Claims Picker Surfacing and Authorization

Lately I assisted in troubleshooting an issue where users trying to start an App-v application where continuously prompted to enter their credentials. Entering the correct credentials did not matter. We found out pretty fast that this had to do with IIS not being able to handle the Kerberos tickets. If we’d put the NTLM authentication on top of the Negotiate provider all was fine. Rebooting also did the trick. But these are just workarounds…

Eventually after some googling I stumbled across this KB article: KB2545850 It seems that whenever a server (computer) changes its password and IIS is restarted somewhere after that, the application pool no longer can decrypt the tickets it receives resulting in an authentication failure. This is a patch which applies to both RTM and SP1 for Windows 2008 R2.

One of the things I noticed during my latest UAG project is that users seemed to be redirect to some sort of error page. In short: if they logged on to a SharePoint site published over UAG and then had their session time out, after click “ok”, they’d be presented with the “You have attempted to access a restricted URL” error.

Using the UAG web monitor, I was able to get a more specific error:

A request from source IP address x.x.x.x, user to trunk secure; Secure=1 for application Internal Site of type InternalSite failed because
the URL /InternalSite/SessionTimeout.asp?site_name=secure&amp;secure=1 must not contain parameters. The method is GET.

So I started investigating the URL Set of the trunk where I was seeing the issue. I could indeed see that the rule didn’t not expected (allowed) parameters. The rule in question was for the URL /InternalSite/SessionTimeout.asp

I peeked around, and I found out that the rule /InternalSite/setpolicy.asp had these exact two parameters. This made adding them to our rule pretty easy, just click each parameter and chose the copy (and paste) option.

After pasting the rules we needed to perform some minor modifications:

• Change the rule to Handle (instead of Reject) parameters
• Modify the Existence to Optional

Save and activate the configuration and now your users shouldn’t be presented with this unexpected message.

I’m currently involved in a project where we publish multiple SharePoint sites using UAG 2010. These SharePoint sites require users to be authenticated using claims. These claims are provided from an AD FS 2.0 farm. When we first applied SP2 for UAG in our lab we noticed that our Single Sign On experience was broken. When we visited a SharePoint URL, we expected to be greeted with the UAG logon form followed by the SharePoint site itself.

Here’s the UAG logon form:

However, after choosing login we saw the following login form. It was fixed to our “ADFS” server we defined in UAG. No matter what credentials we entered, we didn’t got past this form.

After reverting the virtual machine its snapshot, yes I took one! ; ) I could see that SSO was working again as expected. So I switched back the snapshot to where SP2 was installed and started troubleshooting. I tried several things, but nothing worked. So in the end we logged a case with Microsoft. One of the things I had tried, and which the engineer asked me to do as well was the following:

This was how I set it up the authentication of one of the SharePoint sites initially:

This is how he asked me to set it up:

After changing this setting, we got rid of the second form, but now we got an additional “basic authentication” login popup…. After sending over some debug logs and so the engineer suggested to revert back the snapshot to before installing SP2 and to try reinstalling SP2. And I still have no idea why, but everything worked after reinstalling SP2.

Bottom line: when publishing a site which uses claims for authentication, you shouldn’t specify AD FS as an SSO server for the published site. The web application will redirect the user to the ADFS service, and UAG handles SSO towards the ADFS service. But with UAG 2010 pre SP2 either approach worked fine so I didn’t questioned this.

Here you can see an other (unrelated) change in the ADFS configuration when using claims based authentication for the UAG trunks. Before you had to explicitly check “allow unauthenticated access to the web server”. After SP2 the check box is gone.