オンプレミスの SharePoint 2019 に構築した OneDrive for Business（個人サイト）へ、CSOM（C#）でアクセスしようとすると 401 Unauthorized…。ブラウザーでは普通に開けるのに、コードからだけ弾かれる――この現象は、認証方式と URL 周りの設定が少しでも噛み合っていないと簡単に発生します。この記事では、原因の考え方から具体的なレジストリ設定、C# コード例まで、一気に整理して解説します。
環境とトラブルの前提を整理する
まず、今回想定している環境を整理しておきます。
- 同一物理マシン上で、ホスト OS 上から仮想マシン（VM）内の SharePoint 2019 に接続している。
- VM 側には SharePoint 2019 がインストールされ、OneDrive for Business（個人サイト）が構成されている。
- ブラウザー（IE / Edge / Chrome 等）からは同じユーザー資格情報で個人サイトにアクセス可能。
- しかし CSOM（C#）で ClientContext を作成して接続すると、ExecuteQuery() で 401 Unauthorized が返る。
- SharePointOnlineCredentials と NetworkCredential の両方を試したがどちらも失敗。
このように「ブラウザーでは通るのに CSOM だけ 401」という状況は、クライアント側コードの認証方式・URL と、SharePoint 側の認証設定・URL 公開設定がずれているときに典型的に発生します。
特に、SharePoint Online 用のクラスである SharePointOnlineCredentials をオンプレミスの SharePoint 2019 へそのまま使ってしまったり、VM 内のサーバー名で直接アクセスしてしまったりすると、あっさり 401 になります。
401 Unauthorized が発生する典型パターン
今回のような構成で 401 が出るとき、原因は大きく次のようなカテゴリに分類できます。
- 認証方式の不一致
・SharePoint Online 用の認証クラスをオンプレに使っている
・サーバー側の認証プロバイダー（Windows / SAML など）とクライアント側の想定が合っていない - URL / 名前解決 / ループバック関連の不整合
・AAM（代替アクセス マッピング）の公開 URL と、コード内の URL が一致していない
・FQDN ではなくサーバーの NETBIOS 名や IP でアクセスしている
・ループバックチェック（BackConnectionHostNames 未設定）が原因で 401 になる - 権限やサイト状態の問題
・個人サイトがまだプロビジョニングされていない
・アクセスしているユーザーにサイト権限がない - 通信・セキュリティ周り
・TLS / プロキシ / ファイアウォールの影響
・証明書検証やプロキシ認証が途中で挟まっている
この記事では、最短で復旧しやすい順番で、原因と対処を整理していきます。基本は次の三点セットから手を付けると効率的です。
- NetworkCredential を正しく使う
- FQDN かつ AAM の公開 URL を使ってアクセスする
- サーバー側で BackConnectionHostNames を設定する
最初に見直すべきは C# コード：NetworkCredential に統一する
オンプレミスの SharePoint 2019 に対して、SharePointOnlineCredentials は基本的に使えません。これは SharePoint Online（Microsoft 365）のクレームベース認証＋フェデレーションを前提としたクラスで、オンプレミスの Windows 認証（NTLM / Kerberos）環境では想定されていないためです。
そのため、オンプレ SharePoint 2019 に接続する CSOM コードでは、NetworkCredential でドメイン資格情報を指定するのが基本になります。
NetworkCredential を使った接続コード例
using Microsoft.SharePoint.Client;
using System;
using System.Net;
class Program
{
static void Main()
{
// AAM で定義した公開 URL（FQDN）を指定
var url = "http://sp2019.contoso.local/personal/user_domain_com/";
using (var ctx = new ClientContext(url))
{
// ドメイン\ユーザー名 または (ユーザー名, パスワード, ドメイン) で指定
ctx.Credentials = new NetworkCredential("username", "password", "CONTOSO");
// 動作確認用にサイトタイトルを取得
ctx.Load(ctx.Web, w => w.Title);
try
{
ctx.ExecuteQuery();
Console.WriteLine("接続成功: " + ctx.Web.Title);
}
catch (ClientRequestException ex)
{
Console.WriteLine("ClientRequestException: " + ex.Message);
}
catch (ServerException ex)
{
Console.WriteLine("ServerException: " + ex.Message);
}
}
}
}
ポイントは次の通りです。
- URL は AAM の公開 URL（FQDN）を使用する（後述）。
- 資格情報は ドメイン\ユーザー名 または NetworkCredential(“ユーザー名”, “パスワード”, “ドメイン”) で指定する。
- ユーザー名に UPN 形式（[email protected]）を使うときは、環境によって認証の通り方が変わることがあるため、まずは domain\user 形式を試す。
DefaultNetworkCredentials を使うのはどうか？
同一ドメイン内、かつ CSOM を実行するプロセスがすでに適切なドメインアカウントで動作している場合、ctx.Credentials = CredentialCache.DefaultNetworkCredentials; とする方法もあります。ただし、どのアカウントでプロセスが動いているかを正確に把握していないと切り分けが難しく、トラブルシュート中は明示的に NetworkCredential でユーザーを指定した方が分かりやすいケースが多いです。
URL / AAM / DNS / hosts をそろえる
コードの認証方式を正しくしても、アクセス先 URL が AAM（代替アクセス マッピング）の公開 URL と一致していないと、認証がうまく動かず 401 になることがあります。特に次のようなパターンは要注意です。
- ブラウザーでは
http://sp2019.contoso.local/でアクセスしているのに、コードではhttp://sp2019/を使っている。 - ブラウザーは
http://mysites.contoso.local/を使っているのに、コードではhttp://サーバーIP/を使っている。 - HOSTS ファイルや DNS の設定によって、ブラウザーとコードで別の名前解決経路をたどっている。
AAM と URL の関係を整理する
SharePoint では AAM（Alternate Access Mapping）によって、「ユーザーから見える URL（公開 URL）」と「内部的な URL（内部 URL）」をマッピングしています。CSOM でアクセスするときも、ブラウザーで使っているのと同じ公開 URL を指定するのが基本です。
| 項目 | 確認内容 | チェック方法の例 |
|---|---|---|
| AAM 公開 URL | Web アプリケーションに設定されている公開 URL と一致しているか | 中央管理 > システム設定 > 代替アクセス マッピング |
| DNS / hosts | FQDN が仮想マシンの IP に正しく解決されるか | ホスト OS から ping sp2019.contoso.local などで確認 |
| URL の一貫性 | ブラウザーと CSOM の URL が同じ FQDN／パスか | ブラウザーのアドレスバーとコード内の URL を目視で比較 |
特に OneDrive 個人サイトの場合、URL にはユーザー固有のパス（/personal/ユーザー名_ドメイン_com/ など）が含まれます。ブラウザーで正常にアクセスできている URL をそのままコピー＆ペーストし、コードの ClientContext に渡すのが確実です。
ループバックチェックが原因で 401 になるケース
Windows サーバーでは、セキュリティ対策として「ループバックチェック」が有効になっていることがあります。これは、サーバー自身から自分のホスト名（FQDN）を使ってアクセスしたときに、特定の条件で認証を拒否する仕組みです。
今回のように、同一物理マシン上で動いている VM の SharePoint に、ホスト OS から FQDN を使ってアクセスしている場合、実質的に「サーバー自身から自分へのアクセス」に近い状況が発生し、ループバックチェックが 401 を返す原因となることがあります。
BackConnectionHostNames で FQDN を許可する
推奨される対処は、ループバックチェック自体を無効化するのではなく、アクセスを許可するホスト名（FQDN）を BackConnectionHostNames に登録する方法です。SharePoint サーバー（VM）上で、以下のような PowerShell を実行します。
New-ItemProperty `
-Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0" `
-Name "BackConnectionHostNames" `
-PropertyType MultiString `
-Value @("sp2019.contoso.local","mysites.contoso.local")
すでに BackConnectionHostNames が存在する場合は、値を上書きせず追記する形で設定します。設定後は、少なくとも IIS の再起動（iisreset）、環境によってはサーバー再起動を行うと確実です。
DisableLoopbackCheck で丸ごと無効化する方法（非推奨）
一時的な切り分けとして、ループバックチェックそのものを無効化することも可能です。これにより、FQDN へのアクセスでループバックチェックによる 401 が発生しなくなりますが、セキュリティ的には推奨されません。
New-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Control\Lsa" `
-Name "DisableLoopbackCheck" -Value 1 -PropertyType DWORD
テスト目的で一時的に有効化し、問題の切り分けが終わったら、必ず元に戻して BackConnectionHostNames 方式に切り替えることをお勧めします。
SharePoint 側の認証方式を確認する
オンプレミスの SharePoint 2019 では、Web アプリケーション単位で次のような認証方式が構成されていることがあります。
- Windows 認証（NTLM / Kerberos）
- フォーム認証（SQL / LDAP 等）
- SAML / ADFS 認証（クレームベース）
CSOM から NetworkCredential で接続することを前提とするなら、対象 Web アプリケーションに対して Windows 認証が有効である必要があります。もし SAML / ADFS のみが有効で、Windows 認証が無効な場合、単純な NetworkCredential では認証フローに乗れず、結果的に 401 となることがあります。
Windows 認証（NTLM / Kerberos）の確認ポイント
- 中央管理の「認証プロバイダー」で、対象ゾーンに Windows 認証が含まれているか。
- IIS のサイト設定で、「Windows 認証」が有効、「匿名認証」が無効になっているか。
- Kerberos を使用する場合、SPN 登録や委任設定が適切か（通常の読み取りが目的であれば、まずは NTLM で動作させる方がトラブルシュートしやすい）。
もし SAML/ADFS のみで運用している環境で CSOM を用いた自動処理を行いたい場合は、ADFS からトークンを取得し、そのトークンをヘッダーに付けてアクセスするといった、より高度な実装が必要になる場合があります。この場合、単純な NetworkCredential だけでは解決しません。
OneDrive 個人サイトの権限・状態を確認する
401 Unauthorized の多くは認証まわりの問題ですが、実は 権限不足や 個人サイト未プロビジョニングが原因となるケースもあります。
個人サイトがプロビジョニングされているか
OneDrive for Business（個人サイト）は、初回アクセス時にサイトコレクションとして自動作成される構成が一般的です。ブラウザーから一度もアクセスしていないユーザーの場合、個人サイトが存在せず、CSOM からのアクセスが失敗することがあります。
- ブラウザーから対象ユーザーで OneDrive を開き、個人サイトが正しく作成されているかを確認する。
- 管理者として、ユーザー プロファイル サービスの「個人サイト管理」から、対象ユーザーに関連するサイトを確認する。
アカウントの権限を確認する
CSOM で使用しているアカウントが、対象の個人サイトに十分な権限を持っているかも重要です。特に、別ユーザーの個人サイトにアクセスし、情報を一括取得するようなツールを作る場合は、次のような権限設計が必要になります。
- 対象 Web アプリケーションまたは My Site ホストのサイトコレクション管理者に CSOM 実行アカウントを追加する。
- あるいは、ユーザー プロファイル サービス側で「個人サイトの管理者」設定にアカウントを追加する。
ブラウザーから同じアカウントでログインしたときに個人サイトが問題なく表示できるにもかかわらず、CSOM だけ 401 になる場合は、やはり認証方式や URL 周りを疑うべきですが、念のため権限も確認しておくと安心です。
HTTPS / TLS / プロキシの影響を確認する
SharePoint を HTTPS で公開している場合、クライアント（CSOM）側の TLS 設定や証明書の信頼性が影響することがあります。特に、自己署名証明書を使っている検証環境などでは要注意です。
- ホスト OS に、SharePoint サーバーの SSL 証明書（ルート証明書を含む）を信頼済みとしてインポートしているか。
- 古い .NET Framework を使用している場合、
ServicePointManager.SecurityProtocolを明示的に TLS 1.2 に設定する必要がないか。 - 企業プロキシやセキュリティ製品が HTTPS 通信を中継・復号していないか。
プロキシ経由の環境では、ClientContext に対して WebRequestExecutorFactory をカスタマイズし、プロキシサーバーとその認証情報を設定する必要がある場合もあります。401 が返っているように見えて、実は途中のプロキシで認証が失敗しているというパターンもあるため、ネットワークトレース（Fiddler など）は非常に有効です。
ULS ログとトレースで 401 のサブコードを確認する
本格的に原因を追うなら、SharePoint サーバーの ULS ログと IIS のログは必ず確認したいところです。単に 401 とだけ表示されていても、裏側ではサブコード（401.1 / 401.2 / 401.5 など）が出ていることがあります。
- 401.1: 無効な認証ヘッダー。
- 401.2: サーバーの構成または認証方法に起因する認証失敗。
- 401.5: ISAPI/CGI の権限不足。
ULS では、関連するカテゴリ（Claims Authentication、SharePoint Foundation、Security など）をフィルターし、対象時刻近辺のログを追いかけます。クライアント側では Fiddler や Wireshark で HTTP ヘッダーを確認し、WWW-Authenticate ヘッダーや Authorization ヘッダーのやりとりを見ていくと、どのタイミングで認証がこけているかが見えてきます。
例えば、ブラウザーからのアクセスでは WWW-Authenticate: Negotiate, NTLM の応答に対して、ブラウザーが適切な Kerberos チケットや NTLM 応答を返しているのに対し、CSOM からのアクセスでは期待した認証ヘッダーが送られていない、あるいはそもそも別の URL にアクセスしている、というような違いが可視化できます。
すぐ試せる「三点セット」手順
ここまでの内容を踏まえ、最短で問題を解消しやすい三点セットを改めて手順としてまとめます。
- CSOM コードを NetworkCredential に統一する
SharePointOnlineCredentialsを使っていたらすべて撤廃する。ctx.Credentials = new NetworkCredential("username", "password", "DOMAIN");とする。- 動作確認として、サイトタイトル取得など最小限の処理で ExecuteQuery() を試す。
- アクセス先 URL を FQDN の公開 URL にそろえる
- ブラウザーで正常にアクセスできている URL をそのままコードにコピーする。
- AAM の公開 URL 一覧を確認し、コードの URL と一致していることを確認する。
- ホスト OS から FQDN で ping を打ち、正しい IP に解決されていることを確認する。
- SharePoint サーバーで BackConnectionHostNames を設定する
- アクセスに利用する FQDN（例：sp2019.contoso.local、mysites.contoso.local）を BackConnectionHostNames に登録。
- 設定後、IIS リセットまたはサーバー再起動を行う。
- それでもダメな場合は、切り分けとして一時的に DisableLoopbackCheck を有効化し、原因がループバックにあるかを確認する。
よくある落とし穴チェックリスト
最後に、今回のような「CSOM からの接続だけ 401 になる」問題で、特に見落としやすいポイントをチェックリスト形式でまとめます。
| チェック項目 | 概要 | 目安・備考 |
|---|---|---|
| SharePointOnlineCredentials 未使用 | オンプレミスでは使用せず、NetworkCredential を使っているか | コード内から完全に排除されているか確認 |
| URL と AAM の一致 | ClientContext の URL が AAM 公開 URL と一致しているか | ブラウザーの URL と同じ FQDN / パスになっているか |
| DNS / hosts の整合 | FQDN が正しく SharePoint サーバーに解決されているか | ホスト OS からの ping / nslookup で確認 |
| BackConnectionHostNames 設定 | ループバックチェックでブロックされていないか | 必要な FQDN を BackConnectionHostNames に登録済みか |
| 認証プロバイダー設定 | Windows 認証（NTLM / Kerberos）が利用可能か | SAML のみ構成になっていないか、IIS 設定も含めて確認 |
| アカウント権限 | 個人サイトへのアクセス権を持っているか | サイトコレクション管理者または適切な権限を付与 |
| 個人サイトの状態 | 対象ユーザーの個人サイトがプロビジョニング済みか | ブラウザーから OneDrive を開いてみる |
| TLS / プロキシ | HTTPS やプロキシで途中の認証が挟まっていないか | 自己署名証明書や企業プロキシの有無に注意 |
| ULS / トレース | 401 のサブコードや詳細な失敗理由を確認したか | ULS ログ・IIS ログ・Fiddler で時刻を合わせて追跡 |
- SharePointOnlineCredentials を使っていない（オンプレでは不可）。
- コードの URL が AAM の公開 URL（FQDN）と一致している。
- DNS / hosts で FQDN → VM の IP 解決が正しい。
- BackConnectionHostNames を設定済み、または一時的にループバック無効化して切り分け済み。
- Web アプリの認証プロバイダー設定で Windows 認証が利用可能。
- アカウントに個人サイトへのアクセス権（サイトコレクション管理者など）がある。
- ULS / トレースで 401 の詳細を確認し、別の問題が潜んでいないか確認。
まとめ：CSOM + SharePoint 2019 + OneDrive 個人サイトの 401 を攻略する
オンプレミスの SharePoint 2019 に構築した OneDrive 個人サイトへ、CSOM（C#）で接続しようとしたときに 401 Unauthorized になる原因は、ほとんどの場合、
- 認証方式の不一致（SharePointOnlineCredentials 利用や認証プロバイダーの設定ずれ）
- URL / 名前解決 / ループバック周りの設定不備（FQDN・AAM・BackConnectionHostNames）
に集約されます。まずは、
- NetworkCredential に統一したシンプルな CSOM コードで、
- AAM の公開 URL（FQDN）に対して接続し、
- SharePoint サーバー側で BackConnectionHostNames を適切に設定する
という三点セットを実施し、それでもダメな場合に、認証プロバイダー（Windows / SAML）、権限、TLS / プロキシ、ULS ログといった深い層を切り分けていくと、効率的に原因へたどり着けます。
一度この流れを押さえておくと、別の環境や別バージョンの SharePoint でも応用が利きます。ブラウザーでは開けるのに CSOM だけ 401 になる――そんなときは、本記事のチェックリストを上から順に確認してみてください。
コメント