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 サーバーによって定義されるセキュリティ メカニズムを使用するように構成されます。 場合によっては、ユーザー名とパスワードがプレーンテキスト (シンプル) でやり取りされることもあります。 その他の場合では、バインドは、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 接続の作成と管理」を参照してください。