Нужна помощь в настройке Google Cloud Directory Sync с AD с помощью безопасного LDAP

Обновление 20 января 2020 г .: Ожидается, что с патчами марта 2020 г. Microsoft запретит небезопасные привязки. Этот ответ, вероятно, привлечет дополнительное внимание, поскольку Google Cloud Directory Sync, скорее всего, не сможет подключиться к AD, если не используется TLS.

Оригинальный ответ

Google Cloud Directory Sync - это приложение Java. Программа установки GCDS устанавливает версию среды выполнения Java в подпапку. Эта установка имеет собственный набор доверенных корневых центров сертификации. Он не использует сертификаты, установленные в Windows.

Чтобы все заработало, вам необходимо импортировать общедоступный сертификат для доверенного центра сертификации, который выпустил сертификат, используемый вашим контроллером домена. Вместо этого вы можете установить общедоступный сертификат со своего контроллера домена, но этот сертификат, скорее всего, истечет намного раньше, чем сертификат выдающего сертификат центра сертификации.

Google предоставляет инструкции здесь: https://support.google.com/a/answer/3075991?hl=en Однако в их инструкциях используется открытый сертификат DC, а не сертификат CA.

Получите сертификат CA. Я назову это the_cert.cer

Если вы следуете инструкциям Google, вы экспортируете сертификат из контроллера домена:

certutil -store My DomainController %TEMP%\the_cert.cer

Но опять же, вам лучше с сертификатом CA.

Переместите сертификат на хост GCDS.

На хосте GCDS

Перейдите в папку jre, в которой установлен GCDS. Для меня это было:

cd "c:\Program Files\Google Cloud Directory Sync\jre"

Ваш может отличаться в зависимости от вашей среды.

Установите сертификат в хранилище ключей Java:

bin\keytool -keystore lib\security\cacerts -storepass changeit -import -file %TEMP%\the_cert.cer -alias pick_a_name_you_like

В keytool утилита подскажет: Trust this certificate? [no]: Введите да и нажмите Enter ключ.

Очистить:

del the_cert.cer

Теперь, снова идя против моего совета и используя сертификат DC, вот полный сценарий, который вы можете запустить через Task Scheduler, чтобы поддерживать актуальность сертификата на контроллере домена, при условии, что вы запускаете GCDS на том же контроллере домена.

<#
  .SYNOPSIS
  Exports the bound AD LDAPS encryption certificate and imports it into
  Google Cloud Directory Sync's Java keystore, so that GCDS syncs will succeed.

  .DESCRIPTION
  Google Cloud Directory Sync runs on Java. Java maintains its own trusted keystore,
  separate from the host operating system. Often, this keystore grows stale when updates
  are neglected. Further, the keystore would never contain certificate information for
  self-signed or internally-distributed certificates.

  In order to make GCDS work with TLS using secure LDAPS binding, it is necessary to
  export your trusted certificate from the machine's certificate store and import it into
  the GCDS-bundled Java Runtime Environment's certificate store.

  This script assumes the DC being contacted resides on the same host as the GCDS installation.

  Given a ComputerName and Port, this script will connect to the named DC and determine the
  thumbprint of the certificate bound to the DC on the specific port.

  Using this thumbprint, the script then exports the certificate from the Local Computer's MY (Personal)
  certificate store. This does NOT include the private key, and therefore it's safe to do this.

  Next, the script deletes and re-imports the certificate into the JRE certificate store.

  .PARAMETER ComputerName
  Use the fully-qualified network name of the machine. We're assuming this is the same network name
  that will be used in GCDS to bind against the DC, and is also the CommonName represented in the certificate.

  .PARAMETER Port
  Usually this will be 636, but could be custom depending on your environment.

  .OUTPUTS
  Will list the thumbprint of the cert found and will show stderr and stdout of the keytool commands.
  Error handling could definitely be beefed up here.

  .EXAMPLE
  C:\PS> .\Update-JavaDomainControllerCertificate.ps1 -ComputerName my.domain.com -Port 636

#>

[CmdletBinding()]
param (
    [Parameter(Mandatory=$true)]
    [string]
    $ComputerName,

    [int]
    $Port = 636
)
$FilePath = "$($Env:TEMP)\adcert.crt"
$Certificate = $null
$TcpClient = New-Object -TypeName System.Net.Sockets.TcpClient
try {

    $TcpClient.Connect($ComputerName, $Port)
    $TcpStream = $TcpClient.GetStream()

    $Callback = { param($sender, $cert, $chain, $errors) return $true }

    $SslStream = New-Object -TypeName System.Net.Security.SslStream -ArgumentList @($TcpStream, $true, $Callback)
    try {

        $SslStream.AuthenticateAsClient('')
        $Certificate = $SslStream.RemoteCertificate

    } finally {
        $SslStream.Dispose()
    }

} finally {
    $TcpClient.Dispose()
}

if ($Certificate) {
    if ($Certificate -isnot [System.Security.Cryptography.X509Certificates.X509Certificate2]) {
        $Certificate = New-Object -TypeName System.Security.Cryptography.X509Certificates.X509Certificate2 -ArgumentList $Certificate
    }
    Write-Output "Found Certificate:"
    Write-Output $Certificate
}

Export-Certificate -Cert $Certificate -Force -FilePath $FilePath | Out-Null

Set-Location -Path "C:\Program Files\Google Cloud Directory Sync\jre"

# Delete existing entry
& .\bin\keytool -keystore lib\security\cacerts -storepass changeit -delete -noprompt -alias $ComputerName 2>&1 | %{ "$_" }

# Add entry
& .\bin\keytool -keystore lib\security\cacerts -storepass changeit -importcert -noprompt -file $FilePath -alias $ComputerName 2>&1 | %{ "$_" }

Remove-Item -Path $FilePath -Force

Итак, я только что поговорил со службой поддержки Google и, похоже, собираюсь изменить направление в этом вопросе. Они подтвердили, что клиент безопасно обменивается данными с серверами Google. Он также сказал, что включение SSL значительно увеличит время синхронизации. Кроме того, если я запускаю клиент на DC и использую 127.0.0.1, мне даже не нужно беспокоиться о раскрытии трафика в нашей сети, и даже тогда он все равно будет ограничен нашей частной серверной сетью, если я запустил это на рядовом сервере.

Итак, я, вероятно, немного поиграю с ним, чтобы увидеть, смогу ли я заставить 636 работать просто для удовольствия, но я, вероятно, не буду тратить на это слишком много времени, так как у меня есть много других вещей, которые нужно взять забота о. Что странно, я попытался использовать инструмент MS LDP с того компьютера, на котором установлен клиент GADS, и он без проблем подключается к моему DC через порт 636. Я пробовал всевозможные комбинации домен \ имя пользователя, все из которых отлично подключаются к 389, но как только вы меняете его на 636 и LDAP + SSL, он выплевывает:

Инициализация ... Ошибка: сбой подключения Исключение: не удалось выполнить запрос, поскольку объект с базовым DN: «DC = mydomain, DC = com» отсутствует или недоступен.

Так что да, я не совсем уверен, почему он не подключается к 636, но похоже, что я даже не хочу этого в любом случае.