Kerberos 化されたバージョンの ftp、rcp、rlogin、rsh、ssh、telnet、または SSH クライアントを使用してサーバーに接続すると、元のユーザーの識別情報は Kerberos V5 認証システムに対する認証を受ける必要があります。その後、~/.k5login ファイルと gsscred テーブルに適切なエントリが存在する場合や、デフォルトの GSS/Kerberos 認証ルールが正常に Kerberos 主体名を UNIX ログイン名にマップしている場合、アカウントアクセスの認証が可能になります。
セキュリティーの問題を回避するには、クライアントがアクセスを試みているサーバー上のリモートユーザーが ~/.k5login ファイルを所有している必要があります。ファイルには、principal/instance@realm 形式の Kerberos 主体名で構成される非公開の承認リストが含まれている必要があります。Kerberos 主体名の /instance 変数はオプションです。たとえば、jdb@ENG.ACME.COM や jdb/happy.eng.acme.com@ENG.ACME.COM などのさまざまな主体名は同等ではありませんが、正当な Kerberos 主体です。~/.k5login ファイルがリモートユーザーアカウントのログインディレクトリに配置され、元のユーザーがファイルに指定された主体のいずれかに対する認証を受けることができる場合、クライアントにアクセス権が付与されます。Kerberos 主体名の詳細については、 gkadmin(1M) および kadm5.acl(4) を参照してください。
~/.k5login ファイルがリモートユーザーのログインアカウントに見つからなかった場合は、元のユーザーに関連付けられた Kerberos V5 主体名が gsscred テーブルと比較してチェックされます。gsscred テーブルが存在し、そのテーブルで主体名が一致している場合、テーブルにリストされている Unix ユーザー ID がクライアントがアクセスを試みているユーザーアカウントに対応していれば、アクセス権が付与されます。Unix ユーザー ID が一致しない場合、アクセスは拒否されます。gsscred (1M) を参照してください。
たとえば、gsscred テーブルにリストされている元のユーザーの主体名が jdb@ENG.ACME.COM、uid が 23154 の場合、23154 がユーザーアカウントデータベースにリストされている jdb-user の uid でもあれば、jdb-user アカウントへのアクセス権が付与されます。passwd(4) を参照してください。
最後に、~/.k5login ファイルが存在せず、元のユーザーの Kerberos V5 識別情報が gsscred テーブルに存在しない場合や、gsscred テーブル自体が存在しない場合、次の条件 (デフォルトの GSS/Kerberos 認証ルール) を満たせば、クライアントにアカウントへのアクセス権が付与されます:
認証された主体名のユーザー部分がクライアントが指定した Unix アカウント名と同じである。
krb5.conf(4) auth_to_local_realm パラメータを使用してレルムを作成しない場合を除いて、クライアントとサーバーのレルム部分は同じである。
Unix アカウント名がサーバーに存在する。
たとえば、元のユーザーの主体名が jdb@ENG.ACME.COM で、サーバーのレルムが SALES.ACME.COM の場合、jdb がサーバー上の有効なアカウント名であっても、クライアントのアクセスは拒否されます。これは、レルム SALES.ACME.COM と ENG.ACME.COM が異なるためです。
krb5.conf(4) auth_to_local_realm パラメータによっても承認は影響を受けます。デフォルト以外のレルムは、認証済みの name-to-local name マッピングのデフォルトレルムと同等とみなすことができます。
ユーザーアカウントごとの認証ファイルです。
システムアカウントファイルです。この情報はディレクトリサービスに存在することもあります。passwd(4) を参照してください。
属性についての詳細は、attributes(5) を参照してください。
|
ftp(1)、rcp(1)、rsh(1)、telnet(1)、gkadmin(1M)、gsscred(1M)、kadm5.acl(4)、krb5.conf(4)、passwd(4)、attributes(5)、gss_auth_rules(5)