2

私はこの問題で髪を引っ張ってきました。スタックオーバーフローがいたるところにありましたが、まだ修正できていません。

目標

Windows Server 2019 Azure VM でオンデマンドでアカウントを作成しようとしています。VM はドメインに参加しておらず、その孤独なワークグループ内のスタンドアロン サーバーにすぎません。アプリケーションは、Azure で App Service として実行される ASP.NET Framework v4.6.1 Web API アプリケーションです。

    using (var context = new PrincipalContext(ContextType.Machine, vmData["ip"].ToString(), null, ContextOptions.Negotiate, $@"{vmData["name"]}\{vmData["username"]}", vmData["password"].ToString()))
    {
        using (var user = new UserPrincipal(context))
        {

            user.DisplayName = username;
            user.SamAccountName = username;
            user.SetPassword(password);
            user.PasswordNeverExpires = true;

            user.Save();

            using (var group = GroupPrincipal.FindByIdentity(context, "Administrators"))
            {
                group.Members.Add(user);
                group.Save();
            }
        }
    }

問題

このコードをローカルで実行すると、すべてがうまくいき、Azure VM への接続が成功し、ユーザーが作成され、サーバーのローカル管理者グループに追加されます。

このコードが Azure の App Service に発行されると、常にSystem.Runtime.InteropServices.COMException: Access is denied.at lineがスローされますuser.DisplayName = username;。user.Displayname を設定しようとすると、サーバーは何らかの方法で照会されると想定していますが、ユーザーのそのプロパティは一意である必要はなく、以前のプロジェクトから、Save() を使用すると一意のプロパティの実際のチェックが行われることがわかっています。ユーザー。

研究と試みられた修正

  • App Service IP から Azure VM へのインバウンド トラフィックを許可するファイアウォール ルールを無効にして、別の例外が発生するかどうかを確認しました => タイムアウト / サーバーに到達できませんでした。ファイアウォール ルールは正しいようです
  • すべてのファイアウォールを完全に無効にして、ファイアウォール ルールが必要なポートまたはプロトコルを見逃していないことを確認しました => アクセスが拒否されました!
  • 例外から詳細を取得することを期待して、App Service をリモートでデバッグするために Visual Studio をアタッチしました => アクセスが拒否されました。
  • PSEXECからの修正を試み、アクセス拒否エラー
  • UserPrincipal.FindByIdentity (System.DirectoryServices.AccountManagement) の .NET 4.5 バグ => 4.6.1 を使用して、 .NET 4.5 を使用してバグが見つかった
  • リモートサーバーをチェックして、作成中のアカウントがまだ存在していないことを確認しました
  • この問題、ログインの失敗、監査などに関連する可能性のあるログについて、リモート サーバーのイベント ログを確認しました。何も見つかりません。

最後の手段

この時点で、これらの VM で OpenSSH を有効にして、その方法でローカル アカウントを作成しようとしています。

どこを見ればいいのか、他に試してみるべきことはありますか?

前もって感謝します!

更新 1:

Azure App Service は .NET v3.5 または .NET v4.7 を実行するため、プロジェクトを .NET Framework v4.6.1 から v4.7.2 に変更しました。

.NET v4.7 設定を表示している Azure App Service 構成のスクリーンショット

これがローカル マシンで同じ例外を生成する可能性があることを期待して、もう一度テストを行ったところ、同じ行で実際に COMException がスローされました。ただし、同じ COMException ではありません。

System.Runtime.InteropServices.COMException: Multiple connections to a server or shared resource by the same user, using more than one user name, are not allowed. Disconnect all previous connections to the server or shared resource and try again.

v4.7.2 に変更したばかりなので、この新しい例外についてまだ調査中です。この追加情報が元の問題に追加するのに重要である可能性があると考えました。

4

1 に答える 1