GitLabとActive Directoryの連携とは
この記事では、RHEL8のコンテナ上に構築したGitLab Community Edition（CE）を、WindowsのActive Directoryと連携させてユーザー管理する方法について紹介します。
これにより、Active Directoryを使ったユーザーの一元管理が可能になり、効率的な運用が実現できます。
GitLab CEの基本的なインストール方法については、以下の記事で詳しく解説しています。
GitLabとActive Directoryの連携とは
GitLabとActive Directory（AD DS）を連携させることで、WindowsのドメインユーザーとGitLabの開発者ユーザを一元管理することができます。これにより、GitLabにおけるユーザー管理の手間が削減され、管理効率が格段に向上します。
具体的には、次のようなメリットがあります。
- ユーザーのアカウントを開発環境内で一元管理できる。
- GitLabのアカウント管理作業の手間が省ける。
- セキュリティ強化（強固なパスワード管理）
この手順では、WindowsのActive Directory（AD DS）との連携を進めていきます。ユーザー認証を安全に行うため、SSL（Secure Socket Layer）を使用して通信を暗号化します。
特に自己認証局を使用している場合、暗号化された通信が正常に機能するためには、自己認証局が発行した認証局（CA）証明書の検証が必要です。
そのため、CA証明書が手元に準備されていることを前提として解説を進めます。このCA証明書をGitLabに設定して、AD DSとの間における通信の正当性を確認します。
Active Directoryとは
Active Directoryは、ドメインユーザーの認証情報をLDAP（Lightweight Directory Access Protocol）というプロトコルを使用して通信します。
LDAP は、ディレクトリサービス（Active Directory）に格納された情報にアクセスするための標準的な手段であり、ユーザー名やパスワード、グループ情報などを取得できます。
Active Directoryと連携させることで、GitLabへのログイン時において、LDAPを使ってユーザーを認証することができます。
これにより、個別にGitLabユーザーの追加作業が必要なくなり、強固なセキュリティ環境下におけるユーザの一元管理が実現できます。
LDAPSの連携手順
ここからは、LDAPS（LDAP over SSL/TLS） プロトコルを利用して、暗号化された通信によるLDAP連携の手順について解説します。LDAPSを使うことにより、Active Directoryと安全なデータ交換が可能となります。
GitLabのLDAPS設定は、gitlab.rbファイルを使って定義します。
# cd /etc/gitlab
# vi gitlab.rb以下のパラメータに対して設定します。以下を参考にしながら、自身の環境に適した設定を行ってください。
gitlab_rails['ldap_enabled'] = true
gitlab_rails['ldap_servers'] = YAML.load <<-EOS
main: # 'main' is the GitLab 'provider ID' of this LDAP server
label: 'LDAP'
host: 'srv00.reafnex.local' #Active Directoryのホスト名
port: 636 #LDAPSの標準ポート番号
uid: 'sAMAccountName' # ユーザー名の属性
bind_dn: 'CN=binduser,OU=sysadmin,OU=Labo,DC=reafnex,DC=local' # バインドユーザーのフルDN
password: 'XXXXXXXX' # バインドユーザーのパスワード
encryption: 'simple_tls' # LDAPS（暗号化通信）を使用
verify_certificates: true # 証明書の検証を有効化
ca_file: '/etc/gitlab/ssl/reafnex_CA.crt' # CA証明書のパス
smartcard_auth: false
active_directory: true # Active Directory を使用する
# smartcard_ad_cert_field: 'altSecurityIdentities'
# smartcard_ad_cert_format: null # 'issuer_and_serial_number', 'issuer_and_subject' , 'principal_name'
allow_username_or_email_login: false
lowercase_usernames: false
block_auto_created_users: false
base: 'DC=reafnex,DC=local' # 検索ベースDN
user_filter: '' # 必要に応じてフィルタを設定
# ## EE only
# group_base: ''
# admin_group: ''
# sync_ssh_keys: false
EOSパスワードを設定する項目があるため、gitlab.rbファイルのパーミッションが600であることを確認し、rootユーザ以外がアクセスできないことを確認してください。
設定を保存したら、自己認証局のCA証明書を「ca_file」パラメータで設定したディレクトリに配置します。
（CA証明書のファイル名は一例です。自身の準備したCA証明書に読み替えてください。）
CA証明書を所定の場所に配置したら、GitLabの環境構築を再実行します。
# gitlab-ctl reconfigure
# gitlab-ctl restart続いて、LDAPSによる認証設定が正しく動作するか確認します。
# gitlab-rake gitlab:ldap:check
Checking LDAP ...
LDAP: ... Server: ldapmain
LDAP authentication... Success
LDAP users with access to your GitLab server (only showing the first 100 results)
DN: cn=access control assistance operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Access Control Assistance Operators
DN: cn=account operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Account Operators
DN: cn=administrator,cn=users,dc=reafnex,dc=local sAMAccountName: Administrator
DN: cn=administrators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Administrators
DN: cn=allowed rodc password replication group,cn=users,dc=reafnex,dc=local sAMAccountName: Allowed RODC Password Replication Group
DN: cn=backup operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Backup Operators
DN: cn=binduser,ou=sysadmin,ou=labo,dc=reafnex,dc=local sAMAccountName: binduser
DN: cn=cert publishers,cn=users,dc=reafnex,dc=local sAMAccountName: Cert Publishers
DN: cn=certificate service dcom access,cn=builtin,dc=reafnex,dc=local sAMAccountName: Certificate Service DCOM Access
DN: cn=cloneable domain controllers,cn=users,dc=reafnex,dc=local sAMAccountName: Cloneable Domain Controllers
DN: cn=cryptographic operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Cryptographic Operators
DN: cn=denied rodc password replication group,cn=users,dc=reafnex,dc=local sAMAccountName: Denied RODC Password Replication Group
DN: cn=distributed com users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Distributed COM Users
DN: cn=dnsadmins,cn=users,dc=reafnex,dc=local sAMAccountName: DnsAdmins
DN: cn=dnsupdateproxy,cn=users,dc=reafnex,dc=local sAMAccountName: DnsUpdateProxy
DN: cn=domain admins,cn=users,dc=reafnex,dc=local sAMAccountName: Domain Admins
DN: cn=domain computers,cn=users,dc=reafnex,dc=local sAMAccountName: Domain Computers
DN: cn=domain controllers,cn=users,dc=reafnex,dc=local sAMAccountName: Domain Controllers
DN: cn=domain guests,cn=users,dc=reafnex,dc=local sAMAccountName: Domain Guests
DN: cn=domain users,cn=users,dc=reafnex,dc=local sAMAccountName: Domain Users
DN: cn=enterprise admins,cn=users,dc=reafnex,dc=local sAMAccountName: Enterprise Admins
DN: cn=enterprise key admins,cn=users,dc=reafnex,dc=local sAMAccountName: Enterprise Key Admins
DN: cn=enterprise read-only domain controllers,cn=users,dc=reafnex,dc=local sAMAccountName: Enterprise Read-only Domain Controllers
DN: cn=event log readers,cn=builtin,dc=reafnex,dc=local sAMAccountName: Event Log Readers
DN: cn=group policy creator owners,cn=users,dc=reafnex,dc=local sAMAccountName: Group Policy Creator Owners
DN: cn=guest,cn=users,dc=reafnex,dc=local sAMAccountName: Guest
DN: cn=guests,cn=builtin,dc=reafnex,dc=local sAMAccountName: Guests
DN: cn=furukawa hirokazu,ou=sysusers,ou=labo,dc=reafnex,dc=local sAMAccountName: h-furukawa
DN: cn=hyper-v administrators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Hyper-V Administrators
DN: cn=iis_iusrs,cn=builtin,dc=reafnex,dc=local sAMAccountName: IIS_IUSRS
DN: cn=incoming forest trust builders,cn=builtin,dc=reafnex,dc=local sAMAccountName: Incoming Forest Trust Builders
DN: cn=key admins,cn=users,dc=reafnex,dc=local sAMAccountName: Key Admins
DN: cn=krbtgt,cn=users,dc=reafnex,dc=local sAMAccountName: krbtgt
DN: cn=network configuration operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Network Configuration Operators
DN: cn=performance log users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Performance Log Users
DN: cn=performance monitor users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Performance Monitor Users
DN: cn=pre-windows 2000 compatible access,cn=builtin,dc=reafnex,dc=local sAMAccountName: Pre-Windows 2000 Compatible Access
DN: cn=print operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Print Operators
DN: cn=protected users,cn=users,dc=reafnex,dc=local sAMAccountName: Protected Users
DN: cn=ras and ias servers,cn=users,dc=reafnex,dc=local sAMAccountName: RAS and IAS Servers
DN: cn=rds endpoint servers,cn=builtin,dc=reafnex,dc=local sAMAccountName: RDS Endpoint Servers
DN: cn=rds management servers,cn=builtin,dc=reafnex,dc=local sAMAccountName: RDS Management Servers
DN: cn=rds remote access servers,cn=builtin,dc=reafnex,dc=local sAMAccountName: RDS Remote Access Servers
DN: cn=read-only domain controllers,cn=users,dc=reafnex,dc=local sAMAccountName: Read-only Domain Controllers
DN: cn=remote desktop users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Remote Desktop Users
DN: cn=remote management users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Remote Management Users
DN: cn=replicator,cn=builtin,dc=reafnex,dc=local sAMAccountName: Replicator
DN: cn=schema admins,cn=users,dc=reafnex,dc=local sAMAccountName: Schema Admins
DN: cn=server operators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Server Operators
DN: cn=srv00,ou=domain controllers,dc=reafnex,dc=local sAMAccountName: SRV00$
DN: cn=storage replica administrators,cn=builtin,dc=reafnex,dc=local sAMAccountName: Storage Replica Administrators
DN: cn=terminal server license servers,cn=builtin,dc=reafnex,dc=local sAMAccountName: Terminal Server License Servers
DN: cn=users,cn=builtin,dc=reafnex,dc=local sAMAccountName: Users
DN: cn=windows authorization access group,cn=builtin,dc=reafnex,dc=local sAMAccountName: Windows Authorization Access Group
DN: cn=wsus administrators,cn=users,dc=reafnex,dc=local sAMAccountName: WSUS Administrators
DN: cn=wsus reporters,cn=users,dc=reafnex,dc=local sAMAccountName: WSUS Reporters
Checking LDAP ... Finished「LDAP authentication… Success」と「Checking LDAP … Finished」が表示されたら、LDAPSの設定が完了し、GitLabがActive Directoryと連携できるようになりました。
うまくいかない場合は、以下のコマンドでサーバからLDAPにアクセスできているか確認します。
# openssl s_client -connect <ディレクトリサーバのホスト名またはIPアドレス>:636 -showcertsディレクトリサーバ側のポート（636番ポート）が解放されているかも確認してください。
なお、セキュリティリスクの観点から、LDAPの設定と確認は慎重に実施してください。
LDAPでログインする
Active Directoryに連携したGitLabのログイン画面は、以下のとおりです。「LDAP」と「標準」の2つのタブが追加されています。
Active Directoryに登録されているユーザでログインする場合は、「LDAP」のタブからドメインのユーザ名とパスワードを入力して「サインインする」を実行します。もし、GitLabにアカウントが追加されていない場合は、自動的にユーザが登録されてログインできるようになります。
なお、GitLab CEの場合は、既にアカウントが登録されているユーザをLDAP連携に変更することはできないため、一度、GitLabのアカウントを削除してから、再度ログインすることにより、LDAP連携でログインできるようになります。
GitLab Enterprise Edition（EE）では、画面からLDAP連携に変更することができます。
まとめ
いかがでしたでしょうか。
今回は、RHEL8のコンテナ上に構築したGitLab CEとWindowsのActive DirectoryをLDAPS（LDAP over SSL/TLS）で連携させる手順について紹介しました。
この設定により、GitLabのユーザーをActive Directoryで一元管理し、強固なパスワード管理と運用管理の効率化を実現することができます。
また、Active Directoryに新しいユーザーを追加することによって、ユーザにGitLabを利用させることが可能となるため、運用管理が格段に楽になります。
LDAPSプロトコルを使用することで、暗号化された通信によるセキュアな認証を行うことができます。
これらの手順を実施することで、GitLabの運用とユーザー管理が一層効率化され、企業のセキュリティ基準に適合した運用が可能になるはずですので、ぜひ試してみてください。
参考になれば幸いです。
システムのお悩みについてご相談ください
SOHOのシステム運用管理に関するお悩みごとについて、なんでもお気兼ねなくご相談ください。
現役システムエンジニアのスタッフが、ボランティアでご相談にご対応させていただきます。
