Azure SCIM prepends email with random id

Question

We at miro.com support SCIM protocol and have an app in Azure Marketplace https://azuremarketplace.microsoft.com/en-us/marketplace/apps/aad.realtimeboard
We have many Customers who have successfully configured the integration between Azure and Miro and can manage Users and Groups automatically.
However we have a Customer who claims that the integration between Azure and Miro works very odd. The Customer claims that any attempt to deactivate the User in Azure results in User's email in Miro modified and prepended with some random id. We searched the logs on Miro side and indeed can confirm this

{  
    "schemas":  
    [  
        "urn:ietf:params:scim:api:messages:2.0:PatchOp"  
    ],  
    "Operations":  
    [  
        {  
            "op": "Replace",  
            "path": "active",  
            "value": "False"  
        },  
        {  
            "op": "Replace",  
            "path": "emails[typeeq\"work\"].value",  
            "value": "******@email.com"  
        },  
        {  
            "op": "Replace",  
            "path": "userName",  
            "value": "******@email.com"  
        },  
        ... few more attributes changed  
    ]  
}  

We at Miro could not reproduce this behavior within our test Azure account. Neither we found any anomalies in the Attribute Mappings on the Customer side.
Could you please clarify, under which circumstances does Azure issue a SCIM request like that? Why does Azure attempt to prepend the userName attribute someuser@tiedtlaw email .com with some random id? According to the Customer this happens automatically upon the User deactivation and isn't expected.
We adviced the Customer to contact directly with Azure support. However we at Miro also would like to know the root cause.

Answer 1

Hi @Aleksandr Dorogush ,

The behavior you are describing is by design.

The Azure AD Provisioning service reads data about users and groups via AAD Graph. When a user is soft-deleted (and placed in the Azure AD recycling bin), it is returned via AAD Graph/MS Graph with the ObjectId value prepended to the UserPrincipalName value. This is expected behavior, and if your customer is seeing it inconsistently they should open a support case via portal.azure.com to receive assistance in determining the cause of any unexpected behavior.

See also:
Azure AD SCIM adding suffix and prefix to username when Deleting User
Azure AD SCIM random ID in "userName eq"

Let me know if this helps.