以前の記事にも書いたのですが私はドライブが好きで、思い立った時にすぐに出かけてしまいます。この時は讃岐うどんが食べたくなって、香川県まで出かけて２件のうどん屋さんでかけうどんと天ぷらうどんをいただいた時の写真です。これは２件目の天ぷらうどんの写真です。かけうどんにかき揚げが付いている非常にシンプルなうどんなのですが、そのシンプルさがうどんのおいしい味を引き立ててくれます。あぁ腹減った。。。また行きたくなってきました 🙂
password management
さて、パスワード管理はどのようにされていますでしょうか？ M$ Windows をお使いであれば On-Premise の Active Directory を使用したドメインでの管理がこれまでよく使用されていた方法かと思います。ここにきて Azure Domain Controller も結構熱くなってきているようです。では、UN*X 環境ではどうでしょう？最もシンプルな構成は /etc/passwd ベースのサーバー単位での管理ですが、問題があります。サーバーの数が増えてくるとパスワードの更新はほぼ無理といっても構わないと思います。/etc/passwd でパスワードの有効期限を決めてサーバ毎にリセットさせるようにするのもありでしょうが、私はパスワードパニックが大嫌いです。覚えきれません 🙁 同じパスワードを未来永劫使っていくとなると、この方法もありかもしれません。しかし、一旦パスワードが他に知れると、もうどうしようもなくなりますし、私の会社ではこれは許されず、パスワードは２か月に一度変更する必要があります。以前の記事でも書きましたが、NIS を使用してパスワード管理を行えばある程度負荷は軽減できるのですが、これも問題があります。FreeBSD ではまだ NIS は普通に使用できますが、最新の Linux を見てみると、NIS は過去のものとしてサポートされなくなっているディストリビューションも目立つようになってきています。ここではそのことは置いておいて、何らかの方法でアカウント情報を用意して、パスワードを Kerberos で管理できるようにしてみたいと思います。因みに Windows Active Directory はユーザ管理と、Kerberos の両方を取り扱えるので、UN*X からもユーザ管理のできる KDC として使用することができます。私の会社でも SAMBA をドメインメンバーにして、Windows ユーザ情報を PAM 経由で利用できるようにしています。一旦 PAM でユーザの取り扱いができてしまえば、KRB5 や LDAP 等をサポートしていないアプリケーションでも簡単にユーザとパスワード管理ができてしまいます。手元の実験設備には M$ Windows Domain Controller はありませんので、UN*X のみの環境でユーザ管理とパスワード管理を行い、パスワードを Kerberos で管理できるようにしてみます。
KDC primary
まず、KDC の構成を設計してみます。プライマリの KDC を dhcp さんで実行します。セカンダリの KDC を package さんで実行します。プライマリとセカンダリ間のレプリケーションを行い、プライマリの障害に備えます。このパート1では、プライマリのみを設定して、セカンダリ、およびレプリケーションはパート２でご紹介できたらと思います。Kerberos の資料を読むと、Kerberos 専用のマシンを用意することを強く推奨するということです。言っていることはわかるのですが、それを実験環境で行っていてはリソースが足りなくなるので、例によって貧乏構成で行きたいと思います 🙂 KDC をセットアップすると、/var/heimdal ディレクトリにデータベースファイルや関連ファイルが格納されるようになります。まずは何も設定はしていないので、ディレクトリが空であることを確認します。
一番最初にしないといけないのは、データベースの初期化を行います。レルムは何でも OK なので、適時読み替えてください。私の場合、いつものように HOME.JF3VQB.NET を使用しました。
次に行うことはマスターキーを作ることです。人手でタイプすることはないはずなので、十分長い複雑なランダムのパスワードを使いましょう。
次に行うことは管理者プリンシパルを作ることです。いくつ作っても構わないのですが、管理者ごとに１つ必要になります。１つの管理用プリンシパルを管理者間で共有しているケースがあると思うのですが、セキュリティ上よろしくありませんので、一人一つとしたいと思います。わかりやすい名前で、UID/admin や UID/root などがよく使われると思います。勿論何でも構いませんが、後でわかりやすくしておくことが望まれます。ですので、私は pokemon/admin を使用することにします。
前の手順で作られたプリンシパルが何故管理者プリンシパルとなれるのかというと、アクセスコントロールで何でもできるようにと指定するので、管理者プリンシパルとして使用することができるようになります。この手順なくしては、ただのプリンシパルにすぎません。
さぁ、準備は完了仕上げを御覧じろ！ということで、各種サービスを起動します。/etc/rc.conf に適切に変数をセットして、service コマンドで起動します。他にも、kdc サービスを起動するのに、/etc/rc.d/kdc に start オプションを付けて/bin/sh に喰わせても構いません。
管理者プリンシパルを使用して、個人のプリンシパルを作成します。
KDC DNS resources
これで KDC が準備できて個人のプリンシパルもできました。ここで問題です。他の Kerberos クライアントは KDC がどこで利用できるのかを知りません。KDC を設定した dhcp さん自身もどこで KDC が利用できるのかわかっていません。この情報をクライアントに提供する方法は２つあるようです。/etc/krb5.conf ファイルに必要な情報を書き込み、各クライアントに配布する方法、もう一つが DNS を使用して、どこで KDC が利用できるのかを指定する方法です。せっかく家庭内の DNS を設定したので、DNS を使って実現してみたいと思います。ドメイン home.jf3vqb.net の Kerberos に関する部分を表示しておきました。DNS でおなじみのリソースレコードは A とか AAAA とかであると思いますが、ここでは SRV と TXT レコードが使われています。SRV はサービスレコードと呼ばれ、ネットワークでのサービスがどこで利用できるかを指定することができます。この例で一番最初の行の場合、TCP/IP で Kerberos を利用できるのは dhcp.home.jf3vqb.net 上のポート番号 88 で利用できると読みます。同じ列に 10 とか 20 とか書かれた行がありますが、これは優先度で、数字の少ないほうが優先されることになります。ですので、TCP/IP で Kerberos を利用するときは dhcp さんのポート 88 を最初に試してみて、利用できなければ package さんのポート 88 を試してみるという意味になります。最後の行の txt はテキストレコードで、各クライアントは Kerberos のデフォルトレルムを得ることができます。今回は優先度 20 のリソースは、KDC が準備できていませんので、パート２まで使用されることはありません。
logging
DNS を使用すると /etc/krb5.conf に書かれている情報を提供できるので、無くても構わないはずです。ただ、ハンドブックの２つ目のノートには最小の情報を書き込む必要があるとなっていますが、通常のクライアントでこのファイルが無くて困ったことはありません。ですので無くても構わないはずなのですが、リソースの場所の指定以外にもログをどのようにとるかなどの挙動を変更することができます。KDC はデフォルトで /var/heimdal に kdc.log というファイルを作り、ログを書き込んでゆきます。これはあまり便利ではないので、syslog に吐き出すようにしたいと思います。
/etc/krb5.conf に logging の設定を書き込みます。そして、/usr/local/etc/syslog.d ディレクトリにログの取り方を、/usr/local/etc/newsyslog.conf.d ディレクトリに古くなったログファイルの処理方法を指定しておきます。間違いないようであれば、syslogd プロセスに HUP シグナルを送ります。このシグナルを受け取ると、設定を読み直します。教科書的には sh /etc/rc.d/syslogd reload とするのが良いようです。
これで、KDC を動かしなおします。すると、/var/heimdal/kdc.log は使われることはなくなりますので、このファイルは削除しておきます。
/etc/krb5.keytab
これで、サービスを利用する準備もできたことになります。dhcp さんの host プリンシパルを作成して、通信に必要な鍵を入れておくファイル /etc/krb5.keytab ファイルを作ります。鍵の種類はアプリケーションにより異なります。例えば、NFS で使用される鍵は nfs/dhcp.home.jf3vqb.net@HOME.JF3VQB.NET などとなります。各アプリケーションの Kerberos に関する記述のあるところで、調べることができます。ですので、例えば NFS を Kerberos で使用するには NFS の鍵も必要になります。
では、pokemon さんで Kerberos が使えるようにしてみましょう。プリンシパルを作成して、それを基に pokemon さんで鍵を取得します。
私個人になって、kinit コマンドでチケットを取得します。
SSH の Kerberos が利用可能となっていることを確認します。
dhcp さんに ssh してみます。さぁ、どうでしょう？いい感じですね 🙂 パスワードは必要ありませんでした。
動作確認
新しく作ったお試しサーバで確認してみましょう。素の FreeBSD でパッチの適用と vmware-tools と pdksh をインストールしただけです。そのサーバの SSH で Kerberos を使えるようにします。当然のことながら、pokemon さんで行ったように、dhcp さんでは kadmin で host プリンシパルを作成して、krb5 では ktutil で /etc/krb5.keytab を作っています。
PAM のファイルの全てから pam_krb5 のコメントを外します。こちらは sshd ファイルの例です。
/etc/nsswitch.conf ファイルで NIS が使えるようにします。勿論 /etc/rc.conf にも NIS クライアントが正常に動くようにします。Active Directory などのように、ユーザ情報を提供してくれる機能が手元になく、すぐには NIS しかありませんので悪しからず。
NIS マスタの dhcp で monster というユーザを作成します。パスワードには ‘*’ が入っています。通常であればアカウントは無効の状態です。
NIS サーバに情報をプッシュします。
NIS クライアントから monster ユーザが見えることを確認します。
kinit で monster ユーザのチケットを取得します。勿論取得できると言うことは、前もって、プリンシパルが作られているということです。
krb5 に ssh してみます。おっと、ユーザ指定で ssh します :) そうすると、チケットが有効なので、パスワードを聞かれることはありませんでした。
引き続いて krb5 から他のサーバに ssh してみます。チケットが無いので、kinit しておきます。package さんに ssh してみます。パスワードは不要でした。
package さんからログアウトすると、krb5 の monster さんは新しいチケットを持っているのがわかります。
今回は NIS にパスワードを無効にしたユーザを作成して、そのパスワードが Kerberos で管理できることがわかりました。そして、一旦 kinit でパスワードを入力してチケットを取得すると、一定期間シングルサインオンが提供されます。今回実験したシナリオでは、集中管理の全てのユーザ情報が全てのマシンで利用できる場合を想定したので、NIS を使いましたが、特定のユーザのみが利用でするサーバが多いというシナリオでは、/etc/passwd ベースのユーザを作成してパスワードを Kerberos で管理などとすると、Active Directory のような集中管理のシステムなしでも使用に耐えるのではないかと思います。ただ、組織の規模が大きくなると、管理者はユーザ管理で超多忙になるようには思いますが。。。
こちらは高松港の港に突き出した海釣り公園です。気持ちいい風が吹きわたっており、２件目の讃岐うどん屋へ行くまでの腹ごなしには最適でした。
2杯目の天ぷらうどんも平らげて、ドライブ続行です。高松までは淡路島経由の鳴門大橋を利用しましたが、帰りは瀬戸大橋を使ってみたいと思います。地道を海沿いに走っていると、展望台という案内が目に入ったので、ふらふらと指示通りに進む。五色台展望広場ということです。2m や 430MHz などはよく飛びそうなロケーションでした。
乃生岬という場所で、瀬戸大橋を眺めながらしばし休憩。ちょっと天気が悪くなりそうな気配がします。帰りを急ぎます。
ご存じ与島のSAです。ちょうど日没でしたので、しばし物思いにふけります。
以下広告
コメント