[Azure AD/Windows 10]外部SAML IdPとID連携しているとAzure AD Joinできない

こんにちは、富士榮です。

今回はかなり、レアかつマニアックな話です。
以前、Office365へOpenAMを使ってログインする方法を紹介しました。

　[Office365/AzureAD]OpenAMとのID連携①
　http://idmlab.eidentity.jp/2014/11/office365azureadopenamid.html


Azure ADは純正の外部IdPであるAD FS以外にもws-federationもしくはSAMLに対応した外部IdPとのフェデレーションもサポートしているので、OpenAMやPingFederateなどのサードパーティIdPでOffice365などAzure ADと連携されているアプリケーションへのログインが可能になる、という事です。

通常のWebアプリケーションであれば問題はないのですが、実はWindows 10のAzure AD Join（いわゆるWorkplace Joinではなく）を外部SAML IdPと連携したAzure ADで実行しようとすると問題が起きます。
（外部IdPがws-federationだと行けます。本国の方々と話をしていたんですが、あまりにもレアケースなので・・・という感じでした。まぁ、確かに。）

ということで、現状はAD FS以外の外部IdPと連携したAzure ADへのWindows 10デバイスの直接参加は不可能なので、もし将来的にAzure AD Joinを行う計画のある人は外部SAML IdPを使うのはやめておいた方が良いかも知れません。
注）AD FSを使う場合も正規の手続き（Convert-MsolDomainToFederated）以外を使った場合（Set-MsolDomainAuthenticationでプロトコルにSAMLを指定）は他の外部SAML IdPと同様にAzure AD Joinが出来なくなります。


では、どんなことが起きるのか、何が原因なのか、について少しだけ解説しておきます。

◆何が起きるのか？

[設定]からAzure ADへの参加を使用とすると「職場または学校のアカウント」の入力を求められます。

正規の手順で構成されたAD FSを使っている場合は、ユーザ名を入力して[次へ]をクリックすると組織のサインインページ（要はAD FSのログイン画面）へ遷移します。

しかし、その他の外部SAML IdPを使っている場合は以下の様に「組織のアカウントではない」と怒られてしまい、Azure AD Joinが出来ません。

◆何が起きているのか？

Azure ADへのサインインを行う際、入力したユーザがどこで認証されるべきか？をドメインパート（＠より後ろ）を見て判別する、いういわゆるホームレルムディスカバリというプロセスが実行されます。これは、ブラウザシナリオでも今回のような非ブラウザシナリオでも同様です。

今回ブラウザシナリオでは外部IdPを使ってもログインできて、Azure AD Joinの場合だけダメなのか？はこのホームレルムディスカバリの方法と仕様が異なるためです。

ブラウザシナリオにおいては
　https://login.microsoftonline.com/common/userrealm
というエンドポイントにクエリパラメータに「user=ユーザ名」をつけたGETリクエストを行うのに対し、Azure AD Joinの場合は、
　https://login.microsoftonline.com/common/GetCredentialType
というエンドポイントにユーザ名の情報をPOSTします。
※ちなみにワークプレイスジョイン（組織アカウントの追加）の場合はブラウザシナリオと同じエンドポイントを使うので、外部SAML IdPを使っても問題なくサインインできます。

エンドポイントが異なるのと同様に返ってくるレスポンスも異なり、ブラウザシナリオでは、外部SAML IdPの種類にかかわらず、ちゃんと利用プロトコルと外部SAML IdPのURLを返してきますが、Azure AD Joinの場合は、外部SAML IdPのURLが返ってこず、ここでレルム探しが失敗、先のエラーメッセージが表示されています。

ブラウザシナリオでのレスポンスの例

{
  "NameSpaceType":"Federated",
  "federation_protocol":"SAML20",
  "Login":"hoge@example.net",
  "AuthURL":"https://idp.example.net",
  "DomainName":"example.net",
  "FederationBrandName":"eIdentity",
  "federation_saml_request":"xxxxx",
  "federation_saml_relay_state":"xxxxx",
  "cloud_instance_name":"microsoftonline.com"
  "TenantBrandingInfo":[{"xxxx"}]
}

Azure AD Joinのレスポンスの例（AD FSの場合）

{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":0,
  "Credentials":{
    "PrefCredential":4,
    "HasPassword":true,
    "RemoteNgcParams":null,
    "FederationRedirectUrl":"https://fs.example.net/adfs/ls/?...omit...",
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
  }
}

Azure AD Joinのレスポンスの例（外部SAML IdPの場合）

{
  "Username":"hoge@example.net",
  "Display":"hoge@example.net",
  "IfExistsResult":1,
  "Credentials":{
    "PrefCredential":1,
    "HasPassword":true,
    "RemoteNgcParams":null},
    "EstsProperties":{"xxx"},
    "apiCanary":"xxx"
   }
}

上記のように、外部SAML IdPを使っているとFederationRedirectUrlが返ってこないので、フェデレーション先にリダイレクトがされません。

どこかのタイミングでこの挙動も変わるかも知れませんが、取り合えず現状はAzure AD Joinの計画がある場合は、Azure ADだけでサインインするか、AD FSを含む外部ws-federation IdPとして使う、という2択になりそうです。