SailPoint Windows Localコネクタで「The specified username is invalid」になる原因と解決策（IQService配置の正解も整理）

Windows Localコネクタのオンボーディング中、「Test Connection」で The specified username is invalid が出るのに、同じ資格情報でRDPログインは成功する——このギャップは珍しくありません。結論から言うと、IQServiceは“基本的に”各Windowsサーバーへ個別インストール必須ではありません。ただし、接続方式の都合で「ユーザー名の書式」「認証先の解釈」「IQServiceサーバーとターゲットの関係（ドメイン/ネットワーク/ポリシー）」が揃っていないと、このエラーが出やすくなります。 SailPoint 開発者コミュニティ+1

SailPoint Windows Localコネクタで「The specified username is invalid」になる原因と解決策（IQService配置の正解も整理）

まず結論：IQServiceは各ターゲットに入れなくてもよい（ただし条件あり）

Windows LocalコネクタはIQService経由で対象Windowsにアクセスします。IQServiceは「対象に到達できるWindowsサーバーに置く」設計で、1つのIQServiceで複数のWindows Localソースを扱うこと自体は可能です。 SailPoint 開発者コミュニティ+1

一方で、SailPointのドキュメント上は、Windows Localコネクタで“非ローカル（ドメイン）やクロスドメインの対象”を集約するケースでは、IQServiceが同一ホスト上か、少なくとも同一ドメイン側にいる必要がある旨が示されています。つまり「万能にどこでもOK」ではなく、配置によって出来る/出来ないが出ます。 SailPoint Documentation

エラーの正体：「RDPで通る」と「IQServiceで通る」は別物

RDPログイン成功は、主に「対話ログオン（Interactive）」の可否です。
一方、IQService経由のWindows Localは、RPC/管理API/リモート管理系の権限と解釈に依存します。そのため、次のような差が出ます。

ユーザー名の解釈が違う（ターゲット側で“どのアカウントとして”認証するか）
ローカルアカウントの扱いが違う（IQServiceサーバー上のローカルなのか、ターゲット上のローカルなのか）
ポリシーでリモート管理が制限されている（SAM/RPCの制限など）

このとき現れやすいのが「ユーザー名が無効」という、原因を一段抽象化したメッセージです。

最重要チェック：ユーザー名の書式（ここが9割）

Windows Localの“ターゲット”に対してローカルアカウントで認証するなら、基本は次の形が安全です。

ターゲットのローカルアカウント：TARGET_HOSTNAME\Username
ドメインアカウント：DOMAIN\Username もしくは Username@domain（環境次第）

特に「IQServiceは別サーバーに置いている」場合、.\Username や単体の Username は、IQServiceサーバー側のローカルとして解釈されたり、認証先が揺れて失敗しがちです。コミュニティでも、このエラーで最初に確認すべき点としてユーザー名書式が挙げられています。 SailPoint 開発者コミュニティ

ありがちな落とし穴

ターゲットのつもりで .\admin を入れていた（実際はIQServiceサーバーのローカル扱い）
Administrator のみを入力していた（どこのAdministratorか曖昧）
ドメイン参加/信頼関係の境界で DOMAIN\user が意図通りに評価されていない

「IQServiceを共用できる」ための現実的な条件

IQServiceを別サーバーに置いたまま、複数のWindows Localターゲットに繋ぐなら、少なくとも以下が揃っている必要があります。

IQServiceサーバーからターゲットへ名前解決と到達性がある（DNS/ルーティング/ACL）
必要な通信が遮断されていない（RPCや管理系に相当する通信。環境のFW設計次第で詰まりやすい）
認証に使うアカウントがターゲット側で“リモート管理として”許可されている
ターゲットがドメイン/クロスドメイン絡みなら、IQService配置も同一ドメイン側に寄せる（要件により同一ホストが必要なケースもあり得る） SailPoint Documentation+1

「同じIQServiceで別のADソースは動いている」場合でも、Windows Localはターゲットが“ローカルSAM”であるぶん、組織のセキュリティポリシーの影響を受けやすい点に注意が必要です。

ポリシー起因の代表例：SAM/RPCの制限で認証が落ちる

Windowsのローカルセキュリティポリシーで、リモートSAM呼び出し（RPC）を制限していると、資格情報が正しくても失敗することがあります。SailPoint側のトラブルシュートでも、特定ポリシーの設定確認が案内されています。 SailPoint Documentation

ここが厄介なのは、ログ上「ユーザー名が無効」「認証が通らない」といった形で見えることがある点です。原因の切り分けとしては、ターゲット側のセキュリティイベントログ、IQServiceログ、ネットワーク機器ログの3点セットで当たりを付けるのが近道です。

すぐ試せる復旧手順（上から順に潰す）

ユーザー名を TARGET_HOSTNAME\Username（ローカル）または DOMAIN\Username（ドメイン）へ統一
同じ資格情報でも、RDPではなく“管理系の到達/権限”が必要だと割り切り、ターゲットのローカル管理者権限（または必要権限）を再確認
IQServiceサーバーからターゲットへの疎通と名前解決（短縮名/別名/大文字小文字ではなく、意図したホストを指しているか）
ターゲットのローカルセキュリティポリシーでリモート管理が制限されていないかを確認（特にSAM/RPC系）
ドメイン/クロスドメイン要件があるなら、IQService配置を同一ドメイン側へ寄せる（それでもダメなら同一ホスト配置を検討） SailPoint Documentation

運用設計のおすすめ：IQServiceを増やすべきタイミング

「1台のIQServiceで全部まとめる」は管理が楽ですが、次の条件があるなら分割のメリットが出ます。

ネットワークセグメントが分かれていて、管理系ポートが通りにくい
ドメイン境界/信頼関係が複雑で、認証の解釈が揺れる
ターゲットが多く、障害時の影響範囲を小さくしたい

この場合は「拠点/ドメイン/セキュリティ境界ごとにIQServiceを置く」ほうが、テスト接続の失敗を根本から減らせます。

まとめ：このエラーは「必須要件の誤解」より「書式と解釈のズレ」を疑う

IQServiceは各ターゲットに必須でインストールする必要はない（共用は可能） SailPoint 開発者コミュニティ+1
ただし ユーザー名書式（TARGET_HOSTNAME\Username）が最重要で、ここがズレると「ユーザー名が無効」に見えやすい SailPoint 開発者コミュニティ
ドメイン/クロスドメインやセキュリティポリシー次第で、IQService配置の条件が効いてくる SailPoint Documentation+1

まずは「ターゲット名\ユーザー名」の形式に揃え、それでも同じならポリシーと配置要件（同一ドメイン側）を順に当てていく——これが最短で解決に近づく手順です。