GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう!

Ask the Speaker 写真撮影動画撮影
セッション資料
後日公開
Twitter ハッシュタグ
SE03
GoodBye AD FS
Azure Active Directory Only の認証方式へ切り替えよう!
マイクロソフトコーポレーション
Program Manager, Identity Division
兒玉雄介
#decode19 #SE03

de:code 2019 SE03
Good Bye AD FS - Azure Active
Directory Only の認証方式へ切り替えよう!
マイクロソフトコーポレーション
Program Manager, Identity Division
兒玉雄介

自己紹介
兒玉雄介 Yusuke Kodama
Azure AD 開発部門 PM
仕事
お客様要件と製品のギャップを埋める

このセッション終了後
どうして Good Bye AD FS するのか？ (WHY?)
やる価値が訴求できないと案件化できないし・・・
Good Bye AD FS の手順は？ (HOW?)
タスクの全体像が見えないと工数試算出来ないし・・・
じゃあ、なにから着手すればよいの？ (To Do)
案件化する前に何か明日からできることは・・・？

AD FS の世界
Azure
SaaS
オンプレミス
Windows Server
Active Directory
AD FS
Azure AD Connect
クラウド
フェデレーション信頼
WAP
アカウント同期
DMZ
Azure AD
認証の通り道

どうして Good Bye AD FS なのか？
セキュリティ
コスト
事業継続性 (可用性)

最も重要なメリットはセキュリティ向上
サイバー攻撃への対応として (Link)
Azure AD のセキュリティメリットを最大限享受

すべての Azure AD テナント
(検証/テストテナントを除く)
36.6%
63.4% 77.8%
22.2%
直近 3 カ月以内に作られた
Azure AD テナント
フェデレーション認証
AD FS, 3rd Party IdP など
クラウド認証
Password Hash Sync, PTA

古いセキュリティの考え方を変えることを決意
昔構築した環境のセキュリティコンセプトが古くなっていた
VPN

最新の制御には条件付きアクセスが必須
場所は関係なく、常にデバイスの状態を評価する
ゼロトラストネットワーク
セキュリティの概念

どうして Good Bye AD FS なのか？
• IP ベースのアクセス制御から脱却してよりセキュアな環境を構築しよう (Link)
• モダンアクセスコントロール実現に向けた戦略策定方法 (Link)
• ハイブリッド ID ソリューションの適切な認証方法を選択する (Link)
• Azure AD Webinar セッション > 適切な Azure AD 認証方式の選択の決め手
(Link)
• de:code 2018 セッション AD FS では守れない？！アカウント乗っ取りを防ぐために
すべき 3 つのこと～ユーザー企業の実例のご紹介～ (Link)
もっと詳しく

ステップ①：Azure AD と AD FS を切断
Azure
SaaS
オンプレミス
Windows Server
Active Directory
AD FS
Azure AD Connect
クラウド
WAP
DMZ
Azure AD

ステップ②：アプリを移行
Azure
SaaS
オンプレミス
Windows Server
Active Directory
AD FS
Azure AD Connect
クラウド
WAP
DMZ
Azure AD

ステップ③：Say Good Bye to AD FS
Azure
SaaS
オンプレミス
Windows Server
Active Directory
AD FS
Azure AD Connect
クラウド
WAP
DMZ
Azure AD

Good Bye AD FS のロードマップ
事前準備
Azure AD
AD FS 連携切断
AD FS 連携
アプリ移行
AD FS 停止
移行実施
メリット
① ② ③
①と②は並行実施可能

Step1: Azure AD-AD FS 連携切断

1-a. 先進認証の有効化
条件付きアクセスを利用する場合に必須の措置
Exchange Online と Skype for Business で有効化が必要
2017/8 以降契約のテナントでは自動で ON
クライアントアプリ側も先進認証に対応する必要がある
基本、Office 2013 以降。2010 は NG
重要：レガシー認証は多要素認証が利用できないため攻撃の対象となっており、直
ちに先進認証を利用するよう切り替え、およびレガシー認証をブロックすることを推奨

1-b. 認証方式の決定
いずれもクラウド認証の分類であるが、PHS が MS 推奨
パスワードハッシュ同期 (PHS) パススルー認証 (PTA)
アカウント/パスワード
同期
PTA
Agent
PTA
Agent
パスワード検証
※ 以後、PHS 選んだ前提で話します

1-c. 条件付きアクセス (CA) 実装
最初に M365 Golden Config を参照する

1-c. 条件付きアクセス (CA) 実装
既存のクレームルールをそのまま移行しない
多くの企業では、時代に合わないネットワークベース設計になっている
条件付きアクセスポリシー設計の進め方ガイドを参照
設計時には開発チームが提供している設計テンプレートを利用
• Ｍ365 Golden Config (Link)
• Azure AD Webinar -詳説！Azure AD 条件付きアクセス (仕組み編, 設計編)
• Deployment Plans – Conditional Access (Link)
もっと詳しく

アクセスコントロールの新旧比較
UPN 入力 User Name
***********
条件付き
アクセス評価
90 日間

1-d. パスワードハッシュ同期実装
事前に全ユーザーのパスワードハッシュを同期
• 同期にはある程度時間がかかる (20,000 user/hour)
• 同時にシームレス SSO の設定も入れておくことを推奨
この作業では認証フローは変わらない
パスワード同期はセキュリティ上問題にならない
重要：AD FS を使い続けるとしても、パスワードハッシュ同期だけはやる
(漏洩した資格情報検知レポート、災害対策のため)

1-e. Staged Rollout による段階移行
フェデレーションドメインに属するユーザーの一部のみを Managed
Authentication にスイッチする機能が登場
Azure AD
Windows Server
Active Directory
Federation Provider
(AD FS)
contoso.com contoso.com
1
2
3
認証
1
2
認証

1-e. Staged Rollout で安心な移行
Contoso.com：Federated
・・・
・・・
認証は AD FS で発生認証は Azure AD で発生
テストユーザー
・・・
段階移行
Managed

1-f. ドメイン切り替えの実施
Azure AD Connect のアップグレード (1.1.819.0+)
詳細手順：Azure Active Directory でフェデレーションからパスワードハッシュ同期に移行する
ドメイン切り替え後、ユーザーの認証先が切り替わるまで最大で 4 時間程度
Azure AD Connect で
認証方式を切り替え
Azure AD Connect で
ユーザーサインイン設定を変更
Azure AD PS モジュールで
ドメインを変換
AD FS を AADC で構成したか？
YES NO

三井物産・MKI 様の場合
移行の作業
事前準備後の Staged Rollout 検証期間は 4 週間
事前のエンドユーザー周知・教育はナシ (問い合わせ 0 件)
やってよかったと思うこと (コメントそのまま掲載)
シンプルな構成でこれから何をやるにしてもやりやすくなった
欧米からの O365 アクセスが体感で速くなった
社内からの SaaS 連携依頼が圧倒的に増えた

シングルサインオンの提供
PHS + SSSO で PC ログインとアプリのログインを SSO
アクセスコントロールの提供
条件付きアクセスを用いてより細かく精密な制御を
特有な認証要件への対応
• レガシー認証のブロック
• 3rd Party 多要素認証製品との連携
• 証明書/Authenticator App を用いたパスワードレス施策
AD FS (フェデレーションサービス) の主な役割

レガシー認証ブロックは CA で実装
CA にて実装可能 (できればアプリでブロック)
CA の割り当て条件はすべて利用可能
(だが、基本すべてブロックを推奨)

レガシー認証ブロック
ベースラインポリシーに追加されました

カスタムコントロールで 3rd Party IdP 連携
3rd
Party の認証ツールを条件付きアクセスからトリガー
現状では以下に対応
Duo Security
Entrust Datacard
Ping Identity
Azure MFA の置き換えではなく、特別なリソースに対する
“追加” のセキュリティ対応として実装するためのもの
• SecureAuth
• Silverfort
• Symantec VIP
• Trusona

パスワードレスは最新の方法で実現しよう
現在証明書で実装しているパスワードレスの施策は別の方
式で実装できる可能性がある
• Windows Hello for Business
• FIDO 2.0
• Phone Sign-In
Aka.ms/GoPasswordLess をチェック

Call to Action
先進認証有効化
パスワードハッシュ同期の有効化
条件付きアクセス設計開始
セキュリティのために。条件付きアクセスで必須
漏洩したパスワードの検出、災害対策
Zero Trust への第一歩

Step2: AD FS 連携アプリ移行

アプリを Azure AD に繋げる利点とは？
セキュリティ機能運用機能
非機能要件を
Azure AD が負担する
Azure AD

B2B をアプリの外部ユーザー共有シナリオに利用
これまで
アプリ
社員用アカウント外部アカウント
これから
アプリ
社員用アカウント
外部アカウント
招待
詳細は Azure AD B2B の Webinar で！：Azure AD で実現するスムーズな外部パートナー協業

2-a. アプリケーション分析からまず着手
AD FS Migration Tool を用いてアプリ移行を計画
移行可能、要確認、アプリ変更要の 3 パターンに分類
確認するポイント、移行できない理由をレポートに明示
https://github.com/AzureAD/Deployment-Plans/tree/master/AD FS%20to%20AzureAD%20App%20Migration

Stats Numbers %
Total Number of Applications 36
Applications that may need to be Modified 20 55.56%
Applications that need further Review 6 16.67%
Applications that can be migrated Today 10 27.78%
Percentage of apps that can be migrated 27.78%

Application Status Notes of Failure/Warning Claim Rules to Review Attributes Not Synced to AAD by Default Authorization Rules Present Restricted Claim Types
Active Directory Pass
N/A
0 0 0 0
AtHoc Messaging Notification Pass
N/A
0 0 1 0
Black Board Stage SAML Fail
Warning: Custom Issuance Transform Rules
Fail: SAML Request Signing Required
1 0 1 0
Campuslogic Production Fail
Warning: Auto Update Enabled on App
Fail: SAML Token Encryption Enabled
Warning: Monitoring Enabled on App
0 1 1 0
Campuslogic Sandbox Fail
Warning: Monitoring Enabled on App
0 1 1 0
CRM IFD Relying Party TEST environment Fail
3 0 1 0
Dub Labs Application - Production - ACC Pass
N/A
0 0 1 0
Dub Labs Application - Production - WCU Pass
N/A
0 0 1 0
Dub Labs Application - Test - WCU Pass
N/A
0 0 1 0
Dub Labs Application -Test - ACC Pass
N/A
0 0 1 0
Dynamics CRM Claims Relying Party PROD Fail
3 0 1 0
Dynamics CRM IFD Relying Party for DEV Fail
3 0 1 0
External Dynamics CRM for PROD Fail
3 0 1 0
EZProxy_ACC Fail
0 0 1 0
Host Analytics Pass
N/A
0 0 1 0

RP Name RuleSet Rule IsKnownRuleMigratablePattern KnownRulePatternName
Black Board Stage SAML IssuanceTransform
@RuleTemplate = "LdapClaims"
@RuleName = "Transform Username to NameID"
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer
== "AD AUTHORITY"]
=> issue(store = "Active Directory", types = ("SamAccountName"), query =
";sAMAccountName;{0}", param = c.Value);
TRUE Extract Attributes from AD
Black Board Stage SAML IssuanceTransform
@RuleTemplate = "MapClaims"
@RuleName = "Transform Email to Name ID"
c:[Type == "SamAccountName"]
=> issue(Type =
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier", Issuer =
c.Issuer, OriginalIssuer = c.OriginalIssuer, Value = c.Value, ValueType =
c.ValueType,
Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/format"] =
"urn:oasis:names:tc:SAML:1.1:nameid-format:emailAddress");
FALSE N/A
Campuslogic Production ImpersonationAuthorization
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/primarysid",
Issuer =~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
=> issue(store = "_ProxyCredentialStore", types =
("http://schemas.microsoft.com/authorization/claims/permit"), query =
"isProxySid({0})", param = c.Value);
TRUE ADFS V2 - ProxySid by user
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/groupsid", Issuer
=~ "^(AD AUTHORITY|SELF AUTHORITY|LOCAL AUTHORITY)$"]
"isProxySid({0})", param = c.Value);
TRUE ADFS V2 - ProxySid by group
c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/proxytrustid",
Issuer =~ "^SELF AUTHORITY$"]
"isProxyTrustProvisioned({0})", param = c.Value);
TRUE ADFS V2 - Proxy Trust check
Campuslogic Production IssuanceAuthorization
@RuleTemplate = "AllowAllAuthzRule"
=> issue(Type = "http://schemas.microsoft.com/authorization/claims/permit", Value =
"true");
TRUE Permit All
Campuslogic Production IssuanceTransform
@RuleTemplate = "LdapClaims"
@RuleName = "Campuslogic Production claim rule"
c:[Type ==
"http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer
== "AD AUTHORITY"]
=> issue(store = "Active Directory", types =
("http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier",
"westcoastuniversity/StudentID",
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress",
"westcoastuniversity/FirstName", "westcoastuniversity/LastName"), query =
";employeeNumber,employeeNumber,mail,givenName,sn;{0}", param = c.Value);
TRUE Extract Attributes from AD

利用には Azure AD Connect Health の有効化が必須
今から導入しておきましょう

2-b. App ギャラリーにアプリを登録しよう
Application Gallery に載っていないアプリは登録する
• 申請から 10 -12 営業日程で登録される
• 事前に Microsoft による連携検証が行われるため、安心
https://docs.microsoft.com/ja-jp/azure/active-directory/develop/howto-app-gallery-listing
アプリベンダー担当者
お客様
申請
申請
お客様から
アプリベンダーにお願い、
のパターンがベスト！

2-c. アプリ用 CA ポリシー
アプリ向けのアクセスコントロール設計を検討
Office 365 と異なるアクセス制御が必要となる場合には CA ポリシーを作成

2-d. アプリケーションの移行
SaaS はギャラリーによる連携を実施
載っていない場合にはすぐに申請を！
LOB アプリは Non ギャラリー連携を実施
場合により Azure App Proxy による外部公開を組み合わせる
AD FS から Azure AD へのアプリ移行ガイドを参照
https://aka.ms/migrateapps/AD FSsolutionguide
https://aka.ms/migrateapps/whitepaper

アプリケーション移行を支援する機能強化
新しいクレーム変換メソッドのサポート (doc)
ToUpper, ToLower, ExtractAlpha() – Prefix などが追加に
SAML/OIDC グループクレーム (doc)
ユーザーが所属するグループ名をトークンを含められるように
SAML トークン暗号化 (doc)
トークンのインターセプト対応としてのアサーション暗号化機能

さらなる機能強化のロードマップ
Apply multiple transformation on the same claim
• 同じクレーム値に対して複数の変換ルールを適用
• YKODAMA@MICROSOFT.COM -> ykodama
• ToLowerCase(ExtractEmailPrefix(($email))
Conditional claims
• 条件によりクレーム構成 (種類、値) を操作
• グループメンバーシップ、ユーザータイプ (Member, Guest) などが条件
App integration API
• アプリ連携を API 経由で。設定のバックアップにも

Call to Action
AD FS アプリケーションの棚卸を開始
SaaS アプリケーションのギャラリー登録申請
次から導入するアプリは Azure AD に連携すること
移行可能アプリを可視化し移行計画を開始
ベンダーによる事前テストで安心な移行を

このセッション終了後
どうして Good Bye AD FS するのか？
セキュリティ、業務継続性、コスト
組織のアクセスコントロールを次のステップへ
Good Bye AD FS の手順は？
まずは O365 から着手、その後その他のアプリへ
Staged Rollout の利用により安全に、段階的に移行可能

明日、なにから着手すればよいの？
O365 認証方式変更に向けて
先進認証有効化
パスワードハッシュ同期の有効化
条件付きアクセス設計開始
アプリ移行に向けて
AD FS Migration Tool でアプリの棚卸を開始
SaaS アプリケーションのギャラリー登録申請
新規アプリは Azure AD に連携開始

DAY 時間 ID タイトル
1 12:30 - 13:20
SE01 Azure Active Directory のログの "みかた" - 長
期保存・外部 SIEM 連携・分析手法 -
1 16:30 - 17:20
SE51 Cloud Security Boot Camp
- Zero Trust vs VPN
1 17:30 – 17:50
SE82 20 分で理解する Azure Active Directory
最新アップデートと利活用シナリオ
2 15:00 – 15:50
CD03 Azure Active Directory B2C/B2B コラボレーショ
ンによる Customer Identity and Access
Management (CIAM) の設計と実装

Azure AD 開発チームの Webinar もチェック！
https://aka.ms/AzureADWebinar

© 2018 Microsoft Corporation. All rights reserved.
本情報の内容（添付文書、リンク先などを含む）は、作成日時点でのものであり、予告なく変更される場合があります。
© 2019 Microsoft Corporation. All rights reserved.
本情報の内容 (添付文書、リンク先などを含む) は、de:code 2019 開催日 (2019年5月29~30日) 時点のものであり、予告なく変更される場合があります。
本コンテンツの著作権、および本コンテンツ中に出てくる商標権、団体名、ロゴ、製品、サービスなどはそれぞれ、各権利保有者に帰属します。

新しいサインイン間隔調整の機能
ASLP (Adaptive Session Lifetime Policy)
• Custom Token Lifetime の代わりとなる機能
• 特定シナリオで利用できるサインイン間隔をコントロールする機能

GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう!

GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう!

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう!

Similar to GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう! (20)

Recently uploaded

Recently uploaded (9)

GoodBye AD FS - Azure Active Directory Only の認証方式へ切り替えよう!