Windowsへのソースアクセスがない場合、推測ではないことを言うのは困難です。その免責事項は別として、これを読んで私が収集できたものは次のとおりです。
UACは、ログオン時に2つのセキュリティトークンを作成します。ユーザーの完全なグループメンバーシップを含む昇格したトークンと、「Administrators」グループのメンバーシップが取り除かれた制限付きトークンです。各トークンには、ログオンセッションを識別する個別のローカルで一意のID(LUID)が含まれています。これらは、2つの別個の異なるログオンセッションです。
Windows 2000 Server SP2以降、マップされたドライブ(オブジェクトマネージャーの名前空間でシンボリックリンクとして表されます)は、それらを作成したトークンのLUIDでタグ付けされます(このKBaseの記事でこの動作へのMicrosoftの参照を見つけることができます。このブログ投稿で機能の仕組みの詳細をご覧ください)。この機能の要点は、あるログオンセッションで作成されたマップされたドライブに別のログオンセッションからアクセスできないことです。
EnableLinkedConnections値を設定すると、LanmanWorkstationサービスとLSAセキュリティサブシステム(LSASS.EXE)の動作がトリガーされ、LSAはユーザーのトークンのいずれかからマップされたドライブを他のトークンのコンテキストにコピーします。これにより、昇格されたトークンでマップされたドライブが、制限されたトークンとその逆から見えるようになります。ドメイン環境と非ドメイン環境に関して、この機能の動作に特殊性はありません。ユーザーが非ドメイン環境で「管理者」アカウントで実行している場合、制限されたトークンと昇格したトークンは、デフォルトで独立したドライブマッピングを持ちます。
脆弱性に関しては、Microsoftからの公式文書が不足しているようです。2007年のUACについての会話で、潜在的な脆弱性について質問するマイクロソフトの従業員からのコメントと応答を見つけました。彼の答えに信頼性があると考える傾向があります。以下は、「...技術的に実際に何が起こっているのか、それが何らかのUACの抜け穴を開くのかを説明する情報を見つけていません。コメントできますか?」という質問に対する彼の答えの要点です。
技術的には、昇格されていないマルウェアがドライブ文字+昇格されたコンテキストへのマッピングを「事前シード」できるため、小さな抜け穴が開きます。これは、環境に合わせて特別に調整されたものでない限り、リスクが低いはずです。
個人的には、ドライブマッピングを使用して昇格したトークンを "シード"する場合、ユーザーがその "シード"されたドライブマッピングから悪意のあるものを実際に昇格して実行する必要がある限り、この抜け穴を "悪用する"方法は考えられません。しかし、私はセキュリティ研究者ではありません。潜在的なエクスプロイトを思い付くための良い考え方でこれにアプローチしているわけではありません。
顧客がWindows NT 4.0の展開を開始したときに始まった傾向を継続することで、顧客サイトでEnableLinkedConnections値を使用することを避けました。これは長年にわたって私たちにとってうまく機能し、Windows 7でも引き続きうまく機能します。