Category: Security

I ran into the following error while traversing certain user’s security groups in Active Directory:

System.DirectoryServices.AccountManagement.NoMatchingPrincipalException: An error occurred while enumerating the groups. The group could not be found.

The error was thrown when calling GetAuthorizationGroups() on line 3:

PrincipalContext adServer = new PrincipalContext(ContextType.Domain, CasRolesConfig.ADServer);
UserPrincipal adUser = UserPrincipal.FindByIdentity(adServer, samAccountName );
PrincipalSearchResult<Principal> adAuthGroups = adUser.GetAuthorizationGroups();
foreach (Principal adAuthGroup in adAuthGroups)
    string groupName = adAuthGroup.Name;
    // [...]

The error occurs when the group or child group contains a ForeignSecurityPrincipal. Microsoft has confirmed it as an issue and a bug has been raised internally.

Read more

I encountered some strange behavior while implementing role-based security. The web application would get stuck in an endless loop at around 16h00 every day. This only happened while running on the web server and could not be reproduced locally in a development environment.

The problem was that the Central Authentication Service (CAS) would invalidate the session tokens after 8 hours. And since most people start at 08h00, the problem would only manifest after 16h00. At this point, the authentication system and the response filter started a tug o’ war – the authentication system trying to redirect the response to the login page and the response filter trying to flush the filtered response back to the client.

Special thanks to Mike D for figuring it out, without even looking at a single line of code… I had to hand over one of my hats.

The solution was simple – to bypass the filter if the response is being redirected (301), line 11:

public class WebApplication : System.Web.HttpApplication
    public WebApplication()
        ReleaseRequestState += new EventHandler(OnReleaseRequestState);

    void OnReleaseRequestState(object sender, EventArgs e)
        // Ensure that the request is not being redirected before applying the filter
        if (HttpContext.Current.Response.StatusCode == (int)HttpStatusCode.Redirect)

        // Install the filter
        var response = HttpContext.Current.Response;
        var request = HttpContext.Current.Request;
        response.Filter = new SecurityFilterStream(response.Filter, request);


Enabled loadFromRemoteSources as the plugins weren’t being picked up anymore because of a change in the .Net Framework.

From MSDN:

In the .NET Framework version 3.5 and earlier versions, if you loaded an assembly from a remote location, the assembly would run partially trusted with a grant set that depended on the zone in which it was loaded. […] If you try to run that assembly in the .NET Framework version 4 and later versions, an exception is thrown; you must either explicitly create a sandbox for the assembly, or run it in full trust.

So I added the following to app.config to get it working again:

    <loadFromRemoteSources enabled="true" />