[edit]
root# set system login class consultant allow-configuration interfaces [edit]
root# set system login class consultant permissions configure
3. ユーザー carrie
を設定して、consultantクラスに割り当てます。[edit]
barnys# set system login user carrie class consultant authentication plain-text-password
New password:
Retype new password:
設定をコミットします。
[edit]
barnys# commit commit complete
確認 ここで、アカウントが想定どおりに動作していることを確認する時間を 取ってください。各クラスに何の役割を期待するのかを理解すること は、ネットワークの多くの管理問題を軽減するために重要です。ここ では、
max、 halle、 carrie
のみを確認します。アカウントbarnys
は、これまでに使用した
root
アカウントとまったく同じであるため省略し ます。4. ユーザーアカウント max
をテストします。[barnys@server1 ~]$ ssh [email protected] [email protected]’s password:
--- JUNOS 10.1R1.8 built 2010-02-12 17:24:20 UTC max> configure
^
unknown command.
第4章：管理者の設定 35
max> show configuration
## Last commit:2010-04-11 04:13:21 UTC by barnys version /* ACCESS-DENIED */;
system { /* ACCESS-DENIED */ };
interfaces { /* ACCESS-DENIED */ };
routing-options { /* ACCESS-DENIED */ };
security { /* ACCESS-DENIED */ };
max> clear interfaces statistics all max> traceroute 10.189.132.70
traceroute to 10.189.132.70 (10.189.132.70), 30 hops max, 40 byte packets 1 10.189.140.97 (10.189.140.97) 1.011 ms 0.718 ms 0.654 ms
2 10.189.132.97 (10.189.132.97) 0.684 ms 0.220 ms 0.207 ms 3 10.189.132.70 (10.189.132.70) 1.650 ms 0.361 ms 0.355 ms max> ping 10.189.140.97 count 2
PING 10.189.140.97 (10.189.140.97):56 data bytes
64 bytes from 10.189.140.97: icmp_seq=0 ttl=64 time=0.873 ms 64 bytes from 10.189.140.97: icmp_seq=1 ttl=64 time=0.878 ms 10.189.140.97 ping statistics
---2 packets transmitted, ---2 packets received, 0% packet loss round-trip min/avg/max/stddev = 0.873/0.875/0.878/0.003 ms
operator
クラスに割り当てられたユーザーmax
は、コンフィグレーションモードへの切り替えができないため、設定の変更や読み 取りができません。ただし、インタフェースの統計をクリアしたり、
traceroute
、ping
、診断コマンドを実行することはできます。これは、このクラスの想定どおりの動作です。
5. ユーザーアカウント halle
をテストします。[barnys@server1 ~]$ ssh [email protected] [email protected]’s password:
--- JUNOS 10.1R1.8 built 2010-02-12 17:24:20 UTC halle> configure
^
unknown command.
halle> clear ^
unknown command.
halle> ping ^
unknown command.
halle> show configuration
## Last commit:2010-04-11 04:13:21 UTC by barnys version /* ACCESS-DENIED */;
system { /* ACCESS-DENIED */ };
interfaces { /* ACCESS-DENIED */ };
routing-options { /* ACCESS-DENIED */ };
security { /* ACCESS-DENIED */ };
halle> show system uptime
Current time:2010-04-11 04:34:02 UTC
System booted:2010-03-29 14:30:13 UTC (1w5d 14:03 ago) Protocols started:2010-03-29 14:31:16 UTC (1w5d 14:02 ago) Last configured:2010-04-11 04:13:21 UTC (00:20:41 ago) by barnys 4:34AM up 12 days, 14:04, 2 users, load averages:0.00, 0.00, 0.00 halle> show interfaces fxp0
Physical interface: fxp0, Enabled, Physical link is Up <snip>
アカウント
halle
の権限は、オペレーションモードのshow
コマンド に制限されています。インタフェースをクリアしたり、アプリケーショ ンを実行することはできません。read-onlyクラスは、デバイスの運 用ステータスの監視を担当する管理者に適しています。6. ユーザーアカウント carrie
をテストします。[barnys@server1 ~]$ ssh [email protected] [email protected]’s password:
--- JUNOS 10.1R1.8 built 2010-02-12 17:24:20 UTC carrie> show
^
unknown command.
carrie> edit
Entering configuration mode
Users currently editing the configuration:
barnys terminal p0 (pid 20718) on since 2010-04-11 04:10:24 UTC, idle 00:30:32 [edit]
[edit]
carrie# show
## Last changed:2010-04-11 05:02:53 UTC interfaces {
ge-0/0/0 { unit 0 {
family inet {
address 192.168.2.1/24;
} } }
ge-0/0/1 { unit 0 {
family inet {
address 198.18.100.4/24;
}
第4章：管理者の設定 37
} }
ge-0/0/2 { unit 0 {
family inet {
address 66.129.250.1/24;
} } } fxp0 { unit 0 {
family inet {
address 10.189.140.99/27;
} } } } [edit]
carrie# edit interfaces fxp0 [edit interfaces fxp0]
carrie# set description “Connects to 10.188.0.0/14 for management only”
[edit interfaces fxp0]
carrie# commit and-quit commit complete
Exiting configuration mode
想定どおり、ユーザー
carrie
の権限は、インタフェース設定の表示お よび変更に制限されています。ヒント すべてのユーザーにそれぞれ一意なアカウントが設定されたため、各 管理者が接続時に何が入力されたかを正確に確認できます。これは、
全員が同じ
root
アカウントを共有していた場合にはできなかったこと です。工場出荷時のデフォルト設定により、インタラクティブコマンド のログが有効になっています。このログは、show loginteractive-commandsコマンドで表示できます。これは、非常に強力な監査ツー
ルです。
RADIUS サポートの設定
RADIUS
の機能を示し、設定済みのローカルアカウントとの混同を避けるために、
barnys、 max、 halle、 carrie
の各ユーザーを削除します。[barnys@server1 ~]$ ssh [email protected] [email protected]’s password:
[barnys@server1 ~]$ ssh [email protected] [email protected]’s password:
--- JUNOS 10.1R1.8 built 2010-02-12 17:24:20 UTC root@% cli
root> configure
Entering configuration mode [edit]
root# delete system login user barnys [edit]
root# delete system login user max [edit]
root# delete system login user halle [edit]
root# delete system login user carrie [edit]
root# commit commit complete
ここで、ユーザークラス
consultant
は、RADIUS認証用に必要なた め、そのまま残しています。RADIUS
の認証および認可コンポーネントにはさまざまな設定方法があるため、実際のインフラストラクチャと、RADIUSサーバーの熟 知度に基づいて、アプローチ方法を選択する必要があります。ここで は、役に立つと思われるアプローチを
2
つ紹介します。1
つ目のアプローチでは、SRX
でユーザークラスをローカルに設定し、RADIUS
を認証目的のためだけに使用します。この方法はうまく機能しますが、ネットワーク内に数百〜数千台のデバイスがある場合は、
認可プロセスが分散化するというリスクがあります。そのため、例えば、
前述の例のように
consultant
クラスを作成し、誤ってすべてのデバ イスでまったく同じ設定を行わなかった場合は、大きな問題となる可 能性があります。このアプローチでは、認証はRADIUS
サーバー上 で行われ、認可（ユーザーに何ができるか）はローカルで定義され たクラスから行われることを、明確に理解しておいてください。第4章：管理者の設定 39
2
番目のアプローチでは、認証と認可の両方を、RADIUSサーバー から設定、取得します。これは、より強力で優先すべきアプローチの ように思われますが、認証を付与し、正しい属性をSRX
に渡すように
RADIUS
を設定する方法を、管理者がしっかりと把握しておく必要があります。この方法のメリットは、RADIUSサーバーでほんの数回 クリックするだけで、必要なクラスへのアクセスを数千人もの管理者 に付与できることです。
どのアプローチを選択する場合でも、共通の設定パラメータがありま す。RADIUSを認証に使用することを
SRX
に通知すること、IPアド レス、秘密鍵、追加のオプションなどです。では、やってみましょう。RADIUS
サポートを設定するには：認証順序を設定します。
[edit]
root# set system authentication-order [radius password]
警告 自分を閉め出さないようにしてください。認証順序を
RADIUS
のみ に設定してしまうと、SRX
がRADIUS
サーバーとの通信を確立でき ない（サーバーがダウンしている）場合にのみ、ローカルユーザーデー タベースがチェックされることになってしまいます。例のように認証順 序を設定すると、サーバーと通信できるものの、RADIUSシステムで アカウントが適切に設定されていない場合に、ローカルユーザーアカ ウント（rootなど）で接続できるようになります。言い換えれば、例 のように設定すれば、サーバー側で何らかの問題が発生した場合で も、バックドアからの処理が常に可能になります。サーバーを設定します。秘密パスワード（この場合は
secret123
）は、SRX
とRADIUS
サーバーで共有する必要があります（サーバーの場所と詳細については、図
2.2
を参照）。[edit]
root# set system radius-server 10.189.132.70 secret secret123
次に、ローカルユーザークラスを使用して
RADIUS
認証を設定します。これは、SRXでユーザークラスをローカルに設定し、RADIUSを認 証目的のためだけに使用する、前述した
1
つ目のアプローチに相当し ます。RADIUS
認証とローカルの認可を設定するには：1.
ユーザーアカウントを設定して、ローカルクラスに割り当てます。[edit]
root# set system login user barnys full-name “Super-user rights” class super-user [edit]
root# set system login user max full-name “Operator rights” class operator [edit]
root# set system login user halle full-name “Read-only rights” class read-only [edit]
root# set system login user carrie full-name “Consultant rights” class consultant [edit]
root# commit commit complete
管理者の視点から見れば、この設定では、すべてが前のセクションと 同様に機能するはずです。例えば、
halle
が接続する場合、認証はRADIUS
から付与され（ユーザーに対して完全に透過的）、コマンドラインプロンプトでは、オペレーションモードの
show
コマンドのみ を使用できます（ローカルクラスread-only
によって付与された認 証）。では、2つ目のアプローチに進みましょう。認証と認可の両方を
RADIUS
サーバーから取得すれば、SRX
の設定は簡潔になりますが、サーバー側は少し複雑になります。サーバーからファイアウォールに 渡す必要のある属性を知っておく必要があるからです。
RADIUS
の認証と認可を設定するには：1. 設定済みの system login
パラメータをすべて削除します。root# delete system login [edit]
この最後の手順を明確に理解してください。以前のユーザーアカ ウントも、consultantクラスも、もう必要ありません。いずれも
RADIUS
サーバーによって提供されるからです。2. すべての RADIUS
ユーザーの接続テンプレートとして使用するユーザーを作成します。
第4章：管理者の設定 41
[edit]
root# set system login user remote full-name “Radius-user template” class unauthorized