NISのActive Directoryとの統合
このトピックでは、SSSDを使用して、NISをLinux VDAのWindows Active Directory（AD）と統合する方法について説明します。Linux VDAは、Citrix XenAppおよびXenDesktopのコンポーネントと考えられています。そのためLinux VDAは、Windows AD環境に密接に結びついています。
ADの代わりにNISをUIDおよびGIDプロバイダーとして使用するには、ADとNISでユーザー名とパスワードの組み合わせのアカウント情報を同一にする必要があります。
注：
NISを使用した場合も、認証はADサーバーにより行われます。NIS+はサポートされません。NISをUIDおよびGIDプロバイダーとして使用する場合、WindowsサーバーからのPOSIX属性は使用されません。
ヒント：
これは、Linux VDAを展開する方法として廃止済みであるため、特定のユースケースでのみ使用してください。RHEL/CentOSディストリビューションの場合は、「Linux Virtual Delivery Agent for RHEL/CentOSのインストール」の指示に従ってください。Ubuntuディストリビューションの場合は、「Linux Virtual Delivery Agent for Ubuntuのインストール」の指示に従ってください。
SSSD：
SSSDはシステムデーモンです。SSSDの主な機能は、システムにキャッシュとオフラインサポートを提供する共通フレームワークを通じて、リモートリソースの識別および認証のアクセスを提供することです。PAMやNSSモジュールを提供しており、将来的にはD-BUSベースのインターフェイスもサポートして、拡張ユーザー情報に対応する予定です。また、ローカルユーザーアカウントと拡張ユーザー情報を保存するための優れたデータベースを提供します。
必要なソフトウェア
ADプロバイダーは、SSSD Version 1.9.0で初めて導入されました。
次の環境については、このドキュメントに記載した指示を使用したテストおよび検証を行っています。
- RHEL 7.3以降/CentOS 7.3以降
- Linux VDA Version 1.3以降
NISとADの統合
NISとADを統合するには、次の手順を実行します：
- Linux VDAをNISクライアントとして追加
- ドメインに参加し、Sambaを使用してホストのkeytabを作成
- SSSDのセットアップ
- NSS/PAMの構成
- Kerberos構成の確認
- ユーザー認証の確認
Linux VDAをNISクライアントとして追加
NISクライアントを構成します。
yum –y install ypbind rpcbind oddjob-mkhomedir
<!--NeedCopy-->
NISドメインを設定します。
ypdomainname nis.domain
echo "NISDOMAIN=nis.domain" >> /etc/sysconfig/network
<!--NeedCopy-->
NISサーバーとクライアントのIPアドレスを /etc/hosts に追加します：
{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、ホームディレクトリ、およびログインシェルが正しく設定されていることを確認します。
ドメインに参加し、Sambaを使用してホストのkeytabを作成
SSSDでは、ドメイン参加とシステムのkeytabファイルの管理に関するADのクライアント機能が提供されていません。この機能を取得するには次のような方法があります：
- adcli
- realmd
- Winbind
- Samba
このセクションでは、Sambaによるアプローチについてのみ説明します。realmdについては、RHELまたはCentOSのベンダーのドキュメントを参照してください。SSSDを構成する前に、以下の手順に従う必要があります。
ドメインに参加し、Sambaを使用してホストのkeytabを作成する：
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を開いて、［Global］ セクションに次のエントリを追加します。ただし、追加するのは、authconfigツールによって生成されたセクションの後です：
kerberos method = secrets and keytab
Windowsドメインに参加するには、ドメインコントローラーに到達できることと、コンピューターをドメインに追加する権限を持つADユーザーアカウントが必要です。
sudo net ads join REALM -U user
<!--NeedCopy-->
REALMは大文字のKerberos領域名で、userはコンピューターをドメインに追加する権限を持つドメインユーザーです。
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 lower-case version of the long version of the Active Directory domain.
ad_domain = ad.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
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 スクリプトでのその他の解決方法としては、デフォルト値を使用します。
Kerberos構成の確認
Linux VDAで使用できるようにKerberosが正しく構成されていることを確認するには、次のコマンドにより、システムのkeytabファイルが作成済みでkeytabファイルに有効なキーが含まれていることを確認します：
sudo klist -ke
<!--NeedCopy-->
このコマンドにより、プリンシパル名と暗号スイートのさまざまな組み合わせに対して使用できるキーの一覧が表示されます。Kerberosのkinitコマンドを実行し、これらのキーを使用して、マシンをドメインコントローラーに対して認証します：
sudo kinit –k MACHINE$@REALM
<!--NeedCopy-->
マシン名と領域名は大文字で指定する必要があります。ドル記号（$）は、シェルによる置き換えを防ぐためにバックスラッシュ（\）でエスケープする必要があります。環境によっては、DNSドメイン名がKerberos領域名と異なります。したがって、必ず領域名を使用します。このコマンドが成功すると、出力は表示されません。
次のコマンドを使用して、マシンアカウントのTGTチケットがキャッシュされたことを確認します：
sudo klist -ke
<!--NeedCopy-->
ユーザー認証の確認
getentコマンドを使用して、ログオン形式がサポートされていること、およびNSSが機能するかどうかを確認します：
sudo getent passwd DOMAIN\username
<!--NeedCopy-->
DOMAINパラメーターは短い形式のドメイン名です。別のログオン形式が必要な場合は、まずgetentコマンドを使用して確認します。
サポートされているログオン形式は次の通りです：
- ダウンレベルログオン名：
DOMAIN\username - UPN：
username@domain.com - NetBIOSサフィックス形式：
username@DOMAIN
SSSD PAMモジュールが正しく構成されていることを確認するには、ドメインユーザーアカウントを使用してLinux VDAにログオンします。以前はドメインユーザーアカウントは使用されていませんでした。
sudo localhost –l DOMAIN\username
id -u
<!--NeedCopy-->
次のコマンドによって返されたUIDに対応するKerberos資格情報キャッシュファイルが作成されたことを確認します：
ls /tmp/krb5cc_{uid}
<!--NeedCopy-->
次のコマンドで、ユーザーのKerberos資格情報キャッシュのチケットが有効で、期限切れではないことを確認します：
klist
<!--NeedCopy-->