Azure NetApp Files での LDAP の使用について

[アーティクル]
10/28/2023

ライトウェイトディレクトリアクセスプロトコル (LDAP) は、インターネットエンジニアリングタスクフォース (IETF) と呼ばれる国際委員会によって開発された標準ディレクトリアクセスプロトコルです。 LDAP は、異種プラットフォーム間でネットワークオブジェクトを検索するために使用できる汎用のネットワークベースのディレクトリサービスを提供することを目的としています。

LDAP モデルは、LDAP ディレクトリストアと通信する方法、ディレクトリ内のオブジェクトを検索する方法、ストア内のオブジェクトを記述する方法、およびディレクトリへのアクセスに使用されるセキュリティを定義します。 LDAP では、ストアに記述されているオブジェクトのカスタマイズと拡張が可能です。そのため、LDAP ストアを使用して、さまざまな種類の情報を格納できます。初期 LDAP 展開の多くは、電子メールや Web アプリケーションなどのアプリケーションのディレクトリストアとして LDAP を使用し、従業員情報を格納することに重点を置いていました。多くの企業では、ネットワークインフォメーションサービス (NIS) をネットワークディレクトリストアとしての LDAP に置き換えつつある、または既に置き換えています。

LDAP サーバーは、NAS ボリュームで使用する UNIX ユーザー ID とグループ ID を提供します。 Azure NetApp Files では、現在サポートされている唯一の LDAP サーバーとして Active Directory を使用できます。このサポートには、Active Directory Domain Services (AD DS) と Microsoft Entra Domain Services の両方が含まれます。

LDAP 要求は、2 つの主な操作に分割できます。

LDAP バインド は、LDAP クライアントから LDAP サーバーへのログインです。このバインドは、LDAP 参照を実行するための読み取り専用アクセス権を持つ LDAP サーバーに対する認証に使用されます。 Azure NetApp Files は LDAP クライアントとして機能します。
LDAP 参照 は、名前、数値 ID、ホームディレクトリパス、ログインシェルパス、グループメンバーシップなど、ユーザーとグループの情報をディレクトリに照会するために使用されます。

LDAP は、デュアルプロトコル NAS アクセスで使用される次の情報を格納できます。

ユーザー名
グループ名
数値のユーザー ID (UID) とグループ ID (GID)
ホームディレクトリ
ログインシェル
ネットグループ、DNS 名、および IP アドレス
グループのメンバーシップ

現在、Azure NetApp Files では、ユーザーとグループの情報にのみ LDAP が使用され、ネットグループやホスト情報には使用されません。

LDAP は、UNIX ユーザーとグループにとっての ID ソースとしてさまざまな利点を提供します。

LDAP は将来に備えています。
より多くの NFS クライアントに NFSv4.x のサポートが追加されるにつれ、アクセスが定義されたときに最適なセキュリティと確実なアクセスを確保するために、クライアントとストレージからアクセスできるユーザーとグループの最新のリストが含まれた NFSv4.x ID ドメインが必要です。 SMB ユーザーと NFS ユーザーに対し一様に 1 対 1 の名前マッピングを提供する ID 管理サーバーがあることで、現在だけでなく、今後何年もの間、ストレージ管理者の作業が大幅に簡素化されます。
LDAP はスケーラブルです。
LDAP サーバーは、何百万ものユーザーオブジェクトとグループオブジェクトを含む機能を提供します。Microsoft Active Directory では、パフォーマンスと回復性の両方を拡張するために複数のサーバーを使用して複数のサイト間でレプリケートできます。
LDAP はセキュリティで保護されています。
LDAP は、ストレージシステムが LDAP サーバーに接続してユーザー情報を要求する方法の形でセキュリティーを提供します。 LDAP サーバーには、次のバインドレベルが用意されています。
- 匿名 (Microsoft Active Directory では既定で無効になっています。Azure NetApp Files ではサポートされていません。)
- 簡易パスワード (プレーンテキストパスワード。Azure NetApp Files ではサポートされていません。)
- 簡易認証とセキュリティ層 (SASL) – TLS、SSL、Kerberos などの暗号化されたバインド方法。 Azure NetApp Files では、TLS 経由の LDAP、LDAP 署名 (Kerberos を使用)、SSL 経由の LDAP がサポートされています。
LDAP は堅牢です。
NIS、NIS+、ローカルファイルは、UID、GID、パスワード、ホームディレクトリなどの基本情報を提供します。しかし、LDAP はこれらに加えさらに多くの属性を提供します。 LDAP で使用される追加の属性により、LDAP では NIS と比較して、デュアルプロトコル管理がはるかに統合されます。 Azure NetApp Files では、ID 管理の外部ネームサービスとしてサポートされるのは LDAP のみです。
Microsoft Active Directory は LDAP 上に構築されています。
既定では、Microsoft Active Directory では、ユーザーとグループのエントリに LDAP バックエンドが使用されます。ただし、この LDAP データベースには UNIX スタイルの属性は含まれません。これらの属性は、UNIX 用 ID 管理 (Windows 2003R2 以降)、Unix 用サービス (Windows 2003 以前)、または Centrify などのサードパーティの LDAP ツールにより LDAP スキーマが拡張される際に追加されます。 Microsoft ではバックエンドとして LDAP が使用されるため、LDAP は、Azure NetApp Files でデュアルプロトコルボリュームを利用することを選択した環境に最適なソリューションとなります。

Note

Azure NetApp Files では現在、LDAP サービスにはネイティブ Microsoft Active Directory のみがサポートされています。

Azure NetApp Files での LDAP の基本

以下のセクションでは、Azure NetApp Files に関連する LDAP の基本について説明します。

LDAP 情報は LDAP サーバー内のフラットファイルに保管され、LDAP スキーマを使用して編成されます。 LDAP クライアントは、その要求および参照が、LDAP サーバー上のスキーマと調整されるように構成する必要があります。
LDAP クライアントは、LDAP バインドを使用してクエリを開始します。これは、実質的に、LDAP スキーマへの読み取りアクセス権を持つアカウントを使用する LDAP サーバーへのログインです。クライアント上の LDAP バインド構成は、LDAP サーバーによって定義されるセキュリティメカニズムを使用するように構成されます。これは、場合によっては、プレーンテキストでのユーザー名とパスワードの交換です (simple)。その他の場合では、バインドは、TLS 経由の Kerberos や LDAP などの "簡易認証とセキュリティ層" 方法 (sasl) によるセキュリティで保護されます。 Azure NetApp Files では、可能な限り最高のセキュリティを実現するために、SMB マシンアカウントを使用して SASL 認証によりバインドします。
LDAP に格納されているユーザーとグループの情報は、RFC 2307 で定義される標準 LDAP 検索要求を使用してクライアントにより照会されます。さらに、RFC 2307bis などのより新しいメカニズムにより、より合理化されたユーザーとグループの参照が可能です。 Azure NetApp Files は、Windows Active Directory でのスキーマ参照に RFC 2307bis の形式を使用します。
LDAP サーバーは、ユーザーとグループの情報とネットグループを格納できます。ただし、Azure NetApp Files では現在、Windows Active Directory 上の LDAP でネットグループ機能を使用することはできません。
Azure NetApp Files の LDAP はポート 389 上で動作します。現在、このポートは、ポート 636 (SSL 経由の LDAP) やポート 3268 (Active Directory グローバルカタログ検索) などのカスタムポートを使用するように変更することはできません。
暗号化された LDAP 通信は、TLS 経由の LDAP (ポート 389 経由で動作) または LDAP 署名を使用して実現できます。どちらも Active Directory 接続上で構成できます。
Azure NetApp Files では、3 秒以内で完了する LDAP クエリがサポートされています。 LDAP サーバーに多数のオブジェクトがある場合、そのタイムアウトを超える可能性があり、認証要求が失敗する可能性があります。そのような場合は、LDAP 検索スコープを指定してクエリをフィルター処理してパフォーマンスを向上させることを検討してください。
Azure NetApp Files では、要求の高速化に役立つ優先 LDAP サーバーの指定もサポートされています。 Azure NetApp Files リージョンに最も近い LDAP サーバーが使用されるようにしたい場合は、この設定を使用します。

優先 LDAP サーバーが設定されていない場合は、Active Directory ドメイン名が DNS で LDAP サービスレコードに対して照会され、その SRV レコード内にあるリージョンで使用可能な LDAP サーバーの一覧が作成されます。 nslookup または dig のコマンドを使用して、クライアントから DNS 内の LDAP サービスレコードに対して手動でクエリを実行することも可能です。

次に例を示します。

C:\>nslookup
Default Server:  localhost
Address:  ::1

> set type=SRV
> _ldap._tcp.contoso.com.

Server:  localhost
Address:  ::1

_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 0
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = ONEWAY.Contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = oneway.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = parisi-2019dc.contoso.com
_ldap._tcp.contoso.com   SRV service location:
          priority       = 0
          weight         = 100
          port           = 389
          svr hostname   = contoso.com
oneway.contoso.com       internet address = x.x.x.x
ONEWAY.Contoso.com       internet address = x.x.x.x
oneway.contoso.com       internet address = x.x.x.x
parisi-2019dc.contoso.com        internet address = y.y.y.y
contoso.com      internet address = x.x.x.x
contoso.com      internet address = y.y.y.y

LDAP サーバーを使用して、ユーザーのカスタム名マッピングを実行することもできます。詳細については、「LDAP を使用したカスタム名マッピング」を参照してください。
LDAP クエリのタイムアウト

既定では、LDAP クエリは、適切な時間内に完了できない場合はタイムアウトになります。タイムアウトが原因で LDAP クエリが失敗した場合、ユーザーやグループの参照は失敗し、ボリュームのアクセス許可の設定によっては、Azure NetApp Files ボリュームへのアクセスが拒否される可能性があります。 Azure NetApp Files LDAP クエリのタイムアウト設定については、「Active Directory 接続の作成と管理」を参照してください。

名前マッピングの種類

名前マッピングルールは、"対称" と "非対称" の 2 種類に分類できます。

""対称" 名前マッピングは、同じユーザー名を使用する UNIX ユーザーと Windows ユーザーの間での暗黙的な名前マッピングです。たとえば、Windows ユーザー CONTOSO\user1 は UNIX ユーザー user1 にマップされます。
"非対称" 名前マッピングは、異なるユーザー名を使用する UNIX ユーザーと Windows ユーザーの間での名前マッピングです。たとえば、Windows ユーザー CONTOSO\user1 は UNIX ユーザー user2 にマップされます。

既定では、Azure NetApp Files では対称名前マッピング規則が使用されます。非対称名前マッピング規則が必要な場合は、LDAP ユーザーオブジェクトでそれが使用されるように構成することを検討してください。

LDAP を使用したカスタム名前マッピング

LDAP サーバー上の LDAP スキーマ属性が入力されている場合は、LDAP を名前マッピングのリソースにすることができます。たとえば、UNIX ユーザーを 1 対 1 ではなく対応する Windows ユーザー名にマップする (つまり非対称) には、uid に対して Windows ユーザー名に対して構成されているものとは異なる値をユーザーオブジェクトで指定できます。

次の例では、Windows 名 asymmetric を持つユーザーを、UNIX ID UNIXuser にマップする必要があります。これを Azure NetApp Files で実現するには、Active Directory ユーザーとコンピューター MMC のインスタンスを開きます。次に、目的のユーザーを見つけて、プロパティボックスを開きます。 (これを行うには、[属性エディター] を有効にする必要があります。) [属性エディター] タブに移動し、[UID] フィールドを見つけて、目的の UNIX ユーザー名 UNIXuser を [UID] フィールドに入力し、[追加] をクリックして [OK] をクリックして確定します。

この操作が完了すると、Windows ユーザー asymmetric によって Windows SMB 共有から書き込まれたファイルは、NFS 側では UNIXuser により所有されます。

次の例では、Windows SMB 所有者 asymmetric が表示されています。

次の例では、NFS 所有者 UNIXuser (LDAP を使用して Windows ユーザー asymmetric からマップされた) が表示されています。

root@ubuntu:~# su UNIXuser
UNIXuser@ubuntu:/root$ cd /mnt
UNIXuser@ubuntu:/mnt$ ls -la
total 8
drwxrwxrwx  2 root     root   4096 Jul  3 20:09 .
drwxr-xr-x 21 root     root   4096 Jul  3 20:12 ..
-rwxrwxrwx  1 UNIXuser group1   19 Jul  3 20:10 asymmetric-user-file.txt

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 での LDAP の使用について

Azure NetApp Files での LDAP の基本

名前マッピングの種類

LDAP を使用したカスタム名前マッピング

LDAP スキーマ

次のステップ

その他のリソース