ワーク フォルダーについては、既定の Windows 認証のまま、パススルーで WAP で公開する方法を説明しました。ワーク フォルダーを AD FS 認証に切り替えることができることはわかっていたのですが、実際に動作させることができなかったため、AD FS 認証による WAP 公開は個人ブログでフォローアップすると書きました。
具体的な手順が以下のブログで公開されました。以下のブログを見ればわかりますが、情報なしで、これを正しく構成することなんてできませんよ (言い訳)。
The Storage Team at Microsoft - File Cabinet Blog > Deploying Work Folders with AD FS and Web Application Proxy (WAP)
[URL] http://blogs.technet.com/b/filecab/archive/2014/03/03/deploying-work-folders-with-ad-fs-and-web-application-proxy-wap.aspx
以前、この情報なしで自分なりに (つまり、適当に) 構成したところ、ワークフォルダーのセットアップ時にエクスプローラーがクラッシュするという状況になりました。→「連載: 『Windows 8.1の新しいファイル同期機能「作業フォルダー」』 - ASCII.jp (2013/09/19)」 今回、この情報を参考に日本語環境 (書籍と同じ環境) で試したところ、めでたく成功しました。
AD FS、ワーク フォルダー、WAPの構成については、 省略します。『Windows Server 2012 R2 テクノロジ入門』の第 3 章、第 5 章、第 8 章でそれぞれ説明しているとおりです。よかったら買ってください。ポイントになる以下の 3 点だけ、スクリーンショットで手順を説明します。Deploying Work Folders with AD FS and Web Application Proxy (WAP) にもスクリーンショットがたくさんありますが、ID 系は英語と日本語の対応が???なときがあるので...
Setup AD FS Relying Trust for Work Folders (ワーク フォルダー用の証明書利用者信頼を構成する)
Setup AD FS Authentication (ワーク フォルダーの AD FS 認証を構成する)
Publish Work Folders Web Application (WAP でワーク フォルダー Web アプリケーションを公開する)
---
(ワーク フォルダー用の証明書利用者信頼を構成する)
[AD FS] (AD FS の管理) スナップインを開き、[証明書利用者信頼の追加ウィザード]を開始。"証明書利用者信頼"="Relying Trust"です。
[証明書利用者についてのデータを手動で入力する]を選択する。
表示名を適当に。
[AD FS プロファイル]を選択。
何もせず[次へ]。
ここも何もせず[次へ]。
https://windows-server-work-folders/V1 を追加。windows-server-work-folders の名前解決とか考えなくていいです。ワーク フォルダーのアプリケーションの識別子らしい。ここが https://windows-server-work-folders/V1 である必要があることまでは、なんとなく分かってました (以前、クラッシュ エラーで失敗したときにイベント ログの内容から)。
[現時点では...]のまま[次へ]。
[すべてのユーザーに対してこの証明書利用者へのアクセスを許可する]を選択して[次へ]。
そのまま[次へ]。
チェックボックスをチェックして[閉じる]。
クレームの変換をこんな感じで設定する。Active Directory 側の属性が下手に日本語化されているのでわかりにくいっす。クレーム系の設定でいつもこんな感じで迷います。今回は、こちら (→ http://sssslide.com/www.slideshare.net/junichia/ad-fs-deep-dive-claim-rule-set by MS 安納氏 の「(参考) 既定のクレーム タイプの表示名」) を参考にさせていただきました。
User-Principal-Name → UPN
Display Name → 名前 (英語だと Name)
Surname →Surname
Given-Name → 指定名 (英語だと Given Name)
ここで 4 つのおまじない。こんなおまじない知らなかった。自分で設定して成功しないわけだ。
Set-ADFSRelyingPartyTrust -TargetIdentifier "https://windows-server-work-folders/V1" -EnableJWT $true
Set-ADFSRelyingPartyTrust -TargetIdentifier "https://windows-server-work-folders/V1" -Encryptclaims $false
Set-ADFSRelyingPartyTrust -TargetIdentifier "https://windows-server-work-folders/V1" -AutoupdateEnabled $true
Set-ADFSRelyingPartyTrust -TargetIdentifier "https://windows-server-work-folders/V1" -IssueOAuthRefreshTokensTo AllDevices
・・・
Setup AD FS Authentication
(ワーク フォルダーの AD FS 認証を構成する)
ファイル サーバーでワークフォルダーの認証方法を設定します。こんなところに設定がありました。
AD FS サーバーの FQDN を入力します。
Windows PowerShell なら次のコマンドライン 1 行でできます。これは知ってました。
Set-SyncServerSetting -ADFSUrl "https://<AD FS サーバーのFQDN>"
ちなみに、この時点でワーク フォルダーは AD FS 認証に完全に切り替わります。Windows 8.1 クライアントからワーク フォルダーをセットアップすると、Windows 認証ではなく、AD FS 認証が要求されました。
ちなみに、既定の Windows 認証の場合は、こんな (→) 感じで通常の[Windows セキュリティ]ダイアログ ボックスが出てきます。
ドメイン メンバーの Windows 8.1 PC にドメイン ユーザーでサインインしている場合は、パススルー認証できるので資格情報の入力は必要ありません。
Publish Work Folders Web Application
(WAP でワーク フォルダー Web アプリケーションを公開する)
WAP では、ワーク フォルダーをクレーム対応 Web アプリケーションとして AD FS 事前認証でリバース プロキシ公開できます。
AD FS 側で設定したワークフォルダー用の証明書利用者信頼を選択します。
外部および内部 URL に https://workfolders.<FQDN> を設定し、適切な SSL 証明書を指定する (共通名または DNS 代替名に workfolders.<FQDN> が設定されている) のがポイント。
ここでも Windows PowerShell でおまじない。このおまじないもとっても大事。
Get-WebApplicationProxyApplication -Name <公開名>|Set-WebApplicationProxyApplication -UseOAuthAuthentication
おまじないをしないと、WAP 経由でワーク フォルダーに接続したセットアップ済みクライアントはこんなエラーで同期が停止。
新規にセットアップ使用とした場合も同じエラー (0x80072f0c)。
おまじないの効果で、セットアップも同期も OK に。なお、エクストラネットからワークフォルダーをセットアップした場合、次のように AD FS の Web 認証フォームが出ます。
こちらはイントラネット (192.168.10.0/24) で WAP を経由せずにワーク フォルダーと直接同期しているところ。ワーク フォルダー (workfolders.demo.contoso.com: 192.168.10.66) や AD FS サーバー (adfs.demo.contoso.com: 192.168.10.70) と直接通信できる環境です。
こちらは同じコンピューターをエクストラネット (192.168.20.0/24) に持っていって、WAP 経由でワーク フォルダーと同期しているところ。エクストラネットを用意するのはめんどいので、WAP サーバーをマルチ ホーム (wap.demo.contoso.com: 192.168.10.71, 192.168.20.71) にして、Windows 8.1 コンピューター (192.168.20.123) と閉じたネットワークで接続 (実際には Hyper-V の仮想環境) し、hosts ファイルで名前解決させました。
・・・例えば、
●社内のBYODデバイスからのワークフォルダーへの接続は、ワークプレース参加の登録済みデバイスに限定する (WAP を社内に設置する)
●社外からのワークフォルダーへの接続に多要素認証 (標準だとスマート カード認証) を要求する (境界に WAP を設置する)
なんてことができます。どちらも、ワークフォルダーを既定の Windows 認証で構成した場合にはできないことです。
以前書いた「Windows Server 2012 R2 & System Center 2012 R2 評価ガイド」 (→ MS) では、下のようなポンチ絵を描きましたが、ようやくこのとおりに動かすことができました。ただし、かじりかけのリンゴさんデバイスは除きます。かじりかけのリンゴさんデバイスは、ワークプレース参加はできますが、ワーク フォルダーには未対応です (当初の情報では将来アプリで対応予定とのこと)。
・・・
長々と書きましたが、何のことやら?って感じでしょう。この記事は『Windows Server 2012 R2 テクノロジ入門』(→日経BP) のフォローアップです。書籍と同じ環境で確認しましたので、書籍とあわせて参照していただければ、いろいろと理解できると思います。
0 件のコメント:
コメントを投稿
注: コメントを投稿できるのは、このブログのメンバーだけです。