Azure NetApp Files の LDAP スキーマを理解する

ライトウェイト ディレクトリ アクセス プロトコル (LDAP) スキーマは、LDAP サーバーが情報を整理および収集する方法です。 LDAP サーバー スキーマは、一般に同じ標準に従いますが、LDAP サーバー プロバイダーによってスキーマの表示方法が異なる場合があります。

Azure NetApp Files が LDAP に対しクエリを実行する場合、スキーマは名前検索の高速化に役立ちます。ユーザーに関する情報を検索するために UID などの特定の属性を使用できるからです。 エントリを検索するには、Azure NetApp Files の LDAP サーバーにスキーマ属性が存在する必要があります。 そうでない場合、LDAP クエリはデータを返さない可能性があり、認証要求は失敗する可能性があります。

たとえば、Azure NetApp Files で UID 番号 (root=0 など) を照会する必要がある場合は、スキーマ属性 RFC 2307 uidNumber Attribute が使用されます。 LDAP 中の uidNumber フィールドに UID 番号 0 が存在しない場合、参照要求は失敗します。

Azure NetApp Files で現在使用されているスキーマの種類は、RFC 2307bis に基づくスキーマの形式であり、変更することはできません。

RFC 2307bis は RFC 2307 の拡張であり、posixGroup へのサポートが追加されています。これは、LDAP スキーマの memberUid 属性を使用するのではなく、uniqueMember 属性を使用して補助グループを動的に参照できるようにするものです。 この属性には、ユーザーの名前だけを使用する代わりに、LDAP データベース内の別のオブジェクトの完全識別名 (DN) が含まれています。 そのため、グループは他のグループをメンバーとして持つことができます。これにより、グループを入れ子にすることができます。 RFC 2307bis のサポートにより、オブジェクト クラス groupOfUniqueNames のサポートも追加されます。

この RFC 拡張は、Microsoft Active Directory が通常の管理ツールを使用してユーザーとグループを管理する方法に適合しています。 これは、標準の Windows 管理方法を使用して Windows ユーザーをグループに追加する場合 (およびそのグループに有効な数値 GID がある場合)、LDAP 参照によって通常の Windows 属性から必要な補足グループ情報がプルされ、数値 GID が自動的に検索されるためです。

Azure NetApp Files ボリュームで NFS ユーザー ID の LDAP 参照を実行する必要がある場合、一連の属性が RFC-2307bis に基づいて LDAP スキーマによって定義されます。 次の表に、LDAP 参照で使用される属性を示します。これらは、UNIX 属性を使用する場合に Microsoft Active Directory で定義される既定値です。 適切に機能するには、これらの属性が、LDAP でユーザー アカウントとグループ アカウントに適切に設定されていることを確認します。

UNIX 属性	LDAP スキーマ値
UNIX ユーザー名	uid*
UNIX ユーザーの数値 ID	uidNumber*
UNIX グループ名	cn*
UNIX グループの数値 ID	gidNumber*
UNIX グループ メンバーシップ	member**
UNIX ユーザー オブジェクト クラス	ユーザー**
UNIX ホーム ディレクトリ	unixHomeDirectory
UNIX の表示名	gecos
UNIX ユーザー パスワード	unixUserPassword
UNIX ログイン シェル	LoginShell
名前マッピングに使用される Windows アカウント	sAMAccountName**
UNIX グループ オブジェクト クラス	Group**
UNIX メンバー UID	memberUid***
固有名の UNIX グループ オブジェクト・クラス	Group**

* 適切な LDAP 機能の必須属性

** 既定で Active Directory に設定されます

*** 不要

LDAP 属性のインデックス作成について

Active Directory LDAP には、参照要求の高速化に役立つ、属性のインデックス作成方法が用意されています。 これは、LDAP 検索が Azure NetApp Files での参照のタイムアウト値 10 秒を超える可能性がある、大規模なディレクトリ環境で特に役立ちます。 検索がそのタイムアウト値を超えると、アクセスを要求しているユーザーまたはグループ ID をサービスが検証できないため、LDAP 参照は失敗し、アクセスは正常に機能しません。

既定では、Microsoft Active Directory LDAP では、Azure NetApp Files で LDAP 参照に使用される次の UNIX 属性のインデックスが作成されます。

• 共通名 (CN)
• uidNumber
• gidNumber

既定では、uid 属性のインデックスは作成されません。 その結果、UID に対する LDAP クエリは、インデックス付き属性のクエリよりも時間がかかります。

たとえば、20,000 人を超えるユーザーとグループを含む Active Directory 環境におけるクエリの次のテストでは、インデックス付き属性 CN を使用するユーザーの検索に約 0.015 秒かかりましたが、UID 属性 (既定でインデックスが作成されない) を使用する同じユーザーの検索は 0.6 秒近くかかりました。これは 40 倍遅くなります。

小規模な環境では、これは問題を起こしません。 しかし、大規模な環境 (すなわち Active Directory 環境がオンプレミスであるか、ネットワーク待機時間が長い環境) では、Azure NetApp Files ボリュームにアクセスするユーザーにとってこの違いがアクセスの問題を引き起こすほど大きくなる可能性があります。 そのため、Active Directory によってインデックスが作成されるように LDAP の UID 属性を構成することをお勧めします。

Active Directory によってインデックスが作成されるように UID 属性を構成する

属性は、属性オブジェクトの searchFlags 値を使用してインデックスが作成されます。これは、スキーマ名前付けコンテキストで ADSI Edit によって構成可能です。 ADSI Edit へのアクセスは慎重に行う必要があり、少なくともスキーマ管理者権限が必要です。

既定では、uid 属性オブジェクトの searchFlags は 0x8 (PRESERVE_ON_DELETE) に設定されます。 この既定の設定により、Active Directory 内のオブジェクトが削除された場合であっても、属性値はユーザーの属性の履歴レコードとしてディレクトリに保管されたままになります。

これに対して、Active Directory で LDAP 検索用にインデックスが作成される属性の値は、0x1 (またはその値を含む組み合わせ) になります (uidNumber など)。

このため、uidNumber のクエリは uid のクエリよりも高速に応答が返されます。 一貫性とパフォーマンスを確保するために、0x1 を既存の値 0x8 と一緒に追加して uid の searchFlags 値を 9 に調整できます (INDEX |PRESERVE_ON_DELETE)。 この追加により、属性インデックスをディレクトリに追加しながら既定の動作が維持されます。

インデックス作成では、uid を使用したユーザー属性の検索は、他のインデックス付き属性の検索と同じくらい高速です。

次のステップ

• LDAP の基本について理解する
• LDAP を使用した名前マッピングについて
• LDAP オプションを使用したローカル NFS ユーザーの許可について理解する