ラベル Internet Week の投稿を表示しています。 すべての投稿を表示
ラベル Internet Week の投稿を表示しています。 すべての投稿を表示

2017年1月4日水曜日

[Internet Weekフォローアップ]デモ環境の作り方⑥

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

引き続きInternet Weekのフォローアップです。いよいよ最終回です。

利用部門で勝手に構築したOpenAMを完全に撤廃して、情シス管理のAzure Active Directory(Azure AD)にすべてをゆだねます。


すでに前回、G SuiteへのID管理(プロビジョニング)はAzure ADで実施する様に構成し、シングルサインオンについても経過期間ということでOpenAMと連携する様に設定を行いました。

今回はG SuiteとOpenAMの連携を解除し、Azure ADと直接連携することでOpenAMを使わないようにします。

では、早速初めて行きます。

<Step 3>

◆G SuiteとAzure ADのシングルサインオン設定をSAMLベースへ変更する

前回は、既存のOpenAMを活用するためにAzure AD上に登録したG Suiteのシングルサインオン設定に「リンクされたサインオン」を選択しましたが、今回からはG SuiteとAzure ADを直接連携させるため、ここの設定を「SAMLベースのサインオン」へ変更します。


SAMLを使って連携する属性を編集します。
今回、メールアドレス属性にGoogleで使うログインIDが入っていますので、ユーザ識別子として「user.mail」を指定します。


また、デフォルトでgivenNameやsurNameなどがAttributeStatementに含まれるように構成されますが、日本語の値が入っているとGoogle側でエラーになるので、不要な属性は削除しておきます。

この辺りは以前紹介した注意事項を参照してください。




次にSAMLアサーションに署名するための証明書を作成します。


注意)ここで証明書をダウンロードしてG Suiteへアップロードするのですが、現在新ポータルでダウンロードした証明書をアップロードするとG Suiteがエラーを出しますので、ここだけクラシックポータルへアクセスして証明書をダウンロードしてください。

G Suiteの出すエラー

クラシックポータルでの証明書ダウンロード

後は、G Suiteへ設定するAzure AD側のエンドポイント情報を確認します。
Google Appsの構成メニューを選択すると右側に設定すべきエンドポイントの情報が出てきますので、これをコピーしておきます。



◆G Suite側の設定を更新する

ここまでくればあとは、G Suite側へ設定を入れるだけです。
先ほどメモしたログインページのURL、ログアウトページのURL、パスワード変更URLを入力し、証明書をアップロードします。



尚、この設定を行っている間(Azure ADで設定変更~保存、G Suite側の保存)はシングルサインオン設定がAzure ADとG Suite側でズレているので利用者へ影響が出ますので、事前にアナウンスをしてから実施する様にしましょう。


◆動作確認を行う

これで、設定は完了です。
後は動作確認をしてみます。

ドメイン参加したPCでアクセスパネル(https://myapps.microsoft.com)へアクセスします。
Azure ADと連携されたドメインに参加しているので、Desktop SSOが有効なのでAzure ADのログイン画面が表示されることなくパネルへアクセスできます。


ここでGoogle Appsをクリックし開くとシングルサインオンされます。この際、前回までの構成だと一旦OpenAMへアクセスしていましたが、今回からは直接Azure ADと連携しているのでOpenAMを経由することなくG Suiteへアクセスしていることがわかります。

※もちろん、アクセスパネルを経由せずに直接G SuiteへアクセスしてもDesktop SSOが実行されるので、ユーザは何も意識することはありません。



後は、OpenAMを停止するだけです。
ようやく利用部門が抱えていた認証基盤およびアプリケーションの管理がすべて情報システム部門へ移管されました。

めでたし、めでたし。

◆最後に

今回、Internet Week向けのデモということであまり情シス目線だけに閉じたものはやめておこうというコンセプトで今回のコンテンツを作成しました。
また、オーディエンスが技術者の方が中心ということもあり、家に帰ってすぐに試せるもの、というのも大きなテーマでしたので、あえてOpenAMを引っ張り出してきました。


なかなか実世界では考えにくいシナリオだったかもしれませんが、技術要素としてのSAMLやKerberosを使ったDesktop SSOなどは覚えておいても損はありませんので、少しでもエッセンスが伝われば幸いです。






2016年12月26日月曜日

[Internet Weekフォローアップ]デモ環境の作り方⑤

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

引き続きInternet Weekのフォローアップです。ようやく残り2回です。

いよいよStep 2の情シスとの連携開始です。


前回まではあくまで利用部門で野良ITとしてG SuiteとOpenAMを構成し、利用者が社内ADのアカウントでシングルサインオン出来るようにしてきました。

今回は情報システム部門が重い腰をようやく上げ、Azure Active Directory(Azure AD)を契約し、これまで利用部門が独自で管理していたG SuiteのID管理やSSOを順番に巻き取っていきます。



では、早速始めていきましょう。

<Step 2>


◆Azure AD上にG Suiteを登録する

何はともあれ、情報システム部門がG Suiteを巻き取るにはAzure ADを使ってG Suiteを管理する必要があります。

そのためにはAzure AD上のエンタープライズアプリケーションとしてG Suiteを登録する必要があります。

AzureポータルよりActive Directoryを開き、エンタープライズアプリケーションの追加を選択するとギャラリーが開くので、Google Appsを選択して[作成]をクリックします。



◆既存OpenAMと連携したシングルサインオン設定を行う

最終的にはAzure ADを使ってシングルサインオンも行うように構成しますが、現在はOpenAMが存在しますので、十分なテストが完了するまでは、引き続きOpenAMを使っておきたいところです。

ただ、情シスが管轄している他のアプリケーションと同列で管理をしていきたいので、Azure ADでG Suite自体の管理を行うために既存OpenAMと連携する形でシングルサインオン設定を行っておきます。

クリックスタートより[シングルサインオンを構成する]を開きます。


シングルサインオンのモードとして、

  • Azure ADシングルサインオンが無効
  • SAMLベースのサインオン
  • パスワードベースのサインオン
  • リンクされたサインオン

がありますので、[リンクされたサインオン]を選択します。


サインオンURLにG SuiteのURLを入れることで既存でG Suiteに設定されているシングルサインオン(OpenAM)をそのまま使い続ける形でAzure ADと連携を行うことが出来ます。


取り敢えずこれでシングルサインオン設定は完了です。


◆ID管理(プロビジョニング)をAzure ADから行うように設定する

次はプロビジョニングです。これまで利用部門が手動でG Suite上のIDの作成、削除をしてきましたが、この部分をAzure ADから自動的に行います。(もちろんAzure ADは社内のADとAzure AD Connectを経由して同期されているので、社内ADのIDの作成・更新・削除がそのままAzure ADを経由してG Suiteまで反映されるようになります)

この部分が利用部門の一番の負荷となっていた部分なので、これをやるだけでも相当大きなメリットがあります。

まず、Azure AD上の対象となるユーザに対してG Suiteを割り当てる必要があります。
Azure AD Premiumのライセンスがあるとグループベースでの割り当てが出来るのですが、今回用意したテナントは無償版なので、個別にユーザを割り当てる必要があります。

具体的には[ユーザとグループにシングルサインオンをデプロイする]というよくわからないメニューで割り当てを行います。




対象のユーザを選択します。


次に、G Suiteに対するプロビジョニングを有効にします。

まず、G Suite側でAPI管理を有効にしておきます。この設定を行うことでDirectory APIなどを使ってG Suite上のユーザやグループを外部から操作することが可能になります。


ここまでできたらAzure ADにG Suiteに対するプロビジョニング設定です。
今回行いたいのは、
・プロビジョニングの実行(作成・更新・削除)
・プロビジョニング属性のカスタムマッピング
です。

特に今回はAzure ADのドメイン名とG Suiteのドメイン名が異なっているので、デフォルトのマッピングだとAzure ADのuserPrincipalNameとG SuiteのLoginIDがアンマッチとなり正常にプロビジョニングされません。

そこで、社内のADのmail属性にG Suiteで使うメールアドレスをセットし、その値をAzure AD経由でG SuiteのLoginIDとマッピングすることで連携を行います。

まずは、プロビジョニングの有効化です。
これまたわかりにくいメニュー名[Google Appsでテストユーザを作成する]を開いてプロビジョニングモードを[自動]に設定します。

ここでG Suiteとの連携を行うためにAzure ADに対して管理権限を委譲します。


ここで[承認する]をクリックするとポップアップでG Suiteに対する管理権限の委譲に同意を求められるので、同意します。(G Suiteの管理権限を持つユーザでログインをします)


これで一旦保存をすると属性のマッピングを変更できるようになります。

ユーザの属性マッピングを開き、userPrincipalNameをLoginIDにマッピングしている行を選択して、ソース属性をuserPrincipalNameからmail属性に変更し保存をします。


尚、新ポータルでマッピングを変更しようとするとエラーが起きることがあります。その場合はクラシックポータルを使ってマッピングを変更してください。


これで設定は完了です。


◆プロビジョニングを実行する

プロビジョニングを[オン]にしてG Suiteへプロビジョニングを実行します。
少し時間がかかるので、ゆっくり待ちましょう。


上手くいくとG Suite上にユーザが新規に作成されます。
尚、一度もログインしたことのない新規ユーザは[停止中のユーザ]として作成され、初回ログインを行うとアクティブに変更されます。



これでID管理とシングルサインオンの両方がそろったことになりますので、テストをしてみます。

◆Azure ADを経由してアクセスしてみる

Azure ADにG Suiteを登録したとはいえ、実際にシングルサインオンを行うのはOpenAMです。しかし、Azure ADに登録したことにより、Azure ADに登録された他のアプリケーションと同列でアプリケーションへのアクセスを管理することが可能になります。

具体的には利用者からアクセスできるアクセスパネル(https://myapps.microsoft.com)から利用可能なアプリケーションとして参照・アクセスすることが可能になります。



情シスが管理している他のアプリへのシングルサインオンは当然可能です。



同じようにG Suiteへアクセスすると一瞬OpenAMへアクセスしますが、Desktop SSOが有効なのでそのままシングルサインオンされ、シームレスにログインすることが可能です。



もちろんこれまで通り、G Suiteへ直接アクセスした場合はOpenAMでシングルサインオンされますので、利用者から見た使い勝手は全く変化ありませんが、これでID管理の統合、およびほかのアプリケーションとのシングルサインオンなど、少し幅が広がりました。


次回は野良ITだったOpenAMをいよいよ撤廃してAzure ADへ一本化していきますが、利用者がほぼ気が付かない状態で移行していくのが大きなポイントとなります。

2016年12月20日火曜日

[Internet Weekフォローアップ]デモ環境の作り方④

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

前回に引き続きInternet Weekのフォローアップです。

今回はユーザにとっての利便性をあげるため、PCへのログインとOpenAMのログインをシングルサインオンする「Desktop SSO」の構成を行います。このことにより、OpenAMと連携されているG SuiteへもOpenAMのログイン画面を見ることなくアクセスをすることが可能になります。



◆デスクトップSSOを有効にする

最終的に情シスの管理するAzure ADへG Suiteとの連携・管理を移管していくことを考えると、利用者に対してOpenAMの存在が見えてしまうは得策ではありません。

ここは少しだけ情シスの人にも協力してもらって、統合Windows認証を有効にしてPCへのログインとOpenAMへのログインをシングルサインオン出来るように構成してみます。

この情シスの人への「少しだけ」のお願い事項は以下の2点です。
1.ドメインコントローラでktpassコマンドを実行してキータブファイルを作成してもらう
2.(オプション)パスワードが無期限のサービスアカウントを作成してもらう

※2番目についてはOpenAMがADへ問い合わせをするためのユーザのパスワードを無期限にしてもらった方が後々面倒が少ないから、という理由うなのでどちらでも構いません。

いずれにしてもドメイン管理者権限など情シスの人が嫌がりそうな手間は取らせません。

早速やってみましょう。

・キータブファイルを作成してもらう
以下のコマンドをドメインコントローラで実行してもらいます。

ktpass -out [ファイル名] -princ HTTP/[OpenAMサーバのFQDN]@[ADのドメイン名] -ptype KRB5_NT_PRINCIPAL -pass [OpenAM用ユーザのパスワード] -mapuser [OpenAM用ユーザ名] -target [ドメインコントローラのコンピュータ名]

例えば、以下のようなコマンドです。
ktpass -out desktopsso -princ HTTP/openam.adfs20.net@EIDENTITY.ADFS20.NET -ptype KRB5_NT_PRINCIPAL -pass P@ssw0rd -mapuser openam -target dc



結果、出来上がるファイル(例では、desktopsso)を入手してください。
このファイルをOpenAMがアクセスできる場所へ配置し、tomcatユーザで読み込めるように権限を設定します。

以下の例では、/usr/share/tomcat/openam/openam/へコピーし、chown tomcat:tomcat ./desktopssoでオーナーをtomcatユーザへ変更しています。




・認証モジュールを追加する
第1回で実施したのと同様に認証モジュールを追加します。

前回はTypeにActive Directoryを選びましたが、今回は[WindowsデスクトップSSO]を選択します。



各種設定項目には先ほどktpassコマンドで指定した項目をセットします。


先のコマンド例に従うと以下の表のような設定となります。

設定項目設定値
サービス主体HTTP/openam.adfs20.net@EIDENTITY.ADFS20.NET
Keytab ファイル名/usr/share/tomcat/openam/openam/desktopsso
Kerberos レルムEIDENTITY.ADFS20.NET
Kerberos サーバー名dc.eidentity.adfs20.net



ここまでで認証モジュールの設定は完了です。


・認証チェインの設定を行う
これも第1回で設定したのとほぼ同じ手順です。
新しく認証モジュールを設定したので、このモジュールを使って認証を行うように認証チェインの設定を行います。

新規に認証チェインを作成し、任意の名前を付けます。



認証モジュールに先に作成したデスクトップSSOのモジュールを、クライテリアには[Sufficient]を設定します。



こんな設定になるはずです。



後は、一般ユーザを認証するときにこのチェインを使うように設定するだけです。
Authentication Sttings -> Coreより組織認証設定(一般ユーザ向けの認証設定)に先ほど作成した認証チェインを指定します。


これでOpenAM側の設定は完了です。
念のため以下のコマンドでtomcatを再起動しておきます。

/bin/systemctl restart  tomcat.service


・OpenAMのサーバをイントラネットゾーンへ入れる
後はクライアント側の設定です。
IEやEdge、Chromeを使っている場合はインターネット設定のゾーン設定でOpenAMサーバをイントラネットゾーンへ配置します。FireFoxの場合はFirefox自体の詳細設定でゾーン設定を行います。(この辺りは適当に検索して方法を探してください)

ただ、個々にブラウザへ設定するのは結構手間なので、もう一つだけ情シスの人にお願いが出来るならば、グループポリシーで一括設定をしてもらうのも手段の一つです。
その場合は、
 ユーザーの構成
  ポリシー
   管理用テンプレート
    Windowsコンポーネント
     Internet Explorer
      インターネットコントロールパネル
       セキュリティページ
の中の[サイトとゾーンの割り当て一覧]でOpenAMサーバを値[1]で登録してください。



上手くポリシーがあたっていれば、ブラウザのゾーン設定でOpenAMサーバが確認できます。


・テストする
上手く設定できているか確認するために、OpenAMのログイン画面へアクセスしてみます。
https://openamserver/openam/XUI/#login/&realm=AD

先ほどはログイン画面が表示されましたが、今回はいきなりプロファイルが表示されるはずです。




もし上手くいかない場合は、OpenAMのデバッグログを確認してみてください。
デフォルトでは以下のディレクトリにあります。
/usr/share/tomcat6/openam/openam/debug


これが上手くいけば、当然G Suiteへのログインも出来ますので、PCへログインしてそのままブラウザを開き、Gmailへアクセスしてみてください。

ID、パスワードを入力することなくログインできるはずです。




ここまでで、Step 1のフロント部門で勝手にOpenAMを構築してG Suiteと連携する、という姿を実現することが出来ました。

次回からはいよいよStep 2の情シスとの連携開始です。

2016年12月13日火曜日

Internet Weekの資料と動画を公開しました

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

遅くなりましたが、Internet Weekで使った資料を動画をアップロードしています。
(イベント直後にアップロードしてあったのですが、こちらに告知するのを忘れていました)


また、デモ環境の構築手順もまとめたので明日から順番に書いていこうと思います。


まずは資料です。



続いてデモの動画です。


内容は

  • OpenAMと社内ADをこっそり連携
  • OpenAMでデスクトップSSO
  • OpenAMとG Suite(Google Apps)を連携
  • OpenAMと連携したG SuiteをAzure ADと連携
  • G Suiteの連携を利用者に知られずにOpenAMからAzure ADへ切り替え

という内容です。

当日のデモとこの動画はOpenAM 12.0ベースで作っていますが、明日から公開する予定の環境構築手順はOpenAM 13.0ベースで作り直していますので、また参考にしてもらえればと思います。