別のドメインユーザーに対してSudoを実行する場合の特権
MS ActiveDirectoryを使用する企業ドメインmydomainがあるとします。ドメインには、ユーザーmyuserとyouruserがあります。現在、1つの特定のUbuntuマシンmymachineで、myuserはSudo権限を持ち、Sudo su youruser（またはSudo -u youruser sh）を実行します。 myuserには必要なsudoers構成があるため、ユーザーのパスワードを入力する必要はなく、thatマシンで効果的にユーザーになります。
この時点で
youruserにはどのようなmyuser特権がありますか？明らかに、youruserがマシン上にホームディレクトリも持っている場合、myuserはそれにアクセスして、彼のプライベートローカルファイルを読み取ることができます。しかし、kerberos、sambaなどを使用してネットワークドメインリソースにアクセスしようとするとどうなりますか？彼はyouruserのパスワードを入力したことがないので、ドメインユーザーとして認証されておらず、Kerberosチケットなどを持っていません。したがって、ユーザーIDのグループメンバーシップをチェックするネットワークサービスがある場合、それも失敗します。 ？これはどのように作動しますか？彼は別のユーザー、たとえばmymachine\\youruserではなくmydomain\\youruserと見なされますか？専用のドメインユーザー
myserviceuserを使用して、マシン上でデーモンとして実行されているWebサービスがあるとします。このWebサービスがネットワークリソースにアクセスする必要がある場合、つまりKerberosで認証する必要がある場合、たとえば起動スクリプトからデーモンをどのように設定する必要がありますか？通常はSudo -u myserviceuser <cmd>のようなものを使用して開始しますが、上記の仮定を前提とすると、これによりWebサービスにネットワークリソースにアクセスする権限が付与されますか？このユーザーのパスワードをどこかに入力する必要はありませんか？
このようなIMOに関する明確なドキュメントはほとんどありません。
その通りです。サービスがKerberosによって保護されている場合、su/Sudoは必要な認証をバイパスするのに十分ではありません（ターゲットユーザーが現在ログオンしているためにキャッシュされたチケット、またはキータブを持っている場合を除く）。ほとんどのリソース（ローカルファイルシステムなど）は、ユーザーを識別するためにuidnumberとgidnumberに依存しており、root/Sudoアクセスによってバイパスできます。
これは私が現在仕事で扱っている楽しいものです。サービスアカウントを言うApacheカーネル化されたNFS共有にアクセスする必要があります。 Apacheのキータブをローカルファイルシステムにエクスポートし、サービスの開始時にcronを介して定期的にチケットを更新するソースを作成する必要があります。 RHEL7にはgssproxyがあり、これはこれを単純化するように見えますが、私はまだその点に到達していません。
キータブは事実上保存された資格情報です。誰かがそれにアクセスできる場合、彼らはそのユーザーになりすますことができます。 IPAおよびADで新しいキータブをエクスポートすると、アカウントのパスワードが変更されます。
Microsoft kerberosは少し異なりますが、ほとんどのルールが引き続き適用されます。
KerberizedNFSv4ディレクトリのautofsホームディレクトリでも同様の状況にあります。
- 別のkerberizedマシンから来ている場合は、転送可能なTGTを使用してターゲットマシンにSSHで接続でき、ターゲットマシンのアカウントは自動マウントされたホームディレクトリで通常どおりログインします。
- 別のkerberizedマシンから来ていない場合は、（ローカルACLに従って）そのマシンのパスワードを使用してログインし、PAMにチケットを生成させることができます。この状況では、自動マウントされたホームディレクトリも表示されます。
~/.ssh/authorized_keysにエントリがあるアカウントに依存している場合、ターゲットのSSHデーモンにホームディレクトリにアクセスできないため、このマシンにログインできません。マウントされていないためアクセスできませんが、SSHデーモンにはauthorized_keysファイルを含むホームディレクトリにアクセスするためのTGTがないためアクセスできません。- マシンへのアクセスを取得すると、
Sudo権限に関係なく、ホームディレクトリにアクセスできない限り、別のユーザーのアカウントにSudo suすることはできません。ここでもTGTはありません。 - そのマシンでは、私はcan
suをアカウントに送信し、suを介したログインはPAMを通過するため、パスワードを持っている場合はログイン時にホームディレクトリを利用できます。自動マウントを成功させるTGTを取得します。 - TGTがアクセス可能なキーストア（システムキーチェーンなど）に格納されているアーキテクチャでは、明示的な
kdestroyを実行しない限り、ログアウトしてもTGTは消去されません。これで、そのユーザーのアカウントにSudo suできるようになり、ホームディレクトリの自動マウントが成功します。
ここでの一般的なスレッドは、転送可能なチケットが別のマシンから転送されるか、ユーザーが何らかのログインまたはkinitでチケットを取得するためのパスワードを持っていない限り、TGTにアクセスできないことです。
サービスアカウントがユーザーをホストする場合があることを許可すると（たとえば、~/.kube/のような複雑な構成を一元化する場合）、authorized_keysが機能しないのと同じ理由で、アカウントディレクトリにキータブを配置するだけでは不十分です。また、システムキーチェーンを補充するために、ライフタイムの長いチケットとcronジョブに依存するだけでは不十分です。再起動するとキーチェーンがワイプされ、次のcron呼び出しまで使用できなくなるためです（おそらくしばらく時間がかかります）。マシンのクラスター全体でそのようなcronを設定するのも面倒です。