Quantcast
Channel: ADFS | Always on the clock
Viewing all 66 articles
Browse latest View live

様々な証明書を利用したADFSによる多要素認証

$
0
0

皆さんこんにちは。国井です。

MSテクノロジーを利用して多要素認証と言えば、Azure MFAサービスを利用したモバイルアプリや電話を利用した多要素認証を思い浮かべる方も多いと思いますが、ADFSサーバー固有の多要素認証機能に証明書を利用した方法があります。多要素認証と言えば「面倒くさい」というイメージが強いですが、証明書を利用した方法であれば、証明書がインストールされているか、いないかを自動的にチェックするので、ユーザーさんに手間をかけさせずに多要素認証を実行できるメリットがあります。

ADFSサーバーを利用した証明書ベースの多要素認証というと、
Active Directory証明書サービスを利用して、
エンタープライズCAをインストールして、
自動的に証明書をインストールして、

という一連の作業手順が定型化しており、しかもそれが唯一の方法であると信じていました。

しかし先日、お客さんと証明書を利用した多要素認証の実装方法について話をしていて、エンタープライズCAを使わないで多要素認証を実装したいとの要望を受け、改めて確認してみることにしました。

結論から先に言えば、

エンタープライズCA以外の認証局から発行した証明書でも多要素認証の証明書として活用することはできます。

では、実装方法を確認してみましょう。
(2016年5月31日追記 – 結構色々と不備があったので、修正箇所は全部赤を入れておきました。)

前提条件

ADFSサーバーによる証明書ベースの多要素認証の実装方法については、
過去に「ADFSによる多要素認証の設定」という投稿で紹介していますので、ご覧ください。

証明書の用意

エンタープライズCAで発行される証明書以外の証明書であれば何でもいいのですが、
私の環境では、次のような証明書発行要求を作成して、スタンドアロンCAで証明書を発行することにしました。
(スタンドアロンCAの作成方法などは割愛します)
まずは、以下のファイルをメモ帳で作成し、

[NewRequest]
Subject=”E=hamada@xxxx.adfs.jp,CN=hamada,CN=Users,DC=example,DC=com”
KeyUsage=0xa0

Exportable=FALSE
KeyLength=2048
MachineKeySet=FALSE
SMIME=FALSE
[EnhancedKeyUsageExtension]
OID=1.3.6.1.5.5.7.3.2
[Extensions]
2.5.29.17=”{text}”
_continue_ = “upn=hamada@xxxx.adfs.jp”

(OIDはクライアント認証を目的とした証明書を発行しなさい、という意味です。
あ、あと大事なことですが、E=…にはメールアドレス、CN=…の欄は利用ユーザーのDN、upn=…にはユーザーのUPNを入れてください)
発行要求テキストファイルができたら、コマンドプロンプトで

certreq -new 発行要求テキストファイル名 発行要求ファイル名

で発行要求ファイルを作成して、

image

スタンドアロンCAのWebサイトから発行要求ファイルの内容をコピペして、発行を要求します。
スタンドアロンCAで発行を許可して、

image

発行した証明書をクライアントコンピューターからスタンドアロンCAのWebサイトにアクセスして、[保存された要求証明書] をクリックしてインストールします。

image

これで証明書のインストールができました。
インストールされた証明書はcertmgr.mscツールから確認できます。

image

認証局とADFSサーバーの連携設定

続いて、ADFSサーバーの多要素認証に利用可能な認証局の設定を行います。
最初に認証局のルート証明書を用意しておきましょう。
スタンドアロンCAの場合、CAのWebサイトから[CA証明書、証明書チェーン、またはCRLのダウンロード]からダウンロードできます。

image

ダウンロードした証明書はroot.cerという名前で保存しておきます。
保存したファイルはADFSサーバーにコピーし、コマンドプロンプトから次のコマンドを実行します。

certutil –enterprise –addsotre “NTAuth” root.cer

実行すると、ルート証明書がADFSサーバーの証明書ストア内にあるNTAuthストアに格納されます。

image

その他、ルート証明書の情報はADFSサーバーと証明書認証を利用するクライアントコンピューターの[信頼されたルート証明機関]に入れておくことも忘れないように。

これで準備は完了です。
Office365のポータルサイトにアクセスすると、シングルサインオンで自動的に多要素認証画面に推移し、

image

さらに、ポータルサイトへ自動的に画面が推移します。

image

この方法が活用すれば、ドメイン参加していないPCにも証明書を利用した多要素認証が実装できるので、デバイス認証の代わりとしても利用できますね。

お試しあれ。

 

■2016年5月31日追記
証明書認証に失敗する方はCRLの設定をチェックしてください。
証明書認証時にはクライアントがCRLのチェックをするため、CRLが公開されていなかったりすると認証に失敗します。ご注意を。


ADFSによるシングルサインオン環境でAzure RemoteAppを利用

$
0
0

皆さんこんにちは。国井です。

私はよくAzure ADのお話をするときに、Azure ADにID基盤を一元化することに関するメリットを強調するのですが、そのときに次のようなスライドをよく使います。

image

右側にAzure ADで認証することによってアクセスできる先が書いてあるのですが、このうち、社内ネイティブアプリの部分はAzure RemoteAppを使って、オンプレミスで動かしているアプリを切り出して認証もAzure ADを使ってみてはいかがでしょうか?という話をします。

では、ADFSサーバーを使ってシングルサインオン環境が構築されているところで、Azure RemoteAppを動かしたら、どんな動きになるのでしょうか?今日はAzure RemoteAppとADFSの組み合わせによる認証の動作について、紹介します。

クラウドサービスへのアクセスがブラウザーであれば、WS-Federationでいうところの「パッシブプロファイル」の仕様に従って動作するのですが、Azure RemoteAppクライアントはインストールして利用するリッチアプリケーションです。
そのため、ブラウザーからOffice 365にSSOするときみたいに、[ローカルイントラネット]ゾーンにフェデレーションサービス名を登録して、Windows統合認証を利用して、、みたいなことはできず、パスワード入力は必ず求められてしまいます。社内ネットワークからドメインに参加しているコンピューターからアクセスしたとしても例外なくパスワードを入力させられます。

Azure RemoteAppのSSO環境を導入してみようというモチベーションも下がったところで(笑)、実際の動きを見てみましょう。
まず、Azure RemoteApp用のWindows クライアントをインストール・起動し、以下の画面から[開始する]をクリックすると、

image

最初にサインイン画面が表示されます。
シングルサインオンのユーザー名を入力すると、

image

サインインページにリダイレクトされることがわかります。
(パケットキャプチャなどをしていると、外部からのアクセスはWebアプリケーションプロキシ、社内からのアクセスはADFSサーバーにリダイレクトされているようです。←ちょっと腑に落ちないポイントがあり、本当かな?と思っています。もし、間違っていたら、どなたかご指摘いただけると助かります)
パスワードを入力してサインインすると、

image

アクセスできます。

image

繰り返しますが、ブラウザーからOffice365のサイトにアクセスするとき、
社内からのアクセスであれば、パスワードを入力することなく、アクセスできたのに、
Azure RemoteAppクライアントでは社内からのアクセスであるにもかかわらず、パスワードの入力は求められます。

その他、多要素認証を使う人にとって気になるのがADAL対応ですが、
Azure RemoteAppクライアントはADAL対応になっています。そのため、Azure RemoteAppからでも多要素認証もちゃんと処理してくれます。

 

最後になりますが、どうしてもAzure RemoteAppでSSOがしたい!ということでしたら、HTML5クライアントを利用するのはひとつの解決策だと思います。HTML5クライアントはブラウザーアプリケーションですので、ブラウザーでOffice365にサインインするときと同じ動きになります。

AAD Connect のトラブルシューティング

$
0
0

皆さんこんにちは。国井です。

オンプレミスのActive DirectoryとAzure ADの間でID情報を同期するだけでなく、ADFSサーバーのインストールやSSO環境の構築など、何かと便利な機能を提供してくれるAzure Active Directory Connect (AAD Connect) ツール。だけど、事前準備が整っていないとAAD Connectはあっさりエラーを表示して私たちを切り捨ててくれます。。そんなときにエラーの原因から何が問題でどのような対処をすればよいか?私が見かけたパターンを公開します。

必須コンポーネントのインストールエラーが表示されるパターン

これは、見たまんまのエラーで、エラーメッセージに書いてあるフォルダー内のファイルを削除しましょう。
ちなみにこれが起こるのは、AAD Connectを複数回実行することが原因です。

image

Install ADFS Certificateエラーが表示されるパターン

これはわかりやすいエラーで、証明書の構成に問題があるパターンです。
用意すべき証明書がADFSサーバーで使用可能なSSL証明書ではない場合に表示されました。

image

Configure Web App Proxyエラーが表示されるパターン

結構よく見かけるような気がしますが、私が遭遇したパターンはADFSサーバーで使用するSSL証明書がオレオレ証明書という場合。この場合、Webアプリケーションプロキシの[信頼されたルート証明機関]にSSL証明書の情報(認証局の情報)が登録されていない場合に表示されました。
ADFSサーバーの[信頼されたルート証明機関]に登録されていなくても、ADFSサーバーのインストールエラーとはならないのに、Webアプリケーションプロキシのインストール(構成)時には、[信頼されたルート証明機関]が設定されていないと確実にエラーになります。

image

ちなみに、[信頼されたルート証明機関]にSSL証明書の情報が登録されていない場合は、手動でWebアプリケーションプロキシをインストールして、ADFSサーバーとの信頼関係を設定してもエラーになります。

image_thumb.png

Configure New ADFS Taskエラーが表示されるパターン

このパターンはADFSサーバーを過去にインストールしたことがあり、手動でADFSサーバーをアンインストールして、再度AAD Connectを実行すると表示されます。
原因はADFSサーバーをアンインストールしても、ADFSサーバーで使用するデータベースは削除されずに残っていることが原因で、新しいデータベースを作れないことにあります。
こういうときは、「ADFS3.0の再インストールするときの注意点」を参考にデータベースの手動削除を行いましょう。
(エラーメッセージを見ていると、他のエラーパターンでも表示されそうな気がするんですけどね)

image

Configure New ADFS Taskエラーが表示されるパターンPart2

このパターンも、メッセージは異なりますが、最初の「Configure New ADFS Task」エラーと同じです。対処方法は上記のとおり。

image

Configure New ADFS Taskエラーが表示されるパターンPart3

このパターンは、ADFSサーバーがリモートから追加された後、再起動が要求される場合に出るエラーです。
ADFSをインストールしたサーバーを一度再起動した後で、[再試行]をクリックしてあげると、エラーが解消されます。

image

Configure New ADFS Taskエラーが表示されるパターンPart4

これは、何が原因の時に表示されたか、忘れてしまいました。。ごめんなさい。

image

最後に

Azure AD Connectのエラーは多種多様です。
ここにあるエラー以外にも、単純にタイムアウトしただけ?というエラーもあり、
そうした原因の追及は、やっぱりログを見ることに尽きます。
エラー画面にログファイルへのリンクがついているので、クリックしてアクセスしてみましょう。
そうすれば、こんな感じでログファイルを参照できます。
ポイントは、ERRORというキーワードで検索すること。簡単でしょ?
(画像が小さいので、文字起こしすると
「AAD Failed. This may be due to replication delay.」とのことです。

image

えっ、タイムアウト?
と思ったら、Azure AD Connectを再実行してみましょう。
本当にタイムアウトだったら、2度目はうまく実行できるだろうし、
他に原因があれば、他のエラーを出してくれます。(←ちなみに私のケースはこっちのパターンでした)

■ ■ ■

誰かのトラブルシューティングに役立てばうれしいですし、
他にもこんなのがあったよ、とか教えていただけたら、もっとうれしいです。

ADFS × Azure 仮想マシンのプローブ設定

$
0
0

皆さんこんにちは。国井です。

ADFSサーバーをMicrosoft Azureの仮想マシンに実装し、運用するケースってよく見られる運用だと思います。そのとき、ロードバランサーを実装し、その配下にADFSサーバーを置くことになると、Azureのロードバランサーが死活状況を確認し、動作しているサーバーにパケットを振り分けるよう、プローブと呼ばれる設定を行います。

本来、プローブはWebサーバーの実際のコンテンツが保存されている場所(default.aspxみたいなWebページ)を指定しておき、そのページにアクセスできることを確認することで、「このサーバーは死んでないな。よしパケットを振り分けてあげよう!」ということをします。

では、ADFSサーバーがロードバランサーの配下にいる場合、どのページをプローブとして設定すればよいでしょうか?

方法はいろいろとあるのでしょうが、ADFSサーバーではプローブ用の専用ページを用意しています。そのため、プローブ用のページを指定してあげるのが吉ではないでしょうか。以下のページがプローブ用のページです。

http://<フェデレーションサービス名>/adfs/probe

ポイントはhttpsではなく、httpプロトコルを指定しているところ。これを踏まえてAzureのロードバランサーにプローブを設定してあげましょう。
Azureの新ポータルから設定するのであれば、こんな感じ。

image

負荷分散規則がhttpsでも全く関係なく、httpプロトコルのプローブは設定できます。

image

 

Azure仮想マシンをロードバランサーで負荷分散させ、ADFSのサービスを冗長化させたいときには、ぜひ試してみてください。

Office 365 ProPlusの先進認証

$
0
0

皆さんこんにちは。国井です。
先日、Microsoft MVPを受賞させていただきました。これで2006年から11年連続での受賞になります。本当に感謝の気持ちでいっぱいです。

さて、今日はお客様からのご質問をいただくことが多い、ADALを利用した先進認証(Modern Authentication)について、私のところで調べてみたことをまとめたいと思います。

ADALってなに?

Active Directory Authentication Libraryの略で、乱暴な言い方をするなら、ブラウザーでのADFSを利用した認証方法と同じ認証方法をネイティブアプリケーションでも利用できるようにするための機能、といったところです。
このあたりはMVPふじえさんのブログに関連情報が掲載されているので、合わせてごらんください。

Office2013 Windowsクライアントが多要素認証とSAML IdPサポート
http://idmlab.eidentity.jp/2014/11/office2013-windowssaml-idp.html

[Office Preview]Outlook等の多要素認証サポート
http://idmlab.eidentity.jp/2015/03/office-previewoutlook.html

先進認証(Modern Authentication)とは?

Office 365の公式ブログでも紹介しているように、Office 2013 (Office 365 ProPlus) では、これまでOfficeアプリケーションからOffice 365への認証にはMicrosoft Online Servicesサインインアシスタントを利用しており、ADFSサーバーを利用したシングルサインオン環境では、ブラウザーとは異なる認証プロセス(つまりWS-Fedのパッシブプロファイルではないってことです)になっていました。そのことが原因で、Officeアプリケーションで多要素認証が利用できない、といった問題がありました。だからこそ、Office 365(Azure AD)でOfficeアプリケーションを利用するときだけ多要素認証を使わなくてもよいようなパスワード=アプリケーションパスワードなんてものがあったわけです。

Office 2013とOffice 2016のでは新しく先進認証をサポートし、Officeアプリケーションからの認証でADFSサーバーが絡む場合でも、ブラウザーのときと同じようにアクセスできるというのです。

では、どのように実現するか、必要な要素と設定を見てみましょう。

Office 2016 での先進認証

最近はOffice 365 ProPlusもOffice 2016バージョンで提供されるので、最近Office365を導入された方はOffice2016を利用していることも多いと思います。
Office 2016ではデフォルトで先進認証を利用するため(MSさんのサイト「Office 2013 クライアント アプリと Office 2016 クライアント アプリでの先進認証のしくみ」で詳しく解説しています)、特別な設定は必要ありません。と言いたいのですが、Exchange OnlineとSkype for Business Onlineではデフォルトで無効になっているので、有効化操作が必要です。

Exchange Onlineでは、以下のWindows Powershell用Azure Active Directoryモジュールを起動し、以下のコマンドレットを実行します。

$UserCredential = Get-Credential
Connect-MsolService –Credential $UserCredential$UserCredential

$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://outlook.office365.com/powershell-liveid/ -Credential $UserCredential -Authentication Basic –AllowRedirection

Import-PSSession $Session
Set-OrganizationConfig -OAuth2ClientProfileEnabled:$true

これで出来上がり。
実際にOutlookを起動し、プロファイルを作成してみましょう。すると、見た目には何も変わらないように思えますが、

image

[次へ]をクリックすると、パスワード入力することなく終了します。そう、先進認証によってブラウザーによるシングルサインオンと同じ動きになり、パスワード入力が必要なくなっているのです。

image

ADFSサーバーのログを見ると、Outlookアプリケーションによるトークン発行時には、x-ms-endpoint-absolute-pathクレームに/adfs/services/trust/2005/usernamemixedではなく、ブラウザーアクセスの時と同じ/adfs/ls/wiaが割り当てられていることが分かります。
image

その他、タスクトレイのOutlookアイコンをCtrl+右クリックし、[接続状態]をクリックすると、[認証]欄に「べアラー」と表示されていることが分かります。べアラーとは、ベアラートークンのことです。
image

Office 2013 での先進認証

Office 2013 の場合、デフォルトで先進認証が利用できるわけではないので、先進認証を利用するために以下のレジストリ設定が必要です。(直近では、どのレジストリを必ず設定する必要があるのか、わかりませんが、少なくともEnableADALの設定は絶対必要です)

HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL (REG_DWORD) 値:1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version (REG_DWORD) 値:1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Debug\TCOTrace (REG_DWORD) 値:3

以上により、先進認証によりOffice 2016と同様にブラウザーと同じような認証ができるようになります。ここでは、Wordでのサインインで多要素認証が利用できる様子を確認しておきましょう。ドメイン参加しているコンピューターでWordを起動すると、最初からユーザー名がOfficeアプリケーションに関連付けられるため、サインインで明示的にユーザー名を指定する必要はありません。しかし、ADFSサーバー(またはAzure AD)側で多要素認証が有効になっていると、ご覧のようにサインインエラーになります。

image

そこで、ファイルメニューから[アカウント]をクリックして、サインアウト→サインインの順でユーザー名を指定すると、

image

パスワード入力の画面は表示されずに多要素認証の実行が始まります。

ADAL1ADAL3

多要素認証が完了すると、Wordが使えるようになりました。

■ ■ ■

最後になりますが、このあたりの検証を行うときは、イベントビューアでログを追いかけながら見ていくと、いつの時点でADFSサーバーでのトークン発行が行われたか?それが先進認証で行われているか?などを追跡できますし、この操作方法を覚えておくとトラブルシューティングなどにも活用できるようになります。

具体的なトラブルシューティング手法については、私が開催している「Office365とクラウドサービスの認証ベストプラクティスコース」でも実践していただくことができますので、ご興味がありましたら、ご参加いただければ幸いです。

 

■そのほか参考情報
Office 2013 modern authentication public preview announced
https://blogs.office.com/2015/03/23/office-2013-modern-authentication-public-preview-announced/

Office 2013 updated authentication enabling Multi-Factor Authentication and SAML identity providers
https://blogs.office.com/2014/11/12/office-2013-updated-authentication-enabling-multi-factor-authentication-saml-identity-providers/

AD FS を運用している組織の Office 2013 モダン認証によるサインイン問題のトラブルシューティング
https://support.microsoft.com/ja-jp/kb/3052203#bookmark-_issue2

Office 2013 with ADAL not working with Single Sign-On
https://goodworkaround.com/2015/4/16/office-2013-with-adal-not-working-with-single-sign-on/

AAD Connectによる代替ID設定

$
0
0

皆さんこんにちは。国井です。

以前、当ブログでAlternate Login ID(代替ID/代替ログインID)という方法を利用して、Office365(Azure AD)のシングルサインオン(SSO)を構成する方法を紹介しました。
代替IDを使うとディレクトリ同期やSSOにUPNを使わなくなるので、kunii@example.localのようなUPNでも、代替UPNサフィックスを使わないでSSOができるという、ありがたいお話でした。

以前は代替IDの設定は結構面倒だったのですが、AAD Connectでは驚くほど簡単になっています。これって、よく質問されるポイントでもあるので、今日は設定を載せておきます。

■ ■ ■

AAD Connectを使ってSSO設定を行う際(ウィザードのステップバイステップはこちらに乗せてあります)、AAD Connectのウィザード設定で[Azure AD サインインの構成]というページがあるので、[ユーザープリンシパル名]としてuserPrincipalNameではなく、mailを選択するだけ。

image

これにより、mail属性をベースにAzure ADへディレクトリ同期が行われ、SSOもmail属性ベースで行われるようになります。

また余談ですが、
(以下、同期ツールに詳しい人だけ見てもらえれば良いです)
Synchronization Servicesツールから同期された様子を見てみると、Azure ADにエクスポートするタイミングでuserPrincipalNameの値にActive DirectoryユーザーのUPNではなく、メールアドレスが入ります。
(もともとのActive DirectoryでのUPN値はonPremisesUserPrincipalName属性の値としてセットされます)

image

一方、メタバースにユーザーの情報を格納するときは、userPrincipalNameの値にメールアドレスではなく、Active DirectoryでのUPN値が入ります。

そのほか、代替IDを使っている場合、ADFSサーバーから発行されるトークンには、代替ログインIDというクレームが追加され、その中にメールアドレスが入ります。

■ ■ ■

ADFSを使ったシングルサインオンをしたいけど、UPNを変更したくない、というお客様はいらっしゃるようですが、代替IDを使うことによって、UPNを変えなくても簡単にシングルサインオン環境を構築できることがわかります。ただし、代替IDの利用には、いくつかの制限事項があるのでご注意を(以下参考)。

■代替ログイン ID を構成します
https://technet.microsoft.com/ja-jp/library/dn659436%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396

完全非公認!Microsoft Ignite ハンズオンラボの歩き方

$
0
0

皆さんこんにちは。国井です。

今から、およそ1か月後に米国アトランタでMicrosoft Igniteカンファレンスが開催されます。

Microsoft Ignite 2016 (2016年9月26-30日)
https://ignite.microsoft.com/

マイクロソフト社で開催されるカンファレンスは国内外を問わず、たくさんありますが、私自身の業務上、最も重要視しているのが、このMicrosoft Ignite (旧TechEd) カンファレンスです。
理由は、マシンを使って最新技術を試せる、ハンズオンラボを使えること
もちろんテクニカルセッションを通じて色々なお話を聞くのも重要なのですが、ハンズオンラボを試せば、一発で仕組みとかが頭に入るので、すごく効果的と私は思うのです。Microsoft IgniteはTechEdの時代から含めて10年以上参加していることですし、参加される方(ごく少数だと思いますけど)に向けて、こんな感じでハンズオンラボを使ってみては?という私なりの使い方を紹介します。

■ ■ ■

 ハンズオンラボの基礎

ハンズオンラボは、会場に大きな専用スペースが用意されており、マシンがぎっしり並んでいます。空いているマシンがあれば、勝手に腰を掛けましょう。

2010-06-10 10.30.35
MMS2013でのハンズオンラボ会場

マシンは1人あたり2台用意されており、1台は実習用、もう1台は手順書を映し出すPDF用です。

20150505_161519592_iOS
SurfaceにOS展開するハンズオンラボは1人3台の豪華構成

マシンには利用可能なラボがずらりと並んでいます。(Microsoft Ignite2015のときは250種類ぐらいあったと記憶しています) その中から興味のあるラボのLaunchボタンをクリックすると、関連する仮想マシンが勝手に立ち上がり、ラボが始められます。

20150505_163118013_iOS

後は自分のペースでラボを心ゆくまで操作するだけ。簡単でしょ?
では、続いて、ハンズオンラボ必勝法をご紹介します。

1.ハンズオンラボは初日の頭から行かないこと

設営しているのは日本人じゃありません。なので、9時の開店から準備万端なんてことは絶対ありません。
なので、初日(特に早い時間)は期待しないほうがいいでしょう。
もしハンズオンラボがオープンしていても、利用できないラボがあるなんてことはザラにあります。

2012-06-11 13.39.03
TechEd 2012でのハンズオンラボ会場のとなりにあったサーバールーム(の説明図)

2.やりたいラボはある程度決めておく

ハンズオンラボは人気のあるコーナーです。そのため、全部のハンズオンができるとは限りません。そのため、ある程度優先順位をつけておくとよいでしょう。
ただし、「ある程度」です。パンフレットにはハンズオンラボの種類が書いてあっても、実際に行ってみると「できませんでした」というラボも多いので、「ある程度」やりたいことを決めておいて、ダメだったらしゃーない、ぐらいの感じで行くとがっかりしません。

ちょっと話はそれますが、ADFSサーバーどうしの信頼関係を結ぶというハンズオンラボを操作していて、手順通りに動作しなかったことがありました。サポートスタッフにそのことを伝えたら、サポートスタッフは5分ほど席を離れ、戻ってきたら「おまえがやってたラボ、使用中止にしといたぜ!」と一言。
親切心がアダとなってADFSサーバーのラボは出来なくなってしまいました。講師業をやっていると、手順通りに動かないって、よく受講者の方から言われますが、ハンズオンラボでは、そんなことを言うと状況はますます悪くなるので黙っているのが一番(笑)
(さらに脱線するけど、サポートスタッフは「One Second, please」って言って、戻ってきたのは5分後。米国人のOne Second=1分、a couple of minutes=10分、ぐらいに思っておけば、間違いないです)

20150506_183616151_iOS
ほんとに”temporarily unavailable”なのかい?

3.手順書は後で公開されるのか?

ハンズオンラボで参照できるPDFの手順書は、サポートスタッフの人に声をかけると「後で公開されるよ」と必ず言います。
だけど、公開されているのをあんまり見たことないんですよね。。
万が一、公開されなかったときのことを考えて、どうしても必要な手順書があったら、写真に収めておくといいかもしれません。
でも写真を撮っていたらサポートスタッフに「後で公開されるよ」と5回ぐらい言われてしまいましたけど。
20150506_190607796_iOS

4.最終日が近づくと混む

ハンズオンラボは、テクニカルセッションに次いで人気のコンテンツです。ですので、テクニカルセッションで目玉となるようなセッションが無い日、無い時間帯は、おのずとハンズオンラボに流れます。
特に最終日近くになると、目玉も少なくなるので、ハンズオンラボは超人気になり、順番待ちになってしまうことも多いです。時間は限られていますから、それだけは絶対に避けましょう。
そして、一度ハンズオンラボの席を確保したら、自分のやりたいことが終わるまでは絶対に離れないようにしましょう(笑)

IMAG0824
Microsoft Ignite2105(だったかな?)で使われていたハンズオンラボ用のサーバー。ラボ用の仮想マシンはすべてここで動いてます。

5.サポートスタッフに過剰な期待はしないでください

去年、サポートスタッフの人と話をしたら、ボランティアでサポートをしているそうです。
そんな立ち位置の人ですから、文句はもちろん、技術的な質問をしてはいけません。
技術的な質問があったら、ハンズオンラボ終了後に、製品サービス別に用意されたブースがありますから、そこに行くとよいでしょう。

じゃあ、サポートの人は何してるの?とは聞かないでください(笑)
彼らは、きさくに「おまえ、昨日も来たよな?」とか、「Hyper-VでのCtrl+Alt+Deleteの押し方知ってるか?」とか、話しかけてくれます。
(誰ですか!「Pepperで十分」って言った人は!!)

2013-04-10 10.02.27
TechEd2011でのハンズオンラボ会場の風景

6.ラボ環境は割とよく落ちる

何が原因かはわかりませんが、ラボ環境はこんな感じで使えなくなることが割とよくあります。このときは黙って待ちましょう。サポートスタッフの方が裏でトラブルシューティングしてくれているはずです。

20150506_184254598_iOS

7.寒い!

ハンズオンラボで利用する仮想マシンは上の写真で見たように、集中管理されています。そのため、サーバーを冷やすべく、ものすごい冷房をかけます。米国でのカンファレンス会場は寒い、という印象を持たれている方は多いと思いますが、ハンズオンラボ会場はなかでも極寒です!
長時間の極寒に耐えられるだけの服装で挑みましょう。

2012-06-11 13.38.27
ハンズオンラボのマシンはSystem Centerで管理されている

色々書きましたけど、いくつかの妥協を差し引いても、ハンズオンラボは本当に役立つものばかりだと思いますし、サポートスタッフの方々も「いい人」ばかりです。

機会がありましたら、ぜひ足を運んでみてください。

Windows Server 2016 × Azure Active Directory Connect によるADFSのインストール

$
0
0

皆さんこんにちは。国井です。

先週(2016年9月24日~)、米国アトランタで開催されていたMicrosoft Igniteに参加してきました。当ブログでもメインのパートとなっているAzure ADの話も多く、充実した日々を過ごしておりました。
今年は日本人の方で参加していた方や、オンラインでご覧になっていた方も多く、様々なブログ等でイベントの様子などは語られておりましたので、イベントの話は他の方にお任せして、私自身の所感などは様々なセミナーなどでご紹介させていただければと思います。

■ ■ ■

今日は、そのMicrosoft Igniteのイベントの中でGA(リリース)が発表された、Windows Server 2016でのADFSサーバーのインストールと、Office365のシングルサインオンについて確認します。

結論から先に言うと、ADFSのインストールやOffice365のシングルサインオン設定(初期設定)はAzure Active Directory Connectを使うことを推奨しているようなので、Windows Server 2016ならではの設定などはありません。
実際に、役割の追加でADFSの役割を追加し、構成ウィザードを実行すると、ご覧のように、「Office365のシングルサインオン設定するなら、Azure AD Connect使ってね」というメッセージが出ています。
(参考までに言っておくと、このメッセージを無視してADFSを手動でインストールしても、Windows Server 2012 R2のときと同様にSSO設定は可能です)

image

ということで、Azure AD Connectを使ってインストールを行います。

前提条件はこれまでと同じく

・Active Directoryドメイン
・ADFSサーバーとなるWindows Server 2016
・WebアプリケーションプロキシとなるWindows Server 2016(独立したサーバー)
・Azure ADドメイン
・Azure ADドメインに対応した証明書
・リモートからWAPをインストールできるようにするための設定
・代替UPNサフィックスの設定
・代替UPNサフィックスを設定したユーザーの作成

が必要になります。
主なところだけ簡単にご紹介しておきましょう。

【前提条件】Azure AD ドメイン

Microsoft Azure管理ポータルから作成するか、Office365の契約によって自動的に作成されるものを使いましょう。Azure管理ポータルから作成するときは[+新規]をクリックして作成します。
また、会社のドメイン名はAzure管理ポータルの[ドメイン]から[追加]をクリックして追加します。

image

【前提条件】リモートからWAPをインストールできるようにするための設定

Azure AD Connectでは、ADFSサーバーとWAPを一気にインストールします。Azure AD ConnectをインストールするサーバーとWAPとなるサーバーは確実に異なるサーバーになるため、遠隔からの操作でインストールできるように設定しておく必要があります。まず、WAPサーバー側では「Enable-PSRemoting」コマンドレットをPowerShellから実行しておくのと、

image

Hostsファイルにフェデレーションサービス名の名前解決ができるように設定しておきます。

image

一方、ドメインコントローラー側では、DNSサーバーにWAPの名前解決ができるようにレコードを登録しておきます。

image

DNSサーバーには、フェデレーションサービス名となるレコードも登録しておいてください。

image

その他、Azure AD Connectをインストールするサーバーから遠隔操作でWAPをインストールできるようにするための設定として、PowerShellで「Set-Item WSMan:\Localhost\Client\TrustedHosts –Value <WAPサーバーのFQDN> –Force」を実行します。

image

【前提条件】代替UPNサフィックスの設定

[Active Directoryドメインと信頼関係]から代替UPNサフィックスの設定として、会社のドメイン名を追加します。

image

image

【前提条件】代替UPNサフィックスを設定したユーザーの作成

ドメイン名が@以降に設定されたActive Directoryユーザーも作成しておきましょう。既に作成したユーザーであれば、ユーザーのプロパティから変更できます。

image

■ ■ ■

Azure AD Connectのインストール

前提条件が整ったら、いよいよAzure AD Connectをインストールしましょう。こちらのサイトからツールをダウンロードして、

・Microsoft Azure Active Directory Connect
https://www.microsoft.com/en-us/download/details.aspx?id=47594

ダウンロードしたツールをダブルクリックしたらスタートです。ウィザード画面は全部お見せしますけど、コメントは主なところだけ入れておきます。

AADC16-003

ADFSサーバーも一緒にインストールするときは、[カスタマイズ]をクリックします。

AADC16-004

AADC16-005

[ADFSとのフェデレーション]を選択しましょう。

AADC16-007

Azure AD全体管理者の資格情報を入力します。

image

AADC16-009

代替UPNサフィックスが設定されていること、Azure ADに会社のドメイン名が登録されていることを確認し、Verifiedになっていることも同時に見ておきましょう。

image

AADC16-017

AADC16-018

AADC16-019

[パスワードの同期]にチェックがつけてありますけど、必須な設定ではありません。

AADC16-020

前提条件で用意した証明書を指定します。

image

AADC16-022

WAPサーバーの指定画面。WAPサーバーはDNSサーバーに登録したレコードの名前と同じ名前をここでは入力してください。

AADC16-023

AADC16-024

AADC16-025

image

image

ここまででインストールが始まります。しばらくするとインストールが完了します。最後にADFSサーバーにアクセスするためのレコード(フェデレーションサービス名に対応するレコード)が登録されているか確認します。
(ちなみにインストール完了にならずに失敗する場合は、アンインストール→インストールで再チャレンジしてください。)

image

フェデレーションサービス名に対応するレコードがあれば、名前解決は完了し、無事にインストールが完了します。

image

ここまでできれば、ADFSサーバーを使ったOffice365のシングルサインオン環境は出来上がりです。

Azure AD Connectを利用したからといって、設定が劇的に簡単になるかといえば、そうでもなさそうな気もしますね。しかも言葉の意味や、なぜそのような設定をするのか?など、色々理解に苦しむ部分もあったかと思います。
Windows Server 2016での新しい機能の紹介などを含めて、トレーニングコースの中では紹介させていただいておりますので、よろしければご参加を検討してみてください。


2重に多要素認証が実行されるのを回避する方法

$
0
0

皆さんこんにちは。国井です。

ユーザー名/パスワードとは別に、電話やモバイルアプリなどを使って認証を行う多要素認証。
多要素認証にはユーザー名/パスワードが悪用された時の備えとして役立つとされていますが、ユーザーさんには「面倒」と煙たがられます。

特にADFSを使って、Office 365 (Azure AD)にシングルサインオンしている環境だと、ADFSの多要素認証と、Azure ADの多要素認証があって、両方設定してしまった日には、設定した瞬間から苦情が殺到します。
そこで、今日はADFSで多要素認証を設定した場合には、Azure ADで多要素認証を設定しても、回避される方法を紹介します。

あ

■ ■ ■

まず、手始めにADFSサーバーで証明書認証を有効にします。
ADFSサーバーでの証明書認証の設定方法そのものはこちらで紹介しているので、参考にしてください。

image

次に、Azure ADでも多要素認証を有効にします。
Azure ADの多要素認証設定はOffice 365の管理ポータル、またはMicrosoft Azureのポータルから設定できます。

image

設定したら、早速Office 365にシングルサインオンしてみます。
すると、一瞬だけADFSの多要素認証画面が表示され(証明書認証なので、自動的に認証は完了する)、その後、下の画面のように、Azure ADで多要素認証を初めて実行するときの画面が表示されます。
つまり、ADFSとAzure ADの両方で多要素認証が実行されてしまっていることがわかります。

image

ここからがポイントですが、

ADFSサーバーで認証されたユーザーがAzure ADの多要素認証を実行しないようにするには、
ADFSサーバーでクレームルールを設定します。

ADFS管理ツールの[証明書利用者信頼]から[Microsoft Office 365 Identity Platform]を右クリックし、[要求規則の編集]をクリックして、[発行変換規則]タブから規則を追加し、[カスタム規則を使用して要求を送信]をクリックして、以下のルールを作成します。
(1行で書いてください)

=>issue(Type=”http://schemas.microsoft.com/claims/authnmethodsrefe
rences”,Value=”http://schemas.microsoft.com/claims/multipleau
thn”);

下の画面のように設定できたら、[完了]をクリックして、保存しておきましょう。

image

これで再チャレンジします。すると、Azure ADの多要素認証画面が表示されることなく、Office 365にサインインできたことになります。
しかし、ここで大きな問題が。
このクレームルール、ADFSサーバーで多要素認証を行っているか、いないかに関わりなく、Azure ADの多要素認証を回避してしまいます。
せめて、ADFSサーバーの多要素認証だけ実行させたい、という場合はクレームルールに「ADFSサーバーで多要素認証を実行した場合」という条件を書きましょう。

どうやって書くか?
色々やり方はあると思いますが、私が着目したのは証明書を利用して多要素認証を実行した場合、http://schemas.microsoft.com/2012/12/certificatecontext/ekuクレームに値を設定する点です。

image

つまり、ekuクレームがトークンに含まれる場合はAzure ADの多要素認証を回避せよ!というクレームルールを書けばよいので、

Exists([Type==“http://schemas.microsoft.com/2012/12/certificatecont
ext/eku”])
=>issue(Type=”http://schemas.microsoft.com/claims/authnmethodsrefe
rences”,Value=”http://schemas.microsoft.com/claims/multipleau
thn”);

と書けばよいのです。(1行で書いてください)
image

このクレームルールを保存して、もう一度、Office 365へのシングルサインオンを試してみると、ADFSサーバーで多要素認証を実行したPCだけがAzure ADの多要素認証を回避して、シングルサインオンに成功します。

 

【参考情報】
Securing cloud resources with Azure Multi-Factor Authentication and AD FS
https://github.com/Azure/azure-content/blob/master/articles/multi-factor-authentication/multi-factor-authentication-get-started-adfs-cloud.md

Azure MFAをADFSサーバーで利用する方法
https://azure.microsoft.com/ja-jp/documentation/articles/active-directory-conditional-access-azuread-connected-apps/

ADFSとAzure ADの違いを比較してみよう

$
0
0

皆さんこんにちは。国井です。

シェイクスピアも「ADFSにするか、Azure ADにするか、それが問題だ」と言ったように(うそ)、Office365をはじめとするサービスへのシングルサインオン(SSO)を実装する場合、ADFSを利用するか、Azure ADを利用するか、という選択肢で悩むことと思います。

基本的な選択基準は、ID基盤をオンプレミスのActive Directoryを中心に据えて、様々なクラウドサービスへのSSOを実装したいということであればADFSを選択することになるでしょうし、ID基盤を含めてすべてクラウドに移行してしまって運用したいということであればAzure ADを選択することになると思います。

プレゼンテーション1

特にWindows 10の場合、Active  Directoryのドメイン参加とAzure ADのドメイン参加が選べるようになっていて、

Active  Directoryにドメイン参加しているWindows 10 PCの場合はActive  Directory(AD DS)にサインインすることで、以降の認証・認可は自動的に行われることになり(上図の最上段の青の矢印部分)、

Azure ADにドメイン参加しているWindows 10 PCの場合はAzure ADにサインインすることで、以降の認証・認可は自動的に行われることになります(上図の最下段の青の矢印部分)。

いずれの場合も、上図の中段のように、Windowsサインインでユーザー名/パスワードを入力して、Azure ADにサインインするのにユーザー名/パスワードを入力して、と何度もユーザー名/パスワードを入力する必要がないというメリットがどちらにもあります。

■ ■ ■

一方、企業で求められている要件によってID基盤をどちらの方法で運用をするか決めたい、というケースではADFSとAzure ADでどのような機能の違いがあるかを見極める必要があります。
そこで、ここではアクセス制御という点から、ADFSとAzure ADの違いを比較してみたいと思います。

ADFS Azure AD
ユーザー ・クレームルールを利用したグループによるアクセス制御
・多要素認証 (証明書など)
・グループによるアクセス制御
・多要素認証 (モバイル)
デバイス ・デバイス認証
・クレームルールによる次の制御
・デバイスOS種類
・ネットワークの場所
・デバイス認証
・コンプライアンスポリシー
・ネットワークの場所
アプリ ・クレームルールによる次の制御
・クラウドサービス(RP)
・SAMLエンドポイント
・クライアントアプリ種類
・Cloud App Security
リスク ・ロックアウト
・管理者がイベントログから不正アクセスを調査し、必要に応じてアクセスをブロック
・Azure AD Identity Protection

こうやって見てみると、ADFSとAzure ADではアクセス制御機能に、大きな差はなくなってきていることがお分かりいただけると思います。
とは言うものの、これだけで結論付けてしまうのも、、って感じなので、もう少し細かく見てみましょう。

ユーザーベースのアクセス制御

ユーザーベースのアクセス制御はADFSも、Azure ADも、グループ単位でのアクセス制御機能を備えています。
ただし、Azure ADの場合、グループ単位でのアクセス制御は有償版のAzure AD Premiumで実装されています。ユーザー数がちょっと多い企業などですと、アクセス許可設定を行うだけでもひと苦労なので、有償版の利用は避けられないと思います。(うまいこと、できてますね)

また、ADFS/Azure ADともに多要素認証機能も実装されていますが、ADFSの場合は証明書ベース、Azure ADの場合はモバイルを利用した通話、SMSなどによる多要素認証をサポートしています。

http://azuread.net/2014/03/27/adfs%e3%81%ab%e3%82%88%e3%82%8b%e5%a4%9a%e8%a6%81%e7%b4%a0%e8%aa%8d%e8%a8%bc%e3%81%ae%e8%a8%ad%e5%ae%9a/

デバイスベースのアクセス制御

ADFSとAzure ADでは、どちらもあらかじめ登録されたデバイスだけにアクセス許可を与える、デバイス認証機能が実装されています。
ただし、登録可能なOS種類だったり、アクセス制御が可能なクライアントブラウザーの種類だったりがあるので、細かくは確認しておく必要があります。

http://azuread.net/2016/10/17/azure-ad%e3%83%87%e3%83%90%e3%82%a4%e3%82%b9%e7%99%bb%e9%8c%b2%e3%81%a8%e3%83%87%e3%83%90%e3%82%a4%e3%82%b9%e8%aa%8d%e8%a8%bc/

その他、ネットワークの場所(IPアドレスやサブネット)をベースにしたアクセス許可設定も可能です。ADFSとAzure ADのどちらでも設定可能なのですが、ADFSの場合はサブネットの指定が結構面倒なんですよね。

アプリベースのアクセス制御

Azure ADの場合は、Azure ADの有償版がセットになったパッケージ、Enterprise Mobility + Security (EMS)のライセンスの中に含まれるCloud App Securityを使って、特定のクラウドサービスへの不正アクセスを検出していく方法があります。

http://azuread.net/2016/09/06/office-365-azure-ad%e3%81%ae%e3%82%a2%e3%82%af%e3%82%bb%e3%82%b9%e3%83%ad%e3%82%b0%e3%81%a8%e3%82%a2%e3%82%af%e3%83%86%e3%82%a3%e3%83%93%e3%83%86%e3%82%a3%e7%9b%a3%e8%a6%961/

一方、ADFSの場合は証明書利用者信頼に登録されたクラウドサービスの単位でアクセスの許可・拒否をクレームルールで設定できるほか、クラウドサービスへアクセスするときにどのエンドポイントにアクセスするかによってアクセスを制御したり(Office 365の例で言うと、クライアントからどのようなアプリを利用してアクセスするかによって、利用するエンドポイントが異なります)、またはクライアントコンピューター上で利用するアプリ(Internet ExplorerやGoogle Chromeなど)をチェックしてアクセス許可を与える方法が実装できます。

リスクベースのアクセス制御

不正アクセスの可能性を検出し、アクセスをブロックするリスクベースのアクセス制御機能は、Azure ADでしたら、Azure AD Identity Protectionという有償版のAzure AD Premium P2から提供される機能を利用します。
ADFSの場合は、、リスクベースでアクセスをブロックしていく方法ってないんですよね。他のソリューションと組み合わせたり、管理者がイベントログをチェックしながら不正アクセスを手動で見つけていくとか、そういう方法が求められるのです。

■ ■ ■

それぞれの機能について説明しようと思ったら、過去の投稿で解説していることが多く、単なるまとめページになってしまいましたが、
細かな差こそあるものの、ADFSとAzure ADでアクセス制御面での大きな差はないことはお分かりいただけたかと思います。

新コース「Microsoft Azure を利用した ADFS サーバーの構築と運用」スタートします

$
0
0

皆さんこんにちは。国井です。
今日は、待望の新コースのご案内です。

イルミネート・ジャパンさんと共同で開催させてもらっているADFS・Azure AD関連コースに、新しいコースとして「Microsoft Azure を利用した ADFS サーバーの構築と運用」というコースが加わりました。

■Microsoft Azure を利用した ADFS サーバーの構築と運用
http://www.illuminate-j.jp/Pages/CI526-H.aspx

このコースでは、ADFSサーバーを構築する際に、Microsoft Azureの仮想マシンに作成し、運用するために必要な要素について学習します。

ADFSサーバーを構築して、Office 365のシングルサインオンを実現させたいけど、オンプレミスにサーバーを置きたくない

ADFSサーバーの運用に際して、バックアップサイトへの切り替えって、どうやって行えばよいのだろうか?

という課題に応える形で1日のコースとして提供します。
実際に、こんな形の環境をMicrosoft Azureに構築し、動作する様子を見てもらえるので、作成するときの手順を持って帰れるのはもちろん、作成した環境もそのまま持って帰って、自社での検証などにも使えますよ。

image

初回の開催は、2017年4月27日と少し先になりますが、
今期の予算で受講したい(随分とリアルな話でごめんなさい)、などのご要望がありましたらアレンジも可能ですので、その際はコース申し込みサイトよりご相談ください。

教室でお会いできることを楽しみにしています。

2017年度のADFS/AzureADトレーニングのスケジュールが発表されました

$
0
0

皆さんこんにちは。国井です。

イルミネート・ジャパンさんとの協業で提供している「Office 365認証ベストプラクティス」コースと、これから提供される予定の「Microsoft Azure を利用した ADFS サーバーの構築と運用」コースですが、
2017年4月からのスケジュールも発表され、3か月に一度の開催から、2か月に一度の開催に増やすことになりました。
日程は以下のとおりです。

■Office 365認証ベストプラクティスコース
2016/04/24(月) ~ 2016/04/26(水)
2016/06/19(月) ~ 2016/06/21(水)
2016/08/28(月) ~ 2016/08/30(水)

■Microsoft Azureを利用したADFSサーバーの構築と運用コース
2016/04/27(木)
2016/06/22(木)
2016/08/31(木)

コースの詳細についてやお申し込みについては以下のリンクからどうぞ。

Office 365認証ベストプラクティス

Microsoft Azure を利用した ADFS サーバーの構築と運用

また、ご要望が少しずつ高まっているAzure AD PremiumやEMS(Enterprise Mobility + Security)の運用コースについても、
今後の提供を検討しておりますので、ご案内できるようになりましたら、改めてアナウンスさせていただきます。

■ ■ ■

ここ数か月のAzure ADの変化は目覚ましいものがあり、ADFSとどう使い分けていくか、という議論がこれから先、様々なところで起きてくるのではないかと思いますが、
上記のコースで整理をしながら、皆さまの環境におけるベストプラクティスを探っていきたいと思いますので、どうぞよろしくお願いいたします。

Windows Server 2016 ADFSを利用したアクセス制御

$
0
0

皆さんこんにちは。国井です。

Windows Server 2016もリリースされてから時間も経過していますし、そろそろ既存のADFSもWindows Server 2016に切り替えたい、というニーズもボチボチ出てくるころではないかと思います。

私自身も直近では、お仕事の関係でADFSよりもAzure ADを扱うことのほうが多かったのですが、Windows Server 2016のADFSについて、お話を伺うことが出てくるようになってきたので、当ブログでも少しずつ扱っていきたいと思います。

今日はクレームルールに関するお話です。
クレームルールと言えば、今まではc:[xxxx]=>issue(xxx);みたいな言語を記述するという、とても敷居の高いものでした。
Windows Server 2016でも、以前のバージョンのADFSからアップグレードされてきたときには、ご覧のような形でクレームルールを引き続き利用することができます。(下の画面で、[アクセス制御ポリシーの使用]というリンクをクリックすると、クレームルール言語は使えなくなります)

image

ですが、Windows Server 2016ではクレームルール言語を使わなくてもアクセス制御のための条件が設定できるようになりました。
(受け付け変換規則と発行変換規則は、引き続きクレームルール言語とを使います)
Windows Server 2016からは発行承認規則のクレームルールは「アクセス制御ポリシー」と呼ばれるようになっており、あらかじめ[アクセス制御ポリシー]を作成しておき、作成したアクセス制御ポリシーを発行承認規則の中で選択する、というスタイルになっています。
ですので、今までのように発行承認規則のなかではルールは書けなくなりました。(下の画面のように選択するだけの画面に変わっています。)

image

アクセス制御ポリシーは、ADFS管理ツールの中に[アクセス制御ポリシー]という設定項目があり、[アクセス制御ポリシー]項目で集中管理しています。項目を見てみると、デフォルトでいくつかのポリシーが既に用意されていることがわかります。

image

もし、この中にない項目を作成したい場合には、新しくアクセス制御ポリシーを追加し、その中でルールを定義します。
例えば、xxxグループのメンバーだけがアクセスできるルールを作りたい、と言ったら、[アクセス制御ポリシーの追加]から[追加]をクリックして、[規則エディター]を開き、[規則エディター]の中でルールを作成します。
[規則エディター]を使えば、今までクレームルール言語で書いていた内容がGUIで実現できますが、x-ms-client-applicationクレームを使って条件を書きたい!みたいな画面の中にない要望がある場合は[特定要求が要求にある]という項目を使って設定してください。

image

[規則エディター]画面で、[OK]をクリックすると、下の画面のようにルールが追加されます。
なお、ルールは複数作ることができ、[規則エディター]でルールを複数作成すればAND条件、[アクセス制御ポリシーの追加]でルールを複数作成すればOR条件になります。

image

アクセス制御ポリシーを作成したら、後は証明書利用者信頼の中で作成したアクセス制御ポリシーを割り当てるだけ。
これができたら、実際にポリシー通りに動作するか確認してみましょう。
クライアントコンピューターで動作確認することももちろんですが、アクセス状況はADFSサーバーのログでも確認できます。
ADFSサーバーのログの設定方法については、MVPの渡辺さんが紹介してくれているので、それを参考にすることとして、
ここでは、イベントビューアのセキュリティログから結果を見てます。
すると、今までは、とんでもない数のログが生成されていましたが、Windows Server 2016で生成されるログは
イベントID 1200と1202のたった2つ!

しかも、今までだったら1つのログに書ききれないから2つのログに分割して記録する、みたいなアホなことももうしません。

image

ちなみに、Windows Server 2012 R2までの従来型のログで見たいという奇特な?人は

Set-AdfsProperties –AuditLevel verbose

と設定すれば、

image

従来型のログで内容を参照することもできます。

image

クレームルールとアクセス制御ポリシーはADFSを使ってアクセス制御を行う上で、とても重要な要素になります。今回は、基本的なところを紹介しましたが、実際には自分がやりたいことを実現するには、どのようなポリシーを書けばよいか?など、突き詰めると色々な課題にぶち当たることも予想されます。
そんなときは当ブログでいつも紹介しているADFS/Azure ADセミナーの活用もご検討いただければ幸いです。

Windows Server 2016のADFSサーバーにアップグレード

$
0
0

皆さんこんにちは。国井です。

Azure ADへのサインインには、

・Azure ADに直接作成したユーザーでサインインする方法 (クラウドID)
・AAD Connectで同期したユーザーでサインインする方法 (同期ID)
・ADFSでシングルサインオンする方法 (フェデレーションID)

の3種類に大きく分かれますが、
全世界で行われているAzure ADへのサインインのうち、ADFSを使ったフェデレーションIDによるシングルサインオンの割合は47.8%あるそうです。
(ちなみに、クラウドIDは28.2%、同期IDは17.5%)

日本国内で見たときにどのくらいの割合なのかは「中の人」ではないため、知る由もありませんが、私が思うよりも多くの企業で使われているんだなという印象を受けました。(皆さんの印象はいかがですか?)

となると、将来的に現在あるADFSサーバーをWindows Server 2016へ移行したい、というニーズも出てくるのではないかと思います。
そこで、今回はWindows Server 2012 R2からWindows Server 2016へのアップグレード手順を確認してみたいと思います。

■ ■ ■

ADFSサーバーをWindows Server 2012 R2からWindows Server 2016へのアップグレードする場合、新しいサーバーを用意して、既存の環境を新しいサーバーに移行する、いわゆる「サイドバイサイド移行」が一般的な移行方法となるので、ここではサイドバイサイド移行の方法を試してみます。

image

基本的な流れは、

1.新しいサーバーに2台目のドメインコントローラーをインストール
2.新しいサーバーにファームの2台目のサーバーとしてADFSサーバーをインストール
3.新しいサーバーをプライマリとして構成
4.Webアプリケーション プロキシをインストール
5.既存のサーバーを撤去し、ファーム動作レベルをWindows Server 2016に変更

の順序です。
では、順番に見てみましょう。

1. 新しいサーバーに2台目のドメインコントローラーをインストール

新しく用意したWindows Server 2016サーバーにActive Directoryドメインサービスをインストールし、既存のドメインの追加ドメインコントローラーとしてインストールしてください。FSMOやグローバルカタログの移行も忘れずに。

2.新しいサーバーにファームの2台目のサーバーとしてADFSサーバーをインストール

新しく用意したWindows Server 2016サーバーにADFSをインストールします。
インストールするときは、サーバーマネージャーの[役割と機能の追加]から。

image

ウィザードが完了したら、そのまま[このサーバーにフェデレーションサービスを構成します]をクリックして、構成ウィザードを開始しましょう。

image

構成ウィザードの最初の画面では、必ず[フェデレーションサーバーファームにフェデレーションサーバーを追加します]を選択

image

image

既存のADFSサーバー(最初にインストールしたサーバー)の名前を指定します。

image

証明書の選択画面。既存のADFSサーバーにインストールされている証明書と同じものを指定します。まだ新しいサーバーに証明書をインストールしていない場合は、[インポート]ボタンをクリックして、インストールしておきましょう。

image

サービスアカウントの指定。既存のサーバーで使用していたサービスアカウントを流用できます。私のテスト環境では横着してしまったので、Administratorです。(懺悔)

image

image

image

image

ウィザードが完了すれば、新しいサーバーにADFSがインストールされ、既存環境の情報が移行されます。その他、ここには書かないですが、フェデレーションサービス名の名前解決を行うときに、新しいサーバーに名前解決されるよう、必要に応じてDNSレコードを変更しておいてください。

3.新しいサーバーをプライマリとして構成

前の手順でADFSサーバーをインストールしましたが、このままだとWindows Server 2016から管理ツールによる管理ができません。そのため、新しいサーバーをプライマリとして構成しましょう。

プライマリとして構成するときは、新しいサーバーのPowerShellで、

Set-AdfsSyncProperties -Role PrimaryComputer

と実行します。

image

また、既存のサーバーはプライマリではないという宣言をする必要もあるので、既存のサーバーでは、

Set-AdfsSyncProperties –PrimaryComputerName “<新しいサーバー名>” -Role SecondaryComputer

と実行します。

image

ここまでのところで、新しいサーバーからADFS管理ツールを開くと、既存のADFSサーバーで見えていた画面が表示されます。
ところが、証明書を見てみると、

image

証明書、登録されてないじゃん!
念のため、[サービス通信証明書の設定]ボタンをクリックして登録しておきました。

4.Webアプリケーション プロキシをインストール

Webアプリケーションプロキシは、ADFSサーバーとの通信によって各種設定を受け取るので、既存のWebアプリケーションプロキシから何かを移行する必要はありません。そのため、単純に新しいサーバーでWebアプリケーションプロキシをインストールするだけです。

image

image

image

image

image

image

5.既存のサーバーを撤去し、ファーム動作レベルをWindows Server 2016に変更

ここまでの手順が整ったら、もうWindows Server 2012 R2は不要なので、撤去してしまいましょう。
また、ADFSサーバーはWindows Server 2012 R2から設定を引き継いだ場合、
ADFSサーバーの動作レベルがWindows Server 2012 R2のままなので、Windows Server 2016にアップグレードしましょう。
アップグレードするときは、以下のコマンドレットで実行します。

Invoke-AdfsFarmBehaviorLevelRaise

アップグレードの結果は、

Get-AdfsFarmInformation

コマンドレットを実行し、CurrentFarmBehaviorの値が3になっていれば、Windows Server 2016にファームレベルがアップグレードされたことを示しています。

 

■参考情報

How to Upgrade AD FS 3 to AD FS on Windows Server 2016
https://flamingkeys.com/how-to-upgrade-ad-fs-3-to-ad-fs-on-windows-server-2016/

Active Directoryフェデレーション サービスのWindows Server 2016の新機能
https://technet.microsoft.com/ja-jp/windows-server-docs/identity/ad-fs/overview/whats-new-active-directory-federation-services-windows-server-2016

Windows Server 2016でのAD FSへのアップグレード
https://technet.microsoft.com/ja-jp/windows-server-docs/identity/ad-fs/deployment/upgrading-to-ad-fs-in-windows-server-2016

ADFSなしでOfficce365へのシングルサインオンを実現する

$
0
0

皆さんこんにちは。国井です。
前回の投稿ではWindows Server 2016へのADFSサーバーのアップグレードの話をして、今回はADFSの要らないSSOの話をするという、なんかチグハグな感じの投稿ですが、これも多様性ってことでお付き合いください。

私はこれまで、ADFSの必要性について話をするときに、

オンプレミスではActive Directoryを使ってシングルサインオンを実現していました。
しかし、Active Directoryが使っているのはKerberosという社内限定のプロトコルであり、
クラウドに対しては残念ながらKerberosというプロトコルが使えません。
だからこそ、Kerberosのチケットをクラウドで有効なトークンに置き換え、
クラウドの世界もシングルサインオンが実現できるようなADFSが必要なのです。

という話をしてきました。

ところが、直近のバージョンのAzure AD Connectでは、
パススルー認証シングルサインオンというNew Technologyを実装し、
ADFSなしでも、Active Directoryで認証したユーザーは、Kerberosの仕組みを拡張し、そのままAzure ADにアクセスできるような仕組みを提供するようになりました。

■ ■ ■

Azure AD Connectとパススルー認証とシングルサインオンですが、Azure ADへのシングルサインオンの目的でADFSを使っていたのに、それがもう不要になるという破壊力抜群の機能です。
仕組みはこんな感じです。

PHS

PHS

パスワードハッシュ同期+SSOのパターンは、KerberosのチケットをAzure ADに渡すという技、
パススルー認証+SSOのパターンは、ユーザー認証をActive Directoryに丸投げするという技です。

今日はこの中から、パスワードハッシュ同期+SSOのパターンを見てみたいと思います。

設定は、とても簡単で、
Azure AD Connectのインストールウィザード実行時に、
[パスワード同期]を選択して、[シングルサインオンを有効にする]にチェックをつける。

image

あとは、ウィザードの最後のページで、オンプレミスドメインの管理者ID情報を入力するだけ。

image

image

ブラウザー側は、Internet Explorerのイントラネットゾーンに以下の2つのURLを入れておけば、

https://autologon.microsoftazuread-sso.com
https://aadg.windows.net.nsatc.net

認証処理が自動的に上図のように推移し、
ADFSと同様に、パスワードを入れるテキストボックスにはパスワードを入れなくても、勝手にサインインが完了します。

image

Active DirectoryにSTを発行してもらって、Azure ADにアクセスするってことは、
Azure AD用のコンピューターオブジェクトがあったりするの?って思ったあなた、正解です!イベントビューアでKerberosチケット発行の様子をトレースすると、AZUREADSSOACCという名前のコンピューターオブジェクト向けのSTが発行されていることが確認できます。

image

■ ■ ■

ところで、ADFSなしでシングルサインオンできるってことは、ADFSはもう要らないの?という疑問があります。
これについては、何を切り口に語るかで、答えは変わってくると思うのですが、
少なくとも言えることは、シングルサインオンをしたいという単純な理由だけでADFSを使うのではなく、組織で求められているセキュリティ要件を満たすためにADFSにしかできない機能を活用する
という考え方にシフトしていくものと思われます。
これについては、話が長くなりそうなので、機会を改めることとしますが、この当たりのテクノロジーは色々なものが登場してきていて、一度整理しておく必要があるかと思います。
私が提供しているトレーニングでは現在、どちらかというと、ADFSをメインに置いたトレーニングになっていますが、様々なテクノロジーを整理する場として、よろしければご活用いただければと思います。

 

■参考情報
Azure ADパススルー認証とは
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication
シングル サインオン (SSO) とは
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-sso
Azure AD Connect のカスタム インストール
https://docs.microsoft.com/ja-jp/azure/active-directory/connect/active-directory-aadconnect-get-started-custom
クラウド時代のセキュリティ担保にはActive Directoryフェデレーションサービスが必須となる?
http://www.atmarkit.co.jp/ait/articles/1508/19/news021.html


PowerShellからAzure DNSのレコードを操作

$
0
0

皆さんこんにちは。国井です。

マイクロソフトさんからMicrosoft MVPという賞を2006年からいただいておりましたが、
今年もいただくことができました。これで12回目なのですが、この12年の間に周りにいるMVPさんの顔ぶれも結構変わった気がしますし、同じことをずっと続けていくって、案外大変なことなんだなって思います。
私の場合はどうかって?自分の会社で好き勝手にやっているので、このブログと共に、この命ある限り続けますよ!

今日はAzure DNSレコードの操作をPowerShellから行うという、備忘録な感じの話です。
Azure ADやOffice365を検証環境で使っていると、DNSレコードを登録する機会というのは少なからず出てくると思います。ADFSの検証環境を何度も作ってしまうような強者であれば、お名前ドットコムなどで取得した独自ドメインをお持ちで、なおかつDNSにはAzure DNSを使うという人もいるでしょう。そんなときに覚えておきたいのが、Azure DNSをPowerShellから一括で登録・削除する方法。

以下に記しておきますので、ご入用の際はコピペして使ってください。
言うまでもないかもしれませんが、AzureをPowerShellから操作するときは、
Azure PowerShellを事前にインストールしておくこと、
Login-AzureRMAccount
Select-AzureRMSubscription -SubscriptionID <サブスクリプションID番号>
のコマンドレットを実行しておくことを忘れないでください。

Azure DNSレコードの登録

ドメイン確認用のTXTレコードを登録する場合だったら、このように実行します。

$rs = Get-AzureRmDnsRecordSet -name “ドメイン名(sub.adfs.jpだったら、subの部分を指定)” -RecordType TXT -ZoneName “ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)” -ResourceGroupName “リソースグループ名”
$rs.Records[0].Value = “MS=msで始まるレコード”
Set-AzureRmDnsRecordSet -RecordSet $rs

また、Office365用のレコードを登録する場合はこちら。

#各種情報の設定
$recordname=”ドメイン名(sub.adfs.jpだったら、subの部分を指定)”
$domainname=”ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)”
$MXdomainname=”ゾーン名を-で区切って表記 (例:adfs.jpだったら、-adfs-jpと表記)”
$IP=”WAPのIPアドレス”
$RG=”リソースグループ名”

#Aレコードの登録
$rs = New-AzureRmDnsRecordSet -Name $recordname -RecordType A -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Ipv4Address $IP
Set-AzureRmDnsRecordSet -RecordSet $rs

#MXレコードの登録
$ExchangeOnlineName=$recordname + $MXdomainname + “.mail.protection.outlook.com”
$rs = New-AzureRmDnsRecordSet -Name $recordname -RecordType MX -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Exchange $ExchangeOnlineName -Preference 5
Set-AzureRmDnsRecordSet -RecordSet $rs

#TXTレコードの登録
#ドメイン登録用レコードは使い終わった後に削除している前提です
$rs = Get-AzureRmDnsRecordSet -name $recordname -RecordType TXT -ZoneName $domainname -ResourceGroupName $RG
$rs.Records[0].Value = “v=spf1 include:spf.protection.outlook.com -all”
Set-AzureRmDnsRecordSet -RecordSet $rs

#CNAMEレコードの登録
$ASName=”autodiscover.” + $recordname
$SIPName=”sip.” + $recordname
$LyncName=”lyncdiscover.” + $recordname
$MSOIDName=”msoid.” + $recordname
$rs = New-AzureRmDnsRecordSet -Name $ASName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “autodiscover.outlook.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $SIPName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “sipdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $LyncName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “webdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $MSOIDName -RecordType CNAME -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs -Cname “clientconfig.microsoftonline-p.net”
Set-AzureRmDnsRecordSet -RecordSet $rs

#SRVレコードの登録
$SIPTLSName=”_sip._tls.” + $recordname
$SIPFedName=”_sipfederationtls._tcp.” + $recordname
$rs = New-AzureRmDnsRecordSet -Name $SIPTLSName -RecordType SRV -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs –Priority 1 –Weight 100 –Port 443 –Target “sipdir.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs
$rs = New-AzureRmDnsRecordSet -Name $SIPFedName -RecordType SRV -Ttl 60 -ZoneName $domainname -ResourceGroupName $RG
Add-AzureRmDnsRecordConfig -RecordSet $rs –Priority 1 –Weight 100 –Port 5061 –Target “sipfed.online.lync.com”
Set-AzureRmDnsRecordSet -RecordSet $rs

Azure DNSレコードの削除

(ドメイン確認用の)TXTレコードを削除する場合だったら、このように実行します。

$dns=Get-AzureRmDnsRecordSet -RecordType TXT -ZoneName “ゾーン名(例:sub.adfs.jpだったら、adfs.jpの部分を指定)” -ResourceGroupName “リソースグループ名”
$dns | Where-Object {$_.Name -match “ドメイン名(sub.adfs.jpだったら、subの部分を指定)”} | Remove-AzureRmDnsRecordSet -Force

以上です。他のサイトでも見かけることができるような内容だと思いますが、必要であれば、使ってみてください。

【Azure AD】条件付きアクセスにある「ドメイン参加」の条件–ADFS編

$
0
0

皆さんこんにちは。国井です。

前回、条件付きアクセスに「ドメイン参加」の条件について紹介しました。
その中で、Active Directoryドメインに登録しているデバイスであることをAzure ADに
お知らせするために、Azure ADにデバイスを登録しなければならないという話をしました。

そのデバイス登録についてですが、Azure ADにデバイスを登録するときには、
Azure ADで認証を行い、認証が成功するとデバイスの登録が行われます。
(この図、間違っていたら、どなたかご指摘いただけるとありがたいです。)

一方、ADFSを利用している場合には、Azure ADで認証は行わないため、
私はデバイス登録を行いたい。でも、AD/ADFSを通じて既に認証は済ませているから、
Azure ADでの認証プロセスを省略してデバイスを登録させてほしい

というお願いをしなければなりません。

そのため、ADFSを利用している環境で、Azure ADの条件付きアクセスの「ドメインに参加しているデバイスが必要です」を利用する場合には、ADFSから発行されるクレームにデバイス登録を行うための情報(厳密に言うと、Azure ADデバイス登録サービスにデバイスを登録するためのアクセストークンをもらうための情報)を追加して、Azure ADにデバイスを登録するように依頼をします。
ADFSサーバー上で設定するAzure ADデバイス登録のためのクレームルールは証明書利用者信頼の[発行要求規則]から次の3つのルールを作成します。
(発行変換規則のうち、最初の2つはデフォルトの規則で、順序3~5が自動登録のために追加している規則です)

それぞれの規則で登録されている内容について、ざっくり見てみます。
まず、順序3ではaccounttypeクレームにDJという値をセットするというルールです。DJは「Domain Join」の略で、ドメインに参加済みのデバイスという意味です。

c:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(Type = “http://schemas.microsoft.com/ws/2012/01/accounttype”, Value = “DJ”);

次に順序4に登録されている規則は
onpremobjectguidクレームにobjectGUID値をセットするというルールです。

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”, Value =~ “-515$”,Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”] && c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname”,  Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(store = “Active Directory”, types = (“http://schemas.microsoft.com/identity/claims/onpremobjectguid”), query = “;objectguid;{0}”, param = c2.Value);

最後に順序5に登録されている規則は
primarysidクレームの内容をパススルーでセットする(つまりコンピューターアカウントのSIDをクレームの値として登録するってこと)というルールです。

c1:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid”,
Value =~ “-515$”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]&& c2:[Type == “http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid”, Issuer =~ “^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$”]
=> issue(claim = c2);

以上の設定を済ませ、グループポリシーが適用されると、ADFSで発行されたクレームをもってAzure ADにアクセスします。そして、クレームに記述されたobjectGUID値と同じ値を持つデバイスの情報は登録可能な状態となり、後にAzure AD Connectからディレクトリ同期が実行されることによって同一objectGUID値を持つドメイン参加のデバイスの情報がAzure ADに登録されます。
その様子はGet-MsolDeviceコマンドレットの他、Azure ADのSynchronization Service Managerからも確認できます。

クレームルールをADFSサーバーで書かなければならないのが面倒ですが、マイクロソフトさんのWebサイトにはクレームルール作成を自動化するスクリプトも置いてあるので、参考にしてください。

■Azure Active Directory への Windows ドメイン参加済みデバイスの自動登録の構成方法
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup

先進認証利用時のADFSによるアクセス制御について

$
0
0

皆さんこんにちは。国井です。

最近はOffice 2016, 2013を利用する企業も増えてきており、Office 365へのアクセスにADFSを利用している場合であれば「先進認証」を活用される企業も増えてきていると思います。
先進認証はブラウザーからSSOするときと同じように、パッシブプロファイルっぽいSSOアクセスを実現するものですが、認証・認可によってクライアントが受け取るトークンはブラウザーとは異なるものになります。

ブラウザーのSSOの場合はブラウザーを再起動すれば、改めて認証・認可を行い、トークンを発行しますが、Outlookなどのアプリケーションからの先進認証によるSSOの場合は一度トークンを発行すると、長い期間キャッシュを持つことになります。
そのため、ADFSサーバーでアクセス制御の設定を行っても、キャッシュを利用してしまうため、そもそもADFSサーバーにアクセスすることがなくなり、結果的にアクセス制御設定を無視してアクセスできてしまうという課題があります。

このような課題を乗り越えて、毎回ADFSサーバーにアクセスし、アクセス制御設定をチェックしてほしいという場合には、キャッシュを明示的に削除しなければなりません。
そこで今回は先進認証を利用しているケースにおいて、キャッシュを明示的に削除する方法について紹介します。

【基本】先進認証利用時のトークン

ADFSを利用している環境で、先進認証を利用している場合、Azure ADでは主に2種類のトークンを発行します。

・リフレッシュトークン
・アクセストークン (ベアラー)

まず、リフレッシュトークンはユーザー単位で発行されるトークンで、ざっくり言うとユーザー認証に成功したことを示すトークンです。トークンは14日間キャッシュされ、継続して利用していると最長で90日キャッシュされる、非常に長い有効期限に設定されていることが特徴です。リフレッシュトークンの情報はコントロールパネルの資格情報マネージャーから確認できます。
(ユーザー単位の発行だそうなんですが、実際には複数の資格情報が確認できます。なぜ?)

image

続いてアクセストークンは、Office 365の各サービスにアクセスするためのトークンで、有効期限は1時間と短く設定されています。
発行されたトークンの情報はレジストリの
HKEY_CURRENT_USER\Software\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\ <GUID>¥<GUID>\TicketCache
に保存されます。下の画面を見るとわかるように、サービス種類ごとに別々のトークンが発行されます。

image

予約時に発行されたチケットとボーディングチケット

最近は少なくなりましたが、航空券って予約した時に発券されるチケット(今はeチケットなどと呼ばれている、アレです)と、搭乗当日にカウンターで発行されるチケット(ボーディングチケット)の2種類がありました。私は数年ほど前、アメリカ ワシントンの空港で予約した時に発券されたチケットをもとにカウンターでボーディングチケットを発券してもらい、乗り場に向かいました。ところが、海外で様々なトラブルを引き起こす私のことなので、ボーディングチケットを乗り場に向かう最中に無くしてしまいました。
そこで私はゴリ押しでボーディングチケットなしで乗ろうと思い、
国井:「オレ、国井だけど、乗せてくれ」
係員:「は?何言っているの?だったら、予約した時のチケットを見せろ」
国井:「はい、どうぞ」
係員:「OK。ボーディングチケットを再発行しといたよ」
え、予約した時のチケットがあったら、ボーディングチケットって再発行されるの??
予約した時のチケットとボーディングチケットって、
アクセストークンが使えなくなったら、リフレッシュトークンを使ってアクセストークンを再発行する、リフレッシュトークンとアクセストークンの関係みたいですね。
何が言いたいかと言えば、どちらもチケット(トークン)がなくなったからといって、最初から手続きをやり直さなくてもいいってことです。

2つのトークンの関係は以下のMSさんのブログでも紹介されているので合わせて参考にして欲しいのですが、ユーザー認証後に受け取るデータがリフレッシュトークン(ブログ内ではauthentication_codeと表現)、authentication_codeをもとにOffice365にアクセスするための認可情報をアクセストークン(ブログ内ではOAuth JWTトークンと表現)と、パケットフローと共に紹介されております。

Office 製品の Office 365 モダン認証フローと認証キャッシュについて
https://blogs.technet.microsoft.com/sharepoint_support/2016/08/01/modern-authentication-flow-and-cache-of-office-to-office-365/

話が長くなりましたが、
以上のことから、Officeアプリから先進認証でOffice 365にアクセスした場合、最初だけADFSサーバーを利用した認証・認可を行うけれど、それ以降は14日~90日間はADFSサーバーを使うことがなくなることがわかります。
(事実、ADFSサーバーにはトークン発行のログが一切記録されません)

先進認証のキャッシュを削除する

先進認証のキャッシュを残さないようにして、ADFSサーバーによるアクセス制御をチェックさせるには、上記の場所からキャッシュを消せばいいのです。
消し方は次のとおりです。
アクセストークンの削除は次のコマンドレットを実行します。

cmdkey /list | where {$_ -match 'LegacyGeneric'} | foreach { cmdkey /delete "$($_.split()[-1])" }

一方、リフレッシュトークンの削除は以下のとおり。

reg delete HKEY_CURRENT_USER\SOFTWARE\Microsoft\Office\
<バージョン番号>\Common\Identity\Identities\
<GUID>\<GUID>\TicketCache

両方をクライアントコンピューターから削除したうえで、Outlookを起動すると、きちんとADFSサーバーにアクセスし、アクセス制御をチェックしたうえで、トークンが発行されます。
ADFSサーバーのイベントビューアを見ると、イベントID 1200のログ(Windows Server 2016の場合)がセキュリティログに記録されることが確認できます。

image

UserAgentの項目を拡大してみると、Microsoft Outlookって書いてあることがわかります。
(ちなみにSkype for Business クライアントの場合、それとわかるUserAgent文字列を残さないんですよね。。)

image

■ ■ ■

もうひとつの方法として、
Azure AD側で発行するトークンの期間をカスタマイズすることで、キャッシュをいつまでも使わず、トークン発行を頻繁に行うように構成することができます。

Azure Active Directory における構成可能なトークンの有効期間
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-configurable-token-lifetimes

本文中にもありますが、設定にはAzure AD Premium P1のライセンスが必要になるので、注意してください。

 

【おまけ】Skype for Business Onlineの先進認証設定

Exchange Onlineと同様にSkype for Business Onlineで先進認証を利用する場合も事前設定が必要ですので、https://www.microsoft.com/ja-jp/download/details.aspx?id=39366 からダウンロードしたツールを使って、以下のコマンドレットを実行しておいてください。

Import-Module SkypeOnlineConnector
$sfbsession=New-CsOnlineSession
Import-PSSession $sfbsession
Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

 

【余談】SharePoint Onlineへの先進認証
SharePoint Onlineへのアクセスに先進認証を利用する場合、SharePoint Online側で行うべき設定は無いのですが、先進認証を利用している/いないでアクセス制御ができるようです。

image

 

【参考】
Office365 先進認証についての検証
https://sharedtechv.wordpress.com/2017/01/23/office365-%E5%85%88%E9%80%B2%E8%AA%8D%E8%A8%BC%E3%81%AB%E3%81%A4%E3%81%84%E3%81%A6%E3%81%AE%E6%A4%9C%E8%A8%BC/

ユーザーアカウント管理
https://technet.microsoft.com/ja-jp/library/office-365-user-account-management.aspx

ADFS Rapid Restore ツールでADFSサーバーのバックアップ

$
0
0

皆さんこんにちは。国井です。

ADFSはSAML2.0に対応したWindows Server 2008のバージョン以降、利用する企業が随分と増えました。そうすると今度はADFSサーバーの運用をどうするか?という話が出てきます。色々と決めるべき事柄があると思いますが、中でも重要なのはバックアップではないかと思います。ベアメタルでバックアップしてしまえばよい、という考え方もあるでしょうが、一方でADFSに関わるコンテンツだけを独立してバックアップしておきたいというニーズもあるでしょう。
そんなときにおすすめなのが、ADFS Rapid Restoreツール。

Windows Server 2016と2012 R2のバージョンのADFSに対応する、このツールはPowerShellのコマンドレットを1つ実行するだけでバックアップ/復元ができてしまう優れもの。とっても簡単なので、わざわざ紹介するまでもないのですが、意外とハマリポイントもあるので、動きを見てみましょう。

インストール

マイクロソフトのWebサイトからダウンロードして、インストールするだけ。
ウィザード自体もNextボタンを連打していれば、インストール完了です。

バックアップの実行

PowerShellから実行するのですが、最初にモジュールをロードするコマンドレットを実行し、

import-module 'C:\Program Files (x86)\ADFS Rapid Recreation Tool\ADFSRapidRecreationTool.dll'

その後、以下のコマンドレットでバックアップを実行します。

Backup-ADFS -StorageType "FileSystem" -StoragePath "C:\testExport\" -EncryptionPassword "password" -BackupComment "Clean Install of ADFS (FS)" -BackupDKM

このコマンドレットでは、C:\testExportフォルダーにADFSサーバーのコンテンツをまとめてバックアップしてくれって命令を出しています。(フォルダーは事前に作っておいてください)
ちなみにマイクロソフトのWebサイトによれば、以下のコンテンツがバックアップされるそうです。

・ADFS構成データベース (WIDまたはSQL Serverに保存されているものです)
・ADFSサーバーのフォルダーに保存されている構成ファイル
・トークン署名証明書とその秘密キー
・SSL証明書とその秘密キー
・カスタマイズされた属性ストアなどのカスタム認証プロバイダー

バックアップでは、トークン署名証明書をバックアップしないなど、オプションを指定できます。バックアップのオプションに関しては、公式サイトでご確認ください。
(公式サイトの中でDKMという言葉が出てきますが、トークン署名証明書のことだとおもっていただければ、よいでしょう。もうちょっと細かく言うと、DKM=Distributed Key ManagerはADFSサーバーのトークン署名証明書などの証明書が格納されるActive Directoryのコンテナーのことです)

バックアップデータは、指定したフォルダー内に日付を付けたフォルダーが作成され、その中に保存されます。保存されるデータはこんな感じ。

バックアップデータはAES256で暗号化されているので、ファイルを開いても、何も面白いことは書いてありません。

リストア

これまた簡単で、Import-Moduleでモジュールをロードしてからリストアのコマンドレットを実行するだけ。

Restore-ADFS -StorageType "FileSystem" -StoragePath "C:\testExport\" -DecryptionPassword "password" -RestoreDKM

指定したフォルダーに格納されているファイルを読み取って、自動的にリストアしてくれます。ただし、リストア後のADFSサービスの起動は行ってくれません。これは、リストア後に手動で行う作業ができるようにするためです。これは気を付けたいポイントですね。
あと、リストアもオプションが色々ありますが、公式サイトで確認してください。

実際に実行してみた

私の環境では、こんな感じで実行してみました。

おいおい、よく見たらバックアップ失敗してるじゃないですか!
SSL証明書エクスポートできないって、オレ、Administratorだよ!
同じ境遇にある人はそう思うのではないかと思います。
しかし、SSL証明書ってインポートするときに、エクスポート不可能な状態でインポートしてしまうと、いくらAdministratorであろうとバックアップ時にエクスポートできなくなってしまうのです。(以下は手動でエクスポートしようとしたときの画面)

エクスポート不可能な状態で証明書をインポートしてしまったら最後、秘密キーへのフルコントロールアクセス許可があろうと、エクスポートはできなくなってしまいますので、その場合には、SSL証明書のリストアだけは手動で行う必要が出てきます。

あと、言い忘れたことなど

・ログは%localappdata%\ADFSRapidRecreationToolフォルダーから確認できます。
・2012 R2のバックアップデータを2016に復元できないので、アップグレードには使えません。
・リストア時のオプションを使えば、異なるサーバーへの復元や使用するデータベースの変更(WID→SQL、SQL→WID)ができます。

色々なシナリオを考えてみると、色々なオプションを使うことになるのでしょうが、
それについては、また別の機会に触れてみたいと思います。

Windows Server 2016 ADFSサーバーによる証明書認証

$
0
0

皆さんこんにちは。国井です。
だいぶ前の話になりますが、Azure ADの概念実証(PoC)に利用可能なプレイブックがマイクロソフトさんから公開されました。

■Azure Active Directory の概念実証戦略: 概要
https://docs.microsoft.com/ja-jp/azure/active-directory/active-directory-playbook-building-blocks#generic-ldap-connector-configuration

PoCの項目の中に「証明書ベースの認証を構成する」というのがありますが、Azure ADだけで実現する内容ではなく、実際にはADFSサーバーを使っています。最近、ADFSサーバーで証明書を使うシナリオはWindows Hello for Businessが絡んでくる関係で、色々なパターンがあるのですが、ここで解説しているシナリオはADFSでシングルサインオンするときに、証明書を使った多要素認証を行うパターンを紹介しています。
(以下の図では、ADFSサーバーにアクセスしてからの流れだけを紹介しています)

 

ADFSを使った証明書認証は以前にも「ADFSによる多要素認証の設定」で紹介させていただいたのですが、だいぶ時間が経過していることやQ&Aサイトなどで「国井のブログを見たとおりに設定したけど、うまくいかない」などの書き込みを見かけることがあり、
Windows Server 2016バージョンを改めて、まとめておこうかなと思ったわけです。

■ ■ ■

Windows Server 2016の証明書認証の設定は、以前のバージョンと同じく多要素認証の設定で証明書認証を利用するように定義します。
ADFS管理ツールから[サービス]-[認証方法]から[多要素認証方法の編集]で証明書認証を選択します。

image

また、同じ画面から[プライマリ認証方法の編集]で証明書認証を利用するように設定します。

image

その他、多要素認証を使うときは、証明書利用者信頼のアクセス制御ポリシーで、MFAを利用するようなポリシーを選択しておきます。

image

ADFSサーバーの設定はこれだけ。

一方、認証局の設定は基本的に「ADFSによる多要素認証の設定」で紹介した

・証明書サービスのインストール
・クライアントコンピューターへのユーザー証明書のインストール

の2つの項目通りに設定していただければ結構です。
このときに、認証局の設定ミスあるあるとして、

・CRLを発行・公開していない
image

・物理的にアクセスできない場所をCRLのパスとして指定している
(CDPとAIAにLDAPのパスがデフォルトに入っていますが、LDAPってFWの外からアクセスできないですよね)
image

などがあります。このあたりをちゃんとチェックしておきましょう。

以上が出来上がれば、証明書認証の設定は完了です。実際にOffice365のサイトにアクセスしようとすると、ADFSサーバーによるSSOプロセスの中で証明書認証が実行され、証明書を持っていれば勝手にサインインが完了し、証明書を持っていなければ認証エラーになります。

image

また、Windows Server 2016からの機能として、Webアプリケーションプロキシ経由のアクセスに証明書認証だけを使ったアクセス方法というのがあります。

image

ADFS管理ツールのプライマリ認証方法の設定で、エクストラネットの認証方法に[証明書認証]だけを選択することで、Webアプリケーションプロキシ経由のアクセスにユーザー名/パスワードを使わず、証明書だけを使って認証することができるようになります。今までのADFSって、Webアプリケーションプロキシを経由することで必ずユーザー名/パスワードを入れていたので、「なんだよ、シングルサインオンじゃないじゃん」って言ってた人もいると思います。しかし、Windows Server 2016からは場所を問わず、ユーザー名/パスワードを入力することなく認証を済ませることができるようになるのです。

Viewing all 66 articles
Browse latest View live


<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>