Personalized Community is here!
Quickly customize your community to find the content you seek.
Have questions on moving to the cloud? Visit the Dynamics 365 Migration Community today! Microsoft’s extensive network of Dynamics AX and Dynamics CRM experts can help.
2023 Release Wave 1Check out the latest updates and new features of Dynamics 365 released from April 2023 through September 2023
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Community | FastTrack Program | Finance and Operations TechTalks | Customer Engagement TechTalks | Upcoming TechTalks | All TechTalks
Totally new issue for me. In our system (8.2 on premise) I created a new user without any noticeable errors. When the user starts her browser, she navigates to https://ourorganizationurl and gets to logon ADFS. After pressing the [logon] button, she receives a message stating that either her account is disabled or the business unit is disabled.
Both are active. BUT! In the URL of the error message I noticed it stated "The user with SystemUserId 658fcd68-251c-e611-80cd-02bfac10284b in OrganizationContext 0cf95118-02ed-e511-80c5-02bfac10284b is disabled"The orginazation id is correct, but the userid IS NOT HERS (spooky, huh?).The systemuserid in the URL is the one of a former colleague who has left us long time ago. Even his AD isn't active anymore. The only link is that they have exactly the same emailaddress. Before creating the new user, I cleared the emailaddress in the deactivated former colleague hoping to prevent problems. Unfortunately that didn't do the trick.
It looks as if ADFS provides the systemuserid of our former colleague out of a (at least three year old) caching or so. Doesn't make sense, but maybe to you?
Any thoughts on how to solve this?
Hi, I don't think ADFS returns the wrong information(claims) as it queries the Active Directory(assuming default provider that is).
As you mentioned the old and the new user are sharing the same email address and that you cleared it, just to be sure here, was this done in AD or on the disabled User in CRM?
Can we confirm the old collegeau's AD user object wasn't re-used for the new user?
If I were you I would check the ActiveDirectoryGuid column within "SystemUserBase" table and within AD see how the disabled and the new user matches the new colleagues ObjectGUID in AD.
Best regards. /Philip
Hope you are well.
This behavior could be related to wrong info in SystemUserAuthentication (SUA) records (MSCRM_CONFIG database).
Important tables and cardinalities
· SystemUser (aka SU) (GEO)
One record represents one unique user. One user may have an access on multiple orgs.
· SystemUserAuthentication (aka SUA) (GEO)
Authentication information for the user. Usually P: and C: AUTHINFO records are for one user.
· SystemUserOrganization (aka SUO) (GEO)
One records represents user’s access on one organization.
· SystemUserBase (aka SUB) (Organization database)
User record in an organization database.
Would suggest you to apply the "dummy user" procedure:
>Edit the affected CRM user
>Change to an AD dummy user (AD user object which does not belong to Dynamics)
>Change back to affected CRM user
So, using this procedure, you are remapping all references on SU, SUA, SUO and SUB tables.
Business Applications communities