Hello Maria! We have had several reports of the problem and we are currently investigating the reason for this. It seems that there has been API changes in the .NET framework as the problem disappears when changing the .NET framework runtime version for the web site.

I can not tell if this information is related but here are the results of my recent experiments with AD authentication. The text is actually from a different message thread but I add it here for reference. It is possible that my findings actually describe a bug in V4.61.0.83 that only occurs when ASP.NET V2 is installed and AD authentication is used. For AD (Active Directory) authentication to work with groups in the AD it is important that the AD "Domain Functional Level" is set to "Windows 2000 native" or "2003 mode" (and not the NT4 compatible "mixed mode"). If the AD is left in mixed mode then logins will work but the groups the user belongs to can not be properly read by EPiServer. Only machine local groups like Administrators and Users will work, but AD groups will fail. You can upgrade the mode (it can not be reversed though, so make sure you do not have any old NT4 servers or other units that require mixed mode) in the "Active Directory Users and Computers tool" by right clicking the tree name and selecting "Raise Domain Functional Level" in Win2003 or something similar (a button called "Change Domain Mode" instead of a menu option) if you use W2k server. All group types work fine i.e. both domain local, global and universal groups are interpreted by the AD. Any group you wish to use must be specified by name in the group administration dialogue inside EPiServer. How to do this is described in the technote "Security in EPiServer.pdf". In short you just add a group with a name on the format "DOMAIN\Groupname". The change in the AD can take a very long time to activate in EPiServer because login information is being cached by the EPiServer system. To ensure a quick response, log out, log in again and then run "iisreset" on the webserver. There should be a better less interruptive way to do this but I have not found out how yet. Without this procedure you might have to wait for 30 minutes for the AD information to be updated. You do not have to, in fact you should not, specify any LDAP parameters at all! Just leave all these blank since they are only needed for LDAP authentication, not for pure AD authentication. Best regards, Mats B.

This is indeed a change in behaviour from .NET 1.x to 2.0. Seems like Microsoft now exposes more errors as exceptions instead of just silently ignoring them. I had a case where this happened, and the error message was actually correct. There was a trusted domain that could not be reached, and thus, the authentication failed. Some background information on how EPiServer does autorization might be in order. When identified as a windows user, EPiServer will get the complete collection of groups defined in Admin mode, and do an IsInRole on the underlying WindowsPrincipal (this is not specific for Windows users, but all types of users.) If you have groups with names with the domain as part of it ("domain\user"), Windows will only try check the role membership against that domain. Now, if you have a group without the domain part, Windows will try to check all trusted domains for this group membership, and if there is a problem with any of the trust, it will fail with the exception shown above. And this is the change from 1.x to 2.0 - it seems that .NET just ate the exception in previous releases. Look through the groups in admin, and look for any groups that don't have the domain\name pattern. Remove any of those groups that you don't need. If you're only using Windows authentication, the WebAdmins and WebEditors (and other) groups can be created as local machine groups (without users), if you do not want to delete them when testing. I have created a standalone .aspx file that you can copy to your site (without the need of recompiling anything), to test which group(s) that give this exception. I'll send it to anyone that send me an email and ask for it. /Steve

We had the same problem here is how we fixed it 1. In your Active Directory Server select the administrativ tools menu 2. Active Directory Domains and Trusts 3. Select properties on the domain 4. Remove the inactive trusted domains /Per Hassle Thanx Steve

We also experienced this error message but it was resolved thanks to your postings! We simply added empty local Windows groups at the webserver, named "WebEditors" and "WebAdmins" (we want to keep these for a while, in case the db is brought to another environment). However we run inte problems with IsInRole. The AD "is member of" does not match the UnifiedPrincipal GroupList (used in the utility UserInformation.aspx). Christian Wallgren