Workflow: Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

July 24, 2015 at 17:38
filed under Dynamics AX
Tagged , , , , , ,

On AX2012 FP the vendor invoice line workflow was throwing the following error which caused the workflow to stop:

Failed to create a session; confirm that the user has the proper privileges to log on to Microsoft Dynamics.

I couldn’t really figure out what was wrong, but the internet said “do a full compile and full CIL”. So I did, it didn’t help.
My colleague had a blog post about this error but that was about partitions and these are only available on R2 and R3, not on Feature Pack, so that was no help either.

After some debugging, it was clear that the error was thrown when the runAs function was executed. So I created a class and put the following method in it to test which users could not execute the runas function successfully. In this example I use the SysWorkflowDocument::assertAsUser method but it is better to create your own empty static method to test with. Remember that you have to perform an incremental CIL compilation after you have created a new static method to use in the runAs function.

public static server void main(Args _args)
{
    container   result, args;
    UserInfo    UserInfo;

    while select id from UserInfo
    {
        try
        {
            new RunAsPermission(UserInfo.id).assert();
            result = runAs(UserInfo.id, classNum(SysWorkflowDocument), staticMethodStr(SysWorkflowDocument, assertAsUser), args);
            CodeAccessPermission::revertAssert();
        }
        catch
        {
            CodeAccessPermission::revertAssert();
            info(UserInfo.id);
        }
    }
}

This gave me a list of all users that were causing problems. Everything seemed fine with these users, so I decided to check if the SID in the UserInfo.sid field matches those on the domain for those users. I didn’t. Most likely these users were deleted on the domain and recreated with the same username, but a different SID. After the users were deleted in AX and the imported again, the error disappeared.

By the way, you can retrieve the SID of a domain user using Windows PowerShell with this command:

$objUser = New-Object System.Security.Principal.NTAccount("YOURDOMAIN", "YOURUSERNAME")
$strSID = $objUser.Translate([System.Security.Principal.SecurityIdentifier])
$strSID.Value

2 comments

RSS / trackback

  1. Tim De Lobelle

    on February 26, 2018 at 17:22

    http://sinedax.blogspot.be/2013/07/update-ax-user-sid.html

    Script to update Userinfo table with new SID:

    static void UpdateSID(Args _args)
    {
        UserInfo                UserInfo;
        AxaptaUserManager       aUserManager = new AxaptaUserManager();
         DomainName              networkDomain;
        Sid                     sid;
        ;
         networkDomain = (select networkDomain from UserInfo
                          where UserInfo.id == curUserId()).networkDomain;
         info(networkDomain);
         while select forUpdate UserInfo
            where  UserInfo.networkAlias
                && UserInfo.id != “Guest”
        {
            try
            {
                ttsBegin;
                 info(UserInfo.networkAlias);
                 sid = aUserManager.getUserSid(UserInfo.networkAlias, networkDomain);
                 if( !sid )
                {
                    warning(strFmt(“Utente %1 non presente in active directory, domain %2”, UserInfo.name, networkDomain));
                    continue;
                }
                 UserInfo.networkDomain  = networkDomain;
                UserInfo.sid            = sid;
                UserInfo.update();
                ttsCommit;
            }
            catch
            {
                warning(strFmt(“Impossibile modificare l’utente %1”, UserInfo.name));
            }
        }
    }

  2. Don Bingham

    on March 31, 2021 at 22:29

    Thanks for this post. I would have spent quite a while tracking down this issue since all the other posts for this error message seem to relate to DB sync issues.

respond