イメージを構築し、サービスを実行するように設定されたユーザーでそのイメージを展開する自動プロセスがあります。ユーザーは Azure ネットワーク ファイル共有にアクセスできる必要があります。ファイル共有にアクセスするための資格情報を提供するには、以下のコマンドを使用して資格情報を Windows 資格情報マネージャーに保存し、サービス アカウントとして実行します。
cmdkey /add:storage.file.core.windows.net /user:Azure\storage /pass:password
次にネットワークマップを追加します
net use Z: \\storage.file.core.windows.net\share /persistent:yes
ネットワークがマップされ、上記の UNC パスにアクセスできるようになりました。次に、sysprep を実行して一般化し、イメージ キャプチャ用に VM を準備します。
C:\Windows\Sysprep\Sysprep.exe /oobe /generalize /quiet /quit /mode:vm
イメージを再度スピンアップすると、サービス アカウントにログインできますが、追加した cmdkey は消えてしまいます。スケジュールされたタスクを作成して cmdkey を再度追加することはできますが、Windows 資格情報を消去するのは本当に Sysprep なのか、またそれを回避する方法はあるのか疑問に思っています。
答え1
私はこの方法を使用して、すでにマウントされているネットワーク ドライブがあるイメージを作成していました。そこでわかったのは、自動化されたプロセス (Packer) は、同じアカウントで実行されていても、スクリプト セッションの資格情報とユーザー セッションの資格情報を共有しないということです。
スクリプト経由でネットワーク共有をマウントし (同じアカウントで実行されているかどうかに関係なく)、その共有がユーザー セッション/アプリケーションにマウントされることを期待しても機能しません。資格情報は 2 つ間で共有されません。
私が行ったのは、サービスが実行されるとすぐにネットワーク共有をマウントするバッチ ファイルをスクリプトで作成し、サービスが認証されたセッションとしてセッション上で実行されることがわかっているので、バッチ ファイルを呼び出してサービスからネットワーク共有をマウントするだけで、サービスがネットワーク共有にアクセスできるようになるというものでした。
興味深いことに、サービスが自分のアカウントとして認証され、ネットワーク共有をマウントすると、資格情報を提供せずに RDP でネットワーク共有にアクセスできるようになります。これは、アプリケーション セッションがユーザー対話型セッション間で共有されていることを示しています。