sidebarIdM実験室いろんなアイデンティティ管理系製品やサービスの実験の記録をしていきます。後は、関連するニュースなどを徒然と。ADでログインするこんにちは、富士榮です。Service(ACS)のサービス提供が終了します。ACSを自前サービス用に使っているようなB2B/B2C向けサービスを提供している企業の方はある程度切り替えは終わっているとは思いますが、意外と見落としがちなのがオンプレミスでSharePointを構築して使っている企業の方々です。2016でさえClaimベース認証を構成しようとするとプロトコルとしてws-federation、トークンはSAML1.1しかサポートしていません。Serverの間で直接のフェデレーションを構成することが出来ませんでした。ACSなど割と柔軟にws-federationの構成が出来る製品やサービスを間に噛ませてシングルサインオンを実現していましたこんな構成です。ACSのサービス提供が終了、ということでそろそろ対策を行わないと手遅れになってしまいます。ADを直接接続しておきたいところです。Serverと直接接続するための方法を解説します。この手法は特に裏技というわけではなく、オフィシャルに(ひっそりと)公開されている手順です。Serverが解釈できるようにしてやろう、という作戦です。以下の順に構成を行います。Serverと接続するとどうなるのか?について確認しておきたいと思います。Serverが受け取ったらどういう挙動をするか?の確認です。(上記の手順のトークン発行ポリシーの変更をしないとどうなるか?という話しです)結果、ID4014エラーが出てSAML2.0はサポートされていない、と言って怒られます。modeをoffに設定しています。Serverを登録する当然ギャラリーには無いアプリケーションなので、「ギャラリー以外のアプリケーション」を選択してアプリケーションを登録していきます。この段階ではプロトコルもトークンもSAML2.0のアプリケーションとして登録します。アプリケーションの作成が終わったら、シングルサインオン設定を行います。ServerのEntityIDとサインオンURLです。※通常は「urn:sharepoint:{サーバ名}」とか「http://{サーバ名}」を使うことが多いです。※httpsが必要なので、先にSharePointのSSL化は済ませておくことこんな感じです。次に、トークン署名用の証明書をダウンロードしておきます。ADのサインインURLと作成したアプリケーションのオブジェクトIDが必要になるのでメモしておきましょう。URLはシングルサインオンの構成のページに表示されているものを使います。(実際はSAMLではなくws-federationを使うので、URLのパスはwsfedに変更する必要があります)オブジェクトIDはプロパティのページにあります。アプリケーションIDと間違えやすいの注意です。オブジェクトIDの方を使います。AD上のユーザでSharePointを利用するユーザの限定が必要なければ「割り当てが必要ですか?」は「いいえ」を設定しておきます。◆SAML1.1トークン発行用のカスタム・ポリシーの作成とリンクを行うこの作業が一番のキモです。Explorer(https://graphexplorer.azurewebsites.net/)で直接実行した方が手っ取り早いと思います。(トラブルを避けるために、先のエンタープライズ・アプリケーションの登録に使ったグローバル管理者権限を持った組織アカウントでログインしてください。マイクロソフトアカウントは不可です)実行するのは、以下のAPIです。現状のポリシーを確認するメソッド:GETリソース:https://graph.windows.net/myorganization/servicePrincipals/{先ほどメモしたエンタープライズ・アプリケーションのオブジェクトID}/policiesこれで、現在アプリケーションにリンクされているトークン発行ポリシー(SAML2.0のトークンを発行するポリシー)のIDが取得できます。同時に複数のトークン発行ポリシーを一つのServicePrincipalにリンクすることは出来ないので、このポリシーとのリンクは削除してしまいます。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を取得しておき、エンタープライズ・アプリケーションとリンクします。contents)のでポリシーのリンク状態を確認しておきます。AD側の準備は完了です。ADのサインオンURL、ダウンロードした証明書を用意しておき、SharePoint管理シェル(PowerShell)を管理者権限で起動、以下のコマンドを実行します。ADのサインオンURL。Serverの管理ページのWebアプリケーションの管理で認証プロバイダとして設定を行います。ServerのSSO設定も完了です。◆ユーザーポリシー(ユーザへの権限付与)を構成する最後に信頼済みアイデンティティ・トークン発行者からわたってくるユーザがサイトへアクセスできるように権限を付与します。この手順が抜けると認証は出来ても認可がされないのでログインすることが出来ません。対象のWebアプリケーションを選択してユーザ・ポリシーを開きます。AD上のユーザ名を入れて検索ボタンをクリックし、出てくるユーザを追加します。これで全ての設定が完了です。ADへリダイレクトされ、認証が終わるとコンテンツが表示されるはずです。Tracerでトレースをしてみると、ちゃんとトークンのバージョンがSAML1.1になっていることがわかります。ADと直接フェデレーションする様に構成を変更しておきましょう。よりアクセス解析を行っています。品質向上のみを目的とし、個人の特定などを目的とはしておりません。中で公開されることはあります。問い合わせ不明点等は管理人までご連絡ください。本プライバシーポリシーは予告なく変更/削除することがあります。プライバシーに関するトラブルについては一切の責任を負いかねますのでご了承ください。