この章では、ユーザーのセル内でユーザー・アカウントを作成し、保守する方法を説明します。
ユーザー・アカウントを作成する最適なメソッドは、 uss プログラムを使用することです。このプログラムは、単一コマンドで複数のアカウントを作成できます。uss コマンド組によるユーザー・アカウントの作成と削除 を参照してください。各アカウントのコンポーネントを個別に作成したい場合は、 AFS ユーザー・アカウントの作成の説明に従ってください。
この章では、指示されたコマンドを使って以下のタスクを実行する手順について説明します。
保護データベース項目の作成 | pts createuser |
認証データベース項目の作成 | kas create |
ボリュームの作成 | vos create |
ボリュームの取り付け | fs mkmount |
ACL 上に項目を作成 | fs setacl |
保護データベース項目の検査 | pts examine |
ディレクトリー所有権の変更 | /etc/chown |
認証の試みの失敗を制限 | kas setfields、 -attempts および -locktime 併用 |
認証データベース項のロック解除 | kas unlock |
パスワードの存続時間の設定 | kas setfields、 -pwexpires を併用 |
パスワード再利用の禁止 | kas setfields、 -reuse を併用 |
AFS パスワードの変更 | kas setpassword |
ユーザー所有のグループのリスト作成 | pts listowned |
保護データベース項目の名前変更 | pts rename |
認証データベース項目の削除 | kas delete |
ボリュームの名前変更 | vos rename |
マウント・ポイントの取り外し | fs rmmount |
保護データベース項目の削除 | pts delete |
ボリューム・ロケーションのリスト作成 | vos listvldb |
ボリュームの取り外し | vos remove |
AFS ファイル・システムと UNIX ファイル・システムは異なるので、完全な AFS ユーザー・アカウントは、UNIX ユーザー・アカウントと同じではありません。以下のリストでは、AFS ユーザー・アカウントのコンポーネントについて説明します。これと同じ情報がuss コマンド組によるユーザー・アカウントの作成と削除の対応する機能グループにもありますが、便利なようにここでも繰り返し説明します。
セルの AFS のファイル・スペースへの認証済みアクセスを入手するには、ユーザーは、有効な AFS トークンを持っているだけではなく、キャッシュ・マネージャーがユーザーを提示しているマシンのローカル・パスワード・ファイル (/etc/passwd または同等のファイル) に項目を持っていなければなりません。この機能グループでは、ユーザーの AFS UID と、ローカル・パスワード・ファイルにリストされる UNIX UID を一致させることが重要である理由、およびファイルのパスワード・フィールドに指定するのに適切な値について説明します。
uss 命令を使用する理由の 1 つは、このコマンドが、ローカル・パスワード・ファイル項目をアカウント作成の一部として自動的に生成できるからです。共通送信元パスワード・ファイルの作成 を参照してください。
これと同じ情報は、uss コマンド組によるユーザー・アカウントの作成と削除の対応する機能グループにもありますが、便利なようにここでも繰り返し説明します。
AFS ユーザー ID 番号 (AFS UID) と UNIX UID が一致する場合、ユーザー・アカウントは管理と使用が最も容易です。AFS 文書内のすべての命令は、2 つの UID が一致することを前提としています。
AFS の UID と UNIX の UID を同じにする最も基本的な理由は、 UNIX ls -l および ls -ld コマンドによって報告される所有者名が、 AFS ファイルおよびディレクトリーに対して意味を持つようにするということです。標準 UNIX 実践に従って、ファイル・サーバーは、 AFS ファイルまたはディレクトリーの所有者フィールドのユーザー名ではなく、数字、すなわち所有者の AFS UID を記録します。 ls -l コマンドを発行すると、このコマンドは、 AFS 保護データベースではなくローカル・パスワード・ファイルのマッピングに従って、 UID をユーザー名に変換します。AFS の UID と UNIX の UID が一致しない場合、 ls -l コマンドは、予期せぬ (かつ正しくない) 所有者を報告します。ローカル・パスワード・ファイルが同じ UNIX UID を異なる名前にマップする場合は、異なるクライアント・マシン上では、出力が異なることがあります。
以下のようなさまざまなタイプのユーザーのアカウントを作成しているときには、指示された機能グループでの勧めに従って、AFS および UNIX UID を一致させてください。
AFS 仕様に変更されたログイン・ユーティリティーのインストールと構成を行う場合は、 AFS による認証が最も簡単です。AFS は、ユーザーをローカル・ファイル・システムに記録することと、 AFS トークンを入手することを 1 つのステップで行います。この場合、ローカル・パスワード・ファイルは、もはや、ほとんどの状況下で、ユーザーのログインする能力を制御しません。なぜなら、 AFS 仕様に変更されたログイン・ユーティリティーは、ユーザーが正しい AFS パスワードを提示したかどうかについて、ローカル・パスワード・ファイルを調べないからです。しかし、それでも、パスワード・ファイル項目内のパスワード・フィールド (通常、 2 番目のフィールド) を以下の方法で使用して、ログインと認証を制御できます。
AFS 仕様に変更したログイン・ユーティリティーを使用しない場合、標準の UNIX パスワードを、ユーザーが使用するすべてのクライアント・マシンのローカル・パスワード・ファイルに入れなければなりません。ユーザーは、ローカル・ファイル・システムだけにログインし、次に、 klog コマンドを発行して AFS と認証しなければなりません。ローカル・パスワード・ファイルと認証・データベースのパスワードが同じであれば、最も単純ですが、これは必須ではありません。
この機能グループでは、ユーザーのセルが既存の UNIX アカウントを持っていて、ユーザーがそのアカウントを AFS アカウントに変換したい場合に検討しなければならない 3 つの主要な問題について説明します。
前述のように、AFS ユーザーは、自分が承認済みユーザーとして AFS ファイル・スペースにアクセスするすべてのクライアント・マシン上のローカル・パスワード・ファイル内に項目を持っていなければなりません。UNIX UID と AFS UID が一致する場合は、管理と使用が両方とも、より単純になります。既存の UNIX アカウントを変換するとき、以下の 2 つの代替があります。
ユーザーの UNIX UIDを保存しているので、ローカル・パスワード・ファイル項目内の UID を更新する必要がない。しかし、AFS仕様に変更されたログイン・ユーティリティーを使用している場合は、項目のパスワード・フィールドの変更が必要なことがあります。パスワード・フィールドの値が、 AFS 仕様に変更されたログイン・ユーティリティーによるログインにどのように影響するかについての説明は、ローカル・パスワード・ファイルにパスワードを指定を参照してください。
現在または将来、既存の UNIX UID アカウントを持っていない新規ユーザーに対して AFS アカウントを作成する必要がある場合は、新規 AFS UID が既存の UNIX UID のどれとも競合しないことを確認する必要がある。最も簡単な方法は、保護データベースの max user id カウンターを、既存の最大 UNIX UID よりも高い値に設定することです。AFS UID および GID カウンターの表示および設定 を参照してください。
AFS アカウントを作成するとき、保護サーバーに AFS UID を自動的に割り振らせることができる。それから、すべてのクライアント・マシンで、ローカル・パスワード・ファイルのユーザー項目を変更して、新規 UID を組み込む必要があります。
UNIX UID を変更することには、1 つの欠点がある。つまり、 AFS ユーザーになる前にユーザーがローカル・ファイル・システム内で所有していたファイルとディレクトリーの所有者フィールドに、前の UID が含まれたままであるということです。 ls -l および ls -ld コマンドによって、正しい所有者を表示したい場合、ファイルをローカル・ファイル・システムに残すか AFS に移動するかにかかわらず、chown コマンドを使用して、値をユーザーの新規 UID に変更します。ローカル・ファイルを AFS に移動する を参照してください。
既存の UNIX アカウントは、すでに、パスワード・フィールド内の (スクランブル) パスワードと共に、項目をローカル・パスワード・ファイル内に持っています。ログイン・ユーティリティーのタイプによっては、以下のようにパスワード・フィールド内の値の変更が必要になる場合があります。
既存の UNIX アカウントは、おそらく、マシンのローカル・ファイル・システムに保管されたファイルとディレクトリーを所有しており、これらは、新しいホーム・ボリュームに転送すると意味をなします。最も容易なメソッドは、それらを、AFS クライアント・マシンのローカル・ディスク上に移動することであり、その後、UNIX mv コマンドを使用して、それらをユーザーの新規 AFS ホーム・ディレクトリーに転送します。
ファイルとディレクトリーを AFS に移動する際、それらのモード・ビットの意味が変更することに留意してください。 AFS では、モード・ビットの 2 番目と 3 番目のセット (グループおよびその他) を無視し、最初のセット (所有者ビット) は直接使用しません。ただし、ACL 上の項目と一緒の場合にのみ使用します (詳細は、AFS が UNIX モード・ビットを解釈する方法 を参照してください)。 ACL がファイルまたはディレクトリーを少なくともモード・ビットと同じくらい安全に保護することを確認してください。
ユーザーの UNIX UID を変更して、新規 AFS UID に一致させることを選択した場合は、 UNIX ファイルとディレクトリーの所有権も変更しなければなりません。AFS に常駐している system:administrators グループのメンバーだけが、 chown コマンドをファイルおよびディレクトリー上で発行することができます。
ユーザー・アカウントの作成には 2 つのメソッドがあります。最適なメソッドは、uss コマンドを使用するメソッドで、単一コマンドで複数のアカウントを作成できます。このメソッドでは、テンプレートを使用して、各ユーザーに対して同一のアカウント・コンポーネント (割り当て量など) の標準値を定義しますが、可変コンポーネント (ユーザー名など) に対しては異なる値を提供します。 uss コマンド組によるユーザー・アカウントの作成と削除 を参照してください。
2 番目のメソッドでは、個別のコマンドを発行してアカウントごとにコンポーネントを作成します。 1 度に 1 つのアカウントを作成する場合に最適な方法です。一部のコマンドは関連するコンポーネントの 1 つのインスタンスしか作成できないからです。各コンポーネントの機能を確認するには、AFS ユーザー・アカウントのコンポーネント を参照してください。
以下の命令を使用して、機能のレベルが異なる 3 つのタイプのユーザー・アカウントのいずれかを作成します。タイプについては、AFS ユーザー・アカウントの作成 を参照してください。
% klog admin_user Password: admin_password
次のリストは、必要な特権を指定し、それらの特権を所有しているかどうかを検査する方法を示しています。
% pts membership system:administrators
% bos listusers <machine name>
% fs listacl [<dir/file path>]
system:administrators グループのメンバーは、a (管理)、および、デフォルトで l (検索) アクセス権を、常にすべての ACL に暗黙的に持っています。また、必要に応じて fs setacl コマンドを使用して、他の権限を付与することができます。
% pts createuser <user name> [<user id>]
ここで、
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas create <name of user> \ -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password initial_password: initial_password Verifying, please re-enter initial_password: initial_password
ここで、
% vos create <machine name> <partition name> <volume name> \ [-maxquota <initial quota (KB)>]
ここで、
% fs mkmount <directory> <volume name>
ここで、
マウント・ポイントに読み取り / 書き込みパスを指定して、読み取り専用ボリューム内に新しいマウント・ポイントを作成しようとしたときに障害が発生するのを防ぎます。規則では、パス名の第 2 レベルのセル名の前にピリオドを付けて、読み取り / 書き込みパスを指定します (たとえば、 /afs/.abc.com)。ファイル・スペースの読み取り / 書き込みパス、および読み取り専用パスの概念についての詳細は、 マウント・ポイント横断の規則 を参照してください。
% fs setvol <dir/file path> -offlinemsg <offline message>
ここで、
マウント・ポイントへの読み取り / 書き込みパスを指定し、読み取りボリュームの変更時に生じる障害を回避してください。通例、読み取り / 書き込みパスを指定するには、パス名の第 2 レベルのセル名の前にピリオドを挿入します (たとえば /afs/.abc.com)。ファイル・スペースにおける読み取り / 書き込みおよび読み取り専用パスの概念の詳細は、マウント・ポイント横断の規則 を参照してください。
また、コマンドを使用して、 vos create コマンドが新規ボリュームのルート・ディレクトリーの ACL に自動的に配置する項目を、編集または削除することができます。この項目は、system:administrators グループにすべてのアクセス権を許可します。項目を削除する場合は、デフォルトにより、グループのメンバーは、すべての ACL において暗黙的な a (管理) および l (ルックアップ) アクセス権を持ち、必要に応じて、ユーザーに他のアクセス権を与えることができることに留意してください。
fs setacl コマンドについての詳細な説明は、ACL 項目の設定 を参照してください。
% fs setacl <directory> -acl <user name> all \ [system:administrators desired_permissions]
既存の UNIX アカウントを AFS アカウントに変換する場合、ユーザーの新規ホーム・ディレクトリーに一部のファイルやディレクトリーを移動できます。既存の UNIX アカウントの変換 を参照してください。
% pts examine <user or group name or id>
ここで、
出力の最初の行には、ユーザー名および AFS UID が表示されます。詳細および出力の例については、保護データベースからの情報の表示 を参照してください。
一部のオペレーティング・システムでは、ローカルのスーパーユーザーroot だけに、chown コマンドの発行を許可します。必要な場合は、chown コマンドを発行する前に、su コマンドを発行します。
% chown new_owner_ID directory
ここで、
% vos release <volume name or ID>
注: | このステップは、ホーム・ディレクトリーの親ディレクトリーが、複写されたボリュームのマウント・ポイントではなくても、必要な場合があります (また、そのようなケースでは、このステップを実行した方が監視が容易です)。たとえば、ABC Corporation が、 /afs/abc.com/usr ディレクトリー内のユーザー・ボリュームにマウント・ポイントを置くとしましょう。このディレクトリーは、マウント・ポイントというよりは通常のディレクトリーですので、 /afs/abc.com ディレクトリーに取り付けられた root.cell ボリューム内に常駐します。このボリュームは複写ですので、新規のマウント・ポイントの作成によって変更されたら、管理者は、 vos release コマンドを発行する必要があります。 |
パッケージ・ユーティリティーを使用して、パスワード・ファイルの共通バージョンをすべてのクライアント・マシンに配布する場合、共通バージョンだけを変更する必要があります。パッケージ・プログラムを使用したクライアント・マシンの構成を参照してください。
AFS では、非認証アクセスに対してセルのファイル・スペースを保護するための助けとなる、いくつかのオプション機能を提供します。以下のリストでは、それらの機能について要約します。
認証されていないユーザーがファイル・スペースにアクセスする最も一般的な方法の 1つは、認証済みユーザーのパスワードを憶測することです。このハッキング・メソッドは、ハッカーが複数のログイン・プロセスを並列して使用できる場合、または RPC インターフェースを直接使用できる場合に、最も危険です。
このようなタイプの攻撃に対抗して保護するために、kas setfields コマンドに -attempts を使用して、ユーザーが AFS 仕様に変更されたログイン・ユーティリティーまたは klog コマンドのどちらを使用しているかにかかわらず、誤ったパスワードを連続して入力できる回数を制限することができます。この制限を超えると、認証サーバーは、kas setfields コマンドの -locktime 引き数に定義された期間、認証データベース項目をロックします(認証試行を不許可にします)。必要な場合、システム管理者は、kas unlock コマンドを使用して、ロックアウト時間が完全に経過する前にロックを解除することができます。
特定の状況では、失敗した認証試行回数の制限に使用したメカニズムは、失敗した試行数が -attempts 引き数によって設定した制限の範囲内であっても、ロックアウトを発生させる場合があります。klog および AFS 変更済みログイン・ユーティリティーなどの認証プログラムは、通常、認証試行に対して、認証サーバーをランダムに選択します。そして、認証に失敗した場合は、次の試行のために別の認証サーバーを選択します。さまざまなデータベース・サーバー・マシン上で実行される認証データベースは、ユーザーが正しいパスワードの提供に失敗した回数を相互に通知しません。代わりに、各認証サーバーは、補助データベース・ファイル kaserverauxdb (デフォルトでは /usr/afs/local ディレクトリーにある) の独自の個別コピーを保守します。このコピーには、各ユーザー・アカウントごとの連続失敗回数および最近の失敗の時刻が記録されています。この実装は、平均的には各認証サーバーは、失敗試行の合計数の少数部分に関してしかわからないことを意味します。-attempts 引き数で設定された試行回数以上の許可しないようにする唯一の方法は、各認証サーバーは合計の小数部の一部だけを許可するという方法です。具体的に説明すると、失敗試行の限界回数が f で、認証サーバーの数が S であるとすると、各認証サーバーが許可できる試行回数は、f を S で割った数にしかなりません (認証サーバーのための Ubik 同期サイトでは、剰余数 fmodS が追跡されます)。
通常、このメカニズムが許可される試行数を構成済みの限界 (f) 以下に削減することはありません。1 つの認証サーバーが試行を拒否しても、クライアントはサーバーの別のインスタンスにアクセスして、認証が正常に行われるまで、またはサーバーの全インスタンスにアクセスが完了するまで継続します。ただし、1 つ以上の認証サーバー・プロセスが使用不可の場合、事実上、数量 U を S で割った数に等しいパーセンテージだけ限界回数が少なくなります。ここで、 U は使用不可のサーバー数で、S は、正常に使用可能なサーバー数です。
失敗した認証試行の限界数設定について、望ましくない結果を避けるため、次の推奨処置に注意してください。
要約すると、お勧めする認証試行の制限回数は 9 回、ロックアウト時間は 25 分です。
使用するパスワードが長いほど、ハッカーはそのパスワードを知るのに時間がかかります。このタイプのハッキングから保護するには、 -pwexpires 引き数を kas setfields コマンドに使用して、ユーザーのパスワードの有効日数を制限します。パスワードが失効すると、ユーザーは AFS を使って認証できなくなりますが、 30 日以内に kpasswd コマンドを使用すれば、新規パスワードを設定できます。30 日間が経過した後は、認証データベース項目に関する ADMIN フラグを持つ管理者だけが、パスワードを変更することができます。
パスワードの有効期間を設定すると、多くの AFS 仕様に変更されたログイン・ユーティリティー (ただし、 klog コマンドではない) は、 PASSWORD_EXPIRES 環境変数に、パスワードが失効するまで残っている日数を設定します。ゼロを設定すると、パスワードの失効日は今日になります。必要な場合、ユーザーのログイン・スクリプトをカスタマイズして、パスワードが失効するまでの残りの日数を表示し、あとわずかの日数で失効するときにはプロンプトを出すことさえできます。
ユーザーが現在の値に新規パスワードを単に設定するだけの場合、新規パスワードの定期的な選択をユーザーに強制するのは効果的ではありません。ユーザーが、最近の 20 のパスワードのいずれかに類似する文字列を新規パスワードとして設定するのを防ぐには、 kas setfields コマンドに -reuse 引き数を使用します。
パスワードの再値用を禁止しているのに、ユーザーが非常に類似するパスワードを指定した場合、認証サーバーは、以下のメッセージを生成し、そのパスワードを拒否します。
Password was not changed because it seems like a reused password
持続ユーザーは、クィック継続 (またはそれを実行するスクリプトの実行)で、このパスワードを 20 回変更することによって、この制限のう回を試行することができます。これが問題になると思う場合は、-minhours 引き数を、 kaserver 初期設定コマンドに組み込みます (詳しくは、 AFS Administration Reference 内のコマンド解説のページを参照してください)。ユーザーが頻繁にパスワードを変更しようとすると、次のメッセージが表示されます。
Password was not changed because you changed it too recently; see your systems administrator
パスワードに対して、最小限の品質基準を課すことができます。それには、 kpwvalid というスクリプトまたはプログラムを作成します。kpwvalid ファイルが既にある場合は、 kpasswd および kas setpassword コマンド・インタープリターがこれを呼び出して、新規パスワードをチェックします。パスワードが品質基準に準拠していない場合、 kpwvalid プログラムは適切なコードを返し、コマンド・インタープリターはそのパスワードを拒否します。
kpwvalid ファイルは、実行可能ファイルでなければなりません。また、 kpasswd および kas バイナリーと同じ AFS ディレクトリーになければなりません。このファイルのディレクトリーの ACLは、w (書き込み) アクセス権を、 system:administrators グループだけに許可していなければなりません。
kpwvalid プログラムを作成する場合は、次のような規定を設けることを考慮してください。
AFS の配布には、kpwvalid プログラムが例として組み込まれています。AFS Administration Referenceの kpwvalid コマンドの参照ページを参照してください。
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas setfields <name of user> \ -admin <admin principal to use for authentication> \ -attempts <maximum successive failed login tries ([0..254])> \ -locktime <failure penalty [hh:mm or minutes]> Administrator's (admin_user) password: admin_password
ここで、
時間と分の (hh:mm) または分だけ (mm) の時間数を、 01 (1 分) から 36:00 (36 時間) の範囲から指定します。kas コマンド・インタープリターは、自動的に、36:00 よりも大きいすべての値を 36:00 に削減し、また、非ゼロ値を 8.5 分の倍数で次に高い最初の値にそれぞれ切り上げます。
値の 0 (ゼロ) は、無限のロックアウト時間を設定するので、管理者のアカウントに指定しない方がよいでしょう。管理者は、このようなアカウントをロック解除するために、常にkas コマンドを発行しなければなりません。
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password ka>
-admin は、認証データベース項目に ADMIN フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。
ka> examine <name of user> User is locked until time
ka> unlock <authentication ID>
ここで、
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas setfields <name of user> \ -pwexpires <number days password is valid [0..254])> \ -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password
ここで、
パスワードが無効になる (有効期限切れになる) と、ユーザーは、認証できなくなりますが、その後 30 日間は、 kpasswd コマンドまたは kas setpassword コマンドを発行してパスワードを変更できます (それ以降は、パスワードを変更できるのは、管理者だけです)。時計は、kas setfields コマンドを発行したときではなく、パスワードを最後に変更したときに開始することに注意してください。そ及的な期限切れを避けるために、ユーザーは、コマンドを発行する直前にパスワードを変更するようにします。
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas setfields <name of user> -reuse < permit password reuse (yes/no)> \ -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password
ここで、
アカウントの作成時に初期パスワードを設定した後は、通常ユーザー・パスワードの変更は不要です。AFS 使用者の手引き の説明に従うことにより、ユーザーが kpasswd コマンドを使用して各自で変更できるからです。まれに、ユーザーがパスワードを忘れた場合またはそれ以外でログインできない場合、 kas setpassword コマンドを使用して、新規パスワードを設定することができます。
ローカル・パスワード・ファイル (/etc/passwd、またはそれに相当するもの) 内の項目が、パスワード・フィールド内に、順序を変えた実パスワードを持っている場合は、そのパスワードも変更することを忘れないでください。詳しくは、ローカル・パスワード・ファイルにパスワードを指定 を参照してください。
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas setpassword <name of user> \ -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password new_password: new_password Verifying, please re-enter new_password: new_password
ここで、
ユーザー・ボリュームは、割り当て量に関しては、他のすべてのボリュームと似ています。vos create コマンドに -maxquota 引き数を使用して、異なる割り当て量を割り当てない限り、新規 AFSボリュームには、5000 KB のデフォルト割り当て量があります。また、以下のコマンドのいずれかを使用して、いつでも割り当て量を変更することができます。
次の 3 つのコマンドのいずれかを使用して、ボリュームの割り当てを表示することができます。
説明については、ボリューム割り当て量および現行サイズの設定および表示を参照してください。
規則では、アカウントのコンポーネントの多くには、ユーザー名、保護および認証データベース項目、ボリューム名、ホーム・ディレクトリー名などが組み込まれています。ユーザー名を変更する場合には、整合性を維持するためにすべてのコンポーネントの名前を変更するのが最適の方法です。したがって、ユーザー名を変更する手順には、新規ユーザー・アカウントを作成する手順とほとんど同じくらい多くのステップがあります。
% klog admin_user Password: admin_password
次のリストは、必要な特権を指定し、それらの特権を所有しているかどうかを検査する方法を示しています。
% pts membership system:administrators
% bos listusers <machine name>
% fs listacl [<dir/file path>]
system:administrators グループのメンバーは、a (管理)、および、デフォルトで l (検索) アクセス権を、常にすべての ACL に暗黙的に持っています。また、必要に応じて fs setacl コマンドを使用して、他の権限を付与することができます。
% pts listowned <user or group name or id>
% pts rename <old name> <new name>
各グループごとにコマンドを繰り返します。その構文についての説明は、 3 のステップにあります。
% pts rename <old name> <new name>
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password ka>
-admin は、認証データベース項目に ADMIN フラグを持つ管理アカウントを指定します (admin など)。password プロンプトはアカウントを admin_user として表示します。適切なパスワードを、admin_password として入力します。
ka> delete <name of user>
ここで、
ka> create <name of user> initial_password: password Verifying, please re-enter initial_password: password
ここで、
ka> quit
% vos rename <old volume name> <new volume name>
% fs rmmount <directory>
% fs mkmount <directory> <volume name>
% vos release <volume name or ID>
注: | このステップは、ホーム・ディレクトリーの親ディレクトリーが、複写されたボリュームのマウント・ポイントではなくても、必要な場合があります (また、そのようなケースでは、このステップを実行した方が監視が容易です)。たとえば、ABC Corporation テンプレートは、 /afs/abc.com/usr ディレクトリー内のユーザー・ボリュームにマウント・ポイントを置きます。このディレクトリーは、マウント・ポイントというよりは通常のディレクトリーですので、 /afs/abc.com ディレクトリーに取り付けられた root.cell ボリューム内に常駐します。このボリュームは複写ですので、変更されたら、管理者は vos release コマンドを発行する必要があります。 |
アカウントを削除する前に、テープなどの永久媒体上にユーザーのホーム・ボリュームのバックアップ・コピーを作成するのが最適の方法です。複数のアカウントを削除する必要がある場合は、おそらく、 uss delete コマンドを代わりに使用する方がより効率的です。uss delete コマンドによる個別アカウントの削除 を参照してください。
% klog admin_user Password: admin_password
次のリストは、必要な特権を指定し、それらの特権を所有しているかどうかを検査する方法を示しています。
% pts membership system:administrators
% bos listusers <machine name>
% fs listacl [<dir/file path>]
system:administrators グループのメンバーは、a (管理)、および、デフォルトで l (検索) アクセス権を、常にすべての ACL に暗黙的に持っています。また、必要に応じて fs setacl コマンドを使用して、他の権限を付与することができます。
% pts listowned <user or group name or id>
% pts delete <user or group name or id>+
ここで、
認証サーバーは、既存の AFS トークンを受け入れるのではなく、独自の認証を実行します。デフォルトでは、認証サーバーは、管理者のローカル (UNIX) 識別を認証します。この識別は AFS 特権管理者に対応しません。 -admin 引き数を組み込み、認証データベース項目に ADMIN フラグを持つ識別を指定します。項目にフラグがあることを確認するには、 ADMIN フラグがオンになっていることを確認するで説明するように、kas examine コマンドを発行します。
% kas delete <name of user> \ -admin <admin principal to use for authentication> Administrator's (admin_user) password: admin_password
ここで、
% vos listvldb <volume name or ID>
ここで、
% vos remove <machine name> <partition name> <volume name or ID>
ここで、
ユーザーのバックアップ・ボリュームがホーム・ディレクトリーのサブディレクトリーとして取り付けられている場合、そのバックアップ・バージョンも同時に取り付け解除されます。バックアップ・バージョンを、ファイル・スペースと関係のない位置に取り付けている場合は、バックアップ・バージョン用に fs rmmount コマンドを繰り返し実行します。
% fs rmmount <directory>
ここで、
マウント・ポイントに読み取り / 書き込みパスを指定して、読み取り専用ボリューム内からマウント・ポイントを削除しようとするときに障害が発生するのを防ぎます。規則では、パス名の第 2 レベルのセル名の前にピリオドを付けて、読み取り / 書き込みパスを指定します (たとえば、 /afs/.abc.com)。ファイル・スペースの読み取り / 書き込みパス、および読み取り専用パスの概念についての詳細は、 ボリュームの取り付け を参照してください
% pts delete <user or group name or id>
% vos release <volume name or ID>
注: | このステップは、ホーム・ディレクトリーの親ディレクトリーが、複写されたボリュームのマウント・ポイントではなくても、必要な場合があります (また、そのようなケースでは、このステップを実行した方が監視が容易です)。たとえば、ABC Corporation テンプレートは、 /afs/abc.com/usr ディレクトリー内のユーザー・ボリュームにマウント・ポイントを置きます。このディレクトリーは、マウント・ポイントというよりは通常のディレクトリーですので、 /afs/abc.com ディレクトリーに取り付けられた root.cell ボリューム内に常駐します。このボリュームは複写ですので、マウント・ポイントの削除によって変更されたら、管理者は、 vos release コマンドを発行する必要があります。 |