web-dev-qa-db-ja.com

安全なLDAPを使用してADでGoogle Cloud Directory Syncを設定するのに助けが必要

安全なLDAP（LDAPS）経由でActive Directoryを使用して、他の誰かがGoogle Cloud Directory Sync（GCDSまたはGADS）を設定していないか確認したいと思いました。ポート389を介して同期しており、その接続を暗号化したいのですが、ポート636に切り替えると接続が失敗します。

ドメイン内のメンバーサーバーでGCDSツールを実行しています。GoogleのオフサイトサーバーとDCの間のポート636で確立しようとしている接続ですか、それともGCDSツールとDCの間ですか。また、GCDSツールとDCの間にある場合でも、サードパーティの証明書が必要ですか、それともソフトウェアがドメインに参加しているサーバーで実行されているため、自己署名証明書で十分ですか？ DCでプログラムを実行する必要がありますか？

これがサードパーティの証明書を必要とする問題である場合、私は証明書について特に知識がないので、いくつかのガイダンスがありがたいです。ありがとう！

active-directoryldapcertificateg-suitegoogle
5
Mike

2020年1月20日更新：2020年3月のパッチでは、 Microsoftは安全でないbinds を許可しません。 TLSが使用されていない限り、Google Cloud Directory SyncはADへの接続に失敗する可能性が高いため、この回答はさらに注目される可能性があります。

元の回答

Google Cloud Directory Syncは、Javaアプリケーションです。GCDSインストーラは、Javaランタイム環境のバージョンをサブフォルダにインストールします。このインストールには、独自の信頼されたルート認証局のセットであり、Windowsにインストールされている証明書を使用しません。

機能させるには、ドメインコントローラで使用されている証明書を発行した信頼できる認証局の公開証明書をインポートする必要があります。代わりに、ドメインコントローラーからパブリック証明書をインストールすることもできますが、その証明書は、発行する認証局の証明書よりもはるかに早く期限切れになる可能性があります。

Googleはここに手順を示します： https://support.google.com/a/answer/3075991?hl=ja ただし、その手順では、CAの証明書ではなく、DCの公開証明書を使用します。

CA証明書を取得します。 the_cert.cerと呼びます

Googleの指示に従っている場合は、ドメインコントローラから証明書をエクスポートしています。

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

しかし、繰り返しになりますが、CA証明書の方が適しています。

証明書をGCDSホストに移動します。

GCDSホスト上

フォルダーを、GCDSがインストールされているjreフォルダーに変更します。私にとっては：

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]: yesと入力し、Enterキーを押します。

掃除：

del the_cert.cer

ここで再び私のアドバイスに反して、DCの証明書を使用して、同じドメインコントローラーで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
4
Larry Silverman

だから、私はグーグルサポートと話をしただけで、これについて方向を変えるつもりです。彼らは、クライアントがGoogleサーバーと安全に通信していることを確認しました。また、SSLを有効にすると同期時間が大幅に増加すると述べました。さらに、DC=でクライアントを実行し、127.0.0.1を使用する場合、ネットワーク上のトラフィックを公開することを心配する必要もありません。それでも、制限されます私たちのプライベートサーバーネットワークには、メンバーサーバーで実行するつもりでした。

だから、キックのためだけに636を機能させることができるかどうかを確認するために、もう少し遊んでみますが、他に必要なものをたくさん持っているので、あまり時間をかけないでしょう。の世話。奇妙なのは、GADSクライアントがインストールされているコンピューターからMS LDPツールを使用してみたところ、ポート636でDCに問題なく接続されたということです。 domain\usernameの組み合わせ。これらはすべて389で問題なく接続されますが、636とLDAP + SSLに変更すると、次のように出力されます。

初期化中...エラー：接続に失敗しました例外：ベースDNのオブジェクト「DC = mydomain、DC = com」が見つからないかアクセスできないため、クエリを実行できませんでした。

ですから、636で接続されない理由はよくわかりませんが、とにかく接続したくないようです。

0
Mike