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を使って是非試してみてください。