4. User and Device Claims
Pre-2012: Security Principals Only
• Restricted to making policy decisions based on the user’s group memberships
• Shadow groups are often created to reflect existing attributes as groups
• Groups have rules around who can be members of which types of groups
• No way to transform groups across AD trust boundaries
• No way to control access based on characteristics of user’s device
Windows Server 2012: Security Principals, User Claims, Device Claims
• Selected AD user/computer attributes are included in the security token
• Claims can be used directly in file server permissions
• Claims are consistently issued to all users in a forest
• Claims can be transformed across trust boundaries
• Enables newer types of policies that weren’t possible before:
• Example: Allow Write if User.MemberOf(Finance) and User.EmployeeType=FullTime and
Device.Managed=True
5. Expression-Based ACEs
Pre-2012: ’OR’ of groups only
• Led to group bloat
• Consider 500 projects, 100 countries, 10 divisions
• 500,000 total groups to represent every combination:
• ProjectZ UK Engineering Users
• ProjectZ Canada Engineering Users [etc…]
Windows Server 2012: ‘AND’ in expressions
• ACE conditions allow multiple groups with Boolean logic
• Example: Allow modify IF MemberOf(ProjectZ) AND MemberOf(UK) AND MemberOf(Engineering)
• 610 groups instead of 500,000
Windows Server 2012: with Central Access Policies & Classification
• 3 User Claims & Resource Properties
7. ACL（Access Control List）ベースのアクセスコントロール
• リソースにアクセスコントロールエントリ（ACE）を静的に割り当てる
• 各 ACE は「OR」で接続される
ユーザー
ACL ACE
ACE
Read/Write
ACE
Resource
グループ
ACE ACE
ACE A
Read Only
8. AGDLP
A :Account
G : Global Group
DL : Domain Local Group ユーザー
P : Permission
組織や役割ごと
ACL のグループ
グローバル
ACE
グループ
“アクセス権”に
ACE 合わせて作成さ
Resource れたグループ
ACE ドメイン ローカル グローバル
グループ
グループ
ACE
Read Only
9. 静的なACLを動的に管理するための Id プロビジョニングシステム
• 「静的」な ACE を「動的」に割り当てる仕組みも存在する
• Forefront Identity Manager のダイナミックグループ機能
グループ
メタデータ
グループ
A
workflow
12. グループベース RBAC の限界
• リソースの増加とグループの増加
• 複雑なメンバーシップ管理（1グループ1人 !?）
• イレギュラーでダイナミックな組織構造
• リソース管理者 ≠ ID 管理者
アクセス管理
連携が必要 ID 管理（ID 管理者）
（リソース管理者）
ACL
A A
Resource ACE
ACE
A A A
ACL A
Resource ACE A A
ACE
A
A A
A
13. Expression-Based Access Control
• ユーザー側の属性とリソース側で定義した属性の条件によってアクセスを制御
条件が合致すればアクセス可能
アクセスルール
ユーザーCountry = リソース Country
ユーザー Department = リソース Department
デバイス Owner = “Microsoft”
ユーザー属性 リソース属性
デバイス属性
14. Dynamic Access Control
• Expression-Based Access Control...
...利用者のキャラクター（属性）によって動的にアクセスを制御する
• リソース管理者（リソースオーナー）は条件（Condition）を管理するだけ
• ID 管理者は ID のプロビジョニングに対して責任を持つ
アクセス管理 互いに素 ID 管理（ID 管理者）
（リソース管理者）
condition
営業部 IT部 A 人事部 A
Read
condition
IT部 経理部 A
Resource
Backup
condition
営業部 A 企画部 A
経理部
R/W
17. 「クレームベースのアクセス制御」とは
• 「クレーム」とは「要求」のこと
• 「要求」を出すのは「リソース（例：ファイルサーバー）側」
• ユーザーはリソース側のクレームに合致した属性情報を「トークン」として提示
• リソースは受け取ったトークンを解析してアクセス認可を判断
トークンを解析して
アクセス認可を判断
Name = Junichi Anno
ユーザー Company = MSKK リソース
Department = Evangelism
Title = Evangelist
18. DAC でのアクセス制御プロセス
DAC においては
• クレーム = 「分類属性」として定義
• トークン = Kerberos チケットとして AD DS から発行される
Windows Server 2012 必須
※Kerberosに属性を含める機構が必要
AD DS
ファイルサーバー
ログオン
属性情報を含んだ Windows
Kerberos チケット Server 2012 必須
※属性を受信して解
析する機能が必要
ユーザー Name = Junichi Anno チケットとクレームを
on Windows 8 Company = MSKK
照合
19. （参考）クライアントが Pre-Windows 8 の場合
Windows 7 以前のクライアントの場合、属性が格納されたKerberosチケットを要求することが
できないため、ファイルサーバーがAD DSから属性情報を受け取る
Windows Server 2003 以上のドメインレベル
※Service-for-User-to-Self（S4U2Self）機構が必要
AD DS
ファイルサーバー
ログオン 属性情報を含んだ
Kerberos チケット
Windows
従来の Kerberos
Server 2012 必須
チケット
※属性を受信して解
析する機能が必要
ユーザー 属性は含まれない チケットとクレームを
on Pre-Windows 8 照合
20. 分類属性（Classification Attributes）
• ファイルシステムが持つ標準的な属性情報を拡張するための「属性リスト」
• 属性を編集するにはファイル サーバー リソース マネージャーのインストールが必須
• AD DS 側で属性リストを集中管理し、グループポリシーとして配布可能
AD DS
ファイルサーバー
＋ ファイルサーバーリソースマネージャー
21. DAC に必要なすべての情報が DC で集中管理される
DAC に必要な情報は3つ
• ユーザーの属性情報
• リソースの属性情報（分類属性）
• アクセスルール
Active Directory
Domain Service
アクセスルール
ユーザー Country = フォルダ R_Country
ユーザー Department = フォルダ R_Department
条件が合致すればアクセス可能
