Azure NetApp Files での LDAP の使用について
ライトウェイト ディレクトリ アクセス プロトコル (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.yLDAP サーバーを使用して、ユーザーのカスタム名マッピングを実行することもできます。 詳細については、「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] をクリックして確定します。
![[非対称プロパティ] ウィンドウと [複数値の文字列エディター] ウィンドウを示すスクリーンショット。](media/lightweight-directory-access-protocol/asymmetric-properties.png#lightbox)
この操作が完了すると、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 を使用するローカル NFS ユーザーを許可する
ユーザーが NFS 経由で Azure NetApp Files ボリュームにアクセスしようとすると、要求は数値 ID で送信されます。 既定では、Azure NetApp Files では NFS ユーザーの拡張グループ メンバーシップがサポートされます (標準の 16 グループの制限を超えるため)。 その結果、Azure NetApp ファイルは、RPC パケットでグループ メンバーシップを渡すのではなく、ユーザーのグループ メンバーシップを解決しようとして、その数値 ID を取得し、LDAP で検索しようとします。 この動作により、その数値 ID を LDAP のユーザーに解決できない場合、要求するユーザーがボリュームまたはデータ構造にアクセスするアクセス許可を持っている場合でも、参照は失敗し、アクセスは拒否されます。 Active Directory 接続で LDAP を使用してローカル NFS ユーザーを許可するオプションは、拡張グループ機能を無効にすることで、NFS 要求に対する LDAP 参照を無効にすることを目的としています。 Azure NetApp Files 内の "ローカル ユーザーの作成/管理" は提供されません。
[LDAP を使用するローカル NFS ユーザーを許可する] オプションが有効になっている場合、数値 ID は Azure NetApp Files に渡され、LDAP 参照は実行されません。 これにより、以下で説明するように、さまざまなシナリオに対してさまざまな動作が作成されます。
UNIX セキュリティ スタイル のボリュームを含む NFSv3
数値 ID をユーザー名に変換する必要はありません。 [LDAP を使用するローカル NFS ユーザーを許可する] オプションはボリュームへのアクセスには影響しませんが、NFS クライアントでのユーザー/グループ所有権 (名前変換) の表示方法に影響する可能性があります。 たとえば、数値 ID 1001 が LDAP では user1 であるが、NFS クライアントのローカル passwd ファイルでは user2 である場合、クライアントでは、数値 ID が 1001 のときにファイルの所有者として "user2" が表示されます。
UNIX セキュリティ スタイルのボリュームを含む NFSv4.1
数値 ID をユーザー名に変換する必要はありません。 既定では、NFSv4.1 は認証に名前文字列 (user@CONTOSO.COM) を使用します。 ただし、Azure NetApp Files では NFSV4.1 での数値 ID の使用がサポートされています。つまり、NFSv4.1 要求は数値 ID を持つ NFS サーバーに届きます。 Azure NetApp Files ボリュームのローカル ファイルまたは LDAP などのネーム サービスに数値 ID からユーザー名への変換が存在しない場合は、数値がクライアントに表示されます。 数値 ID がユーザー名に変換される場合は、名前の文字列が使用されます。 名前の文字列が一致しない場合、クライアントは、クライアントの idmapd.conf ファイルで指定された匿名ユーザーに名前をスカッシュします。 [LDAP を使用するローカル NFS ユーザーを許可する] オプションを有効にしても NFSv4.1 アクセスには影響しません。これは、Azure NetApp Files がローカル NFS ユーザー データベース内のユーザー名に数値 ID を解決できない限り、標準の NFSv3 動作にフォールバックするためです。 Azure NetApp Files には、一部のクライアントで問題になる可能性がある一連の既定の UNIX ユーザーがあり、ドメイン ID 文字列が一致しない場合は 「nobody」 ユーザーにスカッシュします。
- ローカル ユーザーには、root (0)、pcuser (65534)、nobody (65535) が含まれます。
- ローカル グループには、root (0)、daemon (1)、pcuser (65534)、nobody (65535) が含まれます。
最も一般的には、NFSv4.1 ドメイン ID が正しく構成されていない場合、NFSv4.1 クライアント マウントでルートが正しく表示されないことがあります。 NFSv4.1 ID ドメインの詳細については、「Azure NetApp Files の NFSv4.1 ID ドメインの構成」を参照してください。
NFSv4.1 ACL は、名前文字列または数値 ID を使用して構成できます。 数値 ID を使用する場合、名前変換は必要ありません。 名前文字列を使用する場合は、適切な ACL 解決のために名前変換が必要になります。 NFSv4.1 ACL を使用する場合、[LDAP を使用するローカル NFS ユーザーを許可する] を有効にすると、ACL の構成によっては、NFSv4.1 ACL の動作が正しくなくなる可能性があります。
デュアル プロトコル構成の NTFS セキュリティ スタイル ボリュームを使用した NFS (v3 と v4.1)
UNIX セキュリティ スタイルのボリュームでは、UNIX スタイルのアクセス許可 (モード ビットと NFSv4.1 ACL) が利用されます。 これらの種類のボリュームの場合、NFS では、上記のシナリオに応じて、数値 ID または名前文字列を利用する UNIX スタイルの認証のみが利用されます。 ただし、NTFS セキュリティ スタイルのボリュームでは、NTFS スタイルのアクセス許可を使用します。 これらのアクセス許可は、Windows ユーザーとグループを使用して割り当てられます。 NFS ユーザーが NTFS スタイルのアクセス許可を持つボリュームにアクセスしようとすると、適切なアクセス制御を確保するために UNIX から Windows への名前マッピングが行われる必要があります。 このシナリオでは、NFS 数値 ID は引き続き Azure NetApp Files NFS ボリュームに渡されますが、初期認証用に Windows ユーザー名にマップできるように、数値 ID を UNIX ユーザー名に変換する必要があります。 たとえば、数値 ID 1001 が、Windows ユーザー "user1" へのアクセスを許可する NTFS セキュリティ スタイルのアクセス許可を持つ NFS マウントへのアクセスを試行する場合、LDAP で 1001 を "user1" ユーザー名に解決して、期待されるアクセス権を取得する必要があります。 数値 ID が "1001" のユーザーが LDAP に存在しない場合、または LDAP が正しく構成されていない場合、試行される UNIX から Windows への名前マッピングは 1001@contoso.com になります。 ほとんどの場合、その名前のユーザーは存在しないため、認証は失敗し、アクセスは拒否されます。 同様に、数値 ID 1001 が間違ったユーザー名 (user2 など) に解決された場合、NFS 要求は予期しない Windows ユーザーにマップされ、ユーザーのアクセス許可は "user2" アクセス制御を使用します。
[LDAP を使用するローカル NFS ユーザーを許可する] を有効にすると、数値 ID からユーザー名への LDAP 変換がすべて無効になり、NTFS セキュリティ スタイルのボリュームへのアクセスが実質的に中断されます。 そのため、NTFS セキュリティ スタイルのボリュームでは、このオプションを使用しないことを強くお勧めします。
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 が自動的に検索されるためです。
次のステップ
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示