Risk converting Domain Local Groups to Universal prior AD migration?

Question

Hello

We're starting a large scale inter-forest Active Directory migration. Source domain has almost 15,000 security groups. 1000 of those groups are Domain Local Groups.

In one of our previous migrations we migrated all security groups first (Universal, Global and Domain Local) and merged sid history to user accounts. Later, when we had started server migration, we were surprised by the fact that there was still large number of end users in source domain, who were still using their source domain PCs and user accounts. They already had their migrated account in target domain and target domain PC but they had some reasons to keep using old PCs.

Servers we migrated had lot folder permissions set using Domain Local Groups. When member server changed domain, all those permissions set with source domain local groups seized working, which is by design. Next, we start receiving complaints from lot of users that they were not able to access migrated servers using their source domain accounts anymore. Permissions on migrated servers were working fine with target domain accounts, because those were members of migrated domain local groups.

Now we're planning our next migration. I'm considering should we convert those 1000 Domain Local Security Groups to Universal before we start our migration. I'm pretty sure that some permissions on the member servers are set using those DLG groups. Just want to avoid that same pitfall with member servers. Of course there is limitation on converting, that DLG can not have other DLG:s as a member, otherwise conversion fails.

Do you think this is good idea and is there any risk converting those groups?

Answer 1

Hi @weedee

Yes, it can be quite complicated when you are dealing with 1000's of groups to replicate the users, so much so, I ended up writing an application specific to manage migrations, that was used to orchestra migration batches and supported discovery, scheduling, and replication of details between domains, this included the replication of group membership in both directions.

Why I wouldn't change the groups type: when changing a group from domain local to universal, you are changing the scope of the group, and what members you can be added to the group, i.e. you will no longer be able to added users from externally trusted domains, which could impact how users access resources pre and post migration, which might require you to change the access model for all the resources that use these groups. The another issue, in this scenario, if you have a multiple domain forest, this change will increase the replication traffic, as now all group membership changes need to be replicated to the global catalog on all domain controllers in the forest. This is not a problem if you have a single site, but if you have multiple sites in different countries, this could impact bandwidth requirements. The other issue which is hard to define, and is normally unknown until after the change, is hardcoded dependencies normally associated to applications.

I hope this helps.

Gary.

Answer 2

Hi @weedee

It's difficult to give a definitive answer with the limited information provided but I wouldn't convert the domain local groups to universal groups. The method that I've used before, is to create the corresponding local groups in the target domain and then add both the corresponding target and source users to the new target local groups. Then dual permission the server so that both source and target groups have permissions on the server resources. This way both the source and target users will be able to access the server while it's still in the source domain.

Depending on migration sequence you may need to also add target users to the source domain local groups.

As I said in my answer to your other post, yes is take a little more work, but there is no reliance on SID history, which is a big bonus.

Gary.

Answer 3

Hello Gary,

First, many thanks for your response to my question. Really appreciate your insights and thoughts.

I recalled that in our previous migration, how we fixed the access issue with source domain users was that we add them to migrated Domain Local Groups. Those migrated Domain Local Groups already contained target domain users ADMT added. So maybe we used same approach as you. But adding those source domain users to right groups in target domain required some heavy scripting with PowerShell but luckily my college was available to help with that.

What are your thougths on why converting those groups is not so good idea? ( And I'm having second thoughts about this as well ) Right now, I'm just seeing that would be easier way to facilitate resource access for those users who need to use source domain accounts after member server is migrated to target domain.

Thanks again.