AADDS How to prevent unexpected SID changes?

Question

AADDS How to prevent unexpected SID changes?

Mike Gilbert 51

I have a fairly vanilla hybrid setup:
On Premise AD->(ADSync)->Azure AD->Azure AD DS.
I have used the cloud domain implemented by Azure AD DS to implement domain-joined file shares in a storage account (populated from on-premise with File Sync), which are in turn referenced by a domain-joined Azure Desktop. The SIDHistory is coming from the on-premise domain, all is well.

Then yesterday users started complaining that their FSLogix profiles had been re-initialized when logging into the Azure Desktop, so all their customizations and personal files had been lost.

I investigated and I found many users had a second profile, BECAUSE AADDS HAD CHANGED THEIR SID! For example, if a user had an AADDS SID ending in 1129, suddenly they had a SID ending in 1171 instead! (The rest of the SID, which is tied to the organization, remained unchanged.) Login still worked, the SIDHistory was still there, but FSLogix, which is based on the SID, thought they were a completely new user and created a second profile.

I can't login to the AADDS DC's so I can't look at their event logs. What could possibly have happened to AADDS to make it decide it needed to assign new SIDs to users? This AADDS has been stable for months with pretty much the same list of users; I was tinkering with the area that controls which groups are synced from Azure, but that shouldn't affect user accounts.

I don't think I can reverse this change as much as I would love to, so users can get their profiles back. But how can I tell what happened, so it never happens again??

Thanks

Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2022-11-11T06:11:04.123+00:00

@Mike Gilbert Thank you for reaching out to us, let me investigate on this issue and will revert back.
Mike Gilbert 51 Reputation points

2022-11-11T06:43:19.77+00:00

Hi, Thank you for investigating this issue. FYI we run Dynamics GP Management Reporter in a VM that we migrated from on premise to Azure under AADDS.

The Management Reporter permissions are all based on SIDs so we had to go through a complex rights recovery process when we first moved this VM to Azure.

Since I submitted my original question, we've discovered that this sudden SID change meant we had to do the rights recovery process for Management Reporter a second time, a real pain.

We certainly don't want this to happen a third time! If you need to know what our specific AADDS instance is so you can review logs or do other troubleshooting, please let me know. I look forward to hearing what your investigation reveals so this will never happen to us again.
Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2022-11-15T13:34:08.073+00:00

Hi @Mike Gilbert Just checking in to see if below information was helpful or not. Did you got a chance to open a support ticket to investigate this further, if you have any further questions, please let me know.

Accepted answer

0 additional answers

Your answer

Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2022-11-11T06:11:04.123+00:00

@Mike Gilbert Thank you for reaching out to us, let me investigate on this issue and will revert back.
Mike Gilbert 51 Reputation points

2022-11-11T06:43:19.77+00:00

Hi, Thank you for investigating this issue. FYI we run Dynamics GP Management Reporter in a VM that we migrated from on premise to Azure under AADDS.

The Management Reporter permissions are all based on SIDs so we had to go through a complex rights recovery process when we first moved this VM to Azure.

Since I submitted my original question, we've discovered that this sudden SID change meant we had to do the rights recovery process for Management Reporter a second time, a real pain.

We certainly don't want this to happen a third time! If you need to know what our specific AADDS instance is so you can review logs or do other troubleshooting, please let me know. I look forward to hearing what your investigation reveals so this will never happen to us again.
Givary-MSFT 35,626 Reputation points Microsoft Employee Moderator

2022-11-15T13:34:08.073+00:00

Hi @Mike Gilbert Just checking in to see if below information was helpful or not. Did you got a chance to open a support ticket to investigate this further, if you have any further questions, please let me know.

Answer 1

Givary-MSFT 35,626 Microsoft Employee Moderator

@Mike Gilbert Discussed your issue with our engineering team.

As per the discussion I had about your issue changing the groups that are sync’d, this is likely the root cause of the problem (the users being sync’d are dependent on the groups that are in/out of scope). We’ll need to look at the metadata to figure that out.

If you have a Azure Support plans with your subscription, open a support ticket, they can further engage the engineering team to investigate your issue further or if you dont have a valid support plan, let me know we can assist creating a one-time support ticket for this issue.

Let me know if you have any further questions.

Please remember to "Accept Answer" if answer helped, so that others in the community facing similar issues can easily find the solution.

Mike Gilbert 51 Reputation points

2022-11-15T20:04:04.233+00:00

Hi,
Thank you for your response. Based on your answer, what I think might have happened is I might have removed one group that contains many users and then added another one -- and that brief interval was enough to trigger AADDS to delete all the users that are not named elsewhere.

At least I know what to be careful of now.

This is way too easy to trigger accidentally. As a suggestion, you guys should store the user SID in the metadata so if the user is deleted and then re-created, you can re-assign the same SID.

Alternatively (or you could do both), you could at least display a warning when a user starts to remove a group, like "removing this group will delete 74 user objects. Would you like to continue?"

Share via

AADDS How to prevent unexpected SID changes?

0 additional answers

Your answer