2018年8月15日水曜日

サービス終了間際のAzure ACS無しでSharePoint ServerへAzure ADでログインする

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

前回も書きましたが今年の11月でAzure Access Control Service(ACS)のサービス提供が終了します。

Azure ACSを自前サービス用に使っているようなB2B/B2C向けサービスを提供している企業の方はある程度切り替えは終わっているとは思いますが、意外と見落としがちなのがオンプレミスでSharePointを構築して使っている企業の方々です。

現状、SharePointサーバは最新バージョンであるSharePoint Server 2016でさえClaimベース認証を構成しようとするとプロトコルとしてws-federation、トークンはSAML1.1しかサポートしていません。

この制限により、SAML2.0トークンしかサポートしていないAzure ADとSharePoint Serverの間で直接のフェデレーションを構成することが出来ませんでした。

このことを解決するために、これまではAD FSやAzure ACSなど割と柔軟にws-federationの構成が出来る製品やサービスを間に噛ませてシングルサインオンを実現していました

こんな構成です。



が、いよいよAzure ACSのサービス提供が終了、ということでそろそろ対策を行わないと手遅れになってしまいます。
となると、引き続きAD FSを使う、というのも一つの手段ではありますが、今更オンプレミスにサーバを配置して管理するのも面倒なので、出来ることならSharePointとAzure ADを直接接続しておきたいところです。

と、言うことで今回はAzure ADにSAML1.1のトークンを発行させることでSharePoint Serverと直接接続するための方法を解説します。
尚、この手法は特に裏技というわけではなく、オフィシャルに(ひっそりと)公開されている手順です。
Using Azure AD for SharePoint Server Authentication
https://docs.microsoft.com/en-us/Office365/Enterprise/using-azure-ad-for-sharepoint-server-authentication

簡単に言うと、Azure ADのトークン発行ポリシーをカスタマイズしてSAML1.1のトークンを発行させることによって、SharePoint Serverが解釈できるようにしてやろう、という作戦です。

以下の順に構成を行います。

  • Azure ADのエンタープライズ・アプリケーションにSharePoint Server接続用のアプリケーションを登録する
    • SharePointのEntityID、Reply URLを登録する
    • トークン署名用の証明書を生成し、公開鍵をダウンロードする
    • ユーザの割り当てを行う
  • 作成したAzure AD上のアプリケーション(ServicePrincipal)にリンクされたトークン発行ポリシーを変更する
    • SAML1.1トークンを発行するカスタム・ポリシーを作成する
    • 元々ServicePrincipalにリンクされているSAML2.0トークン発行のポリシーとのリンクを解除する
    • 新規作成したカスタム・ポリシーをServicePrincipalにリンクする
  • SharePoint Serverの信頼済みアイデンティティ・トークン発行者としてAzure ADを構成する
    • Azure ADからダウンロードした公開鍵を登録する
    • クレームマッピング、識別用属性を指定し、アイデンティティ・トークン発行者登録を行う
  • SharePoint Serverのユーザ・ポリシーを構成する
    • サイトへのAzure AD上のユーザへのアクセス権限を設定する


◆まずはありのままを

はじめる前に、まずは何もしない素の状態のAzure ADのws-federationでSharePoint Serverと接続するとどうなるのか?について確認しておきたいと思います。
要はSAML2.0のトークンをSharePoint Serverが受け取ったらどういう挙動をするか?の確認です。
(上記の手順のトークン発行ポリシーの変更をしないとどうなるか?という話しです)

結果、ID4014エラーが出てSAML2.0はサポートされていない、と言って怒られます。
※エラー内容がわかりやすくなるように、web.configのcustomErrors modeをoffに設定しています。


では早速。

◆Azure ADのエンタープライズ・アプリケーションにSharePoint Serverを登録する

当然ギャラリーには無いアプリケーションなので、「ギャラリー以外のアプリケーション」を選択してアプリケーションを登録していきます。
つまり、この段階ではプロトコルもトークンもSAML2.0のアプリケーションとして登録します。


アプリケーションの作成が終わったら、シングルサインオン設定を行います。
必要な設定はSharePoint ServerのEntityIDとサインオンURLです。

  • EntityID
    • 任意の文字列(後でSharePoint Server側に登録するRealmの文字列と同一の文字列) ※通常は「urn:sharepoint:{サーバ名}」とか「http://{サーバ名}」を使うことが多いです。
  • サインインURL
    • https://{SharePointサーバ名}/_trust/default.aspx ※httpsが必要なので、先にSharePointのSSL化は済ませておくこと

こんな感じです。

次に、トークン署名用の証明書をダウンロードしておきます。

また、他にも後でAzure ADのサインインURLと作成したアプリケーションのオブジェクトIDが必要になるのでメモしておきましょう。
SSO URLはシングルサインオンの構成のページに表示されているものを使います。(実際はSAMLではなくws-federationを使うので、URLのパスはwsfedに変更する必要があります)

オブジェクトIDはプロパティのページにあります。


アプリケーションIDと間違えやすいの注意です。オブジェクトIDの方を使います。

また、同じページにユーザの割り当ての設定もあるので、Azure AD上のユーザでSharePointを利用するユーザの限定が必要なければ「割り当てが必要ですか?」は「いいえ」を設定しておきます。

◆SAML1.1トークン発行用のカスタム・ポリシーの作成とリンクを行う

この作業が一番のキモです。
PowerShellを使って構成することも可能ですが、結局はInvoke-RestMethodでGraph APIを叩いているだけなので、Azure AD Graph Explorer(https://graphexplorer.azurewebsites.net/)で直接実行した方が手っ取り早いと思います。(トラブルを避けるために、先のエンタープライズ・アプリケーションの登録に使ったグローバル管理者権限を持った組織アカウントでログインしてください。マイクロソフトアカウントは不可です)

実行するのは、以下のAPIです。

  • 現状のポリシーを確認する
    • メソッド:GET
    • リソース:https://graph.windows.net/myorganization/servicePrincipals/{先ほどメモしたエンタープライズ・アプリケーションのオブジェクトID}/policies
これで、現在アプリケーションにリンクされているトークン発行ポリシー(SAML2.0のトークンを発行するポリシー)のIDが取得できます。同時に複数のトークン発行ポリシーを一つのServicePrincipalにリンクすることは出来ないので、このポリシーとのリンクは削除してしまいます。(ポリシーそのものは他のアプリケーションで使っているので削除しない様に気を付けてください)

  • ポリシーとのリンクを削除する
    • メソッド:DELETE
    • リソース:https://graph.windows.net/myorganization/servicePrincipals/{先ほどメモしたエンタープライズ・アプリケーションのオブジェクトID}/$links/policies/{直前の手順で取得したリンクしているポリシーのオブジェクトID}
ちなみに、Graph Explorerを使うとDELETEなどHTTP 204 no contentsが返ってくるようなクエリはいつまでたっても結果が表示されずにプログレスバーがじりじりと動くだけですが、ちゃんと処理は実行されているので、遠慮なく止めてしまってOKです。

再度、リンクされているポリシーを確認するとnullが返ってくるのでトークン発行ポリシーとのリンクが解除されたことがわかります。

次は、いよいよカスタムポリシーを作成します。

  • SAML1.1トークン発行ポリシーを作成する
    • メソッド:POST
    • リソース:https://graph.windows.net/myorganization/policies/
    • ボディ:{"displayName":"SPSAML11","type":"TokenIssuancePolicy","definition":["{\"TokenIssuancePolicy\":{\"TokenResponseSigningPolicy\":\"TokenOnly\",\"SamlTokenVersion\":\"1.1\",\"SigningAlgorithm\":\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\",\"Version\":1}}"]}
作成が完了したら、作成したポリシーのオブジェクトIDを確認しておきます。

  • 作成したポリシーを確認する
    • メソッド:GET
    • リソース:https://graph.windows.net/myorganization/policies

ここで先ほど作ったカスタム・ポリシーのオブジェクトIDを取得しておき、エンタープライズ・アプリケーションとリンクします。

  • ポリシーのリンクを作成する
    • メソッド:POST
    • リソース:https://graph.windows.net/myorganization/servicePrincipals/{先ほど作成したエンタープライズ・アプリケーションのオブジェクトID}/$links/policies
    • ボディ:{"url":"https://graph.windows.net/myorganization/policies/{作成したカスタム・ポリシーのオブジェクトID}?api-version=1.6"}


このクエリも返事がない(no contents)のでポリシーのリンク状態を確認しておきます。


  • ポリシーのリンク状態を確認する
    • メソッド:GET
    • リソース:https://graph.windows.net/myorganization/servicePrincipals/{先ほど作成したエンタープライズ・アプリケーションのオブジェクトID}/policies


これでAzure AD側の準備は完了です。

◆SharePoint Serverに信頼済みアイデンティティ・トークン発行者を登録する

先ほどAzure AD上に登録したSharePoint ServerのEntityID、Azure ADのサインオンURL、ダウンロードした証明書を用意しておき、SharePoint管理シェル(PowerShell)を管理者権限で起動、以下のコマンドを実行します。

  • $realm : SharePoint ServerのEntityIDとしてAzure AD上に設定した文字列
  • $wsfedurl : Azure ADのサインオンURL。最後のsaml2をwsfedに変更する
  • $filepath : ダウンロードした証明書ファイルのパス


$realm = "urn:sharepoint:xxxx"
$wsfedurl="https://login.microsoftonline.com/{tenantid}/wsfed"
$filepath="C:\users\Administrator\desktop\sharepoint.cer"
$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2($filepath)
New-SPTrustedRootAuthority -Name "AzureAD" -Certificate $cert
$map = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" -IncomingClaimTypeDisplayName "name" -LocalClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"
$map2 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname" -IncomingClaimTypeDisplayName "GivenName" -SameAsIncoming
$map3 = New-SPClaimTypeMapping -IncomingClaimType "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname" -IncomingClaimTypeDisplayName "SurName" -SameAsIncoming
$ap = New-SPTrustedIdentityTokenIssuer -Name "AzureAD" -Description "SharePoint secured by Azure AD" -realm $realm -ImportTrustCertificate $cert -ClaimsMappings $map,$map2,$map3 -SignInUrl $wsfedurl -IdentifierClaim "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name"

これで信頼済みのアイデンティティ・トークン発行者の登録が完了しますので、SharePoint Serverの管理ページのWebアプリケーションの管理で認証プロバイダとして設定を行います。

対象のWebアプリケーションを選択して認証プロバイダの設定を開き、信頼済みアイデンティティ・トークン発行者の設定で先ほど作成したAzure ADを選択します。


これで、SharePoint ServerのSSO設定も完了です。

いよいよ最後です。

◆ユーザーポリシー(ユーザへの権限付与)を構成する

最後に信頼済みアイデンティティ・トークン発行者からわたってくるユーザがサイトへアクセスできるように権限を付与します。
この手順が抜けると認証は出来ても認可がされないのでログインすることが出来ません。

対象のWebアプリケーションを選択してユーザ・ポリシーを開きます。
ユーザの追加より、ピープル・ピッカーを開き、Azure ADのname(今回は識別子をname属性にしているので)を選択した状態で画面上部の検索窓にAzure AD上のユーザ名を入れて検索ボタンをクリックし、出てくるユーザを追加します。


これで全ての設定が完了です。
早速サイトへアクセスするとAzure ADへリダイレクトされ、認証が終わるとコンテンツが表示されるはずです。

SAML Tracerでトレースをしてみると、ちゃんとトークンのバージョンがSAML1.1になっていることがわかります。

<t:RequestSecurityTokenResponse xmlns:t="http://schemas.xmlsoap.org/ws/2005/02/trust">
    <t:Lifetime>
        <wsu:Created xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-08-12T13:00:58.881Z</wsu:Created>
        <wsu:Expires xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd">2018-08-12T14:00:58.881Z</wsu:Expires>
    </t:Lifetime>
    <wsp:AppliesTo xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy">
        <wsa:EndpointReference xmlns:wsa="http://www.w3.org/2005/08/addressing">
            <wsa:Address>urn:sharepoint:xxxxx</wsa:Address>
        </wsa:EndpointReference>
    </wsp:AppliesTo>
    <t:RequestedSecurityToken>
        <saml:Assertion MajorVersion="1"
                        MinorVersion="1"
                        AssertionID="_d9aa279a-50f5-4f42-a553-ea45faa33ce4"
                        Issuer="https://sts.windows.net/{tenant id}/"
                        IssueInstant="2018-08-12T13:05:58.881Z"
                        xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
                        >



いかがでしょうか?まだACSを使っている人は早めにAzure ADと直接フェデレーションする様に構成を変更しておきましょう。

2018年8月13日月曜日

サービス終了間際!Azure ACSの状況を確認する

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

数年前に一世を風靡したAzure ACS(Access Control Service)ですが、いよいよ11月でサービス提供が終了されます。

ということで過去に作ったACSネームスペースの整理を進めようと思います。

しかし、旧Azure Portalが既にアクセスできず、現在のAzure PortalからはACSのWeb管理コンソールへのリンクがどこにもない、そして作ったネームスペースの名前も忘れている、という状態で途方に暮れているのは私だけではないはずです。

そういう人のためのPowerShellのモジュールがこちらです。

Acs.Namespaces
https://www.powershellgallery.com/packages/Acs.Namespaces/1.0.2


これを使うと、過去に作成したネームスペースの一覧の参照や有効化・無効化・削除などが可能です。

早速使ってみましょう。
手順に従いモジュールのインストールをしたら、まずは「Connect-AcsAccount」でACSに接続します。
ACSのログイン画面がポップアップするのでMicrosoft Accountでログインします。

次に、Microsoft Accountが紐づいているサブスクリプションを「Get-AcsSubscription」取得します。ACSのネームスペースはサブスクリプションに紐づいているので、サブスクリプションIDを指定して検索する必要があるためです。

サブスクリプション一覧が取得できたら、「Get-AcsNamespace」ネームスペースの状態を確認してみます。パラメータには先ほど取得したサブスクリプションのIDを指定します。

こんな感じでネームスペースと管理URLが取得できます。

ちなみに、しばらく放置していたACSネームスペースは無効化されているので、StateがDisabledになっているものは再度有効化しないと管理コンソールへログインできません。
たしかこんな名前のネームスペースがあったはずだけどアクセスできなくなってる・・・という人は無効化されている可能性があるので、確認してみてください。

ネームスペースを有効化するには、「Enable-AcsNamespace」を使います。


これで管理URLへアクセスすると懐かしのACSの管理コンソールが使えます。


昔作ったリソースの移行忘れが無いようにしておきましょう。

特に久しぶりに触るSharePointの実験環境など、私も忘れていたモノがあったのでACSからAzure ADへの切り替えをしておこうと思います。(ちなみにAzure ADでSAML1.1のトークンが発行出来ない問題は密かに解決しているので、既にACSが無くても直接Azure ADでオンプレSharePointのClaim Based Authenticationは使えるようになっています。手順などはまた紹介します)







2018年7月6日金曜日

Active Directoryのパスワードに特定の文字の利用を禁止する

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

先日紹介したAzure ADの新機能「Azure AD Password Protection for Windows Server Active Directory」を使うとブラックリストに載っているパスワードを使うことを禁止することは出来る様になりますが、特定の文字だけを禁止することは今のところ出来なさそうです。

エンタープライズのレガシーなID管理のシナリオだと未だにCSV万能説な文化なので、パスワードに特定の文字を使えなくしたい、というニーズがそこそこあります。
例えば、「,」(カンマ)とか「”」(ダブルクォート)とか「’」(シングルクォート)とかですね。なぜなら、平文パスワードをCSVに載せてFTPで送りつける、ということをしようとすると、この辺りの記号が邪魔をするんですよね・・・。

この辺りに起因する不具合を防止するために、CTRL+ALT+DELを使ったパスワード変更をグループポリシーで禁止して、ID管理パッケージの持つパスワード管理画面からしかパスワードを変更させない様に構成、ID管理システムではパスワードに利用できない文字を定義する、というのが従来の王道パターンでした。

しかし、やはりWindowsの標準の仕組みでパスワード変更を許可したい、というニーズは根強く、各社パスワード・フック用のモジュールをリリースしていたり、という状況です。

当ブログでもほぼ10年前に紹介した「Active Directoryのパスワード変更をフックする」という記事へのアクセスが以外と息が長く、今でもアクセス数トップ3くらいには入っていたりして、何とかしてADのパスワードを引っこ抜いてやろう、という人々が数多く存在するんだな~(違)と感じている今日この頃です。


最近も某所でCSVにパスワードを出力したいからカンマを使えない様にしたい、と言う雑談をしていたりしたので、良し悪しはおいておいてちょっと書いてみました。

この辺りにおいてあります。
 https://github.com/fujie/pwdpol

Visual Studio 2017でC++のDLLを書く、というのも最近は中々無い経験なので新鮮な感じです。

ちゃちゃっと書いたので、エラーハンドリングやログ出力などもありませんし、Visual Studio 2017 on Windows 10 Proで作って、Windows Server 2012 R2で動作確認をしたので、VC++のランタイムのバージョンを合わせるのが面倒だったので、必要なDLL(msvcp140d.dll、vcruntime140d.dll、ucrtbased.dllの3つ)をC:\Windows\System32へコピーするとか強引なことをしてますが、皆さんはちゃんと必要なランタイムの再配布用パッケージをダウンロードして使ってください。

使い方は、ドメインコントローラ上で
・必要なDLLをC:\Windows\System32へ配置
・レジストリへの登録
・再起動
という3ステップですが、こちらは昔の記事と何も変わらないので、こちらをご参照ください。
https://idmlab.eidentity.jp/2018/06/azure-ad-ngad.html

こんなコードです。
<本体:pwdpol.cpp>

#include "stdafx.h"
#include <ntsecapi.h>
#include <regex>

#ifndef STATUS_SUCCESS
#define STATUS_SUCCESS ((NTSTATUS)0x00000000L)
#endif

using namespace std;

// initialize
BOOLEAN NTAPI InitializeChangeNotify(void) {
    return TRUE;
}

// evaluate filter
BOOLEAN NTAPI PasswordFilter(
    PUNICODE_STRING AccountName,
    PUNICODE_STRING FullName,
    PUNICODE_STRING Password,
    BOOLEAN SetOperation) {

    BOOLEAN ret;

    // filter in regular expression
    const wchar_t* pattern = LR"([\"\',])";

    // convert PUNICODE_STRING to wstring
    std::wstring pwd(Password->Buffer, Password->Length / sizeof(WCHAR));
    
    // search filtered charactors
    regex_search(pwd, wregex(pattern)) ? ret = FALSE : ret = TRUE;

    // clear buffer
    SecureZeroMemory((PVOID)pwd.c_str(), pwd.size());

    return ret;
}

// notify change
NTSTATUS NTAPI PasswordChangeNotify(
    PUNICODE_STRING UserName,
    ULONG RelativeId,
    PUNICODE_STRING NewPassword) {

    // nop
    return STATUS_SUCCESS;
}
<定義:pwdpol.def>

LIBRARY "pwdpol"
EXPORTS
    InitializeChangeNotify
    PasswordFilter
    PasswordChangeNotify


DLLの配置をして再起動すると上手くいけばポリシーが有効になります。
管理者がカンマを含むパスワードでリセットしようとしても

ユーザが自分でしようとしても、

ダメです。弾かれます。

これでパスワードをCSVに出力し放題です。何も気にすることはありません。どんどん出力してFTPでばらまきましょう。ファイルサーバにおいてCIFSで共有するのもいいアイデアです。

良い子はマネしちゃいけませんよ。



2018年7月2日月曜日

MVP Renewal 9th!!

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

昨年からMVPの更新サイクルが7月~に一本化されたので、9度目かつ9年半目というよくわからないことになっていますが、今年もEnterprise Mobilityです。

前回のポストを見ていると英語版Blogを頑張ります的な宣言をしていますが、全然できてないですね。その代わり5月~6月のEuropean Identity & Cloud ConferenceとIdentiverseでの登壇をしたので、まぁ良いかな。。。(昨晩、というか数時間前にIdentiverseから帰国したのでヘロヘロです・・・)

今年も色々と活動していきたいと思いますので、今後ともよろしくお願いいたします!


2018年6月16日土曜日

[Azure AD/パスワード保護] NGワードの登録、オンプレADへのポリシー適用

(6/20 更新:モジュールのダウンロードが復活したのでリンクを張りました)
こんにちは、富士榮です。

現状のAzure Active Directory(Azure AD)におけるクラウド・ユーザのパスワード・ポリシーは有効期限と期限切れ通知に関する設定の2点だけしかカスタマイズすることが出来ません。(しかも、Office365のポータルもしくはPowershellコマンドレットで変更するしか方法がありません)

基本的な考え方として、単純なパスワードや漏えいの恐れのあるパスワードや使いまわされているパスワードなどはAzure ADが自動的にブロックしてくれているので、オンプレミスのADに比べてかなり強力な保護が実装されており、そのまま任せておくのがベターというポリシーに基づいているものと思われます。

※Azure AD Connectで同期をしているユーザはオンプレミスのActive Directoryのパスワードポリシーに準拠しますので、グループポリシーで複雑性要件をカスタマイズすることが可能です。
※ちなみにAzure AD B2Cでは複雑性ポリシーなどをカスタマイズすることが可能です。

参考)Azure Active Directory のパスワード ポリシーと制限
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/concept-sspr-policy


しかし、一方でせっかくAzure ADが強力なパスワード保護機能を持っているので、この機能をオンプレミスにも適用したり、更にNGワードを追加したり(例えば会社名など組織内では一般的な用語など)することで全体としてパスワード保護を強化したくもなってきます。(オンプレとクラウドでポリシーがバラバラになることで利用者の混乱を招く可能性も大きいと思いますし)

今回Preview公開されたAzure ADのパスワード保護機能では、以下の機能が実装されています。

  • ロックアウトまでのログイン試行回数の設定
  • ロックアウトが自動的に解除されるまでの時間(秒数)
  • 利用できない文字列の設定
  • オンプレミスADへのポリシーの適用

(2018/06/16時点)
ちなみに昨晩まではオンプレミスADへのポリシー適用に使うためのエージェントモジュールのダウンロードが出来たんですが、本日はリンクが切れています。
おそらく何らかの不具合がありモジュールを引っ込めたと思うので、再公開を待ちましょう。

ということで、オンプレミスADへのポリシー適用については試せていませんので、他の機能を紹介していきます。
6/20更新)以下のページからダウンロードができるようになりました。
 https://www.microsoft.com/en-ie/download/details.aspx?id=57071
オンプレミスADへのポリシー統合に関するドキュメントも合わせて公開されています。
 https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad-on-premises

手順は確認したら別途紹介したいと思います。

◆パスワード保護設定

Azure PortalよりActive Directoryを開くと[Authentication Methods]というメニューが表示されていますので開くと、[Password Protection(Preview)]という設定項目が出てきます。


この画面で先に紹介したロックアウト関連、NGワード登録、オンプレADへの適用に関する設定を行います。
ちなみにオンプレADへの適用についてはAzure ADのライセンス適用状況によってはグレーアウトされます。(おそらくPremium P1かP2のどちらかが必要そう。確認中)
6/20)ドキュメントを見るとやはりAzure AD Premiumが必要とのことです。

◆ロックアウトポリシーを変更する

まずはロックアウトされるまでの認証失敗回数を変更してみます。初期値は10ですので、既に上記の画面ショットでは2回に変更してあります。
つまり、上記の画面の設定だと、2回パスワードを間違えると60秒間ロックされます。

というわけで2回間違えるとこんなメッセージが表示されます。




◆NGワードの登録

Custom banned password listという項目に最大1000個までNGワードを登録できます。
ちなみに、大文字・小文字の判別は無く、oと0、aと@などの代替文字の読み替えも自動的にやってくれます。


ちなみに今回は試しに「hogehage」というNGワードを登録しておき、「H0geh@ge」というパスワードを設定しようとすると以下のように弾かれました。

何度も使っている訳ではないので、メッセージは微妙ですが実際に設定が出来なくなりました。中々便利です。

後はオンプレADへこれらのポリシーを含むAzure ADのパスワード保護が適用できるとかなり便利になると思うので、ダウンロードが回復したら試してみようと思います。

2018年5月25日金曜日

[Azure AD B2C]VS Code Extensionでカスタムポリシーを簡単編集

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

de:codeのセッションの中で軽く紹介したんですが、資料にURLなど載せていなかったので紹介しておきます。

カスタムポリシーってポータルからダウンロードして、XMLファイルをゴリゴリ編集して再度アップロードして、、という作業を経て構成するので中々とっつきにくい、と思って敬遠している方へ朗報です。

Visual Studio Code用のAzure AD B2C用のExtension(ベータ版)が公開されています。

Azure AD B2C Tools
https://marketplace.visualstudio.com/items?itemName=AzureADB2CTools.aadb2c


主な機能と出来ることは以下の通りです。

  • カスタムポリシーエクスプローラー
    • ポリシー内の各エレメント一覧を参照、ジャンプ
  • アイテムの定義の参照
    • Shift+F12を押すことでアイテムの定義箇所へジャンプ
  • XMLエレメントの追加
    • ClaimとかTechnicalProfileなどのエレメントを追加
  • ヘルプと関連情報の表示
    • 関連するドキュメントの表示
  • XMLスキーマの簡易ヘルプ
    • XMLタグにマウスオーバーすると説明がポップアップ


こんな感じです。



かなり生産性が上がると思うので、カスタムポリシーを書く方は是非!

2018年5月18日金曜日

[Azure AD] Azure AD ConnectでPingFederateとのSSO構成が可能に!

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

ちょうど1年近く前に正式リリースされたAzure AD Web Application ProxyとPingIdentityのPingAccess連携の話に引き続き、今度はAzure AD Connectを経由したPingFederateの構成が発表されました。(現状Public Previewです)

 [Azure AD] PingAccess連携が正式リリース
 https://idmlab.eidentity.jp/2017/06/azure-ad-pingaccess.html

対応したのは最新バージョンのAzure AD Connect(1.1.819.0)からです。

Office365、Azure ADとのID連携先としてPingFederateは早い段階から認定されていましたが、より深くインテグレーションされてきました。

関連ドキュメントはこの辺りから。



簡単に言うと、自動的にやってくれることは、

  • PingFederate側に何を設定すれば良いかを教えてくれる(Azure ADのEntityIDとかエンドポイントのURIとか)
  • Azure AD側のFederationの構成してくれる

ということです。

今、手元にPingFederateの環境がないので、インストーラの途中までですが、こんな感じで設定を行います。

User sign-inの設定で「Federation with PingFederate」が選択できるようになっています。

連携するAzure ADのドメインを選択します。

Federationの設定を行うところでは、PingFederateに何を設定するかExportしてくれるのと、PingFederateのURLを指定します。

ちなみにExportした構成情報は結構丁寧にPingFederateに何を設定したらいいのか記載されています。


まぁ正直、手動で構成するのもそれほど手間ではないのですが、最初から選択肢として組み込まれてくるとグッときますね。
皆さんも自宅に転がっているPingFederateを使って是非試してみてください。

2018年5月12日土曜日

[FIDO]Firefox 60の正式版がリリースされたのでWebAuthnを試してみる

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

先月WebAuthnがW3Cの勧告候補になってブラウザ各社が対応を表明したり、Windows 10 April Update 2018からWindows HelloでFIDO2 Security Keyが使えるようになったり(まだTAPなど一部ユーザにしか提供されていませんが)と、にわかにFIDO周りがにぎやかになってきました。

ということでWebAuthnに対応したFirefox 60.0が正式にリリースされたので手元のYubikeyで試してみます。
左から、Security Key By Yubico、Yubikey 4、Yubikey NEOです。
なんだか増殖してます。
Yubikeyの各エディション毎の比較は以下のページから。
https://www.yubico.com/products/yubikey-hardware/compare-yubikeys/


まずは、Firefoxのバージョンを確認しましょう。


ちゃんと更新されてます。

次にWebAuthnがちゃんと有効になっているか確認します。about:configを開きwebauthn関係の設定を検索し、「security.webauth.webauthn」がTrueであることを確認します。

これも大丈夫です。


ということで、テストしてみます。
今回テストに使ったのは、
https://webauthn.io/
https://webauthn.bin.coffee/
の2つのサイトです。

まずはhttps://webauthn.io/です。

ユーザ名を入れて、Register a User/Credentialをクリックします。

セキュリティ・トークンを求められるので、Yubikeyを差し込んでタップします。

登録とログインが成功しました!
ちなみにFIDO2にも対応しているSecurity Key by Yubico(青い奴)とYubikey 4はうまく動きますが、一番古いYubikey NEOだとダメでした。


同じように、https://webauthn.bin.coffee/でも試してみます。

Create Credentialをクリックすると同じようにキーを求められるので、Yubikeyを差し込んでタップします。

こちらも無事に登録が出来ました。


あくまでテストツールでブラウザの対応を確認しただけなので、面白味には欠けますが、これで実際にWebAuthnに対応したWebアプリケーションを作る環境はそろったことになるので、パスワードレスのWebサイトが登場してくるのも近いかもしれません。楽しみですね。

2018年5月8日火曜日

[Azure AD] Build 2018( #msbuild )に合わせてAzure AD PIMとTerm of UseがGA

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

事前にアナウンスが合った通り、昨日より開催されているBuild 2018に合わせてAzure AD関係の以下の機能が一般リリース(GA)されました。


  • Privileged Identity Management(PIM)
  • Conditional Access - Term of Use(ToU)


公式Blogでのアナウンス
https://cloudblogs.microsoft.com/enterprisemobility/2018/04/17/password-less-sign-in-to-windows-10-azure-ad-using-fido2-is-coming-soon-plus-other-cool-news/
※主題はFIDO2の話ですが、しれっとBuildでGAされるよ!という話が書いてあります。


PIMはいわゆる特権管理ですね。Azure AD上の特権を承認を得て一時的に取得するための機能で、Azure AD Premium P2で使えます。


ToUは条件付きアクセスの条件の一つとして設定ができるもので、使用条件に同意をしないとアプリケーションを使わせない、というような条件を設定することが可能です。

こちらは以前、Azure AD B2Bのゲストユーザへの同意を求める、というシナリオで紹介しましたね。
https://idmlab.eidentity.jp/2017/12/azure-ad-b2bterms-of-use.html



他にもIdentity関連のセッションが色々と用意されているようなので、期間中に良い情報が出てくれば紹介したいと思います。

2018年5月7日月曜日

[Azure AD B2C]カスタムドメインのサポートがPublic Preview

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

Azure AD B2Cの各種エンドポイントってxxx.microsoftonline.comなので、Azure ADを使ってるってモロにわかってしまいます。

企業内で利用するシナリオだとそれほど問題にならないかも知れませんが、B2Cシナリオでは外部へのプロモーションに使ったりするので問題になることもしばしばあります。また、同様にB2Cシナリオではログイン画面のカスタマイズを行う前提になると思うので、ドメイン名の問題でJavaScriptを仕込めない、などの機能面での不具合も出てきます。

そこで、しばらく前からPrivate Previewが行われていたカスタムドメインよるJavaScriptのサポートがようやくPublic Previewとして公開されたので紹介します。
※JavaScriptサポートはまだみたいです。想定外の動きをすることもありますが問い合わせとかはしないようにしましょう。(5/21追記)

詳細ドキュメントはこちらです。
 https://docs.microsoft.com/en-us/azure/active-directory-b2c/b2clogin


尚、最初にお伝えしておきますが、本当に好きなドメイン名でログイン画面を構成することが出来るようになるわけではありません。microsoftonline.comの代わりにb2clogin.comという別のドメインが用意され、そのドメイン上のログイン画面ではJavaScriptが使える、というだけです。

カスタムドメインを使う時のURLのルールはこのように変わります。
<従来>
https://login.microsoftonline.com/{テナント名}.onmicrosoft.com
<カスタム>
https://{テナント名}.b2clogin.com/{テナント名}.onmicrosoft.com


では、早速試してみましょう。

◆カスタムUIの準備

まずはログイン画面をカスタマイズしてJavaScriptを仕込んでみます。
最初にHTMLを作成して、blobにアップします。

次に、カスタムポリシーで(もしくは管理画面から)、UI定義で作成したHTMLを使う様に設定します。


後は、サインインポリシーやアプリケーションの定義などは必要ですが、この辺りは割愛します。

◆まずは通常通り呼び出してみる

今回はASP.NET CoreのMVCアプリを作ってAzure AD B2Cを使って認証する様に構成します。
通常はこんな感じで認証の設定を入れるとノンコーディングでAzure AD B2Cを使って認証できるようになります。


アプリケーションを起動し、SignInをしてみるとAzure AD B2Cのログイン画面が表示されます。

ここで、先にアップロードしたHTMLに合った通り、ボタンを押すとAlertが出るはずなんですが、通常のドメインで構成されているのでボタンは全く反応しません。
(もちろんログインは出来ます)

◆カスタムドメインを使う

ようやくカスタムドメインの出番です。
先のアプリケーションのappsettings.jsonを開き、Instanceの行を直接編集します。
元はlogin.microsoftonline.com/tfpだった部分をxxx.b2clogin.comへ変えます。


これだけです。
早速実行してみると、先ほどと同じログイン画面は出ますが、ドメイン名がb2clogin.comになっており、JavaScriptが実行できるようになっています。



これで色々とカスタマイズは出来るようになるので、自由度は各段に増します。
(本当は独自ドメインが使えると良いんですが・・・)

ちょっと応用で、Puzzle CAPTHAのCAPYを組み込んでみました。
この辺りも全部JavaScriptが前提となるので、従来は実現できなかった構成です。



UIのカスタマイズを含む、IdentityExperienceFrameworkの使い方については今月22日~23日のde:codeでチョークトークで解説させていただく予定です。是非こちらもお越しください。(私の出番は23日の最終セッションです)

 AD20
 実践から学ぶ!SNS ID を企業認証基盤で活用するには?
 https://www.microsoft.com/ja-jp/events/decode/2018/sessions.aspx#AD20





2018年4月28日土曜日

Microsoft Authenticatorアプリが設定のバックアップ・リカバリをサポート、しかし・・・

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

みなさん、多要素認証してますか?
アイデンティティは不正利用されている、という前提で運用しないといけない世の中になってきているので、IDとパスワードが盗難されても不正にログインされない様に多要素認証を有効にするのは大人のマナーです。もしくは、少なくともログイン・アラート(知らないログインがあったら通知してくれる機能)が使える認証システムを使う、くらいはいしないとダメな世の中です。
そういえば昨年のde:codeでもこんな話をしてました。

結局、ID盗難って本人が気が付きにくいところが一番の問題なんですよね。


と、言うことでMicrosoftもAuthenticatorアプリをiOS/Android/Windows Mobile向けに提供しており、私もAzure ADアカウント、Microsoftアカウントに加えてGoogleやFacebook、Amazonなどのアカウントの多要素認証をこのアプリでやっています。

が、機種変更などでアプリを再インストールすることになると実は非常に面倒です。全ての多要素認証設定を再度1からやり直さないといけないので、このアプリがないとログインできないような状態になってしまっているサービスがあると詰みます。

そこで登場したのが、ずっとリクエストが上がっていた多要素認証設定のバックアップとリカバリ機能です。

公式Blogでのアナウンス
 Microsoft Authenticator Account Backup and Recovery: Coming soon to an iOS device near you!
 https://cloudblogs.microsoft.com/enterprisemobility/2018/04/24/microsoft-authenticator-account-backup-and-recovery-coming-soon-to-an-ios-device-near-you/


機能を有効化するためには以下の条件を満たす必要があります。
・iOS版であること(残念ながらまだAndroid版では使えません)
・Authenticatorアプリのバージョンが5.7.0以降であること
・Microsoftアカウント(個人アカウント)があること


早速使ってみましょう。
と、その前に本ポストのタイトルに書いた「しかし・・・」の部分が気になりますよね?そう、実は組織アカウント(Azure AD/Office365)の多要素認証はリカバリできないんです。結局は再度QRコードの読み込みから開始なので、管理者にリセットしてもらう必要があります。
また、多要素認証設定済みのMicrosoftアカウントで設定をバックアップすると、リカバリ時に当該のMicrosoftアカウントでログインを求められますが、当然そのMicrosoftアカウントの多要素認証は今からリカバリしたい設定の中に入っているので、アプリで多要素認証は出来ません。他の方法(メールとかSMSでの回復)を設定していないとこれも詰みます・・・


こんな罠だらけの新Authenticatorですが、Googleなどの他の多要素認証はちゃんとリカバリしてくれる(はず)なので一応便利です。(Googleしか試してないのでAmazonとかFacebookが大丈夫かどうかは知りません)


とは言え、気を取り直して試してみます。
アプリを起動して、設定メニューを開くと「バックアップ」という項目が増えています。

おもむろに自動バックアップをONにするとMicrosoftアカウントが求められます。
この画面だけを見るとバックアップはOneDriveとかに保存されるのかな?と思うんですが、アプリを英語モードで起動すると実はこの画面の前にiCloudに保存する、というメッセージが出てきます。
これを見るとバックアップはiCloudにされ、リカバリする時にMicrosoftアカウントで認証することで保険をかけてる、ということなんだと思います。

Microsoftアカウントを追加すると回復アカウントとして表示されます。

後は、おもむろにアプリを消して再インストールしてみます。
まっさらの状態で起動してくるので、「回復の開始」からリカバリをしてみます。

回復に使うMicrosoftアカウントを選択し、ログインしましょう。
ここではアプリ内ブラウザが前に設定した時のMicrosoftアカウントを覚えてくれていたので選択するところから始まっていますが、機種変更などの場合はアカウントを追加するところからスタートですね。
と、ここで先ほど書いた通りのハマりポイントその1です。
このMicrosoftアカウントに多要素認証の設定をしていたので、ログイン時に多要素認証を要求されます。
運良く、実験した時は別のデバイスで多要素認証する様に構成していたので、難を逃れました。


しかし、別のデバイスで認証する構成にしていたが故に不思議なことが起きてしまいます。発生した現象は後述するとして先に進めましょう。

アカウントの回復完了、と表示されるのですが「セキュリティ上の理由から、一部のアカウントで追加の検証が必要です」と出て、Azure ADのアカウントに!マークがついています。

これが先ほど書いた微妙な点です。
Azure AD/Office365のアカウント(組織アカウント)のリカバリは出来ないんです。
回復するには再度QRコードをスキャンする必要があるので、別の方法で何とかログインするか管理者に多要素認証設定をリセットしてもらうしかありません・・・

今回は管理者でリセットしました。Azure ADのポータルからMFA設定を開いてユーザを検索、Manage user settingsを開きます。

再度ユーザが多要素認証設定を設定する様に要求します。

これで再設定をすると一応リカバリされます。
ちゃんとAzure ADアプリへの多要素認証ログインもできました。もちろんGoogleについてはGoogle側で何のリカバリ処理も必要なく、ちゃんと多要素認証ログインできます。


ちょっとおかしなことになってますよね?
気が付いた方いますか?




そうです、リカバリした端末側の多要素認証設定に、リカバリに使ったMicrosoftアカウントのエントリが勝手にできています。
私は別の端末でこのMicrosoftアカウントの多要素認証をしていますので、2つの端末に同じMicrosoftアカウントの多要素認証エントリが存在している状態になります。

試しに、このMicrosoftアカウントでサービスにログインしてみます。

すると、なんと2つの端末に通知が来ます・・・


はい、バグだと思います。
(と思いましたが、Microsoftアカウントの場合は複数の端末で多要素認証をさせることができるので、こういう仕様なんだと思います)

ちなみに、どちらで承認してもちゃんとログインできます。

うーむ・・・



と、若干微妙な感じではありますが、少なくともGoogleの多要素認証はちゃんとリカバリできたので、楽にはなりました。
皆さんも使ってみましょう。