test

Solaris Bandwidth Manager 1.6 のシステム管理

RADIUS サーバーの使用

Sun Directory Services 3.1 で提供されている RADIUS サーバーは、リモートユーザーに認証サービスを提供します。RADIUS サーバーについての詳細は、Sun Directory Services 3.1 に付属のマニュアルを参照してください。

概要

Sun Directory Services 3.1 で提供されている RADIUS サーバーは、NAS (Netowork Access Server) のための認証承認情報サーバーです。 NAS は、SLIP や PPP などのリモートアクセスプロトコルを使用して接続しようとしているリモートユーザーに、ネットワークへのアクセスポイントを提供するデバイスです。NAS は、リモートユーザーからの接続要求で提供される情報を RADIUS サーバーに転送します。RADIUS サーバーはその情報を、ディレクトリ内にあるそのリモートユーザーのエントリと照合します。そして、リモートユーザーの接続についての承認または拒否を NAS に戻します。また、リモートユーザー接続に適切な接続パラメータも提供します。

注 -

NAS は RAS (Remote Access Server) または RADIUS クライアントとも呼ばれます。.

図 6-4 に、RADIUS が Solaris Bandwidth と共に機能する様子をまとめます。

図 6-4 Solaris Bandwidth Manager における RADIUS の使用

Graphic

ユーザーは、ネットワーク資源へのアクセスを要求するエンティティです。ディレクトリデータベースでは、ユーザーは一意の uid 属性で識別されます。この例を含めてリモートユーザーを記述する属性はすべて、remoteUser オブジェクトクラスで定義されます。

NAS は、リモートユーザーが接続するデバイスです。NAS は RADIUS サーバーに認証状態、ユーザープロファイル、および承認について照会します。ディレクトリデータベースでは、NAS は一意の ipHostNumber 属性で識別されます。この例を含めて RADIUS クライアントを記述する属性はすべて nas オブジェクトクラスで定義されます。

RADIUS サーバーは NAS を認証して、ディレクトリデータベース内で、リモートユーザーの同一性と承認を確認します。そして、ユーザーの状態と設定情報を NAS に戻します。RADIUS サーバーが NAS を認証できなかった場合、要求は無視されます。つまり、接続の拒否はありません。

認証プロセスが完了すると、NAS はリモート接続に関するアカウンティング情報を RADIUS サーバーに送信します。この情報は動的に、ユーザーのディレクトリエントリに記録されます。記録された情報は、dynamicIPaddress、dynamicSessionID、dynamicSessionCounter、および dynamicAddressBinding の属性に格納されます。

次に、この情報は複製イベントを使って Solaris Bandwidth Manager の設定内容に複製されます。

次に、Solaris Bandwidth Manager と Sun Directory Services との間で情報の交換が発生します。このとき、Solaris Bandwidth Manager の設定内容は動的な情報で更新されます。作成されたフィルタやクラスには、関連する uid や sessionID 名で名前が付けられます。LSaction アクションが queueName 属性を持っている場合、クラスは作成されません。

注 -

Solaris Bandwidth Manager と相互運用するときは、動的なアカウンティングが使用されます。他の方法については、Sun Directory Services に付属のマニュアルを参照してください。

設定

RADIUS プロトコルを使用可能にするには、Solaris Bandwidth Manager と Sun Directory Services の両方を設定する必要があります。設定手順とスキーマ情報については、Sun Directory Services に付属のマニュアルを参照してください。

Solaris Bandwidth Manager では、次のようにします。

Sun Directory Services では、次のようにします。

ポリシーの動作

ユーザーの policyAux オブジェクトクラスに含まれている policyRef 属性は、Policy タイプのエントリを指す必要があります。このためには、次のどちらかを行います。

フィルタだけの作成

サービスプロバイダは、Standard、StandardPlus、および Premium の 3 つのクラスのサービスを提供します。各クラスには、異なるレベルの保障帯域幅が割り振られています。管理トラフィックなどの副次的なトラフィックは root クラスによって処理されます。

クラス名 

保障帯域幅 

Premium 

50% 

StandardPlus 

30% 

Standard 

10% 

Fred Smith というユーザーは Premium クラスに加入しています。

Fred Smith からトラフィックを受信したとき、policyAux クラスの policyRef 属性がチェックされます。この属性は「Premium」ポリシーを指しています。「Premium」ポリシーは、queueName 属性「Premium」を持つ LSaction アクション「ActionPremiumClass」を含みます。

Fred Smith の IP アドレスを持つフィルタが作成されて、Premium クラスに追加されます。すると、Fred Smith からのトラフィックは Premium クラスにフィルタされます。このフィルタ名は、ディレクトリ内にある Fred Smith のユーザーエントリの UID に sessionID を加えたものです。

また、ポリシーに条件が追加される可能性もあります。たとえば、サービスの指定などです。

クラスとフィルタの作成

サービスプロバイダは、Standard、StandardPlus、および Premium の 3 つのクラスのサービスを提供します。各クラスには、異なる保障帯域幅が割り振られています。管理トラフィックなどの副次的なトラフィックは root クラスによって処理されます。ただし、サービスの管理者が互いに優先度が高いメッセージを送信する必要がある場合もあります。そのためには、admin-urgent というアカウントから電子メールを送信します。こうすると、優先度が 1 で、保障帯域幅が 10% のクラスが作成され、このようなメッセージは即座に処理されます。

Jane Brown というユーザーは、他の管理者たちに緊急のメッセージを送信する必要があります。そのために、Jane Brown は admin-urgent としてログインします。admin-urgent からトラフィックを受信すると、policyAux クラスの policyRef 属性がチェックされます。この属性は「Urgent」ポリシーを指しています。「Urgent」ポリシーは、ceilingRate、guaranteedRate、および queuePriority という属性を持つ LSaction を含みます。queueName 属性が存在しないため、指定された最大帯域幅、保障帯域幅、および優先度を持つ urgent というクラスが Solaris Bandwidth Manager ソフトウェアによって作成されます。次に、admin-urgent のメッセージの送信元である IP アドレスを含むフィルタが作成されます。このフィルタ名は、UID と sessionID から構成されます。