バックエンド

SynologyのNAS(DSM)でGitLabをAD連携させようとしたらDockerやADの設定に不備があった話

皆様どうも、こんにちは!
こまりの社内SE、桑木です。

以前、Synology DS1817+(8GB)を導入した話をしました。1年近く使ってみて細かい不足点(パッケージに縛られる問題)を感じることはありますが、トータルで見ればかなり良い買い物だったと思います。

前提として

DSMのパッケージで以下の物はインストール済みです。

  • Active Directory Server(Synology Directory Server)
    • DNS Server
  • GitLab
    • Docker

NAS設置当初からこれらは運用していて、軽微な問題は認識していますがそれ以上の利便性があるのでそのまま使用しています。(軽微な問題とはADクライアントからDNSの動的更新ができない事です。どこかの設定に問題があるのかもしれませんが、とりあえずDHCPから特定のIPアドレスを優先する設定にしてごまかしています。解決法をご存知の方は教えてください)

今回、Dockerを別件で使用しようとしたところGitLabイメージのドキュメント(DSMのGitLabパッケージはDockerのコンテナ)の存在に気付いて、なんとなしに見ていたら簡単にAD連携できそうだったので試してみました。
結果として、GitLabのAD連携自体は物凄く簡単でしたが、GitLab以外の設定に不備があってつまづきました。

その不備のお話をしていきます。

ポイント1 DockerでDNSの名前解決できなかった問題

AD連携とは直接関係ありませんが、別件でいじってるDockerの動作が何やらおかしい。よくよく調べてみたらホスト名が解決できていない。Dockerイメージに問題があるのかとも思ったけれど、どのイメージでも同じなので、どうやらホスト側の設定に問題があるようです。

そういえば、GitLabでもメールがいつからか送信できなくなっていたのですが、ホスト名が解決できなかったからか、と今更気づきました。特に困っていなかったので放置していましたが。

さてこの問題、不可解にもローカルのDNS Serverで管理しているローカルドメインは解決できる。/etc/resolv.confを確認したら、nameserverはNAS自身(DNS Server)のアドレスだし問題なさそう。

とここで気が付いたのが、DNS Serverの「再帰クエリを送信できるホスト」の設定です。なにかの間違いでグローバルなネットワークに繋がれてしまった時にオープンリゾルバなのはかなり問題があるので、再帰クエリは192.168.0.0/255.255.0.0のみ許可する設定をしていました。Dockerコンテナは特に設定しなければ、172.16~.*.*のIPアドレスが使用されるので名前解決できないのも当たり前というもの。

結局、172.16.0.0/255.240.0.010.0.0.0/255.0.0.0も許可リストに追加してDockerコンテナから名前解決できるようになりました。GitLabからメールも送信できるようになりました。

ポイント2 LDAPがSSL接続を受け付けていなかった問題

とりあえず、単純にLDAPとして疎通ができるかLDAP Adminで確認してみました。(ホスト名がad.sub.domain.co.jpならBaseはDC=ad,DC=sub,DC=domain,DC=co,DC=jpという風になります。ユーザー名はLDAP上の識別子(DN)を指定する必要があります。一旦GSS-APIで接続して対象ユーザーのエントリのdistinguishedName属性の値を見れば確認できます)

LDAP AdminをADユーザーで実行していればGSS-APIでも接続はできますが、GitLabから通常の認証で接続する為にはSimple authenticationの方で接続できる必要があります。暗号化しない(SSL, TLSどちらもチェックしない)で接続しようとすると、暗号化が必要な旨のエラーが出て接続できません。そしてSSLやTLSで接続しようとすると、暗号化に対応していない旨のエラーが出て接続できません。

Sambaのドキュメントによると、smb.conf[global]tls enable = yesを設定すれば良さそうですが、DSMで管理されている項目はGUIから設定しないと自動で書き換えられてしまいます。

Sambaの設定ファイルなどを色々と眺めていると、/var/packages/DirectoryServerForWindowsDomain/conf/etc/smb.tls.conf.mustacheにGUIの設定に応じてyesになるようなことが記述してありました。

はてさて、GUIでどういう設定をしたらこれが有効になるのか……、と考えていたところ「DSMコントロールパネル > セキュリティ > 証明書」の設定を思い出しました。DSMにはLet's Encryptの証明書を自動で取得更新してくれる機能があるので、その時にActive Directoryで使用する証明書も変更したような気がします。

結局、そこの設定の「構成」からActive Directoryで使用する証明書をActive Directory Server自身で生成した証明書に変更したら、tls enable = yesになってLDAP AdminからTLSで接続できるようになりました。GitLabからもAD連携できるようになりました。

本題、GitLabのAD連携

DSMのDockerからはGitLabを停止できないので、パッケージセンターからGitLabを停止させます。停止後はDockerのコンテナから「synology_gitlab」を編集できるので、ここで環境変数を設定します。

変数名
LDAP_ENABLED true
LDAP_HOST (ホスト名)
LDAP_METHOD start_tls
LDAP_VERIFY_SSL false
LDAP_ACTIVE_DIRECTORY true
LDAP_BASE (base)
LDAP_BIND_DN (認証用ユーザのDN)
LDAP_PASS (認証用ユーザのパスワード)

パッケージセンターからGitLab起動後に、「Docker > コンテナ > synology_gitlab > 詳細 > 端末 > 作成」でコンテナのコンソールに繋がるので、

$ /home/git/gitlab/bin/rake gitlab:ldap:check

を実行してLDAPの内容がずらずら表示されれば成功です。

さて、今回の問題は以前に行った設定が原因でしたが、こんなところまで影響があるとはなかなか気付かないものです。難しいですね。

View Prev 一覧へ戻る View Next

関連記事

KOMARI Member

Category