RHEL をドメイン参加させる (SSSD)

## Introduction
SSSD で RHEL 9.3 のドメイン参加を検証したので、解説します。
Samba Winbind を使用した方法はこちらを参照してください。

https://qiita.com/TakSewo/items/b870e45ee9b72d6b0ad3

どちらを使えばいい？となるかもしてませんが基本的に、SSSD がより新しく、多くの機能を提供します。その代替手段として Samba Winbind サービスがあります。それぞれ機能が異なるため、ご用件に合わせて選択してください。SSSD の利点としてはこちらをご参照ください。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/8/html/configuring_authentication_and_authorization_in_rhel/con_benefits-of-using-sssd_understanding-sssd-and-its-benefits

Samba に関してはこちらをご参照ください。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/9/html-single/configuring_and_using_network_file_services/index#assembly_using-samba-as-a-server_configuring-and-using-network-file-services


**SSSD に関して**
RHEL を Active Directory (AD) に接続するには SSSD と realmd の2 つのコンポーネントが必要です。
- SSSD: 中央の ID および、認証ソースとの相互作用します
- realmd: 利用可能なドメインを検出して SSSD がドメインに接続できるように基盤となる RHEL システムサービスを提供します

Linux システムおよび Windows システムは、ユーザーおよびグループに異なる識別子を使用します。
その為、SSSD を使用し、 ID マッピングまたは POSIX 属性のいずれかを使用して AD と統合します。デフォルトでは ID マッピングが使用されます。

具体的な識別子の違いは以下です。
- Linux では ユーザー ID (UID) と グループ ID (GID) が使用されます
- Windows では セキュリティ ID (SID) が使用されます

そのため AD ユーザー用に新規 UID および GID を自動的に生成する必要があります。
また ID マッピングですが、POSIX ID を生成することで、 AD の SID と Linux の ID との間にマップを作成することで可能にります。

UID と GID の確認方法ですが `id <ユーザー名>` で確認が可能です。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/cac31ce7-800f-f7fb-4914-d858f747d3db.png)

また Kerberos 認証のために DC と RHEL システムのシステム時刻が同じことを確認してください。
ドメインコントローラー側で、`net time` をたたきます。
RHEL 側で `date` とコマンドを実行するとシステム時刻の確認ができます。

## AD 参加のさせ方
SSSD を使用した AD 参加には ID マッピングと POSIX 属性の仕様の 2 通りあり、その方法を記載します。また以下が双方の違いとなります。

- ID マッピング
    - ID マッピングは、AD ユーザーとグループの SID (セキュリティ識別子) を UNIX スタイルの UID (ユーザー ID) と GID (グループ ID) にマッピングします
    - この方法では、AD に POSIX 属性を追加する必要はありません。これは、ID マッピングが動的に行われ、AD のユーザーとグループが初めてアクセスしたときに UID と GID が割り当てられます
    - ID マッピングは、大規模な環境や、AD のスキーマを変更できない環境で便利です

- POSIX 属性の使用
    - POSIX 属性を使用すると、AD ユーザーとグループに直接 UID、GID、ホームディレクトリ、ログインシェルなどの属性を設定できます
    - これには、AD スキーマが POSIX 属性をサポートするように拡張されている必要があります。これは通常、Identity Management for Unix コンポーネントをインストールすることで達成されます
    - POSIX 属性を使用すると、より細かい制御が可能になりますが、これらの属性を手動で設定する管理作業が必要になります


これらの方法は、それぞれ異なる利点と制約があります。適切な方法は、特定の要件と環境によります。たとえば、大規模な環境では ID マッピングが適しているかもしれませんが、特定のユーザーとグループに対して細かい制御が必要な場合は、POSIX 属性の使用が適しています。

## ID マッピングを使用した ドメイン参加
前提として通信に必要なポートをご確認ください。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-ad-proc

1\. 対象の RHEL システムで以下のコマンドを実行してください。
```bash
yum install samba-common-tools realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
```

<details><summary>インストールするパッケージの内容</summary>

- realmd：エンタープライズネットワークにシステムを参加させるためツールです
- oddjob：D-Bus メッセージに基づいて特権タスクを実行するためのサービスとヘルパープログラムを提供します
- oddjob-mkhomedir：ユーザーが初めてログインしたときにホームディレクトリを自動的に作成するための Oddjob ヘルパーです
- sssd (System Security Services Daemon)：システム認証、認可、およびユーザーとグループ情報の取得を管理するためのシステムサービスです
- adcli：Active Directory ドメインに対して操作を行うためのコマンドラインツールです
- krb5-workstation：Kerberos 認証プロトコルを使用するためのクライアントプログラムとユーティリティを提供します
</details>

2\. 正しくインストールされたことを確認し、ドメイン参加させます。
```bash
realm join -U <AD ユーザー名> <ドメイン名>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/25bb6c76-444a-b112-0f01-7bc767f4ba47.png)

`ldap_id_mapping = true` となっていることを確認します。



3\. ドメイン名を確認します。
```bash
realm list
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/11eceec7-8cb2-44a1-0ba1-fe82e26b913f.png)

## POSIX 属性を使用した ドメイン参加
前提として通信に必要なポートをご確認ください。

https://access.redhat.com/documentation/ja-jp/red_hat_enterprise_linux/7/html/windows_integration_guide/sssd-ad-proc

1\. 以下のパッケージをインストールします
```bash
yum install realmd oddjob oddjob-mkhomedir sssd adcli krb5-workstation
```

2\. 正しくインストールされたことを確認し、AD 参加させます。
`realm join` のコマンドで `-automatic-id-mapping=no` オプションを付けて実行して、ローカルの RHEL システムで ID マッピングを無効にします。
```bash
realm join --automatic-id-mapping=no -U <AD ユーザー名> <ドメイン名>
```

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/da5bd941-886f-2190-b129-53f7c8f33d04.png)

(2.)すでにドメインに参加している場合は,  `/etc/sssd/sssd.conf` を開き
`ldap_id_mapping = false` と設定します。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/d17ccb29-6e3a-a9e8-14ca-a25cf5df3101.png)

これで、AD の POSIX 属性を使用する形になりました。

ドメインの Active Directory Users and Computers において、ドメイン参加させたコンピューターの Attribute Editor において、uidNumber, gidNumber, unixHomeDirectory, loginShell を設定してください。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/7b66a84a-5ff4-d241-6a82-5dc9139b1f78.png)


- `uidNumber`：ユーザーの一意の識別子。これは通常、自動的に割り当てられますが、必要に応じて手動で設定することもできます
- `gidNumber`：ユーザーが属するプライマリグループの一意の識別子。これは通常、自動的に割り当てられますが、必要に応じて手動で設定することもできます
- `loginShell`：ユーザーがログインしたときに起動するシェルです
- `unixHomeDirectory`：ユーザーのホームディレクトリのパスです
これらの手順を完了すると、AD ユーザーに POSIX 属性が設定されます。

3\. realm list にて ドメインの確認をします.

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/bdfd2826-ceaa-ac38-255f-18a838acaa20.png)


## 共通の確認事項
ここからは ID マッピングを行った RHEL システムで他の確認事項をカバーします。

1\. AD ドメインの AD 管理者アカウントなどの詳細を以下のコマンドで確認します。

```bash
getent passwd "<AD ユーザー名>@<ドメイン名>"
#または
getent passwd "<ドメイン名>\<AD ユーザー名>"
```
2\. .次に RHELでドメインユーザーでログインできることを確認します。
```bash
su - azureadmin@lab001.local
```

その際以下のようにホームディレクトリが自動作成されます。

![image.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/693422/b3bb83de-e299-7b30-4fff-5e1c60cf4484.png)

ドメインに参加できていることが確認できました。

4\. Kerberos 認証が期待通りに機能することを確認します。
こちらは Samaba Windbind を使用したときと同じなので、

https://qiita.com/TakSewo/items/b870e45ee9b72d6b0ad3

こちらを確認してください。

## Wrap up
今回は SSSD を使用して、RHEL 9.3 を Windows Server 2022 の DC に参加させました。
Samba Winbind を使用した例は、上記の URL から参照してください。
ではでは