今までありがとうございました。(ブログ終了)
---------------------
●●の皆様へ
拝啓 皆様にはますますご清栄のこととお喜び申し上げます。
さて、私事
このたび一身上の都合により、平成XX年XX月XX日をもちまして、退社いたしました。
在職中、皆様には一方ならぬお世話を賜り、また、ご指導ご厚情いただきまして誠にありがとうございました。
今後は新しい職場にて心機一転、頑張っていきたい所存です。
末筆ながら皆様に心より御礼申し上げまして、書中をもって、退職の挨拶とさせていただきます。
敬具
平成XX年XX月XX日
△△ △△
---------------------
ADFS (Active Directory フェデレーションサービス) とは
■ADFS (Active Directory フェデレーションサービス) とは
Active Directory フェデレーションサービスは、
Microsoft の ID フェデレーション(連携)ソリューションになる。
ファイアウォールで守られている自社環境に AD DS ドメインというセキュリティ協会を構築し、
そこにパッケージアプリケーションや自社開発の業務アプリケーションを展開してきた。
そしてユーザーは ADDSドメインに参加しているデスクトップPC などを使用して、
業務を行ってきた。
しかし、現代ではパッケージアプリケーションの代わりにパブリッククラウドの
SaaS アプリケーションを使用する企業も増え、ADDSドメインに参加している端末のほかに、
ADDSドメインに参加できないモバイルデバイスを使用するユーザーが増え、
会社だけでなく、自宅や外出先から仕事するユーザが増えてきた。
その結果、現在はセキュリティ業界を ADDSドメインの外まで広げて考えなければならなくなっている。
そのときに対策の一つが、インターネット上の SaaSアプリケーションのユーザー認証であり、
ユーザーが使用するモバイルデバイスのデバイス認証です。
どちらの実装も ADFS を展開することで実装できます。
ADFS は ADDSドメインの環境に現在のワークスタイルに適した、フェデレーション認証昨日を提供してくれる
Windows Server のサービスです。
●ADFS による IDフェデレーション(連携)の実装
従来の ADDSドメイン環境では、1つの組織内でユーザID を管理し、ユーザーを認証しサービスを提供します。
しかし、IDフェデレーションの環境においては、ユーザーの認証とサービスの提供が同じ組織であっても、
別の組織であっても問題ではなく、ユーザーを認証する側とサービスを提供する側とで、
ID 情報を紐付け、ユーザーがサービスを利用できるようにします。
(ID フェデレーションとは、ID情報を紐付けることをさします)
ユーザーID の登録や管理は、ユーザーを認証する側がおこないます。
従って、サービスを提供する側でユーザーID を管理する必要はありません。
サービスを提供する側は、サービスにアクセスしてくるユーザーに対して、
サービスを提供してよいかどうかを判断するだけです。
ADDSドメイン環境とは異なり、IDフェデレーションを実装することで、
ID管理、認証、および許可を組織の境界を越えて展開できるようになる。
ADFS は、この IDフェデレーションのソリューションを実装するための、
Windows Server サービスです。
ADFS にはいくつかのバージョンがあり、
Windows Server 2012 R2 では ADFS3.0 を提供している。
ADFS をインストールしたサーバーをフェデレーションサーバと予備、フェデレーションサービスの
冗長化構成のことをフェデレーションサーバーファームと呼びます。
IDフェデレーションは Microsoft 独自の技術ではありません。
Windows Server の AD FS は、IDフェデレーションの代表的なインターネット標準プロトコルに準拠しているため、
他ベンダが提供する IDフェデレーションソリューションと相互運用することも可能。
●要求ベース認証(クレームベース認証)
IDフェデレーションでは、要求ベースの認証が使用されます。
要求ベースの認証では、サービスを提供する側の組織が許可認証を行います。
サービス提供側の組織がユーザー認証側の組織に許可認証に必要な情報を要求(クレーム)します。
そして、その要求を受けたユーザー認証側の組織が必要なユーザー情報をサービス提供側の組織に渡します。
これを「要求ベースの認証」(クレームベースの認証)と呼びます。
ADFSにおいて、ユーザー認証側の組織を「要求プロバイダー」、
サービス提供側の組織を「証明書利用者」と呼びます。
要求プロバイダーと証明者利用者は、ユーザー情報の受け渡しに関する約束事(要求規則)を事前に取り決めておきます。
要求プロバイダーはその約束事に基づいて、「属性ストア」からユーザー情報を取得します。
属性ストアとは、ユーザー情報の格納庫のことです。
既定の属性ストアは、ADDSドメインコントローラです。
この場合、ドメインコントローラは認証サーバーであり、属性ストアとして動作します。
ドメインコントローラが属性ストアの場合、電子メールアドレス属性、UPN属性、役職属性などが取得できます。
属性ストアから取得されたユーザー情報の1つ1つを「クレーム」と呼び、
クレームは「トークン」という形式で相手の組織に渡されます。
トークンとは、許可処理に必要なクレーム(ユーザー情報)のセットで、トークンを発行した
フェデレーションサーbしうによってデジタル署名が付加されます。
要求ベースの認証では、ユーザー認証はユーザーが所属する組織で一度に行われるだけで、
認証処理と許可処理を別の組織に分けておこなうことができます。
そして、ここで発行されたトークンは、HTTPS を使用してインターネット上で受け流すことができます。
したがって、要求ベースの認証を使用すると、ユーザーはインターネットに
公開されているサービスに対するシングル・サインオン(SSO)を実現することができます。
●フェデレーション信頼
要求ベースの認証を使用するには、ユーザーを認証する側の組織とサービスを提供する側の組織の間で、
信頼済みを構成する必要があります。
この関係をフェデレーション信頼といいます。
フェデレーション信頼は、ADDSのフォレスト信頼とは異なります。
フェデレーション信頼においては、2つの組織間でフェデレーションサーバやドメインコントローラが
直接通信することはありません。
さらに、フェデレーションサーバーはHTTPS(TCP443)で通信するので、ファイアウォールに追加で
ポートをいくつも開く必要がありません。
フェデレーション信頼には目的にあわせて2種類の信頼関係が用意されています。
1つが「要求プロバイダー信頼で、もう1つが「証明書利用者信頼」です。
要求プロバイダー信頼は、ユーザー認証を行う認証機関の登録に使用されます。
証明書利用者信頼は、ADFSが発行したトークンの利用先(サービスやアプリケーション等)の登録に使用されます。
社内のドメインコントローラに対する要求プロバイダー信頼は、既定で作成されます。
しかし、サービスを提供する組織に向けた証明書利用者信頼は、
管理者が作成する必要があります。
＜参考情報＞
AD FS の概要
https://technet.microsoft.com/ja-jp/library/cc755226(v=ws.11).aspx
Windows Server 2012 R2 の AD FS 用のラボ環境をセットアップする
https://msdn.microsoft.com/ja-jp/library/dn280939%28v=ws.11%29.aspx?f=255&MSPPError=-2147217396
Active Directory フェデレーション サービスの概要
https://technet.microsoft.com/library/hh831502?f=255&MSPPError=-2147217396
ステップ バイ ステップ ガイド - Windows Server 2008 R2 の AD FS
https://technet.microsoft.com/ja-jp/library/dd378921
Microsoft Office 365 自習書 AD FS によるシングル サインオン環境構築ステップ バイ ステップ ガイド
https://www.microsoft.com/ja-jp/download/details.aspx?id=28716
＜一般サイト＞
[AD FS]Windows Server 2012 R2 Preview の AD FS ①
http://idmlab.eidentity.jp/2013/06/ad-fswindows-server-2012-r2-preview-ad.html
Windows Server 2012によるADFS構築
http://blog.o365mvp.com/2013/03/31/windows-server-2012%E3%81%AB%E3%82%88%E3%82%8Badfs%E6%A7%8B%E7%AF%89/
Windows Server 2012 R2によるADFS構築
http://blog.o365mvp.com/2013/09/29/adfs_install_manual_win2k12r2/
sysprepa
ご提供頂きましたイベントログを確認致しましたところ、
Service Control Manager ID:7000 が記録され、
以下のサービスが起動できていないことを判断しております。
Sysprep 実行後の対象製品の障害を調査することは可能です。
そのためには、調査観点を明確にして頂く必要がございますので、
各製品サービスの起動に失敗する、失敗した際のエラーメッセージや、
特定の操作においてのみ事象が発生する等の情報をお寄せ頂きたく存じます。
今回の対象サーバにて、各製品再インストール、もしくはシステムリストアをせずに
現行の状態から復旧される場合は、上述の Sysprep サポート可の製品を対象に
調査を実施させて頂きます。
ローカルポリシー削除
以下のグループポリシーを利用してシャットダウンのタイミングで
バッチファイルを自動実行させることができます。
ドメインポリシーで以下のポリシーを設定することで、
適用対象のクライアントがシャットダウンする際に、
バッチファイルに組み込んだ rd コマンドが実行され、
GroupPolicy フォルダを削除します。
削除された GroupPolicy フォルダは、[ローカルグループポリシーエディター] を開くことで再作成される動作を確認しております。
クライアントでローカルポリシーの定義しているような環境でなければ、
設定いただくことをご検討いただければと存じます。
もしくは、以下のバッチファイルをクライアントに配布しておき、
必要に応じて実行いただくなどの対応をあわせて検討願います。
以下には、対処方法のご参考として、検証環境で確認致しました手順を記載致します。
検証いただいた上、手順を確立頂きますようお願い致します。
○グループポリシー
[コンピュータの構成]
- [Windowsの設定]
- [スクリプト(スタートアップ/シャットダウン)]
○コマンド構文例
rd %Systemroot%\System32\GroupPolicy /s /q
コンピューター シャットダウン スクリプトを割り当てる
https://technet.microsoft.com/ja-jp/library/cc770300(v=ws.11).aspx
Rd
https://technet.microsoft.com/ja-jp/library/cc726055(v=ws.10).aspx
--------------
/s
(指定したディレクトリとすべてのファイルを含む、そのすべてのサブディレクトリ) には、ディレクトリ ツリーを削除します。
/q
Quiet モードを指定します。 確認のため、ディレクトリ ツリーを削除するときを表示しません。 (その/q/s /s が指定されている場合の動作に注意してください)。
--------------
