The stack trace will be this:

At the end of the day though, don't sit around and fiddle with the SharePoint trusted authorities and yada yada yada, it boils down to a certificate problem. Basically the one that was specified as the signing certificate, when exported during the ADFS setup, is either malformed (the certificate chain is incomplete) or plainwrong wrong when the trusted issuer was being built up in SharePoint ala powershell. So to get around the error follow two pretty basic steps.

1. Verify the appropriate certificate chain is present on the SharePoint server in both the trusted root authorities as well as in the SharePoint folder within the Certificate MMC snap-in. Never ever, ever delete the self issued ones that SharePoint provisioned within that folder. You will cause a Micheal Bay-spolosion. To verify the chain, just popup open the certificate details within some interface (like, the MMC :) ) doesn't really matter what and verify that the chain is trusted and existent.
2. Next, verify that you actually used the right certificate when specifying the certificate path when building the System.Security.Cryptography.X509Certificates.X509Certificate2 object to pass into your SPTrustedIdentityTokenIssuer. This is pretty easy to mess up when troubleshooting if you are swapping certs all over the place.

Both of these are in place, then that error will go away. Not that another won't popup :)

To fix this issue follow these steps:

1. Open the federation server box.
2. Open the ADFS management console.
3. Edit the claim rules for the relaying party trust
4. Select the tab Issuance Transform Rules
5. Edit the Send LDAP Attributes as Claims
1. This should have:
2. Claim Rule Name : Pass-through LDAP Claims
3. Attribute Store : Active Directory
4. Set: Token Groups unqualified names (Don't Use: Token Groups - Qualified by domain name) | Outgoing ClaimType: Role
5. Set: User-Principal-Name | Outgoing Claim Type : UPN
6. 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.

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:

Now you HAVE to apply KB hotfix 2536591 located here: http://support.microsoft.com/kb/2536591/en-us

Boom! Groups will work.

So let’s assume I am building the RadScheduler object in something like CreateChildControls like so:

In the above I am missing the RadScheduler.Provider property, so gotta populate that. In this example, I am converting the SPList to a dataset, but you could iterate the items and return the values accordingly taking into account type casting. So I end up in a dataset format with something like this:

You could easily just do the SPListItems:

Once you have the collection of Appointments, you have to make the SchedulerProviderBase superclass. This looks like this:

Then coordinate this class with scheduler Provider property:

This behavior seemed erratic. The problem is ADFS has a Cache Scavenge interval, which is the process for purging out-of-date cache records from the client cache. If your timeouts are configured in a pretty orthodox way, for example a ten minute timeout:

On the SharePoint box:

And on the ADFS box:

But you have your TokenLifeTime set to a ridiculously low value (it always has to be above the LoginTokenCacheExpirationWindow btw) such as two, resulting in a difference of a one minute timeout; the Cache Scavenge will never fire. Thus the issued ticket will be considered valid.

Take away is always just test with something like 10 minutes and deal with the wait time for verification.

I am just setting the value in a master/detail view in a straight forward TextBox. I am not using AJAX or anything so some of the wiring to maintain values is simply to deal with PostBacks. Just looks like this:

Firstly, I am going to use the one from CodeProject, which is used in a lot of apps, for example the SnapStream project. You can view the SVN version here:

http://source.snapstream.com/repos/WebAdministration/controls/ProgressBar.cs

Blah Blah blah here is the code.

The ITemplate to wire up to the custom column:

The template column to add to the grid:

Wire up the data bound event:

Wire up this prerender event to the grid:

Wire up the item created event:

Like I said depending on the technology you are using you might not need like half of those events.