注目キーワード
  1. SEO
  2. デザイン
  3. 集客

【第5回】LDAPSによるセキュアな連携：自己署名証明書で署名要件を「完全攻略」する

AD×SVN
目次

はじめに

第4回でSVNとADの連携は成功しました。しかし、セキュリティポリシーが厳しい現場では「AD側の署名要件を『なし』にするなんて許されない」というケースがあります。

今回はその「課題」を片付けます。通信を暗号化（SSL/TLS）するLDAPS（636番ポート）へとアップグレードし、ADのセキュリティ設定を最高レベルに保ったまま連携を完成させます。

設定のポイント（お急ぎの方へ）

  1. 証明書のエクスポート: ADサーバー（認証局）からルート証明書を取り出す。

  2. Linux側へインポート: update-ca-trust でAlmaLinuxに証明書を信頼させる。

  3. subversion.confの変更: プロトコルを ldaps://、ポートを 636 に書き換える。

  4. ADポリシーの復元: LDAP署名要件を「要求する」に戻して最終テスト。

ADサーバーにて自己署名証明書の作成・取得

自己署名証明書の作成（PowerShell）

ADサーバーで管理者としてPowerShellを開き、以下のコマンドを実行します。これにより、ADサーバーが自分自身の身元を証明する「自己署名証明書」を発行します。

# $dnsName にはADサーバーのフルコンピュータ名（FQDN）を入力してください 
$dnsName = "AD-Server.lab.local" 

# 証明書の作成 
New-SelfSignedCertificate -DnsName $dnsName -CertStoreLocation Cert:\LocalMachine\My -NotAfter (Get-Date).AddYears(10)

コマンドの詳細解説

実行した New-SelfSignedCertificate コマンドの各パラメータ（引数）が持つ意味を解説します。

パラメータ 意味と役割
-DnsName

証明書の「名前」を定義します。

LDAPS通信では、アクセスする際のサーバー名（FQDN）と証明書に記載された名前が一致している必要があります。ここでは変数 $dnsName に代入したサーバー名を指定しています。
-CertStoreLocation

証明書の「保存先」を指定します。

 

Cert:\LocalMachine\My は、Windowsの「ローカルコンピューター」の「個人」ストアを指します。ApacheやADサービスが証明書を参照するためには、ユーザー個人ではなくコンピューター全体が管理する場所へ保存する必要があります。
-NotAfter

証明書の「有効期限」を設定します。

デフォルトでは1年程度で切れてしまいますが、(Get-Date).AddYears(10) とすることで、現在から10年間有効な証明書を発行しています。閉塞環境で頻繁に更新作業を行えない場合に有効な設定です。

自己署名証明書の取得

作成した証明書を、LDAPS（636番ポート）が認識できるように紐付けます。

  1. ADサーバーで [ファイル名を指定して実行] ＞ certlm.msc（ローカルコンピュータの証明書）を入力。

  2. [個人] ＞ [証明書] にある「AD-Server.lab.local」をコピーします。

  3. コピーした証明書を[個人] ＞ [信頼されたルート証明機関] へコピーします。

  4. [すべてのタスク] ＞ [エクスポート] を選択し、Base-64 encoded X.509 (.CER) 形式で保存します（例: ad-root.cer）。※基本デフォルトでOK

  5. 作成完了

AlmaLinuxに証明書をインポートする

取り出した ad-root.cer をAlmaLinuxへ転送し、システムに登録します。

SVNサーバへ証明書転送

Windowsのコマンドプロンプトで、証明書があるフォルダへ移動して実行します。

# 実行例：ad-root.cer を AlmaLinuxのユーザーホームへ送る
scp ad-root.cer [ユーザー名]@[AlmaLinuxのIPアドレス]:~/

証明書インポート

これで、Linux側からADサーバーへの暗号化通信が「信頼できる相手」として認められます。

# 証明書を信頼済みディレクトリへコピー 
sudo cp ad-root.cer /etc/pki/ca-trust/source/anchors/ 

# システムの信頼リストを更新 
sudo update-ca-trust

subversion.conf の修正（LDAPS化）

subversion.conf を開き、通信プロトコルとポート番号、さらに検証設定を追記します。

sudo vi /etc/httpd/conf.d/subversion.conf
# --- subversion.conf の修正箇所 ---
# グローバルセクション（Locationの外）に記述
LDAPVerifyServerCert On
LDAPTrustedGlobalCert CA_BASE64 /etc/pki/ca-trust/source/anchors/ad-root.cer

<Location /svn>
   ...
   # IPではなく、証明書のCNに合わせたFQDNを指定
   AuthLDAPURL "ldaps://AD-Server.lab.local:636/OU=SVN,DC=lab,DC=local?sAMAccountName?sub?(objectClass=*)"
   ...
</Location>

あらかじめ /etc/hosts にADサーバーのIPとFQDNを追記しておきましょう。

apacheを再起動させます。

sudo systemctl restart httpd

ADのセキュリティ要件を「元に戻す」

第4回で緩和したポリシーを、本来の安全な設定（要求あり）に戻します。
設定を戻したあと、通信がエラーにならなければ、正しく暗号化（LDAPS）ができている証拠です。

  1. グループポリシー管理を開き、[Default Domain Controllers Policy] を編集。

  2. [ドメイン コントローラー: LDAP サーバー署名要件] を 「要求する」 に戻します。

  3. ADサーバーで gpupdate /force を実行。

最終検証（TortoiseSVNからの接続）

いよいよクライアントPC（Windows）から接続テストです。

  1. TortoiseSVNをインストールしたPCで、デスクトップを右クリック ＞ [SVN チェックアウト]。

  2. リポジトリURLに http://192.168.10.11/svn/repo_a を入力。

  3. ADのユーザー名とパスワードを求められるので入力します。

結果： AD側の署名要件が「要求する」のままでも、暗号化通信（LDAPS）を使っているため、エラーなくチェックアウト・コミットができるはずです！

おわりに

全5回にわたる「SVN×Active Directory連携」の構築記、いかがでしたでしょうか。

単なる「ソフトのインストール」で終わらず、

  • 閉塞環境でのパッケージ管理
  • Linuxの権限とSELinux
  • Active Directory特有の署名ポリシー
  • 証明書による暗号化

といった、現場で必ず突き当たる壁をすべて乗り越えることができました。

この記事が、同じようにサーバー構築で格闘するエンジニアの一助になれば幸いです。

最新情報をチェックしよう！

AD×SVNの最新記事4件