微软特权访问管理

2018-2022是私有云混合云在中国最火热的时代，私有云将在中国从摸索走向成熟阶段，随着云技术的火热，下一个企业必须要思考的将是信息安全的问题，现在企业都在导入云计算技术，建置更多的信息应用系统以从中获取信息化带来的价值。那么随着带来的一个隐患就是，管理员要管理的基础架构和应用系统数量越来越多，这时候管理员账户就变的很重要了，如何保证管理员账户能够安全，如果保证管理员账户的管理操作可控，可记录，如果保证云资源管理员和租户虚机的隐私问题，将是企业信息化接下来必须要考虑的安全点

老王之前做企业咨询实施的时候发现国内企业信息化，发现有一些现象，企业IT部门的管理员，可以很轻而易举的获得多个高权限的管理账号，有些企业信息项目外包出去，外包人员需要的管理员账户，做完项目也不回收。导致了Domain Admins组有大量的用户，这其实是极大的一个安全隐患，越多的高权限账户就有越多的风险，Hacker或者内部恶意管理员只要随便破解找到一个管理员的账号密码，就可以利用这个账号访问所有的域内系统，如果没有虚拟机保护机制，还可以利用此账户去窥探任意租户虚拟机的内容。

针对于这些云技术时代产生的安全隐患，微软在Windows Server 2016开始，正式引入 Privileged Access Management  特权访问管理的概念，PAM在老王看来，它不是指的某一个特定的技术，而是一套控制管理员特权执行生命周期的方法论，通过PAM就可以控制管理员账户的获取-保护-执行-监控，完整的管理生命周期。

下图是PAM的方法论流程图

1.准备：这一个步骤要梳理出来，当前生产林中那些组属于特权保护组，将要在堡垒林中创建不存在用户的安全主体(堡垒林概念下面会提到)，现有生产林中特权组里面，有哪些账户是应该要剔除来的，可根据安全需要酌情处理，最好能够只保留系统必须使用的账号，将个人管理员从中剔除。

2.保护：控制保护管理员账户获取，可以针对于特权主体设置MFA，当用户请求管理员权限时通过MFA多因子验证才可以获得，WS2016开始支持直接调用Azure MFA。

3.操作：通过身份验证后，用户的特权权限申请请求将通过人为审核，或门户工作流审核，审核通过后，用户将获得时效性或永久性权限，如果是时效性权限，当时间到达时，用户令牌将失去特权权限，不能再执行任何特权操作。

4.审计：PAM需要特权访问请求的审计，警报和报告，每一次特权申请和审批结果都应该被详细记录，您可以查看特权访问的历史记录，并查看执行活动的人员。您可以决定活动是否有效，并轻松识别未经授权的活动，例如尝试将用户直接添加到生产林中的特权组。此步骤不仅对于识别恶意软件而且对于跟踪“内部" 恶意管理员也很重要。

可以看到PAM提出了一套很好的对于特权账户的生命周期管理理论，这些理论要想要落地实现，还是离不开技术工具的支持，在2008R2，2012R2时代，一些企业也认识到了这一点，要控制管理员账户的安全，要可控，要监控，但是那时候并没有2016这么多的工具，因此主要还是要通过管理规范推动，通常在2016之前，我们去给企业做这种安全建议的时候会这样说

1.针对于个人管理员账户，设置密码策略，定期更改复杂性密码

2.针对于应用系统，尽量不要每个账户都用最高权限，去technet查询最小需要安全权限

3.建立管理员组成员登记表

4.开启安全策略审计，审计管理员账号登陆，访问

5.管理员操作时尽量通过工作站执行，在工作站上安装杀毒软件，使用防窃取技术

6.利用第三方厂商软件实现权限申请审批

7.利用第三方厂商软件实现密码破解检测

其中一些方法到2016时代也并不过时，但是一些安全点到了2016时代，微软自身就已经有了更好的技术去实现。

2016我们有了JIT，Shadow Principal，JEA，MIM这些来控制管理员账户安全的新技术，下面我们就来解释一下每项技术发挥的作用

Just-in-time 是微软提出的一种即时管理的概念，希望针对于一部分管理员实现，只在需要的时候请求权限，当所需要的时间到达后，即回收管理权限，不要给所有请求都分配永久管理员，这个特别适用于国内外包公司的场景，外包人员需要做项目，可以临时申请管理员权限，项目结束时间到达后自动回收账号权限，或者一个场景，IT管理员需要临时登录到租户虚拟机或应用系统虚拟机，经过审批后，获得一个时效性权限，时间到达时自动回收。

微软不仅提出概念，也有实际落地的技术工具，微软在AD2016中引入了PAM新功能，不借助任何工具，只通过AD域本身就可以实现，对用户设置有时效性的成员资格，当时间到达时用户将自动失去成员资格

由域控制器来管理并在达到TTL限制时将其删除。这也适用于复制，因为复制了TTL值结束时间，并且将在所有域控制器上本地删除链接。与此同时，还有一些Kerberos增强功能可以真正利用基于时间的组。当KDC创建票证时，它会将Kerberos票证生命周期限制为可能的最低生存时间（TTL）值。如果用户还剩15分钟，直到组成员身份的TTL到期，KDC将只创建另外15分钟的TGT/TGST，当票证已过期且请求新票证时，过期的组成员资格的SID将不在，使用此功能，您可以临时为用户提供基于较小时间限制的系统管理员访问权限。DC将维护和删除成员资格，它不会受到复制融合或Kerberos票证生命周期（默认为10小时，可在7天内续订）的不利影响。

实际使用时，首先需要必须要升级域控为2016，并确保林功能级别域功能级别为2016，升级后，需要手动在域控上面启用PAM新功能，才能实现时效性的组成员资格

命令如下

Enable-ADOptionalFeature “Privileged Access Management Feature” –Scope ForestOrConfigurationSet -Target admin.com

创建时效性成员资格

$TTL = New-TimeSpan -Minutes 10

Add-ADGroupMember -Identity“Domain Admins”-Members “Tony”-MemberTimeToLive $TTL

由于Tony临时获得了Domain Admins权限，可以登录到域控，但是查看klist可以看到票证是有时效限制的

查看管理员组时效成员资格，可以看到Tony的TTL时效资格在不断变化

Get-ADGroup -Identity “Domain Admins” -Properties * -ShowMemberTimeToLive |fl member

当时效到达时，Tony将自动离开管理员组

时效到达后使用whomi /groups虽仍可以看到属于管理员组，但是此时已经不能执行网络上管理操作，注销再登录时权限也将彻底失效

这是JIT一个最简单的示例，简单但是实用，他对现有环境的变动最少，只需要升级AD2016即可实现，时效性资格功能也是后面PAM更复杂场景的基石。

如果企业不准备构建复杂的生产林，堡垒林场景，那么就可以利用此功能达到控制特权管理执行的目的

当有可被识别为临时性的访问需求时，请申请人口头告知组长，再由组长执行命令授予临时时效性成员资格，或者如果希望此过程更加标准化，可以借助于Sharepoint+SCO或者SCSM+SCO实现Web申请，我给个思路，在Sharepoint创建一个权限申请列表，再创建一个审核记录列表，权限申请列表包括申请账号，目标特权组(列表或预先填充)，申请时效，申请原因，申请拿到后，会由部门经理或组长进行审批，SCO会监控这样一条新纪录的产生，当看到工作流状态为已批准的时候，将填写的记录转换为变量，通过databus传递给下一个活动，通过脚本操作连接到AD域，将拿到的用户变量，目标组变量，申请时效变量进行填充，执行成功后可邮件通知或Sharepoint站内信通知申请人，同时databus将数据传递到下一个活动，把申请人，申请时效，申请特权组，申请原因，审批人，这些数据，填充到另外一个特权审计表单，记录成功后流程结束，这里只是给出大家一个思路，作为ITpro我们可以通过Sharepoint+SCO实现或者利用SCSM+SCO实现，如果有开发人员配合更加方便，直接请开发人员在Web门户上面做好表单，将输入的数据做成变量，调用powershell执行即可。

那么，这是一个最基本的场景，在微软的PAM规划中，理想情况应该是构建一个堡垒林，如下图所示，微软提倡的是将特权管理账号彻底的单独拿出来，放到一个堡垒林中，生产林中只保留用户账户，应用程序所必须要的账户，两个林之间仅创建单向传入林信任，这样做的好处是最大程度上减少由破解管理员造成对生产林的危害，因为管理账号根本就不存在生产的林中，恶意程序也无法扫描到生产林中的管理员哈希。

当堡垒林中的管理员要管理生产林的时候，需要通过人为或门户的申请，申请通过后会被时效性或永久性的加入到堡垒林中的阴影主体，我们提前会把生产林中的特权账号，特权组，在堡垒林中创建成一个阴影主体，当管理员需要特权的时候，会申请特权组或特权用户的权限，当审批通过的时候，幕后会按照时效性把生产林中的用户加入到阴影主体中去，这个用户就可以连接到生产林中执行管理操作，此时在管理林用户用户的whoami /groups命令里面可以看到生产林特权的SID，当时效到期后自动拿掉生产林的权限。

上面说了很多名词，这里再简单的科普一下

在Windows系统中，当用户登录时，会发生以下几个步骤

1.用户输入账户 密码 域

2.Local Security Subsystem向域控申请用户的Session Ticket

3.Local Security Subsystem向域控申请Workstation的Session Ticket

4.DC上的Kerberos Service确认用户密码和计算机密码正确后，回传ticket给用户端

5.用户端Local Security Subsystem收到回传的ticket产生Access Token

6.使用Access Token去执行接下来的进程

Access Token里面会包括用户的SID，如果是域用户SID由域SID+RID主机分发的编号构成，用户所属组的SID，用户所拥有的特权。

如果企业有采用DAC动态访问控制，Token中也会包括声明。

每一个AD里面的用户属性里面除了自己的SID，还会有一个sidhistory的属性，该属性于windows 2000时代引入，目的是为了确保当发生域用户跨域迁移时，让迁移后的用户仍然能够访问迁移前能够访问的资源，因为当用户迁移到一个新的域，就会由所在域的RID主机产生一个新的编号，就会得到一个新的SID，这样如果访问以前的资源时，对比文件系统ACL的列表发现没有用户新域SID，则访问被拒绝，通过sidhistory可以把用户迁移前的SID，填充到迁移到新域后用户的sidhistory属性里面，这样访问之前可以访问的资源时，发现用户具备匹配的sidhistory，则访问被允许。

后来微软发现sidhistory属性存在安全隐患，一旦两个域创建信任后，在某些情况下，受信任域中的管理员和超级用户可以从信任域获取特权帐户的SID。这些SID不保密，大多数情况下，您可以通过查看信任域中资源的访问控制列表（ACL）来获取此信息。获得SID后，它将附加到受信任域中的任何用户对象，特别是其SIDHistory属性。当此修改后的帐户跨越现有信任关系时，从受信任域到信任域，它将有效地拥有受感染帐户的所有权限，可能会一直提升到域管理员或企业管理员级别

在Windows Server 2000 SP4微软引入了SID筛选的功能，防止SID欺骗提权，SID筛选使安全信任管理员能够丢弃使用可能是欺骗候选者的SID的凭据。在域中创建安全主体时，域SID包含在安全主体的SID中，以标识创建它的域。域SID是安全主体的重要特征，因为Windows安全子系统使用它来验证安全主体的真实性。

同样，从信任域创建的传出外部信任使用SID筛选来验证从受信任域中的安全主体发出的传入身份验证请求是否仅包含受信任域中安全主体的SID。这是通过将传入安全主体的SID与受信任域的域SID进行比较来完成的。如果任何安全主体SID包括来自受信任域的域SID以外的域SID，则信任将删除有问题的SID。

如果用户尝试从受信任域升级，则用户将从信任域添加SID到该用户的SID历史记录。信任链接将此视为潜在的危害，并从身份验证请求过滤所有不是来自受信任域的SID。如果受信任域中的用户是从另一个（第三个）域迁移的，则不允许通过信任链接从第三个域中获取SID信息。

铺垫都做好了，那么就可以来看主菜了，在微软规划的PAM模型中，理想情况下分为堡垒林和生产林，管理账户都在堡垒林，当执行管理操作的时候，堡垒林的管理员将临时获得生产林中特权用户或特权组的SID，这项技术得以实现，主要归功于Windows Server 2016AD域的Shadow Principals，不论是通过Powershell获得权限，还是通过MIM门户获得权限，底层都使用的Shadow Principals，通过Shadow Principals允许堡垒林管理账户跨林得到生产林SID

Shadow Principals涉及到的属性

msDS-ShadowPrincipalContainer

msDS-ShadowPrincipalContainer是msDS-ShadowPrincipal对象的专用容器，在Configuration NC的Services容器中创建一个默认容器。

CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com

可以在其他位置创建主体容器，但不能使用Kerberos。

msDS-ShadowPrincipal

此类表示外部林的主体。只能在Shadow Principal容器中创建，它必须具有msDS-ShadowPrincipalSid值。

Shadow主体可以代表任何安全主体用户，安全组或计算机。它还有成员属性，这里是PAM和Shadow Principals的很酷的地方，我们可以像时效组成员一样在成员资格上设置TTL值。如果Shadow Principal驻留在默认的CN = Shadow Principal Configuration，CN = Services，CN = Configuration，DC = X容器中，任何域用户拥有任何Shadow Principal的成员资格将与任何其他组成员一样添加到Kerberos票证中。一个限制是它只能在其自己的林中拥有主体成员。

如果设置了成员资格的TTL值，它将与Kerberos集成，并且票证的生命周期将设置为最短的到期TTL值。

msDS-ShadowPrincipalSid

此属性包含外部林中主体的SID，属性编入索引。它具有约束，因此您无法从其自己的域或其自己的林中的任何其他域添加SID。并且必须将林信任配置为能够从其他域添加SID，确保针对两个林之间开启sid history，关闭sid filtering。

具体实现，我们会在堡垒林中，在msDS-ShadowPrincipalContainer容器里面，创建生产林中如Domain Admins，Enterprise Admins等组或用户的msDS-ShadowPrincipal克隆对象，当管理员需要对生产林执行特权操作的时候，会有专人手动将堡垒林里面没有权限的用户加到堡垒林msDS-ShadowPrincipal对象的member成员里面，这样这个用户就可以获得时效性或永久性的，生产林中的SID，如果有MIM，当审批通过后会自动添加，如果有Sharepoint和SCO，也可以做成流程审批通过自动添加。

下面我们通过实验验证

当前环境具备一台2012R2的生产域控，一台2016的堡垒林域控，生产林abc.com，堡垒林admin.com，一台堡垒林工作站，当前生产域控Domain Admins组成员已清空，堡垒林中需要临时登录到生产林域控进行巡检。

在此示例中，我们将创建单向林可传递信任。我们需要禁用SID 筛选和Enable sidhistory，以便当admin域中的用户登录到abc中的服务器时，不会过滤掉SID，在Windows Server 2016中，此方案有一种新的信任类型，称为PIM信任。在早期版本中，不可能将像Domain Admins和Enterprise Admins这样的SID与SIDHistory一起使用，它们总是被过滤掉。因此我们还必须启用PIM Trust选项，除此之外还需要在两边域控DNS配置到对方域名的DNS条件转发器。

需要注意，如果生产林域控是2012R2版本，请按照顺序安装以下补丁，2012R2域控才可以拥有PIM Trust命令

Windows8.1-KB2919355-x64 

Windows8.1-KB2919442-x64 

Windows8.1-KB3021910-x64 

Windows8.1-KB3172614-x64

生产林域控执行

netdom trust abc.com /Domain:admin.com /Add /UserD:administrator@admin.com /PasswordD:* /UserO:administrator@abc.com /PasswordO:*

netdom trust abc.com /domain:admin.com /ForestTRANsitive:Yes

netdom trust abc.com /domain:admin.com /EnableSIDHistory:Yes

netdom trust abc.com /domain:admin.com /EnablePIMTrust:Yes

netdom trust abc.com /domain:admin.com /Quarantine:No

如果是中文版系统，需要输入chcp 437进入英文code page，否则会出现命令无法执行成功

堡垒林域控必须为Windows Server 2016及以上，林功能与域功能级别至少2016，只有2016的林域功能级别才能实现后面时效性的组成员资格，才能具有阴影主体属性。确认全部升级到2016后务必手动开启PAM功能

Enable-ADOptionalFeature “Privileged Access Management Feature” –Scope ForestOrConfigurationSet -Target admin.com

堡垒林域控执行

netdom trust admin.com /domain:abc.com /ForestTRANsitive:Yes 

并且不要忘记为Admin域中的信任启用Kerberos AES加密，在System容器中的ABC对象上打开属性并标记复选框：其他域支持Kerberos AES加密

在堡垒林为生产林特权组Domain Admins创建阴影主体

$CORPPrincipal = "Domain Admins"

$CorpDC = "12dc.abc.com"

$ShadowSuffix = "abc-"

$CorpShadowPrincipal = Get-ADGroup -Identity $CORPPrincipal -Properties ObjectSID -Server $CorpDC

$ShadowPrincipalContainer = "CN=Shadow Principal Configuration,CN=Services,"+(Get-ADRootDSE).configurationNamingContext

New-ADObject -Type "msDS-ShadowPrincipal" -Name "$ShadowSuffix$($CorpShadowPrincipal.SamAccountName)" -Path $ShadowPrincipalContainer -OtherAttributes @{'msDS-ShadowPrincipalSid'= $CorpShadowPrincipal.ObjectSID}

创建完成后可以在堡垒林域控连接ADSI配置分区可以在下面路径找到创建的阴影主体

CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com

如果你点开创建好的阴影主体对象，你会看到它的msDS-ShadowPrincipalSid和阴影主体在生产林里面的SID一模一样，这是创建Domain Admins组阴影主体的做法，用户阴影主体同样。

下面模拟发生权限请求，人为批准特权访问生产林操作，将堡垒林管理员用户Mike，临时加入到Domain Admins阴影主体，添加前Mike无任何权限，仅为普通用户。

Set-ADObject -Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com" -Add @{'member'="<TTL=600,CN=Mike,OU=ITAccount,DC=admin,DC=com>"}

执行完成后可以在堡垒林Domain Admins阴影主体对象member属性处看见mike已经作为成员

现在Mike用户已经可以登陆到生产林域控，到这一步其实已经可以判断生效

查看Kerberos部分，我们可以使用klist列出Mike用户当前的时效性票证

除了时效性，事实上我们也可以为mike分配一个永久性的生产林权限，可以直接GUI添加永久阴影主体成员，也可以使用之前PS添加的命令，将TTL设置为0即可，设置之后用户Kerberos票证生命周期将恢复默认十小时

如果管理员希望撤销永久性阴影主体权限或取消还在时效中的成员权限，运行命令

Set-ADObject -Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com" -Remove @{'member'="<TTL=0,CN=Mike,OU=ITAccount,DC=admin,DC=com>"}

GUI查看发现阴影主体member成员已经为空

mike注销后将失去生产林的一切管理权限

进一步理解，事实上阴影主体使用的并非是SIDHistory技术，当mike被添加到阴影主体后，SIDhistory并不会添加，因此说明，被添加到阴影主体的成员登陆令牌里面，除了用户SID，所属组SID，User Right，一些默认SID，还会包含所属阴影主体的SID。

当我们通过阴影主体成员访问生产林幕后发生的事情如下

• 用户尝试RDP到生产中的资源 - >资源不知道该用户 - >需要身份验证和授权

• 身份验证请求将重定向到admin林中的KDC（密钥分发中心 - > DC）

• KDC构建如上所述的SID列表，包括来自生产的Domain Admins的镜像SID

• 生产中的DC检查组在其数据库中嵌套由管理林发布的令牌呈现的SID

• 生产DC根据令牌添加组嵌套

通过这个实验，相信大家对于微软提出的PAM操作模型有了更深入的理解，我更希望的是更多人能够理解，与我讨论，思考在企业里面的应用点，并在企业里面试着应用，可以看到，这是一种重新定义特权访问的理念，将管理权限梳理成时效性权限，将管理员梳理到单独的堡垒林利用阴影主体提供穿透访问。实际应用时候不要着急一刀切，把管理权限全部移动到堡垒林，可以根据企业安全需求，识别出来那些是可以移动的，逐步将管理权限移动。

不论是单域控不构建堡垒林的场景，或是堡垒林的场景，我们都能实现时效性访问，本文演示的是最原始的powershell操作方式，对应到现实里面最后添加成员到阴影主体的操作应该由组长或者部门经理执行，那么我们可以看到，实际上添加也好，删除也好，阴影主体，申请人，TTL时效，都可以封装成变量，就像上面提到的思路，管理员可以借助Sharepoint+SCO或SCSM+SCO，或请开发人员帮忙，通过Web实现流程化的权限申请，权限回收，权限申请审计。

扩展了解，与PAM接近，Azure上面也有一个PIM服务，可以执行以下操作，它与PAM概念不同的是，PAM是一套用于梳理数据中心基础架构特权管理模型的方法论和落地工具，PIM是微软对租户提供的用于租户在Azure平台上面使用时的特权身份管理功能。

• 查看为哪些用户分配了特权角色来管理Azure资源，以及在Azure AD中为哪些用户分配了管理角色

• 启用按需，“及时”管理访问Microsoft Online Services（如Office 365和Intune），以及Azure资源订阅，资源组和单个资源（如虚拟机），具备多个定义好的角色

• 自动和Azure MFA集成，租户申请激活PIM角色，经过MFA验证才可以申请成功

• 由Azure后台实现面对租户申请PIM角色使用的JEA，JIT特性

• 查看管理员激活的历史记录，包括管理员对Azure资源所做的更改

• 获取有关管理员分配更改的警报

• 需要批准才能激活Azure AD特权管理员角色

• 检查管理角色的成员身份，并要求用户提供继续成员资格的理由

• Azure PIM功能体验比本地PAM更好，本地PAM面对是数据中心，AzurePIM实现了面向多租户，为每个租户提供JEA、JIT、PAM体验。

  
  

那么MIM主要是起什么作用的呢，MIM 2016 本身这个产品是FIM的延续，具备跨应用的身份同步，密码自助重置，证书管理，密码更改通知，PAM实现，和AzureAD整合混合同步及混合报告

在PAM的体系里面，MIM可以做到保护——操作——升级的三个过程，与单独的Powershell不同，通过MIM可以配置用户使用多因子登陆，MIM会基于Sharepoint建立一套门户，用于权限申请审批，自带工作流。

除此之外MIM门户还原生具备报告审计的功能，可以看到每次申请的历史记录，以及审批人

MIM实现PAM比原生的Powershell更加标准化，但底层都使用同样的功能实现，它会把每一个安全主体创建成一个个角色，供用户申请审批

MIM架构支持高可用部署

MIM不能部署在域控上面，可以部署多台MIM服务器容错MIM服务，堡垒林域控部署多台，后台SQL数据库支持AG/FC/镜像高可用，Sharepoint支持场架构

由于MIM部署门户非常的复杂，因此如果只是为了要PAM的门户申请和升级功能也未必一定要部署MIM，可以采取老王提到的Sharepoint+SCO思路尝试

MIM PAM部署参考链接

https://docs.microsoft.com/zh-cn/microsoft-identity-manager/pam/configuring-mim-environment-for-pam

https://blogs.msdn.microsoft.com/connector_space/2015/08/25/installation-of-the-privileged-access-management-pam-feature/

https://blogs.technet.microsoft.com/meamcs/2018/12/26/step-by-step-mim-pam-setup-and-evaluation-guide-part-1/

这样我们就把JIT，阴影主体，MIM的概念和逻辑关系都理理清楚，那么JEA是做什么的呢，它是Powershell5.0的一个新功能，帮助实现最小化特权管理

通过利用代表常规用户执行特权操作的虚拟帐户或组托管服务帐户，减少计算机上的管理员数量。我们会开启一个虚拟账户的功能，当用户要执行特权操作的时候会唤醒虚拟账户去实际执行，类似的技术，在微软早期其它产品中也可以看到

通过创建配置文件，控制运行用户可以运行的cmdlet，函数和外部命令操作

通过转录和日志更好地了解用户正在做什么，这些转录和日志可以准确显示用户在会话期间执行的命令

删除管理权限并不总是很容易。考虑DNS角色与Active Directory域控制器安装在同一台计算机上的常见方案。您的DNS管理员需要本地管理员权限才能解决DNS服务器的问题，但为了做到这一点，您必须使他们成为具有高权限的“Domain Admins”安全组的成员。此方法有效地使DNS管理员可以控制整个域并访问该计算机上的所有资源。

JEA通过帮助您采用最小权限原则帮助解决此问题。使用JEA，您可以为DNS管理员配置管理端点，使他们能够访问完成工作所需的所有PowerShell命令，但仅此而已。这意味着您可以提供适当的访问权限来修复中毒的DNS缓存或重新启动DNS服务器，而不会无意中授予他们Active Directory的权限，或浏览文件系统或运行潜在危险的脚本。更好的是，当JEA会话配置为使用临时特权虚拟帐户时，DNS管理员可以使用非管理员连接到服务器凭据并且仍然能够运行通常需要管理员权限的命令。此功能使您可以从具有广泛特权的本地/域管理员角色中删除用户，谨慎控制他们在每台计算机上可以执行的操作

JEA配置参考：https://docs.microsoft.com/en-us/powershell/jea/prerequisites

JEA尤其适用于一些托管执行账号，如VMM托管账户，SCOM监控账户等，一些托管账户，任务执行账户，不再必须要使用Domain Admins账户，只需要分配一个user，然后藏入虚拟account即可。

如果将JEA，JIT，阴影主体这几个技术串起来我们可以完整实现PAM的操作效果，用户在堡垒林申请权限，审批通过后会JIT时效性加入阴影主体成员，加入到的阴影主体也是JEA定义的保护组，申请记录及审批记录会通过MIM或Sharepoint审计，这个用户登录后会连接到一台工作站执行管理操作，有了JEA可能特权组都不一定非要给Domain Admins，普通的管理员组就可以完成，因为幕后会有藏好的虚拟账户执行管理操作，当用户在工作站执行生产林管理操作的时候，能执行的命令操作受JEA配置文件的限制，且管理操作完全通过虚拟账户执行，当JIT时效到期后，用户将完全失去到生产林及工作站的管理权限。

现在我们把2016的整个安全模型串起来

1. 梳理生产林管理员，控制管理员数量，在堡垒林建立安全主体，尽量分配时效性成员资格，针对于需要获取权限的堡垒林用户开启多因子验证。

2. 针对生产林主要服务器，堡垒林工作站，生产林工作站，开启Credential guard，Remote guard，防止哈希破解，配置Windows Defender安全防护

3. 通过MIM或Sharepoint等其它门户，对用户的特权操作进行审计，通过JEA日志记录审计执行命令。
   

4. 通过MBAM管理加密重要服务器磁盘加密

5. 通过SCOM或公有云OMS对服务器进行安全状态诊断，通过APM或Application Insights对应用程序进行可用性/性能/安全诊断。
   

6. 通过ATA进行入亲检测分析，预测对于生产林存留管理账户的破解，异常登录行为，整体分析AD域及syslog

7. 通过Shielded VM对主机和虚拟机进行安全绑定，确保虚拟机只能在允许的主机启动，每次虚拟机启动需要经过验证，虚拟机无法被拷贝到其它主机启动。

通过PAM涉及到的JIT,JEA,阴影主体来管理控制特权执行的生命周期，通过Shielded VM控制恶意拷贝虚拟磁盘，通过ATA对域内账号破解进行入亲检测，这三个2016最外圈的安全体系，互帮互助，构建更好的安全体系。关于Shielded VM和ATA我的好朋友ZJUNSEN已经写了很好的实作博客，大家感兴趣可以去看。