NISとActive Directoryの統合
この記事では、SSSDを使用して、Linux VDA上でNISをWindows Active Directory (AD) と統合する方法について説明します。Linux VDAはCitrix Virtual Apps and Desktopsのコンポーネントと見なされます。その結果、Windows AD環境に密接に適合します。
ADの代わりにNISをUIDおよびGIDプロバイダーとして使用する場合、ADとNISでアカウント情報（ユーザー名とパスワードの組み合わせ）が同じである必要があります。
注:
認証は引き続きADサーバーによって実行されます。NIS+はサポートされていません。NISをUIDおよびGIDプロバイダーとして使用する場合、WindowsサーバーからのPOSIX属性は使用されなくなります。
ヒント:
この方法は、Linux VDAを展開する非推奨の方法であり、特別なユースケースでのみ使用されます。RHELディストリビューションの場合は、「RHELおよびRocky LinuxにLinux VDAを手動でインストール」の手順に従ってください。Ubuntuディストリビューションの場合は、「UbuntuにLinux VDAを手動でインストール」の手順に従ってください。
SSSDとは
SSSDはシステムデーモンです。その主な機能は、システムのキャッシュとオフラインサポートを提供できる共通のフレームワークを通じて、リモートリソースを識別および認証するためのアクセスを提供することです。PAMとNSSの両方のモジュールを提供し、将来的には拡張ユーザー情報のためのD-BUSベースのインターフェイスをサポートできます。また、ローカルユーザーアカウントと拡張ユーザーデータを保存するためのより優れたデータベースも提供します。
NISとADの統合
NISをADと統合するには、次の手順を実行します。
手順1：Linux VDAのNISクライアントとしての追加
NISクライアントを構成します。
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
NISドメインを設定します。
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
/etc/hostsにNISサーバーとクライアントのIPアドレスを追加します。
{NIS server IP address} server.nis.domain nis.domain
authconfigでNISを構成します。
sudo authconfig --enablenis --nisdomain=nis.domain --nisserver=server.nis.domain --enablemkhomedir --update
<!--NeedCopy-->
nis.domainはNISサーバーのドメイン名を表します。server.nis.domainはNISサーバーのホスト名であり、NISサーバーのIPアドレスでもかまいません。
- NISサービスを構成します。
- sudo systemctl start rpcbind ypbind
sudo systemctl enable rpcbind ypbind
<!--NeedCopy-->
- NIS構成が正しいことを確認します。
ypwhich
<!--NeedCopy-->
NISサーバーからアカウント情報が利用可能であることを検証します。
getent passwd nisaccount
<!--NeedCopy-->
注:
nisaccountはNISサーバー上の実際のNISアカウントを表します。UID、GID、ホームディレクトリ、およびログインシェルが正しく構成されていることを確認してください。
手順2：Sambaを使用したドメインへの参加とホストキータブの作成
SSSDは、ドメインへの参加やシステムキータブファイルの管理のためのADクライアント機能を提供しません。これらの機能を実現するには、いくつかの方法があります。
adclirealmdWinbindSamba
このセクションの情報は、Sambaのアプローチのみを説明しています。realmdについては、RHELまたはCentOSベンダーのドキュメントを参照してください。これらの手順は、SSSDを構成する前に実行する必要があります。
Sambaを使用してドメインに参加し、ホストキータブを作成する：
適切に構成されたファイルを持つLinuxクライアントで：
- /etc/krb5.conf
- /etc/samba/smb.conf:
SambaおよびKerberos認証用にマシンを構成します。
sudo authconfig --smbsecurity=ads --smbworkgroup=domain --smbrealm=REALM --krb5realm=REALM --krb5kdc=fqdn-of-domain-controller --update
<!--NeedCopy-->
ここで、REALMは大文字のKerberosレルム名であり、domainはドメインのNetBIOS名です。
KDCサーバーとレルム名のDNSベースのルックアップが必要な場合は、上記のコマンドに次の2つのオプションを追加します。
--enablekrb5kdcdns --enablekrb5realmdns
/etc/samba/smb.confを開き、authconfigツールによって生成されたセクションの後に、[Global]セクションの下に次のエントリを追加します。
kerberos method = secrets and keytab
winbind offline logon = no
Windowsドメインに参加するには、ドメインコントローラーに到達可能であり、コンピューターをドメインに追加する権限を持つADユーザーアカウントが必要です。
sudo net ads join REALM -U user
<!--NeedCopy-->
REALMは大文字のKerberosレルム名であり、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。
手順3：SSSDのセットアップ
注
Name Service Cache Daemon (NSCD) とSSSDを併用すると、予期しない動作が発生する可能性があります。詳細については、「Using NSCD with SSSD」を参照してください。
SSSDのセットアップは、次の手順で構成されます。
- Linuxクライアントマシンにsssd-adおよびsssd-proxyパッケージをインストールします
- さまざまなファイル（例：sssd.conf）に構成変更を加えます
- sssdサービスを開始します
/etc/sssd/sssd.conf
sssd.conf構成の例（必要に応じてオプションを追加できます）：
[sssd]
config_file_version = 2
domains = EXAMPLE
services = nss, pam
[domain/EXAMPLE]
# Uncomment if you need offline logins
# cache_credentials = true
re_expression = (((?P<domain>[^\\]+)\\(?P<name>.+$))|((?P<name>[^@]+)@(?P<domain>.+$))|(^(?P<name>[^@\\]+)$))
id_provider = proxy
proxy_lib_name = nis
auth_provider = ad
access_provider = ad
- # Should be specified as the long version of the Active Directory domain.
- ad_domain = EXAMPLE.COM
# Kerberos settings
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# Uncomment if service discovery is not working
# ad_server = server.ad.example.com
# Comment out if the users have the shell and home dir set on the AD side
default_shell = /bin/bash
fallback_homedir = /home/%d/%u
# Uncomment and adjust if the default principal SHORTNAME$@REALM is not available
# ldap_sasl_authid = host/client.ad.example.com@AD.EXAMPLE.COM
<!--NeedCopy-->
ad.domain.com、server.ad.example.comを対応する値に置き換えます。詳細については、「sssd-ad(5) - Linux man page」を参照してください。
sssd.confのファイルの所有権と権限を設定します。
chown root:root /etc/sssd/sssd.conf
chmod 0600 /etc/sssd/sssd.conf
restorecon /etc/sssd/sssd.conf
手順4：NSS/PAMの構成
RHEL/CentOS：
authconfigを使用してSSSDを有効にします。oddjob-mkhomedirをインストールして、ホームディレクトリの作成がSELinuxと互換性があることを確認します。
authconfig --enablesssd --enablesssdauth --enablemkhomedir --update
sudo systemctl start sssd
sudo systemctl enable sssd
<!--NeedCopy-->
ヒント:
Linux VDA設定を構成する際、SSSDの場合、Linux VDAクライアントに特別な設定がないことを考慮してください。ctxsetup.shスクリプトの追加ソリューションについては、デフォルト値を使用してください。
手順5：Kerberos構成の検証
Linux VDAで使用するためにKerberosが正しく構成されていることを確認するには、システムkeytabファイルが作成され、有効なキーが含まれていることを確認します。
sudo klist -ke
<!--NeedCopy-->
このコマンドは、プリンシパル名と暗号スイートのさまざまな組み合わせで利用可能なキーのリストを表示します。これらのキーを使用して、Kerberos kinitコマンドを実行し、ドメインコントローラーでマシンを認証します。
sudo kinit –k MACHINE\$@REALM
<!--NeedCopy-->
マシン名とレルム名は大文字で指定する必要があります。ドル記号（$）は、シェル置換を防ぐためにバックスラッシュ（\）でエスケープする必要があります。一部の環境では、DNSドメイン名がKerberosレルム名と異なる場合があります。レルム名が使用されていることを確認してください。このコマンドが成功した場合、出力は表示されません。
マシンアカウントのTGTチケットがキャッシュされていることを確認するには、次を使用します。
sudo klist -ke
<!--NeedCopy-->
手順6：ユーザー認証の検証
getentコマンドを使用して、ログオン形式がサポートされているか、およびNSSが機能するかどうかを検証します。
sudo getent passwd DOMAIN\\username
<!--NeedCopy-->
DOMAINパラメーターは、短いバージョンのドメイン名を示します。別のログオン形式が必要な場合は、まずgetentコマンドを使用して検証してください。
サポートされているログオン形式は次のとおりです。
- ダウンレベルログオン名：
DOMAIN\username - UPN：
username@domain.com - NetBIOSサフィックス形式：
username@DOMAIN
SSSD PAMモジュールが正しく構成されていることを確認するには、ドメインユーザーアカウントを使用してLinux VDAにログオンします。そのドメインユーザーアカウントは以前に使用されたことがありません。
sudo ssh localhost –l DOMAIN\\username
id -u
<!--NeedCopy-->
コマンドによって返されたuidに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します。
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
ユーザーのKerberos資格情報キャッシュ内のチケットが有効であり、期限切れになっていないことを確認します。
klist
<!--NeedCopy-->