RHEL などの Linux マシンを直接 Microsoft Active Directory に接続する

ネットワーク上のシステムへのアクセスを管理するのは困難な場合があります。すべてのマシン上にすべてのユーザーを作成する管理者もいれば、SSH キーやパスワードを使ってアカウントを共有する管理者、アクセスをフィルタリングする LDAP クエリの作成が必要な LDAP バインディング (既存の Active Directory インフラストラクチャを使う場合と別のドメインを使う場合がある) を使用する管理者もいます。

こうした手法はいずれもマシンへのアクセスの管理を困難にするものであり、誰かがチームを去ったり、チームに新たに加わったりした場合には管理者への通知が必要になります。共有アカウントでは、全員が同じユーザー名を持つため、ログ記録がほぼ無駄になることがあります。チームメンバーの変更を技術チームに伝える人事担当者に悪い印象を持ったという経験があるのは、おそらく私だけではないでしょう。しかし、これらすべてを解決し、適切に機能し、一般的なエンタープライズ向けのセットアップと統合できるソリューションがあります。

私が接したほとんどの企業では、Microsoft Active Directory (AD) でユーザーアカウントを自動的に作成、無効化、削除する何らかの ERP システムが導入されているため、このような他で行われていることを活用することができます。たとえば、 SSSD は AD に直接接続できます。

AD を信頼する Linux 用認証サーバーを設定したことがあれば、SSSD と AD サーバーを通信させたことがあるでしょう。信頼がどのように機能するかに注目すると、設定した認証サーバーが AD サーバーに参照を返し、SSSD が AD サーバーに直接クエリを実行することが分かります。その後の設定では追加の認証サーバーは不要で、SSSD が AD に直接アクセスするように設定されます。

次の問題は通常、アクセスの制御方法です。そこでロールベースのアクセス制御 (RBAC) の出番です。RBAC によって、ユーザーにアクセス権を割り当てるのではなく、ロールにアクセス権を割り当てられるようになります。グループを設定したら、新しいチームメンバーをチームに割り当てることができます。このチームは、サーバーのグループへの適切なアクセス権を持つロールにすでに組み込まれています。これにより、数カ月前に退職してすべてのアクセス権が削除されている人を引き合いに出して、「採用されたばかりなのですが、X さんと同じアクセス権の付与をお願いします」などと言われることがなくなります。

新しいユーザーにアクセス権を付与するのではなく、そのユーザーをチームのグループに追加すれば、必要なアクセス権を付与できます。また、1 年以上前に退職した人が、その人が退職したことを誰も管理者に伝えていなかったために、まだすべてのサーバーにアクセスできる状態だったと判明するようなこともなくなります。ERP システムによって AD アカウントが自動的に更新されると、すべてのアクセス権が失われます。

Windows 以外のオペレーティングシステムからの AD 管理は、かつては困難でした。しかし、マイクロソフトは Windows Admin Center をリリースして、任意のオペレーティングシステムで実行されている任意のブラウザーから Active Directory ユーザーとコンピュータに直接アクセスできるようにしました。Windows Admin Center によって他のさまざまな Windows 管理ツールへのアクセス権も付与されます。これを Windows サーバーにインストールすれば、セッション制限を気にしたり、RemoteApp で苦労したりすることはありません。ユーザーはブラウザーを起動して Web インタフェースにアクセスするだけです。

ロールベースのアクセス制御用に AD グループを設定する

貴社の命名スキームは、この記事の例とは異なる場合があります。しかし、グループの名前は重要ではありません。重要なのは、各グループをどのように使用するかを確認することです。

SSSD は AD グループを同期せず、ログインプロセス中にユーザーがメンバーに含まれるグループのリストを取得するだけなので、グループがなくてもその設定の機能に影響はありません。しかし、AD 内に権限委任されたパーミッションを持つ複数のチームがある場合は、誤った組織単位 (OU) でグループが作成されて誤ったチームにアクセス権が付与されないようにするために、すべてのグループを作成することをお勧めします。

特定のマシンへのアクセス

各マシン用に Active Directory 内に 2 つのグループを作成します。両方のグループに、マシンの短縮名が含まれている必要があります。 

1 つのグループは、マシン固有の SSH アクセス用です (この記事では Machine_SSH_Access とされます)。

もう 1 つのグループは、マシン固有の sudo アクセスを提供します (この記事では Machine_SUDO_Access とされます)。

グループ形式の例：

<DOMAIN> Linux <hostname> ssh access
<DOMAIN> Linux <hostname> sudo access

• <hostname>：マシンの短縮名
• <DOMAIN>：ドメインの短縮名であり、任意

すべてのマシンへのアクセス

マシンへのグローバルアクセス用に Active Directory 内に 2 つのグループを作成します。

1 つのグループは、すべてのマシンへの SSH アクセス用です (この記事では Global_SSH_Access とされます)。

もう 1 つは、すべてのマシンへの sudo アクセス用です (この記事では Global_SUDO_Access とされます)。

グループ形式の例：

<DOMAIN> Linux ssh access
<DOMAIN> Linux sudo access

<DOMAIN>：ドメインの短縮名であり、任意

ネスト化

AD グループ内のネスト化が可能です。複数のマシンへのアクセス権を持つグループを作成する場合、RHEL マシンの設定を変更する必要はありません。代わりに、新しいグループを特定のマシンのアクセスグループのメンバーにすることができます。この方法では、AD から直接アクセスを制御できます。

ネスト化の例：

• CONTOSO Linux Webserver1 ssh access
  • CONTOSO Linux Webservers ssh access
    • CONTOSO Web Developers
      • User1
      • User2

このネスト化により、特定のシステムに対するユーザーではなく、ロール (CONTOSO Web Developers) をマシンのグループ (CONTOSO Linux Webservers ssh access) に割り当てることができます。

Linux マシンのドメイン参加

使用中の環境で現在 RC4 が有効になっている場合は、 マイクロソフトのセキュリティ・アドバイザリー に従い、今すぐ無効にしてください。

Linux マシンをドメインに参加させるには、以下の手順を実行します。

1. 必要なパッケージをインストールします。

$ sudo dnf install -y chrony krb5-workstation \
samba-common-tools oddjob-mkhomedir samba-common \
sssd authselect

2. /etc/sssd/pki/sssd_auth_ca_db.pem を作成してドメインの CA チェーンを記述し、ドメインの CA チェーンを追加します。ドメインコントローラー (DC) 自体の証明書を含める必要はありません。それらの証明書に署名した証明書で実行できます。
3. CA チェーンをシステムのトラストアンカーに追加します。

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

4. /etc/sssd/sssd.conf または /etc/sssd/conf.d/<DOMAIN>.conf を編集して SSSD を設定し、以下の行に一致させます。

/etc/sssd/conf.d/<DOMAIN>.conf を編集するのが最新かつ推奨される手法ですが、/etc/sssd/sssd.conf を編集することもできます。

[domain/<DOMAIN>]
access_provider = simple
auth_provider = ad
chpass_provider = ad
id_provider = ad
dyndns_update = true
override_homedir = /home/%u
override_shell = /bin/bash
default_shell = /bin/bash
ldap_idmap_range_size = 4000000
cache_credentials = true
simple_allow_groups = Global_SSH_Access, Global_SUDO_Access, Machine_SSH_Access, Machine_SUDO_Access
ignore_group_members = true
ad_gpo_access_control = disabled
ad_enable_gc = false
ad_use_ldaps = true
[sssd]
services = nss, pam
config_file_version = 2
domains = <DOMAIN>

• <DOMAIN> は、すべて大文字のドメインの FQDN です。すべて大文字でないと、認証の問題が発生することがあります。
• ldap_idmap_range_size は任意です。これは、大規模な AD 環境の場合に必要となります。この値を変更すると UID ハッシュが変更されるため、マシンがドメインに参加した後は変更しないでください。また、すべてのマシンで同じ値を使用するようにしてください。
• Global_SSH_Access、 Global_SUDO_Access、 Machine_SSH_Access、 Machine_SUDO_Access は、上記で RBAC 用に作成した AD グループです。

5. 先ほど記述したファイル (/etc/sssd/sssd.conf または /etc/sssd/conf.d/<DOMAIN>.conf) のパーミッションを設定します。

$ sudo chmod 400 /etc/sssd/sssd.conf

または

$ sudo chmod 400 /etc/sssd/conf.d/*.conf

6. /etc/krb5.conf を編集して KRB5 を設定し、以下の行に一致させます。

[logging]
default = FILE:/var/log/krb5libs.log
kdc = FILE:/var/log/krb5kdc.log
admin_server = FILE:/var/log/kadmind.log

[libdefaults]
dns_lookup_realm = true
dns_lookup_kdc = true
ticket_lifetime = 24h
renew_lifetime = 7d
forwardable = true
rdns = true
default_ccache_name = KEYRING:persistent:%{uid}
default_realm = <DOMAIN>

[realms]

[domain_realm]

[realms] または [domain_realm]の下には何も指定する必要はありません。SSSD は、その情報を DNS から自動的に検出します。

7. /etc/sudoers.d にファイルを作成して、SUDO アクセスを設定します。

$ sudo visudo -f /etc/sudoers.d/<DOMAIN>

AD sudo グループのメンバーにデフォルトの sudo アクセスを指定します。ファイル名は任意です。DOMAIN という名前にする必要はありません。

スペースはバックスラッシュ (\) でエスケープする必要があります。たとえば「Linux sudo access」は「Linux\ sudo\ access」と記述します。

%Global_SUDO_Access  ALL=(ALL) ALL
%Machine_SUDO_Access  ALL=(ALL) ALL

Global_SUDO_Access と Machine_SUDO_Access は、RBAC 用に作成した AD グループです。グループ名の前にパーセント記号 (%) がある場合、それがグループであることを示します。

AD グループに付与するその他の sudo アクセスは、個別のファイルでも同じファイルでも同様に定義できます。

8. マシンのホスト名が FQDN に設定されていることを確認します。マシンのホスト名を短縮名にすることはできません。

$ sudo hostnamectl set-hostname $(hostname -f)

9. 次のいずれかのコマンドを使用してマシンを接続します (adcli は SMBv1 および SMBv2 と互換性があります)。接続中に AD 内で OS 情報を設定するには、次のコマンドを使用します。

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

または、OS 情報を設定せずに接続することもできます。

$ sudo adcli join -U <join_user>

<join_user> は、マシンをドメインに参加させるときに使用される AD アカウントです。adcli が要求するパスワードは保存されません。こちらの Delegated Permissions (権限委任されたパーミッション) で、参加に必要なパーミッションについて説明しています。

10. SSSD と oddjobdを有効にして開始します。

$ sudo systemctl enable sssd oddjobd
$ sudo systemctl restart sssd oddjobd

11. AD を使用してログインを有効化します。

$ sudo authselect select sssd with-mkhomedir --force

使用中のアカウントが、作成したいずれかのグループのメンバーであれば、 マシンにログインできます。ドメインを指定する必要はありません。/etc/krb5.conf で default_realm として指定されているドメインが使用されます。GNOME の再起動が必要になる場合がありますが、 sshd は通常、再起動しなくても変更を受け入れます。

OS 情報を最新の状態に保つ

デフォルトでは、コンピュータオブジェクトには自らの OS 情報を更新するパーミッションがありません。必ず Active Directory ユーザーとコンピュータ (ADUC) に移動し、コンピュータオブジェクトの各 OS フィールドに書き込む権限を付与してから更新を実行してください (これは OU レベルで実行できます)。情報を追加した後は、AD オブジェクトを最新の OS 情報で更新します。

$ source /etc/os-release
$ sudo adcli join -U <join_user> --os-name="${NAME}" \
--os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

これは、cron ジョブまたは systemd サービスとして追加できます。以下に例を示します。

[Unit]
Description=Updates AD with current OS information
After=sssd.service

[Service]
Type=oneshot
EnvironmentFile=/etc/os-release
ExecStart=/usr/sbin/adcli update --os-name="${NAME}" --os-version="${VERSION}" --os-service-pack="${VERSION_ID}"

[Install]
WantedBy=multi-user.target

スマートカード認証を有効にする

このセクションでは、Windows マシンでスマートカード認証が機能していることを前提とします。そうでない場合は、まず Windows マシンでスマートカード認証を設定してください。

1. ドメインの証明書チェーンを /etc/sssd/pki/sssd_auth_ca_db.pem に記述します。ドメインコントローラー (DC) 自体の証明書を含める必要はありません。それらの証明書に署名した証明書で実行できます。
2. マシンの信頼できる CA リストに証明書を追加します。

$ sudo trust anchor /etc/sssd/pki/sssd_auth_ca_db.pem

3. ドメインがシステムに参加したときに使用したファイルに応じて、/etc/sssd/sssd.conf または /etc/sssd/conf.d/<DOMAIN>.conf を編集し、[domain/<DOMAIN>] セクション内に次の行を追加します。このエントリーは、ユーザー証明書を探す場所を SSSD に指示します。Windows は userCertificate 属性を使用するので、同じ属性を使用すれば、Linux と Windows の両方で同じスマートカードが動作します。

ldap_user_certificate = userCertificate;binary

以下の行を同じ設定ファイルの末尾に追加します。

[pam]
pam_cert_auth = true

4. /etc/krb5.conf を編集し、 [realms] の下に次の行を追加し、<DOMAIN> をドメインの FQDN (すべて大文字) に置き換えます。これは、Windows では大文字と小文字を区別しませんが、Linux では大文字と小文字を区別するために発生する不一致を解決するためのものです。

<DOMAIN> = {
pkinit_anchors = DIR:/etc/sssd/pki
  pkinit_kdc_hostname = <DOMAIN>
}

5. 次のいずれかのコマンドを使用して、PAM でスマートカード認証を有効化します。

• authselect enable-feature with-smartcard：スマートカード認証をオプションとして許可します。
• authselect enable-feature with-smartcard-required：スマートカード認証を必要とします。デフォルトでは、SSH キーによる認証時に sshd は PAM を呼び出しません。
• authselect enable-feature with-smartcard-lock-on-removal：スマートカード認証を必要とし、スマートカードが削除された場合にはマシンをロックします。

スマートカード証明書を使用して SSH アクセスを有効にする

RHEL 8 以降では、スマートカードを使用して SSH アクセスを有効にすることができます。

1. スマートカード証明書が AD から正しく読み取られていることを確認します。

sss_ssh_authorizedkeys ${USER}

公開鍵が返されない場合は、スマートカード認証が正しく設定されていることを確認します。

2. /etc/ssh/sshd_config を編集して、以下の行を追加します。

AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser nobody

3. sshdを再起動します。

$ sudo systemctl restart sshd

SSH を使用してクライアントからログインするには、PKCS11Provider=/usr/lib64/opensc-pkcs11.so を使用します。スマートカードがユーザーの公開鍵と一致している場合、スマートカードの PIN またはパスワードの入力を求められます。

$ ssh -o PKCS11Provider=/usr/lib64/opensc-pkcs11.so <host>

その他の情報

これで、ユーザーのログインや特権コマンドの実行を制御するロールベースのアクセス制御のあるドメインに参加したマシンを使用できます。他ですでに行われている作業を利用できるので、管理は即座に容易になります。ここで、いくつか注意すべき点があります。

• AD 内のユーザーを無効にすると、マシンへのアクセスが即座にブロックされます。Windows と同様に、すでにログインしているユーザーはログインしたままになります。
• ユーザーのグループに対する変更は、Windows と同様にログイン中に更新されます。これは、ログインを許可されているかどうかを確認する前に実行されます。
• SSSD はサイトを認識します。AD サイトおよびサービス内にサイトを設定すると、SSSD は適切な DC に接続します。
• SSSD は、マシンのパスワードを自動的にローテーションします。
• 動的更新 (安全でも安全でなくても) が有効である限り、SSSD はマシンの DNS レコードを自動的に作成して管理します。

私は通常、Windows ツールを使って Linux システムを管理したり、Linux ツールを使って Windows を管理したりすることはお勧めしていません。それは多くの場合、重要な機能が使えなくなる、セキュリティが失われるなどの問題を引き起こしますし、ネイティブツールで同じタスクを実行する方がはるかに簡単だからです。ただし、AD の場合は異なります。SSSD の開発者は、SSSD に AD との互換性を持たせるために多くの作業を行っており、それによって貴社での作業もさらに容易になるでしょう。