"The trust relationship between the primary domain and the trusted domain failed." after upgrade to v5.11

ServiceStack Authentication
1

After upgrading ServiceStack to version 5.11 we get an error while authenticating with AD:

System.SystemException: The trust relationship between the primary domain and the trusted domain failed.
   at System.Security.Principal.NTAccount.TranslateToSids(IdentityReferenceCollection sourceAccounts, Boolean& someFailed)
   at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
   at System.Security.Principal.WindowsPrincipal.IsInRole(String role)
   at ServiceStack.Auth.AspNetWindowsAuthProvider.PopulateUserSessionWithIsInRole(IRequest req, IPrincipal user, IAuthSession session) in 
...

It seems that in commit https://github.com/ServiceStack/ServiceStack/commit/41c7a06720c0fac0a77fb23cb4ba8bfbf71cf4bf a new “Admin” role was added. After googling I found out that this error is often thrown when WindowsPrincipal.IsInRole is called and the group doesn’t exist in the AD (which doesn’t in our case).

Roles are loaded in AspNetWindowsAuthProvider:

appHost.AfterInitCallbacks.Add(host =>
{
	var allExistingRoles = host.Metadata.GetAllRoles();
    allExistingRoles.Each(x => AllRoles.AddIfNotExists(x));
});

since we are not using any additional roles, “Admin” is the only role in AllRoles property.
If I (for example) comment out the code above (so that AllRoles is empty), we don’t get exceptions anymore.

On some servers, this error can always be reproduced, while on some servers it appears randomly.

Can you investigate what is causing this and what is the possible workaround?

Best regards

2

I think your assessment is right regarding it is happening when it can’t find the role in your AD. Looking at other people with the same error it seems that it might be falling back to another way of checking user roles which might explain happens on some machines and not others as it might start depending on domain setup and the specific machine the application is running on, hard to reproduce.

As for work arounds, I think your best bet is to override the default PopulateUserRoles to skip Admin role before checking via user.IsInRole(role). For example,

myAspNetAuthProvider.PopulateUserRoles = (req,user,session) => {
    foreach (var role in AllRoles.Safe())
    {
        if (session.Roles.Contains(role))
            continue;

        if(role == RoleNames.Admin)
            continue;

        if (user.IsInRole(role))
            session.Roles.AddIfNotExists(role);
    }
};

Let us know how you go.

3

Hi,

I’m confirming that the workaround (you posted) works. Since we had a lot of production issues with this case, I would like to ask you if you made and further investigation what is the cause of this error? Will this be fixed (and in which version) in the ServiceStack?

4

Hi @tpetek,

Thanks for confirming the work around works. We’ve updated the logic in the AspNetWindowsAuthProvider to by default ignore the Admin role from GetRoles and included the ability to manage your own list of roles to ignore via the new IgnoreRoles property.

This change was added in this commit and is now available from MyGet from 5.13.3+.