Login using Active Directory accounts fail after upgrade to 4.61 and ASP.NET 2.0

Vote:
 
We have an external website and an intranet runnig as two separate EPiServer sites on the same web server. Editors (and intranet users) log in using their domain accounts. The user groups are synchronized into EPiServer from an Active Directory. After upgrading the external website to 4.61 and ASP.NET 2.0 (the intranet is still running 4.51) it is no longer possible to log in on the external website using the domain accounts. The site is running fine (and performance has improved) and editors can still log in with user accounts created in EPiServer. The intranet is not affected. The error message is: The trust relationship between the primary domain and the trusted domain failed. Stack Trace: [SystemException: The trust relationship between the primary domain and the trusted domain failed. ] System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed) +1167 System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean& someFailed) +42 System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess) +46 System.Security.Principal.WindowsPrincipal.IsInRole(String role) +205 EPiServer.Security.UnifiedPrincipal.IsInRole(String role, Boolean checkLocalGroups) +29 EPiServer.Security.UnifiedPrincipal.ᐂ(DataSet ) +292 EPiServer.Security.UnifiedPrincipal.ᐁ() +47 EPiServer.Security.UnifiedPrincipal..ctor(IPrincipal original, String machineName) +113 EPiServer.Security.WindowsAuthenticationProvider.WindowsAuthentication(Object sender, AuthenticationEventArgs e) +323 EPiServer.Security.AuthenticationEventHandler.Invoke(Object sender, AuthenticationEventArgs e) +0 EPiServer.Security.AuthenticationProvider.Authenticate(Object sender, String username, String password, IPAddress clientIP) +133 EPiServer.Security.AuthenticationProvider.Authenticate(Object sender, String username, String password) +58 EPiServer.Util.LoginBase.Login(String userName, String password, Boolean persistCookie) +15 EPiServer.Util.Login.Login_Click(Object sender, EventArgs e) +91 System.Web.UI.WebControls.Button.OnClick(EventArgs e) +105 System.Web.UI.WebControls.Button.RaisePostBackEvent(String eventArgument) +107 System.Web.UI.WebControls.Button.System.Web.UI.IPostBackEventHandler.RaisePostBackEvent(String eventArgument) +7 System.Web.UI.Page.RaisePostBackEvent(IPostBackEventHandler sourceControl, String eventArgument) +11 System.Web.UI.Page.RaisePostBackEvent(NameValueCollection postData) +33 System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +5102 The only thing that was chaged in IIS for the external website was switching from 1.1.xxx to 2.0.xxx on the ASP.NET properties tab. The IT department can't find any obvious error. Any thoughts as to what might have happened and how it can be fixed? Has anyone run into similar problems?
#17563
Mar 25, 2008 19:33
Vote:
 
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.
#18412
Mar 25, 2008 19:43
Vote:
 
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.
#18413
Mar 25, 2008 19:43
Vote:
 
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
#18414
Mar 25, 2008 19:43
per
Vote:
 
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
#18415
Mar 25, 2008 19:43
Vote:
 
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
#18416
Mar 25, 2008 19:43