【解決】Azure VMで「The target machine has denied access」エラー！原因はパスワード間違いによるロックアウト？（0xC0000234）

 

Azureの仮想マシン（VM）に突然RDP接続できなくなったことはありませんか？

「The target machine has denied access to this connection」というエラーが表示された場合、原因はネットワーク設定ではなく、パスワードの入力ミスによる「アカウントロックアウト」かもしれません。

本記事では、シリアルコンソールを使った原因特定方法から、具体的な復旧手順までを解説します。

1. 発生した事象とエラーメッセージ

まずは、どのような状況で接続できなくなったのかを記載します。

• 現象: RDP（リモートデスクトップ）接続時に拒否される。

• エラー文: The target machine has denied access to this connection.

• 心当たり: パスワードを数回間違えて入力した。

2. 原因の特定：シリアルコンソールでログを確認する

「本当にパスワード間違いが原因か？」を外側から特定する方法を紹介します。

手順:

Azureポータルから対象VMの「シリアルコンソール」を開く。

cmd → ch -si 1 でコマンドプロンプトを起動。

以下のコマンドでイベントログを確認。

wevtutil qe Security /q:"*[System[(EventID=4625)]]" /c:5 /f:text /rd:true

特定ポイント:

ログの中に以下の情報があれば、ロックアウトが確定です。

• 失敗の原因: アカウントのロックアウト

• 状態コード: 0xC0000234

3. 解決策：アカウントロックを解除する方法

ロックアウトされた場合の対処法は3つあります。

① 自動解除を待つ（30分〜1時間）

多くの設定では、一定時間経過するとロックが自動解除されます。急ぎでない場合は、「一切の操作をせず待つ」のが最も安全です。

② Azureポータルからパスワードをリセット（即時）

急ぎの場合は、Azureポータルの「パスワードのリセット」機能を使います。

Tips: 既存のパスワード（チームで共有しているもの等）を変えたくない場合は、一度「別パスワード」に変更してログインした後、OS内部の設定から元のパスワードに戻すのがコツです。

③ ネットワーク設定（NSG）の確認

もし上記でもダメな場合は、念のためNSG（ファイアウォール）でRDPポート（3389）が開放されているか、自分のIPアドレスが許可されているかを確認しましょう。

まとめ：予防策

• パスワード管理ツールを使用し、打ち間違いを防ぐ。

• 踏み台サーバー（Bastion）の利用を検討する。

Azure Pipelinesで.NET Coreビルドが失敗する原因と解決策｜デフォルトYAMLの修正ポイント

 

以前書こうと思っていたのですが、バタバタしていてまとめる機会がなかなか無く、やっと時間が取れたので、昔を思い出しながら書いてみます。

1. はじめに：Azure Pipelinesは「おまかせ」で動かない？

Azure DevOpsを使い始めたばかりの頃、私は感動しました。

「.NET Core」というテンプレートを選ぶだけで、勝手にYAMLファイルが生成され、あとは実行ボタンを押すだけ。

「これでCI/CD対応完了だ！」と意気揚々と実行した結果、画面に表示されたのは無情な赤いバツ印（Failed）でした。

なぜ、Microsoft純正のテンプレートなのにそのままでは動かないのか？

今回は、初心者が必ずハマる「デフォルトYAMLの落とし穴」と、その修正ポイントをまとめます。

2. 【罠1】SDKのバージョンが合っていない

デフォルトのYAMLには、多くの場合「どのバージョンの.NET SDKを使うか」という指定が抜けています。その結果、Agent（ビルド用マシン）にインストールされている最新バージョンが使われ、古いプロジェクトや新しすぎるプロジェクトがビルドエラーになります。

解決策：UseDotNet@2 タスクを最初に追加する

ビルド（Build）タスクの前に、明示的にバージョンを指定するタスクを差し込みます。

steps:

- task: UseDotNet@2

  displayName: 'Install .NET SDK 8.x'

  inputs:

    packageType: 'sdk'

    version: '8.x' # 自分のプロジェクトのバージョンに合わせる

3. 【罠2】プロジェクトファイルが見つからない

デフォルトでは、リポジトリのルート（一番上の階層）に .csproj や .sln があることを想定しています。しかし、実際の開発では src/ フォルダの中にコードをまとめていることが多いはずです。

解決策：projects プロパティを書き換える

テンプレートのままだと、以下のようなエラーで止まります。

##[error]Project file(s) matching the specified pattern were not found.

これを防ぐために、ワイルドカードを使ってプロジェクトファイルを指定します。

修正前（デフォルト）:

- task: DotNetCoreCLI@2

  inputs:

    command: 'build'

    arguments: '--configuration $(buildConfiguration)'

修正後：

- task: DotNetCoreCLI@2

  inputs:

    command: 'build'

    # リポジトリ全体から.csprojを探すように指定

    projects: '**/*.csproj' 

    arguments: '--configuration $(buildConfiguration)'

4. 【罠3】NuGetリストアの失敗

「ビルドタスクの中で一緒にリストア（ライブラリの復元）もやってくれるだろう」と思いがちですが、ここでも認証エラーやパスの問題が起きることがあります。

解決策：Restoreタスクを分離して明示する

ビルドとは別に restore コマンドを明示的に実行するのが、安定させるコツです。

- task: DotNetCoreCLI@2

  displayName: 'Restore NuGet Packages'

  inputs:

    command: 'restore'

    projects: '**/*.csproj'

5. まとめ：デフォルトは「完成品」ではなく「下書き」

Azure Pipelinesが用意してくれるデフォルトのスクリプトは、あくまで「最低限の構成案」です。

1. SDKバージョンを指定する

2. プロジェクトの階層（パス）を正しく伝える

3. リストア、ビルド、テストを順序よく構成する

この3点を意識するだけで、あの赤いエラー画面から卒業できるはずです。

【Azure】App ServiceのIP制限でハマった話。「確認くん」と違うIPが届く原因と調査法

Azure App Serviceで特定の拠点のみアクセスを許可しようと「アクセス制限」を設定したのに、なぜか自分すら弾かれる……。

「ログストリームを見れば原因がわかるはず」と思いきや、実はここには大きな罠があります。

今回は、App Service（特にLinuxベース）を使い始めたばかりの人が必ずハマる「IP制限の正体」と、正しいトラブルシューティング術について実体験を元に解説します。

1. 罠：403エラーのログは「ログストリーム」には出ない

ApacheやNginxの感覚でいると、「アクセス拒否（403エラー）されたならログが出るはず」と考えがちです。しかし、App Serviceのログストリームをどれだけ眺めても、IP制限で拒否されたログは1行も流れてきません。

なぜ出ないのか？

App ServiceのIP制限は、アプリに届く前の「Azureのプラットフォーム階層」で遮断されるからです。

• アプリ側のログ: アプリまで到達したリクエストの記録。

• IP制限: アプリに届く前に門前払いするため、アプリ側は「アクセスがあったこと」すら知りません。

2. 解決策A：ログが見れないなら「外側」から叩く

App Service側のログが見れない状況で、私が「真の接続元IP」を特定した方法が curl や tcpping です。

「確認くん」などのWebサービスで見えるIPは、ブラウザ（プロキシ経由）のIPに過ぎません。実際の通信がどう見えているかを直接叩いて確認します。

• curlで叩く: curl -v https://your-app.azurewebsites.net

• tcpping / pspingで叩く: ポート443に対して直接疎通を確認。

私のケースでは、これらを試す中で「確認くん」とは別のIPがゲートウェイとして使われていることが判明し、そのIPを許可することで解決しました。

3. 解決策B：どうしてもログを見たいなら「診断設定」

「どうしてもAzure側で拒否されたIPの履歴を特定したい」という場合は、診断設定（AzureAppServiceHTTPLogs）を有効にする必要があります。

ただし、ここで注意したいのがコストです。

インフラチームから「Log Analyticsは高額になりがち」と釘を刺されることがありますが、これは大量のログを溜め続けると課金が膨らむためです。

• 賢い使い方: 調査時だけ有効にし、接続元IPが特定できたらすぐにオフにする。

これでコストを最小限に抑えつつ、確実に「Azureが拒否したIP」をあぶり出せます。

4. まとめ：クラウドを使いこなす「引き出し」を持とう

今回の教訓は以下の3点です。

1. IP制限のログは、アプリのログストリームには出ない。

2. Web用のIPと通信用のIPが違う可能性を疑い、curl等で直接叩く。

3. 診断設定は強力だが、コストを意識して「使い終わったら消す」のがプロの作法。

「設定したのに動かない、ログも出ない」と焦る前に、この構造を知っていれば数分で解決できます。プログラムのコードだけでなく、こうした「クラウドの仕様」を知ることこそが、開発をスムーズに進める鍵となります。

【Azure】App Serviceで「勝手にログアウトされる」謎の現象。Data Protectionの罠と解決策

 

「ローカルでは正常にログインできるのに、Azureに上げたらセッションが維持されない…」

「しばらく放置すると、すぐにログイン画面に戻されてしまう…」

もし、ASP.NET CoreなどのWebアプリをAzure App Service（特にLinux版）で動かしてこのような現象が起きたら、それはコードのバグではなく「Data Protection（データ保護）キーの永続化」が原因かもしれません。

今回は、中級者でも意外と見落としがちな、クラウド環境におけるセッション管理の急所について解説します。

1. 現象：なぜかセッションが維持されない

App ServiceにデプロイしたWebシステムで、以下のような不安定な挙動が発生することがあります。

• ログインして操作している最中に、突然ログアウトされる。

• アプリを再デプロイ（スロット切替含む）すると、全員強制ログアウトされる。

• インスタンスを2つ以上に増やす（スケールアウト）と、ログインがほぼ不可能になる。

これらはすべて、「認証Cookieを復号するための鍵（マスターキー）」が失われているサインです。

2. 原因：Azure App Serviceの「揮発性」

ASP.NET Coreなどは、デフォルトで「Data Protection（データ保護）」という仕組みを使い、ログイン情報を暗号化しています。この暗号化に使う「鍵」の保存先が問題です。

• ローカル環境: Windowsのレジストリやファイルシステムに鍵が半永久的に保存されます。

• App Service (Linux): デフォルトではコンテナ内のファイルシステムに保存されます。しかし、App Serviceは再起動やデプロイのたびに中身がリセットされる「揮発性」を持っています。

つまり、サーバーが再起動するたびに「鍵」が捨てられ、新しく作り直されてしまうのです。古い鍵で作られたCookieは、新しい鍵では解読できないため、システムは「不正なユーザー」とみなしてログアウトさせてしまいます。

3. 解決策：鍵の保存先を「外部」に固定する

この問題を解決するには、Azureのストレージサービスを使って、鍵をコンテナの外に逃がしてあげる必要があります。

もっとも一般的な方法は、Azure Blob Storage を鍵の保管庫にすることです。

実装のイメージ（Startup.cs / Program.cs）

public void ConfigureServices(IServiceCollection services)

{

    // Blob Storageに鍵を保存する設定を追加

    services.AddDataProtection()

        .PersistKeysToAzureBlobStorage(new Uri("<BlobのSASトークン付URI>"));

}

※実際には、Azure Key Vaultを使って鍵自体をさらに暗号化するのがベストプラクティスです。

4. 初学者が知っておくべき「クラウドの流法」

今回のトラブルの教訓は、「サーバーの中を信用してはいけない」ということです。

• サーバーはいつでも使い捨てられる（ステートレス）。

• 消えて困る情報（鍵、ファイル、セッション）は必ず外部サービス（Blob, Redis, DB）に預ける。

この「クラウドの作法」を知っているだけで、デバッグに費やす数時間を節約できます。

5. まとめ：知れば怖くないData Protection

私もWebシステムの経験がありましたが、Azure特有のこの挙動には驚かされました。しかし、一度仕組みを理解してしまえば、設定一つで解決できる問題です。

「なぜかログインが切れる」と悩んでいる初学者の方がいたら、まずはData Protectionの保存先を疑ってみてください。

【Azure】PostgreSQLの登録日時が9時間ズレる？コードを直す前に確認すべき「魔法の1行」

 ローカル環境では完璧だった自作アプリ。しかし、Azure（App Service + PostgreSQL）にデプロイした途端、データの登録日時が「9時間前」を指している……。

「プログラムのバグか？」「PostgreSQLのタイムゾーン設定をSQLで直すべきか？」と焦って調査を開始しましたが、実は解決策はAzureポータル上の「環境変数」を1行足すだけでした。

今回は、知っているだけでトラブルを秒速で解決できる、クラウドサービスを使いこなすことの重要性について共有します。

1. 迫りくる「9時間の壁」

AzureのApp Service（Linux）やデータベースは、デフォルトでは世界標準時（UTC）で動いています。日本（JST）との時差はちょうど9時間。

未設定のままデプロイすると、アプリが「いま何時？」とサーバーに聞いた際にUTCが返ってきてしまい、そのままDBに「9時間前の過去」が刻まれてしまうのです。

2. 解決策：コード修正不要。Azureの環境変数を追加するだけ

当初は「プログラム内で AddHours(9) するか？」とも考えましたが、それは悪手です。Azureというプラットフォーム側で解決するのがスマートな方法でした。

実際に行った手順はこれだけです：

1. Azure Portalで対象の App Service を選択。

2. [設定] ＞ [環境変数] を開く。

3. アプリケーション設定に以下の設定を追加して保存。

• 名前: WEBSITE_TIMEZONE

• 値: Asia/Tokyo

これだけで、App Service上のLinux OSの時間が日本時間に切り替わり、プログラムが吐き出す時刻も、DBに保存される時刻も一発で正常化しました。

3. 「調査」も大事だが「クラウドの仕様」を知る方が早い

今回の件で痛感したのは、「クラウドサービスを使いこなす」ことの威力です。

• プログラムの調査: コードを追い、テストし、再デプロイする（数時間〜）。

• DBの調査: パラメータを調べ、再起動の影響を考える（数十分〜）。

• Azureの設定: 環境変数を1行足すだけ（わずか30秒）。

「何かがおかしい」と思ったとき、まずは「Azure側で用意されているスイッチはないか？」と疑ってみる。この視点を持つだけで、開発効率は劇的に変わります。

4. 知ればすぐ対応できる。それがAzureの便利さ

クラウドのトラブルは「難しい」と思われがちですが、実は「知っているか、知らないか」だけの違いであることも多いです。

今回のように、WEBSITE_TIMEZONE というキーワードさえ知っていれば、余計な工数を使わずに済みます。プログラミングスキルと同じくらい、「クラウドという道具をどう使いこなすか」という知識をアップデートし続けることの重要さを改めて実感しました。

まとめ：トラブルを「仕様の理解」でねじ伏せる

Azure App Service + PostgreSQLの構成で日時のズレに遭遇したら、まずはポータルへ向かいましょう。

1. WEBSITE_TIMEZONE = Asia/Tokyo を設定する。

2. 動作確認する。

3. 浮いた時間で、より本質的な開発に集中する。

これこそが、現代のエンジニアにとっての「最短ルート」です。