Microsoft Passport の利点と現在の欠点、そして回避方法

Azure Active Directory に Windows 10 を「参加」(Azure AD Join)させることで、規定では Microsoft Passport が活性化され、Azure AD から発行された PRT(プライマリ リフレッシュ トークン)を使用して、Azure AD に接続されたクラウドアプリケーション群に対するシングルサインオンが実現できます。 Microsoft Passport とは ?http://blogs.technet.com/b/junichia/archive/2015/08/17/3653348.aspx これはとても素晴らしい機能なのですが、既にオンプレミス Active Directory を展開済の環境では、ちょっと困ったこともあります。というのは、Microsoft Passport を使い始めるとオンプレミス Active Directory を介さなくなるのです。当たり前と言えば当たり前ですが。。。具体的にはどういうことか。。? 以下の手書きの汚い図を、薄目でご覧ください。これは Microsoft Passport を使用した場合の、クラウドアプリにアクセスするまでの流れです。PRT をAzure AD に提示することでアクセストークンが発行されるので、Office 365 をはじめとするAzure AD アプリには完全な SSO が実現できます。ユーザーID(UPN)を提示する必要さえもありません。 さて、こうなると困るのはオンプレミスのアプリです。ファイルサーバーとか WEB サーバーとか。オンプレミス Active Directory に参加しているデバイスならば、AD から発行された TGT(Ticket Granting Ticket)を提示することで、サービスへのアクセスチケットが発行されるため、オンプレミス内では完全な…

1

Windows 10 から Hybrid Identity を使用して Azure AD 参加する場合の留意点

今回はちょっとした「回避ネタ」です。 オンプレミス Active Directory と、Azure Active Directory のハイブリッドアイデンティティが構成されている環境で、Windows 10 を Azure AD に参加させる場合、ちょっとだけ注意しなければならない点があります。 それは AD FS による認証方式です。 以下の画面をご覧ください。AD FS の設定画面を見慣れている方にはおなじみです。AD FS プロキシー等を経由して外部から認証要求を受け取ったときは、規定で「フォーム認証」画面を表示します。逆に、社内ネットワークからアクセスしてきたときには、規定で「Windows 認証」を使用します。 いうまでもありませんが、フォーム認証の画面とは以下のようなものです。 Windows 認証時に表示される画面は、以下のようなポップアップです。 イントラネット側が「Windows 認証」に設定されているのは、言うまでもなく IWA(統合 Windows 認証)を使用できるようにするためです。つまり、ドメインに参加済みで、ドメインのアカウントでサインインしていれば、このポップアップは表示されません。 通常はこのままでよいのですが、社内ネットワークから Azure AD に参加しようとすると問題が起きます。というのも、どうやら Azure AD に参加するためのアプリケーションは Windows 認証に対応していないようで、このままだとエラーが発生します。 そこで、設定を以下のように「フォーム認証」を有効にしておいてください。これにより、「フォーム認証」が使用され、問題なく Azure AD への参加プロセスを実行することができます。 上記の状態であっても、Internet Explorer 等 Windows 統合認証をサポートしているブラウザからアクセスがあった場合には「Windows 認証」が使用されます。 これが正しい対応かどうかちょっと不明なのですが、ひとまず上記でトラブルは回避可能です。


Azure 多要素認証(二段階認証)でできること

Azure Active Directory Premium を契約すると多要素認証プロバイダーを使用することができます。国内では二段階認証と呼ばれることが多くなった昨今ですが、まぁ、別にいいんですけど、認証要素を増やすことでより精度の高い本人確認ができるわけです。 ※ライセンスについてきちんと書いておくと、多要素認証のみを追加契約することも可能です。「ユーザー単位」または「一定時間の認証数(ユーザー数に依存しない)」で契約することができます。 以降、面倒なので Azure AD MFA(Multi-factor Authentication)と書きます Azure AD MFA のよいところは、Azure AD の認証プロセスの拡張機能として組み込まれているため、アプリケーションに依存しない点です。SAML2.0、WS-Federation、OpenID Connect のいずれかの認証プロトコルを使用してAzure AD につながったアプリケーションは漏れなく、この MFA の恩恵を受けることができます。アプリ側に手を入れる必要が無いわけですね。素敵! 今回は詳しくは触れませんが、アプリケーションごとに MFA を有効/無効 にしたり、ユーザーグループごとに MFA を強制したりといったことも可能です。また、若干マニアックですが、Azure AD Application Proxy を使用してオンプレミスの Web アプリを公開している場合にも、以下のように MFA 有効/無効を設定することができます。このあたりは別の機会に。 さて。ちょっと難しいのですが、Azure AD MFA のトリガーは2箇所にあります。 Azure AD 側で Azure MFAが必要と判断したとき オンプレミス AD FS が Azure MFA を必要と判断したとき Azure AD…


Azure AD Connect で規定で複製される属性

Azure AD Connect を使用して、オンプレミスActive Directory から Azure Active Directory にユーザー情報やグループ情報を同期するとき、規定では以下の属性が同期されます(ちょいと長いリストですんません)。ただし、値の入っていないものについては同期されません。 赤字のものは必須属性で、複製の対象から外すことはできません。 accountEnabledaccountNameapproximateLastLogonTimestampassistantauthOrigccncocompanycountryCodedLMemRejectPermsdLMemSubmitPermsdepartmentdescriptiondeviceIddeviceOSTypedeviceOSVersiondeviceObjectVersiondevicePhysicalIdsdeviceTrustTypedisplayNamedomainFQDNdomainNetBiosextensionAttribute1extensionAttribute10extensionAttribute11extensionAttribute12extensionAttribute13extensionAttribute14extensionAttribute15extensionAttribute2extensionAttribute3extensionAttribute4extensionAttribute5extensionAttribute6extensionAttribute7extensionAttribute8extensionAttribute9facsimileTelephoneNumbergivenNamehideDLMembershiphomePhoneinfoinitialsipPhonellegacyExchangeDNmailmailNicknamemanagedBymanagermembermemberCountmiddleNamemobilemsDS-HABSeniorityIndexmsDS-PhoneticDisplayNamemsExchArchiveGUIDmsExchArchiveNamemsExchAssistantNamemsExchAuditAdminmsExchAuditDelegatemsExchAuditDelegateAdminmsExchAuditOwnermsExchBlockedSendersHashmsExchBypassAuditmsExchCoManagedByLinkmsExchDelegateListLinkmsExchELCExpirySuspensionEndmsExchELCExpirySuspensionStartmsExchELCMailboxFlagsmsExchEnableModeration msExchExtensionCustomAttribute1msExchExtensionCustomAttribute2msExchExtensionCustomAttribute3msExchExtensionCustomAttribute4msExchExtensionCustomAttribute5msExchHideFromAddressListsmsExchImmutableIdmsExchLitigationHoldDatemsExchLitigationHoldOwnermsExchMailboxAuditEnablemsExchMailboxAuditLogAgeLimitmsExchMailboxGuidmsExchModeratedByLinkmsExchModerationFlagsmsExchRecipientDisplayTypemsExchRecipientTypeDetailsmsExchRemoteRecipientTypemsExchRequireAuthToSendTomsExchResourceCapacitymsExchResourceDisplaymsExchResourceMetaDatamsExchResourceSearchPropertiesmsExchRetentionCommentmsExchRetentionURLmsExchSafeRecipientsHashmsExchSafeSendersHashmsExchSenderHintTranslationsmsExchTeamMailboxExpirationmsExchTeamMailboxOwnersmsExchTeamMailboxSharePointLinkedBymsExchTeamMailboxSharePointUrlmsExchUserHoldPoliciesmsOrg-IsOrganizationalmsRTCSIP-ApplicationOptionsmsRTCSIP-DeploymentLocatormsRTCSIP-LinemsRTCSIP-OptionFlagsmsRTCSIP-OwnerUrnmsRTCSIP-PrimaryUserAddressmsRTCSIP-UserEnabledoOFReplyToOriginatorobjectSidonPremisesUserPrincipalNameotherFacsimileTelephoneNumberotherHomePhoneotherIpPhoneotherMobileotherPagerotherTelephonepagerphysicalDeliveryOfficeNamepostOfficeBoxpostalAddresspostalCodepreferredLanguageproxyAddressespublicDelegatespwdLastSetregisteredOwnerReferencereportToOriginatorreportToOwnersecurityEnabledsnsourceAnchorststreetAddresstargetAddresstelephoneAssistanttelephoneNumberthumbnailPhototitleunauthOrigurlusageLocationuserCertificateuserPrincipalNameuserSMIMECertificatewWWHomePage 上記のリストで黄色くマークした属性があります。ExtensionAttribute1 ~ 15 です。 この属性、オンプレミスのActive Directory上には存在していません。では、何のために使うのかというと、上記のリストに含まれていない属性を複製したいときに使用します。 例えば、accountExpires 属性と pwsLastSet 属性を同期したい場合には、Azure AD Connect の構成ウィザードで、以下のように設定します。 構成が完了し同期が行われると、Azure AD に上記の属性が同期されています。 データを参照するには、Azure AD の GraphAPI を使用します。が、そのためだけにプログラムを組む必要はありません。Graph Explorer という便利なツールがありますので、これを使わせてもらいましょう。以下のURLにアクセスして、ご自身のテナントのIDでサインインしてください。 https://graphexplorer.cloudapp.net/ サインインが完了したら、画面右側の「JSON]をクリックして、GET フィールドに以下のように入力してみてください。 https://graph.windows.net/pharaojp.com/users/ これによりユーザーの一覧が戻されます。 「+」をクリックすると、ユーザーの情報が属性とともに表示されます。一番下の行に追加した属性が表示されていることがわかります。 { "odata.type": "Microsoft.DirectoryServices.User", "objectType": "User", "objectId": "", "deletionTimestamp": null, "accountEnabled": true, "assignedLicenses": […


Microsoft Passport とは ?

既に、本社の Active Directory チームにより以下の投稿がBLOGに掲載されていますのでご存知の方も多いかと思います。 Microsoft Passport and Azure AD: Eliminating passwords one device at a time!http://blogs.technet.com/b/ad/archive/2015/07/21/microsoft-passport-and-azure-ad-eliminating-passwords-one-device-at-a-time.aspx Windows 10 には Microsoft Passport という機能が実装されました。この機能により、サーバーに保存されたパスワードを使わずに、ローカルコンピューターに保存された(ローカルでしか使えない)「PIN」を使用して認証することができるようになりました。この機能は、Microsoft Account や Azure Active Directory で認証するときに加え、現在Preview提供中のWindows Server 2016で構築された Active Directory ドメインにサインインするときにも使用することができます。 この Windows 10 に実装された Microsoft Passport の仕組みは、FIDO(Fast IDentity Online, フィドー)アライアンスが策定中の FIDO 2.0 にもサブミットされ、仕様への組み込みに向けて検討されています。 Passport がパスワードと比べて何が安全かといえば、PINとデバイスの組み合わせによって認証できるため、例えば海外の得体の知らない第三者にパスワードがバレてのっとられる危険性を軽減することができます。つまりスマートカードを使用した認証同様の効果を、より安価なコストで実現することができるようになるわけです。もちろん、複雑で類推しずらいパスワードを定期的に変更している方にとっては「なんと生ぬるい!」ものに見えるかもしれませんが、不正侵入の70%近くがセキュリティパッチの適用不足と安直なパスワードが原因になっているという現状を鑑みれば、こうした方向性はむしろ歓迎すべきものであると言えます。これまでもISVによる個別ソリューションは多々存在していましたが、それらの混在による不整合がもたらす運用面や安全面のデメリットも、FIDO という有力ベンダー共同体が醸し出すある種の権威と統一化されたプロトコルによって解消されるわけですね。 ではここで、Microsoft Passport とはどんなものなのか、具体的に見ていきたいと思います。 Microsoft Passport は…

1

自己署名証明書を使用している AD FS + Azure AD のハイブリッド環境に Windows 10 を参加させるには

既に多くの方がご存知かと思いますが、Windows 10 Pro/Enterprise/Education は、従来の Active Directory ドメインの代わりに、マイクロソフトの IDaaS である Azure Active Directory に参加することができます。これにより、これまで Active Directory ドメインを使用していなかった企業や大学が、”無理に” Active Directory ドメインコントローラーを設置することなく、クラウドを使用してユーザーやクライアントにガバナンスを効かせることができるようになります。 誤解されている方もいらっしゃるかもしれないので念のために書いておくと、オンプレミス Active Directory とAzure Active Directory の両方に参加することはできません。これについては、別の記事で詳しく書きたいと思います。 さて、Azure AD に参加できるという話を聞くと、まずは「ちょっと試してみようか」と思うのが人情です。 方法は簡単です。 Windows 10 をインストールすると、以下のような画面が出てきます。 ここで、「Azure AD に参加する」を選択して「続行」すればサインイン画面が表示されるので、Azure AD に登録されているユーザーとパスワードを指定すれば OK です。 もちろん、オンプレミス AD とのハイブリッド Active Directory(アイデンティティ フェデーレション)を構成している場合でも、問題なく参加することができます。Windows 10 がファイアウォールの外にいても、Web Application Proxy (AD FS Proxy)を構成していれば、以下のように認証要求が社内に転送されるので大丈夫です。 ただし、1点注意があります。AD FSの構成に自己署名証明書を使用している場合、以下のようなエラーが表示されてしまいます。…

1