Setting up ADC using gMSA - and ADC concepts in general

Connector concepts

1. for an ADC service, on one side, it's on-prem AD, on the other, it's AAD. 
2. ADC is therefore divided with 3 components: connector space to AD, metaverse, and connector space to AAD
   
   
   
   
   
   
   
   
   
3. With these 3 components in mind, there are below operations can be performed
1. Take connectors for AD for example, import from AD (to pick up new changes in AD), this picks up AD object and create a corresponding staging object in Connector Space
2. or to export to AD (for writeback), this exports staging object to AD
3. Synchronization: meaning create metaverse objects from staging objects, then create staging objects on the connector space other side of flow
4. Same operations are applicable on AAD connectors in same way
4. Seamless SSO VS. AADj-join SSO. 
1. Seamless SSO: 
1. For AD users on on-prem device to access cloud resource
2. Leverage a computer object in on-prem AD to represent Azure AD. When a Windows AD user access cloud access, in the background the user is redirected to access the computer object first and get a kerberos ticket, which can be sent to, and decrypted by AAD.
2. Azure-joined SSO (aka Azure Kerberos)
1. For AAD-join device to access on-prem resources
2. Same concept of having a computer object in on-prem AD representing Azure.
3. Azure uses the computer object to acquire partial Kerberos TGT for user. User then use it to acquire full TGT from AD

Steps

1. Create a security group for hosts that will be running ADC service, place all host as member "ADCHosts"
2. Create the gMSA account
1. Import-module ActiveDirectory
2. Add-KdsRootKey -EffectiveImmediately
3. New-ADServiceAccount -Name ADCsvc -Description "gMSA for Azure AD Connect installation" –DNSHostName ADCsvc.johnfoo.tk -principalsAllowedToRetrieveManagedPassword ADChosts
   
   Note: param DNSHostName doesn't really do anything here other than used for populating gMSA's DNSHostName attribute.
3. On ADC server, install gMSA account
   
1. Install-ADServiceAccount -Identity ADCsvc$
   Note: 
1. don't forget the $ sign at the end, remember this is really a computer account
2. If you get access denied error, reboot ADC host for membership change in step 1 to take effect
4. Run ADC Installer
1. custom installation
2. use existing service account
3. specify "johnfoo\adcsvc$" fun ADC service itself
4. specify a "Global Administrator" for AAD
5. specify an existing account or let ADC installer creates a new account for on-prem AD. This account needs DC Sync (replication) permission. 
   Note: the account created by installed is called "MSOL_*" under "users" container. To get the exact name, check ACL entries on top of domain that has DC Sync permission
5. If you use ADC to sync extension attributes (e.g. employeeType), there should be an app in AAD called "Tenant Schema Extension App" , this is where you can find App ID so you can retrieve extension attributes (for example, create a dynamic group based on an extension attribute)

How to initiate a manual sync (see figure above)

1. open "Synchronization Service"
2. On "Operations" tab, right click a connector that is for AD, run, import, or
   On "Connectors" tab, right click a connector for AD, run, import
3. then Run -> sync on both sides
4. Finally export on AAD connector

How to change existing sync rules

1. use Synchronization Rules Editor
2. A rule defines scoping/filter/join rules/transforming rule
3. Understand rule types for different phase of operations: provision/join/
4. Example: if you want to change "sync criteria" (a.k.a "how to uniquely identify users cross forest", which is not possible to be changed using ADC configure GUI once initially set up), this can be done by editing rule for AD inbound rule for user, interOrgPerson, AccountEnable etc., page "join rule" 
5. special notes for "join rules", while there can be multiple sync rules for a connector source, there can be ONLY one sync rule that defines join rules. Such sync rule will have "join" at end of the sync rule name. So for example above, you only need to find and make changes in "inbound from AD * join" rules
6. see here
   

Notes:

1. If install ADC on a member server, Virtual Service Account is recommended
2. Duplicate attribute resiliency Instead of failing to provision objects with duplicate UPNs / proxyAddresses, the duplicated attribute is “quarantined” and a temporary value is assigned.
3. UserPrincipalName soft match When this feature is enabled, soft-match is enabled for UPN in addition to the primary SMTP address, which is always enabled
4. What should be used as sourceAnchor: 
1. ObjectID if single forest; 
2. still ObjectID even in multi-forest scenario, or use something won't change even when moving user between forests. 
3. EmployeeID would be one if uniqueness can be guaranteed
4. For where you don't have a proper attribute to use, Microsoft provides ms-DS-ConsistencyGuid
5. Predecessor: DirSync -> Azure AD Sync
   Sibling: Azure AD Cloud Sync