Azure AD Connect - Import users/One-way-sync only

Gregor Papez 26 Reputation points
2021-11-23T13:22:44.337+00:00

Hi,

our Users were all created and managed in Cloud (admin.microsoft.com). Each of them has Sync status "In Cloud". Our goal is to set-up new Server which will then, using Azure AD Connect Sync the users on the On-Prem server. The sync should not touch users In Cloud, only "pull" them through scheduler.

The last time I've did this, something bad happened while Syncing and quite a few Users and Shared Groups were unable to Login anymore, their Password was reset and the Sync-status for that specific users was set to "On-Premise".

To avoid same issue happening again I would politely ask for a "way-to-go" to create one-way-sync only, that means the AD Connect should only copy users from Cloud locally and never change the Cloud Users.

I was checking the Custom filters but am not 100% sure if this is the path I should follow (https://learn.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-sync-configure-filtering)

Any support would be much appreciated.

Microsoft Security | Microsoft Entra | Microsoft Entra ID
{count} vote

Accepted answer
  1. Marilee Turscak-MSFT 37,206 Reputation points Microsoft Employee Moderator
    2021-11-24T20:14:05.293+00:00

    Hi @Gregor Papez ,

    "AD Connect should only copy users from Cloud locally and never change the Cloud Users."

    Are you trying to apply user writeback, or is your goal to synchronize the users initially from on-prem, but then not change any attributes after the initial sync?

    Azure AD Connect will only sync users from on-premises to Azure, as user writeback from the cloud to on-premises is not currently supported. (There are plans to support two-way sync in the future, but the product cannot do this right now.) You can write back groups and passwords if you set those up, but the users can only sync from on-premises to Azure AD and not the other way around.

    You can apply attribute-based filtering to determine whether objects will synchronize based on the existence of certain attributes, but that will only determine whether or not the attributes are synchronized to the cloud.

    One workaround which you may have heard about is to create a PowerShell script that scans Azure AD regularly, finds the users in Azure, and then creates an on-premises user with the attributes in AAD. (There is an example of this here from Peter Stapf, if you haven't seen this yet.)

    If your goal is to synchronize users from on-prem but not change any attributes after they are synchronized, you can convert the users to cloud-only accounts after the initial sync.

    Let me know if this helps at all. Feel free to clarify if I misunderstood your ask!

    0 comments No comments

2 additional answers

Sort by: Most helpful
  1. Gregor Papez 26 Reputation points
    2021-11-25T06:41:12.933+00:00

    Hi @Marilee Turscak-MSFT and thank you for your feedback,

    my goal is to sync Cloud to On-Premise as we've just set-up new On-Premise server. As I've also found out, the AD Connect doesn't support that so my best guess is, as you've already mentioned, to write a PS script that will connect to Cloud and just pull each user, based on specific filter I've set. And this is exactly what I'm doing right now.

    After I fetch specific users and add them locally with New-ADUser, does the AD Connect tool have to work in Staging mode or have the Sync completely disabled just to be sure it doesn't sync something local that I've just fetched using script back to Cloud?

    thank you again.

    0 comments No comments

  2. Gregor Papez 26 Reputation points
    2021-12-10T07:44:07.7+00:00

    Hi everyone.

    I'll post my script here in case anyone else needs it in the future. Our goal, once again, was to Sync FROM Cloud to On-Premise:

    function manageUser {
      param($user)
    
      if ($user.UserPrincipalName -like "*onmicrosoft.com") {
        Write-Output "Skipping`t$($user.UserPrincipalName) because it does not have a custom logon domain"
        continue
      }
    
      # User exists?
      $existingUser = Get-ADUser -Filter "UserPrincipalName -eq '$(Write-Output $user.UserPrincipalName)'"
    
      if ($existingUser) {
        Write-Output "Existing`t$($user.DisplayName) (licences: $($user.AssignedLicenses.Capacity), enabled: $($user.AccountEnabled))"
      }
      else {
        New-ADUser `
          -Name $user.DisplayName `
          -DisplayName $user.DisplayName `
          -SamAccountName $user.UserPrincipalName.split('@')[0] `
          -UserPrincipalName $user.UserPrincipalName `
          -EmailAddress $user.Mail `
          -PasswordNotRequired $True `
          -Enabled $True
    
        Write-Output "Created `t$($user.DisplayName)"
      }
    }
    
    function showException {
      param($exception)
      Write-Output $exception.toString()
      Invoke-WebRequest $webhookUrl -Method 'POST' -Body "{'text':'$exception'}"
    }
    
    # break as soon as one error is being thrown
    $ErrorActionPreference = "Stop"
    
    # install Module
    Install-Module -Name AzureAD
    
    $webhookUrl = "https://mw1.webhook.office.com/webhookb2/717cf7d8-9327-449f-af3f-3d7ed1fab455@8793db88-3825-4592-9012-0285128118a3/IncomingWebhook/d8a086531f8c4ee4adc5f418d4d83f18/deba343a-f441-4c5c-a99e-1ab5bcbfa60f"
    
    $user = "ADMIN USER"
    $password = "ADMIN PASS"
    $secPass = ConvertTo-SecureString $password -AsPlainText -Force
    $Cred = New-Object System.Management.Automation.PSCredential ($user, $secPass)
    
    
    # connect to Office 365 Azure AD
    try {
      Connect-AzureAD -Credential $cred | Out-Null
      # Connect-AzureAD
    }
    catch {
      showException $_
    }
    
    
    $azureAdUsers = Get-AzureADUser
    
    foreach ($user in $azureAdUsers) {
      manageUser $user
      # Write-Output $user.DisplayName
    }
    
    0 comments No comments

Your answer

Answers can be marked as Accepted Answers by the question author, which helps users to know the answer solved the author's problem.