New domain migration (2008 R2 to 2016 DC) - Revision history

Michael.mast at 14:52, 6 August 2018

2018-08-06T14:52:12Z

Michael.mast at 20:27, 31 July 2018

2018-07-31T20:27:10Z

Michael.mast at 20:26, 31 July 2018

2018-07-31T20:26:55Z

Michael.mast: /* Replicate Security Groups */

2018-07-30T22:52:37Z

Replicate Security Groups

Michael.mast: /* Process */

2018-07-30T22:50:07Z

Process

Michael.mast: /* Process */

2018-06-18T15:04:02Z

Process

Michael.mast: /* Process */

2018-06-18T14:59:06Z

Process

Michael.mast at 14:19, 18 June 2018

2018-06-18T14:19:31Z

Michael.mast: Created page with "==Purpose== To switch from old domain "very.long.name.net" to "new.net". The old servers are in a colo, the new ones are in Azure as VMs (Windows 7 support was still needed, s..."

2018-06-18T14:19:10Z

Created page with "==Purpose== To switch from old domain "very.long.name.net" to "new.net". The old servers are in a colo, the new ones are in Azure as VMs (Windows 7 support was still needed, s..."

New page

==Purpose==
To switch from old domain "very.long.name.net" to "new.net". The old servers are in a colo, the new ones are in Azure as VMs (Windows 7 support was still needed, so Azure AD was not usable.)
===Process===
====Tunnels====
The nice Windows minions created the Azure VMs for me and setup the ipsec endpoint, on my end I used PFSense to handle the ipsec tunnel between the colo and Azure. Very straight forward and similar to AWS. One thing I will say that Azure did right over AWS, was to implement IKEv2 and use SHA256. AWS is lagging behind on this, but since we are tunneling encrypted traffic anyway it makes no difference.
<br>
<br>
Just need to have them turn on IPv6 so I can bypass the tunnels altogether.
====Trust====
Creating the trust was simple enough.<ref>http://www.mustbegeek.com/create-two-way-forest-trust-in-windows-server-2008-r2/</ref>
*Create DNS conditional forwarder in the old domain controller to the new domain.
**I did get an error that the IPs I used were not authoritative to the new domain. Does not seem to be an issue for what I am trying to do so moving on from here.
*Create DNS entries in the new servers (My Windows minions did this already. Good for them, except they disabled the firewall!)
*Open up domains and trust on the new server, create the two way connection, enter admin credentials for the old domain.

← Older revision		Revision as of 14:52, 6 August 2018
Line 33:		Line 33:
	<br>		<br>
	<br>		<br>
		+	==File System Access==
		+	Since I plan on using the old domain for authentication, at least for the time being, I need to add the new Domain Local groups created previously so that users in the new domain can be added.
		+	<br>
		+	<br>
		+	NOTE : The new groups I create are prefaced with "new_", thus the replace statement in the following powerhsell script.
		+	<pre>
		+	$sourcedirectory="$home\test"
		+	$grouplist=@()
		+	get-adgroup -Filter {GroupScope -eq "Global"} -SearchBase "OU=SecurityGroups,DC=domain,DC=tld" \| foreach {$_ \| select -ExpandProperty name \| foreach {$grouplist+="domain\$_"}}
		+	get-childitem -Recurse $sourcedirectory \| foreach {
		+	$fullpath=$_ \| select -ExpandProperty fullname
		+	$acloldobj=get-acl $fullpath
		+	$identitylist=$acloldobj \| select -ExpandProperty access \| select -ExpandProperty identityreference
		+	$acloldobj \| select -ExpandProperty access \| foreach {
		+	$FileSystemRights=$_ \| select -ExpandProperty FileSystemRights
		+	$AccessControlType=$_ \| select -ExpandProperty AccessControlType
		+	$IdentityReference=$_ \| select -ExpandProperty identityreference
		+	$IsInherited=$_ \| select -ExpandProperty IsInherited
		+	$InheritanceFlags=$_ \| select -ExpandProperty InheritanceFlags
		+	$PropagationFlags=$_ \| select -ExpandProperty PropagationFlags
		+	if ($grouplist -contains "$IdentityReference") {
		+	$newname=$identityreference -replace '\\','\new_'
		+	if ($identitylist -notcontains "$newname"){
		+	#echo $newname
		+	$newrule=New-Object System.Security.AccessControl.FileSystemAccessRule($newname,$FileSystemRights,$InheritanceFlags,$PropagationFlags,$AccessControlType)
		+	$acl=$acloldobj
		+	$acl.SetAccessRule($newrule)
		+	Set-Acl -Path $fullpath -AclObject $acl
		+	}
		+	}
		+	}
		+	}
		+	</pre>

@@ Line 14: / Line 14: @@
 *Open up domains and trust on the new server, create the two way connection, enter admin credentials for the old domain.
 ==Managing Groups==
-===Basic Structre===
+===Basic Structure===
 The fun here is that I am not a Windows weenie, which makes the process fun to work through how Microsoft wants you to use their group structure. Thankfully I found a VERY useful article<ref>https://blog.stealthbits.com/all-about-agdlp-group-scope-for-active-directory-account-global-domain-local-permissions</ref> on how to best deploy the groups to allow cross permissions to resources during the migration process.
 *In this case I will follow the AGDLP structure to ensure future compatibility. The last domain admins used random groups, and I followed their bad example and the existing group structure is useless.

@@ Line 27: / Line 27: @@
 The following example reads from the old domain, from a system that is already enrolled, then writes to the new domain. The old groups are Global and here I am creating Domain Local<ref>https://technet.microsoft.com/de-de/library/hh852283(v=wps.630).aspx</reF>
 <pre>
-get-adgroup test-group | new-ADGroup -Server 10.99.1.5 -Path "OU=SecurityGroups,DC=youdomain,DC=tld" -GroupScope 0 -Credential $PSCredential
+get-adgroup test-group | new-ADGroup -Server xxx.xxx.xxx.xxx -Path "OU=SecurityGroups,DC=youdomain,DC=tld" -GroupScope 0 -Credential $PSCredential
 </pre>
 <br>
 <br>
 <br>

@@ Line 21: / Line 21: @@
 <br>
 For example; I want to apply an encryption policy if someone logs into a laptop, then a web browser policy for logging into a terminal server, a policy for logging into VDI environment, then a policy for logging into other servers. <ref>https://support.microsoft.com/en-us/help/231287/loopback-processing-of-group-policy</ref> For initial testing I want to use replace processing, or at least I think I do.
 <br>
 <br>
 <br>

← Older revision		Revision as of 15:04, 18 June 2018
Line 16:		Line 16:
	The fun here is that I am not a Windows weenie, which makes the process fun to work through how Microsoft wants you to use their group structure. Thankfully I found a VERY useful article<ref>https://blog.stealthbits.com/all-about-agdlp-group-scope-for-active-directory-account-global-domain-local-permissions</ref> on how to best deploy the groups to allow cross permissions to resources during the migration process.		The fun here is that I am not a Windows weenie, which makes the process fun to work through how Microsoft wants you to use their group structure. Thankfully I found a VERY useful article<ref>https://blog.stealthbits.com/all-about-agdlp-group-scope-for-active-directory-account-global-domain-local-permissions</ref> on how to best deploy the groups to allow cross permissions to resources during the migration process.
	*In this case I will follow the AGDLP structure to ensure future compatibility. The last domain admins used random groups, and I followed their bad example and the existing group structure is useless.		*In this case I will follow the AGDLP structure to ensure future compatibility. The last domain admins used random groups, and I followed their bad example and the existing group structure is useless.
		+	===Group Policy Process===
		+	In this case I want to use loopback processing to ensure that users get different policies based on the computer they connect to.
		+	<br>
		+	<br>
		+	For example; I want to apply an encryption policy if someone logs into a laptop, then a web browser policy for logging into a terminal server, a policy for logging into VDI environment, then a policy for logging into other servers. <ref>https://support.microsoft.com/en-us/help/231287/loopback-processing-of-group-policy</ref> For initial testing I want to use replace processing, or at least I think I do.
		+
		+	<br>
		+	<br>
		+	<br>

@@ Line 1: / Line 1: @@
 ==Purpose==
 To switch from old domain "very.long.name.net" to "new.net". The old servers are in a colo, the new ones are in Azure as VMs (Windows 7 support was still needed, so Azure AD was not usable.)
-==Process==
+<b>Process</b>
-===Tunnels===
+==Tunnels==
 The nice Windows minions created the Azure VMs for me and setup the ipsec endpoint, on my end I used PFSense to handle the ipsec tunnel between the colo and Azure. Very straight forward and similar to AWS. One thing I will say that Azure did right over AWS, was to implement IKEv2 and use SHA256. AWS is lagging behind on this, but since we are tunneling encrypted traffic anyway it makes no difference.
 <br>
 <br>
 Just need to have them turn on IPv6 so I can bypass the tunnels altogether.
-===Trust===
+==Trust==
 Creating the trust was simple enough.<ref>http://www.mustbegeek.com/create-two-way-forest-trust-in-windows-server-2008-r2/</ref>
 *Create DNS conditional forwarder in the old domain controller to the new domain.
@@ Line 13: / Line 13: @@
 *Create DNS entries in the new servers (My Windows minions did this already. Good for them, except they disabled the firewall!)
 *Open up domains and trust on the new server, create the two way connection, enter admin credentials for the old domain.
-===Group Permissions===
+==Managing Groups==
 The fun here is that I am not a Windows weenie, which makes the process fun to work through how Microsoft wants you to use their group structure. Thankfully I found a VERY useful article<ref>https://blog.stealthbits.com/all-about-agdlp-group-scope-for-active-directory-account-global-domain-local-permissions</ref> on how to best deploy the groups to allow cross permissions to resources during the migration process.
 *In this case I will follow the AGDLP structure to ensure future compatibility. The last domain admins used random groups, and I followed their bad example and the existing group structure is useless.

← Older revision		Revision as of 14:59, 18 June 2018
Line 13:		Line 13:
	*Create DNS entries in the new servers (My Windows minions did this already. Good for them, except they disabled the firewall!)		*Create DNS entries in the new servers (My Windows minions did this already. Good for them, except they disabled the firewall!)
	*Open up domains and trust on the new server, create the two way connection, enter admin credentials for the old domain.		*Open up domains and trust on the new server, create the two way connection, enter admin credentials for the old domain.
		+	===Group Permissions===
		+	The fun here is that I am not a Windows weenie, which makes the process fun to work through how Microsoft wants you to use their group structure. Thankfully I found a VERY useful article<ref>https://blog.stealthbits.com/all-about-agdlp-group-scope-for-active-directory-account-global-domain-local-permissions</ref> on how to best deploy the groups to allow cross permissions to resources during the migration process.
		+	*In this case I will follow the AGDLP structure to ensure future compatibility. The last domain admins used random groups, and I followed their bad example and the existing group structure is useless.