Visual Studio Team Services (VSTS) と Microsoft アカウント (MSA)

Visual Studio Team Services (VSTS) と Microsoft アカウント (MSA)

Windows SDK チームの Jeff です。私は今一時的に VSTS グループに携わっているため、この記事ではいつもとは少し異なる内容をご紹介します。

さて、Microsoft アカウントは 2 種類あります。1 つは MSA アカウント (Microsoft アカウント。旧称 LiveID。Outlook、Hotmail などで利用)、もう 1 つは WSA アカウント (職場または学校のアカウント。Azure Active Directory、Office 365 で利用) です。

WSA アカウントは仕事用のアカウントで、ワークステーションへのログオンやメールで利用され、形式は @CompanyName.com というのが一般的です。MSA アカウントは主に個人用アカウントとして利用され、通常は @Hotmail.com や @Outlook.com といった形式です。ただし、これまでは WSA アカウントと重複する MSA アカウントを作成することも可能だったため、複数のアカウントで UPN が同じという場合もあります。この “ドッペルゲンガー” とも言えるアカウントのうちいずれかでログオンしようとすると、現在は以下のようなダイアログ ボックスが表示されます。

実は、2016 年 9 月 15 日から、MSA と WSA で重複するアカウントを作成することはできなくなりました。MSA アカウントと WSA アカウントが重複することで、さまざまな問題が生じていたためです。たとえば、どちらのアカウントが必要なのかやどちらのアカウントを使用しているのかがわかりにくかったり、適切なアカウントがどれなのか結局判断できないこともありました。こうした問題を解消するべく、マイクロソフトは今後、重複するアカウントの作成を禁止することにしました。詳細については、こちらのブログをご覧ください。なお、これまでに作成したアカウントは引き続きご利用いただけます。

重複したアカウントを作成しようとすると、「You can’t sign up here with a work or school email address. (職場または学校のメール アドレスでサインアップすることはできません。)」というエラーが表示されます。

Visual Studio Team Services への影響

今回の変更は、VSTS にも大きな影響を及ぼします。多くの VSTS アカウントは MSA ベースなので、VSTS へのログオンには MSA アカウントを利用する必要があります。MSA ベースの VSTS アカウントにユーザーを追加する場合、多くの企業では User@company.com に招待を送信しています。VSTS では、アカウントが存在するかどうかにかかわらず任意のユーザーを招待できます。こうしたシナリオで、VSTS 管理者が社内の新規ユーザーである User@company.com を招待したとします。このときメールは企業の受信トレイに送信されます。メールによる招待を受信したユーザーが VSTS にアクセスしようとすると、必要に応じて MSA アカウントを作成するように促されます。VSTS 管理者の多くは、ユーザーが新しい MSA アカウントを作成できるものと思っていますが、2016 年 9 月 15 日以降はアカウントの作成が禁止されています。これまでに VSTS に招待されたユーザーは自身の @company.com アドレスを使用して MSA アカウントを作成できましたが、今後は WSA と一致する MSA アカウントは作成できません。

この件について、VSTS のプログラム マネージャーは、MSA 版の User@company.com の利用が安全でない理由を次のように説明しています。

「個人用の Microsoft アカウントを作成するのに、企業のメール アドレスを使用しても、個人用のメール アドレスを使用しても、管理のしやすさは変わりません。しかし、管理が可能だという期待感や認識を抱かせることになったために少なからず混乱が生じてしまいました。そのため、この方法を禁止することにしたのです。

Azure AD のユーザー アカウントとは異なり、個人用の Microsoft アカウントはどのメール アドレスを使用して作成した場合でも、IT 担当者が制御することはできません。つまり、ユーザーがアカウントのユーザー名を変更したり、退職後も継続してアカウントを利用したりすることを防止する方法がありません。ポリシーの適用もアカウントの削除もできなければ、アカウントを使用してアクセスできるアプリケーションを制御することもできません。さらに、利用状況を監査することも、アカウントの特定の利用について当該機関に正当性を証明することもできません。アカウントやアカウントのデータを放棄するように、マイクロソフトに依頼することも不可能です」。

今回、重複する MSA アカウントを新たに作成できなくなったことで、新規ユーザーが VSTS にアクセスするには、以下のいずれかのオプションを選択する必要があります。

1)      実在する MSA アカウント (@Hotmail、@Outlook) を使用してユーザーを招待する。

2)      Azure/Office 365 と関連付けられていないメール アカウント (@Gmail、@Yahoo) を使用してユーザーを招待する。この場合も、ユーザーが MSA アカウントを所有していなければ、作成する必要があります。

3)      Azure/Office 365 AAD と VSTS をリンクする (英語)。

オプション 1 または 2 を利用する場合、VSTS のアカウント リストで @Hotmail や @Gmail などのアカウントの利用を許可する必要があります。オプション 1 と 2 は最も簡単な方法で、事前の計画も不要です。

VSTS ユーザーに企業のメール アカウントの利用のみを許可する場合は、オプション 3 を利用する必要があります。オプション 3 は比較的複雑で、事前の検討や計画が必要です。AAD と VSTS をリンクする方法については、こちらのドキュメント (英語) をご覧ください。

AAD と VSTS をリンクする場合には、以下の点に注意してください。

1)      外部アカウント: VSTS と AAD をリンクする場合、AAD に含まれるユーザーのみが VSTS にアクセスできます。社内ユーザーであれば問題ありませんが、VSTS アカウントの中に @Hotmail などのアカウントが含まれる場合は AAD に追加する必要があります (ユーザーを追加する際には、[User with an existing Microsoft Account] を選択します)。

2)      ゲスト アカウント: MSA ベースの VSTS アカウントにはゲスト ユーザーという概念はなく、AAD と VSTS アカウントをリンクする場合にのみこの概念が生じます。AAD に含まれる社内ユーザーはメンバーであるので問題ありませんが、外部の Microsoft アカウント (MSA) を AAD で利用する場合は、以下の点に注意する必要があります。ユーザーの種類は、新しい Azure ポータル (portal.azure.com) で確認できます。

1. VSTS に新規ユーザーを追加する場合、ゲストは AAD を検索できません。詳細については、こちらのブログ記事 (英語) をご覧ください。PowerShell を使用してゲストをメンバーに変更する方法も併せて紹介しています。ただし、最近になってエラー メッセージが変更されたのでご注意ください。AAD ゲストはディレクトリを検索できないというメッセージではなく、「No identities found. (ユーザー情報が見つかりません。)」というエラーが表示されます。
2. ゲストに VSTS アカウントの所有権を割り当てることはできません。ただし、AAD にリンクされる前にゲストが VSTS アカウントを所有しており、そのアカウントを後から AAD に追加した場合には、ゲストであっても VSTS アカウントを所有できます。また、PowerShell (英語) を使用して AAD のゲストに変更することもできます (ただし、この方法は推奨されません)。
3. ゲストによるアクセスはすべて拒否することができます。VSTS アカウントの設定タブには、[External guest access] というオプションがあります。このオプションは既定で [Allow (許可)] に設定されていますが、[Deny (拒否)] に設定すると、すべてのゲストが VSTS にアクセスできなくなります。AAD にゲストだけを登録することもできますが、その場合はすべてのゲストが VSTS にアクセスできません。この場合、PowerShell (英語) を使用して VSTS の所有者をメンバーに変更してから VSTS にログオンして、ゲストによるアクセスを許可するように設定し直す必要があります。
   

Jeff