Shulou(Shulou.com)06/01 Report--

2018-2022 is the hottest era of private cloud hybrid cloud in China. Private cloud will move from exploration to maturity in China. With the popularity of cloud technology, the next enterprise must think about the issue of information security. Now enterprises are introducing cloud computing technology and building more information application systems to gain the value brought by information technology. Well, with the increasing number of infrastructure and application systems that administrators have to manage, the administrator account becomes very important. How to ensure the security of the administrator account? if you ensure that the management operation of the administrator account is controllable and recordable, and if you ensure the privacy of cloud resource administrators and tenants, it will be the next security point that must be considered in enterprise informatization.

When Lao Wang was doing enterprise consultation and implementation, he found that there were some phenomena. The administrator of the enterprise IT department could easily obtain multiple management accounts with high authority. Some enterprise information projects were outsourced, and the administrator accounts needed by the outsourcing personnel were not recycled even after the project was finished. As a result, there are a large number of users in the Domain Admins group, which is actually a great security risk. The more high-privilege accounts, the more risks. Hacker or internal malicious administrators can use this account to access all domain systems as long as they can crack and find an administrator's account password. If there is no virtual machine protection mechanism, you can also use this account to spy on the contents of any tenant's virtual machine.

In response to these security risks arising from the era of cloud technology, Microsoft formally introduced the concept of Privileged Access Management privileged access management in Windows Server 2016. In Lao Wang's view, PAM does not refer to a specific technology, but a set of methodology for controlling the executive life cycle of administrator privileges. Through PAM, you can control the access-protection-execution-monitoring of administrator accounts, and the complete management life cycle.

The following figure is the flow chart of PAM's methodology.

1. Preparation: this step needs to be sorted out. Those groups in the current production forest belong to privilege protection groups. Security principals that do not have users will be created in the fortress forest (mentioned below in the concept of Fortress Forest). Which accounts should be removed from the existing privilege groups in the production forest can be handled according to security needs, and it is best to retain only the accounts that the system must use and remove the individual administrator from them.

two。 Protection: control and protect administrator account acquisition. You can set MFA for privileged principals, which can only be obtained through MFA multi-factor verification when users request administrator permissions. WS2016 starts to support calling Azure MFA directly.

3. Operation: after passing the authentication, the user's request for privileged permissions will be audited artificially or by the portal workflow. After the verification is passed, the user will be granted timeliness or permanent permissions. If it is a timeliness permission, when the time arrives, the user token will lose the privileged rights and cannot perform any privileged operations.

4. Audit: PAM requires audits, alerts, and reports of privileged access requests. Each privilege request and approval result should be recorded in detail. You can view the privileged access history and see who performs the activity. You can determine whether the activity is valid and easily identify unauthorized activities, such as trying to add users directly to privilege groups in the production forest. This step is important not only for identifying malware but also for tracking "internal" malicious administrators.

We can see that PAM put forward a set of good life cycle management theories for privileged accounts. If these theories are to be implemented, they still need the support of technical tools. In the era of 2008R2 2012 R2, some enterprises also realized that they wanted to control the security of administrator accounts, to be controllable and to monitor, but at that time there were not as many tools as 2016, so they mainly had to be promoted through management norms. Usually before 2016, we would say this when we go to give this kind of security advice to enterprises.

1. Set password policies for personal administrator accounts and change complex passwords on a regular basis

two。 For the application system, try not to use the highest permissions for every account, and go to technet to query the minimum security permissions.

3. Establish a registration form for members of the administrators group

4. Open security policy audit, log in to the audit administrator account, and visit

5. When operating, the administrator tries to execute through the workstation, install antivirus software on the workstation, and use anti-theft technology.

6. Using the software of third-party manufacturers to realize the examination and approval of authority application

7. Using the software of third-party manufacturers to realize password cracking detection

Some of these methods are not out of date in the 2016 era, but some security points in the 2016 era, Microsoft itself already has better technology to implement.

2016 We have new technologies such as JIT,Shadow Principal,JEA,MIM to control the security of administrator accounts, so let's explain the role of each technology.

Just-in-time is a concept of real-time management put forward by Microsoft. It is hoped that for some administrators, permission can be requested only when needed. When the required time arrives, management rights will be reclaimed, and permanent administrators will not be assigned to all requests. This is especially suitable for domestic and foreign package companies, where outsourcing personnel need to do projects and can apply for administrator permissions temporarily. Account permissions are automatically reclaimed after the end time of the project, or in a scenario, the IT administrator needs to log in to the tenant virtual machine or application system virtual machine temporarily, and obtain a timeliness permission after approval, and automatically reclaim it when the time arrives.

Microsoft not only puts forward the concept, but also has the actual technical tools. Microsoft introduces the new function of PAM in AD2016, which can be realized only through the AD domain itself without any tool. Users will automatically lose their membership when the time is up.

It is managed by the domain controller and deleted when the TTL limit is reached. This also applies to replication because the end time of the TTL value is replicated and the link is deleted locally on all domain controllers. At the same time, there are some Kerberos enhancements that can really take advantage of time-based groups. When KDC creates a ticket, it limits the life cycle of the Kerberos ticket to the minimum time-to-live (TTL) value possible. If the user has 15 minutes left until the TTL for group membership expires, KDC will only create an additional 15-minute TGT/TGST. When the ticket has expired and a new ticket is requested, the expired group membership SID will not be available. Using this feature, you can temporarily provide users with system administrator access based on a small time limit. DC maintains and removes membership and is not adversely affected by replication convergence or the Kerberos ticket lifecycle (default is 10 hours and can be renewed within 7 days).

In practical use, it is necessary to upgrade the domain control to 2016 and ensure that the functional level of the forest functional level domain is 2016. After the upgrade, you need to manually enable the new PAM function on the domain control in order to achieve timely group membership.

The command is as follows

Enable-ADOptionalFeature "Privileged Access Management Feature"-Scope ForestOrConfigurationSet-Target admin.com

Create timed membership

$TTL = New-TimeSpan-Minutes 10

Add-ADGroupMember-Identity "Domain Admins"-Members "Tony"-MemberTimeToLive $TTL

Because Tony has temporarily obtained Domain Admins permission, you can log in to the domain control, but if you look at klist, you can see that the ticket is time-limited.

Looking at the limited membership of the administrator group, you can see that the TTL limitation qualification of Tony is constantly changing.

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

When the time limit expires, Tony will automatically leave the administrators group

Although you can still see that you belong to the administrator group by using whomi / groups after the expiration of the time limit, you can no longer perform administrative operations on the network at this time, and the permissions will expire completely when you log out and log in again.

This is the simplest example of JIT, simple but practical. It makes the least changes to the existing environment and only needs to upgrade AD2016. The timeliness qualification feature is also the cornerstone of later PAM more complex scenarios.

If the enterprise is not prepared to build complex production forest and fortress forest scenarios, then this function can be used to control the execution of privilege management.

When there is a need for access that can be identified as temporary, please inform the team leader orally, and then the team leader will execute the order to grant temporary timely membership, or if you want this process to be more standardized, you can realize Web application with the help of Sharepoint+SCO or SCSM+SCO. I will give you an idea: create a list of permission applications in Sharepoint, and then create a list of audit records, which includes the application account. The target privilege group (list or pre-filled), application limitation, application reason, and the application will be approved by the department manager or team leader after the application is received. SCO will monitor the generation of such a new record. When the workflow status is approved, the filled record will be converted into variables, passed to the next activity through databus, connected to the AD domain through script operations, and the acquired user variables and target group variables. The application limitation variable is filled in, and the applicant can be notified by email or Sharepoint internal message after successful execution. At the same time, databus transmits the data to the next activity, including the applicant, the application limitation, the application privilege group, the application reason, the approver, and these data, fill in another privilege audit form, and the process ends after the record is successful. Here is just to give you an idea. As an ITpro, we can achieve it through Sharepoint+SCO or using SCSM+SCO. If it is more convenient for developers to cooperate, directly ask developers to make a form on the Web portal, change the input data into variables, and call powershell to execute.

So, this is the most basic scenario. In Microsoft's PAM plan, the ideal scenario should be to build a fortress forest. As shown in the following figure, Microsoft advocates taking out the privilege management account completely and putting it into a fortress forest. Only user accounts and accounts required by the application are retained in the production forest, and only one-way trust is created between the two forests. The advantage of this is to minimize the damage to the production forest caused by the cracking administrator, because the management account does not exist in the production forest at all, and the malicious program cannot scan the administrator hash in the production forest.

When the administrator in the fortress forest wants to manage the production forest, he needs to apply artificially or through a portal. After the application is passed, it will be timely or permanently added to the shadow subject in the fortress forest. We will create a shadow subject in the fortress forest with the privileged account and privilege group in advance. When the administrator needs privileges, he will apply for the privileges of the privileged group or privileged user, and when the approval is approved. Behind the scenes, the user in the production forest is added to the shadow subject according to the timeliness, and the user can be connected to the production forest to perform management operations. At this time, the SID of the production forest privilege can be seen in the whoami / groups command of the user managing the forest, and the permission of the production forest will be automatically removed when the validity expires.

There are a lot of nouns above, here is a simple science popularization.

In a Windows system, when a user logs in, the following steps occur

1. The user enters the account password field

2.Local Security Subsystem applies to the domain control for the user's Session Ticket

3.Local Security Subsystem applies for Session Ticket of Workstation from domain control.

After the Kerberos Service on 4.DC confirms that the user password and computer password are correct, send the ticket back to the client.

5. The client Local Security Subsystem receives the returned ticket to generate Access Token.

6. Use Access Token to execute the next process

Access Token will include the user's SID, if the domain user SID is composed of the number distributed by the domain SID+RID host, the SID of the group to which the user belongs, and the privileges of the user.

If the enterprise uses DAC dynamic access control, the declaration will also be included in the Token.

In addition to its own SID, there will also be a sidhistory attribute in each user attribute in AD. This attribute was introduced in windows 2000 to ensure that when domain users migrate across domains, the migrated users can still access the resources that can be accessed before migration, because when users migrate to a new domain, a new number will be generated by the RID host in the domain and a new SID will be obtained. In this way, if you access the previous resources and find that there is no user new domain SID compared with the file system ACL list, the access is denied. Through sidhistory, you can populate the user's pre-migration SID into the user's sidhistory attribute after the migration to the new domain. In this way, when you access the previously accessible resources and find that the user has a matching sidhistory, the access is allowed.

Later, Microsoft discovered that there was a security risk to the sidhistory attribute. Once the trust was created between the two domains, in some cases, administrators and superusers in the trusted domain could obtain the SID of the privileged account from the trusted domain. These SID are not confidential, and in most cases you can obtain this information by looking at the access control list (ACL) of resources in the trust domain. Once the SID is obtained, it will be attached to any user object in the trusted domain, especially its SIDHistory attribute. When this modified account spans existing trust relationships, it will effectively have all the permissions of the infected account from the trusted domain to the trusted domain, possibly all the way up to the domain administrator or enterprise administrator level

Microsoft introduced SID filtering in Windows Server 2000 SP4 to prevent SID from spoofing the claim, and SID filtering enables security trust administrators to discard credentials that use SID that may be a fraudulent candidate. When you create a security principal in a domain, the domain SID is included in the SID of the security principal to identify the domain in which it was created. Domain SID is an important feature of security principals because the Windows security subsystem uses it to verify the authenticity of security principals.

Similarly, outgoing external trusts created from trusted domains use SID filtering to verify that incoming authentication requests from security principals in trusted domains contain only the SID of security principals in trusted domains. This is done by comparing the SID passed into the security principal with the domain SID of the trusted domain. If any security principal SID includes a domain SID other than the domain SID from the trusted domain, the trust removes the problematic SID.

If a user attempts to upgrade from a trusted domain, the user adds a SID from the trusted domain to the user's SID history. Trust links see this as a potential hazard and filter all SID that are not from trusted domains from authentication requests. If users in a trusted domain are migrated from another (third) domain, obtaining SID information from the third domain through a trust link is not allowed.

After laying the groundwork, you can take a look at the main course. In the PAM model planned by Microsoft, it is ideally divided into fortress forest and production forest, and the management accounts are all in the fortress forest. When performing management operations, the administrator of the fortress forest will temporarily obtain the SID of privileged users or privileged groups in the production forest. This technology can be realized mainly due to the Shadow Principals of the Windows Server 2016AD domain, whether through Powershell. Or through the MIM portal to obtain permissions, the underlying use of Shadow Principals, through Shadow Principals to allow fortress forest management account cross-forest to get production forest SID

Attributes involved in Shadow Principals

MsDS-ShadowPrincipalContainer

MsDS-ShadowPrincipalContainer is a dedicated container for msDS-ShadowPrincipal objects, and a default container is created in the Services container of Configuration NC.

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

You can create a principal container in another location, but you cannot use Kerberos.

MsDS-ShadowPrincipal

This class represents the principal part of the external forest. Can only be created in a ShadowPrincipal container, which must have a msDS-ShadowPrincipalSid value.

Shadow principals can represent any security principal user, security group, or computer. It also has member properties, which is the cool part of PAM and Shadow Principals, and we can set TTL values on membership like members of the expiration group. If Shadow Principal resides in the default CN = Shadow Principal Configuration,CN = Services,CN = Configuration,DC = X container, any domain user who has any Shadow Principal membership will be added to the Kerberos ticket like any other group member. One limitation is that it can only have principal members in its own forest.

If the TTL value for membership is set, it will be integrated with Kerberos, and the lifetime of the ticket will be set to the shortest expiration TTL value.

MsDS-ShadowPrincipalSid

This property contains the SID of the principal in the outer forest and the property is indexed. It has constraints, so you cannot add SID from its own domain or any other domain in its own forest. And the forest trust must be configured to be able to add SID from other domains, ensuring that sid history is turned on and sid filtering is turned off for the two forests.

Specifically, in the fortress forest, in the msDS-ShadowPrincipalContainer container, we will create msDS-ShadowPrincipal clone objects for groups or users in the production forest, such as Domain Admins,Enterprise Admins. When the administrator needs to perform privileged operations on the production forest, someone will manually add the users who do not have permission in the fortress forest to the member members of the msDS-ShadowPrincipal object in the fortress forest, so that this user can obtain timely or permanent SID in the production forest. If there is a MIM, it will be added automatically when the approval is approved. If there are Sharepoint and SCO, you can also make the process approval and automatically add it.

Let's verify it through experiments.

The current environment has a 2012R2 production domain control, a 2016 fortress forest domain control, a production forest abc.com, a fortress forest admin.com, and a fortress forest workstation. The members of the current production domain control Domain Admins group have been emptied, and the fortress forest needs to temporarily log in to the production forest domain control for inspection.

In this example, we will create an one-way forest that can pass trust. We need to disable SID filtering and Enable sidhistory so that SID is not filtered when users in the admin domain log on to the server in abc, and in Windows Server 2016, this scenario has a new type of trust called PIM trust. In earlier versions, it was impossible to use SID like Domain Admins and Enterprise Admins with SIDHistory; they were always filtered out. So we also have to enable the PIM Trust option, in addition to configuring the DNS conditional transponder on both sides of the domain control DNS to the other domain name.

It should be noted that if the production forest domain control is the 2012R2 version, install the following patch in order before the 2012R2 domain control can have the PIM Trust command.

Windows8.1-KB2919355-x64

Windows8.1-KB2919442-x64

Windows8.1-KB3021910-x64

Windows8.1-KB3172614-x64

Production forest domain control execution

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

If it is a Chinese version of the system, you need to enter chcp 437 into the English code page, otherwise the command will not be executed successfully

The fortress forest domain control must be Windows Server 2016 or above, and the forest function and domain function level must be at least 2016. Only 2016 of the forest domain function level can achieve the later timeliness group membership and have the shadow subject attribute. Be sure to manually turn on the PAM function after confirming that all upgrades have been made to 2016

Enable-ADOptionalFeature "Privileged Access Management Feature"-Scope ForestOrConfigurationSet-Target admin.com

Fortress forest domain control execution

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

And don't forget to enable Kerberos AES encryption for trust in the Admin domain, open the property on the ABC object in the System container and mark the check box: other domains support Kerberos AES encryption

Create shadow subjects for production forest privilege group Domain Admins in Fortress Forest

$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}

After the creation is completed, you can use the domain control connection ADSI configuration partition in the fortress forest to find the shadow body created in the path below.

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

If you click to create a shadow body object, you will see that its msDS-ShadowPrincipalSid is exactly the same as the SID of the shadow body in the production forest. This is the way to create the shadow body of the Domain Admins group, and the shadow body of the user is the same.

The following simulates the permission request, artificially approves the privileged access to the production forest, and temporarily adds the fortress forest administrator user Mike to the shadow body of Domain Admins. Before adding, Mike does not have any permissions, only ordinary users.

Set-ADObject-Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com"-Add @ {'member'= ""}

After the execution is completed, you can see that mike has been a member at the member property of the Domain Admins shadow body object in the fortress forest.

Now Mike users can log in to the production forest domain control, and it can be judged to be effective at this stage.

Looking at the Kerberos section, we can use klist to list the current expiration tickets of Mike users.

In addition to timeliness, in fact, we can also assign a permanent production forest permission to mike. We can directly GUI to add permanent shadow principal members, or we can use the command previously added by PS to set TTL to 0. After setting it, the life cycle of the user's Kerberos ticket will be restored to the default 10 hours.

If the administrator wants to revoke the permanent shadow principal permission or revoke the member permission that is still in effect, run the command

Set-ADObject-Identity "CN=ABC-Domain Admins,CN=Shadow Principal Configuration,CN=Services,CN=Configuration,DC=admin,DC=com"-Remove @ {'member'= ""}

GUI view found that the shadow body member member has been empty

Mike will lose all management rights of the production forest after logging off.

Further understanding, in fact, the shadow subject does not use SIDHistory technology, when mike is added to the shadow body, SIDhistory will not be added, so it means that the member login token added to the shadow body, in addition to the user SID, the group SID,User Right, some default SID, but also contains the SID of the shadow body.

What happens after we visit the production canopy through the shadow subject members is as follows

The user attempts to RDP to the resource in production-> the resource does not know the user-> requires authentication and authorization

Authentication requests will be redirected to KDC in the admin forest (key Distribution Center-> DC)

KDC builds the list of SID described above, including the mirror SID from the production Domain Admins

DC inspection groups in production nest SID presented by tokens issued by the management forest in their database

Production DC nesting groups based on token addition

Through this experiment, I believe you have a deeper understanding of the PAM operation model proposed by Microsoft. What I hope more is that more people can understand, discuss with me, think about the application points in the enterprise, and try to apply it in the enterprise. We can see that this is a concept of redefining privileged access, combing administrative permissions into timely permissions. The administrator is combed into a separate fortress forest using shadow subjects to provide penetrating access. In practical application, do not worry about an one-size-fits-all approach, move all the management authority to the fortress forest, you can identify those that can be moved according to the enterprise security needs, and gradually move the management authority.

Whether it is a single domain control scenario that does not build a fortress forest, or a fortress forest scene, we can achieve timely access. This article demonstrates the most primitive powershell operation. Corresponding to the reality, the last operation of adding a member to the shadow subject should be performed by the team leader or department manager. Then we can see that actually add or delete, shadow subject, applicant, TTL time limit, can be encapsulated into variables. Like the ideas mentioned above, administrators can use Sharepoint+SCO or SCSM+SCO, or ask developers for help, through Web to achieve the process of permission application, permission recovery, permission application audit.

Expand to understand that, similar to PAM, Azure also has a PIM service that can perform the following operations. Unlike the concept of PAM, PAM is a set of methodology and landing tool for combing the privileged management model of data center infrastructure. PIM is a privileged identity management function provided by Microsoft for tenants to use on the Azure platform.

See which users are assigned privileged roles to manage Azure resources, and which users are assigned administrative roles in Azure AD

Enable on-demand, "just in time" management access to Microsoft Online Services (such as Office 365 and Intune), as well as Azure resource subscriptions, resource groups, and individual resources (such as virtual machines) with multiple defined roles

Automatically integrate with Azure MFA. Tenants apply for activation of PIM roles. Only after MFA verification can the application be successful.

The Azure backend implements the JEA,JIT feature that is used by tenants to apply for PIM roles

View the history of administrator activation, including changes made by the administrator to Azure resources

Get alerts about administrator assignment changes

Approval is required to activate the Azure AD privileged administrator role

Check the membership of the administrative role and ask the user to provide reasons for continuing membership

The functional experience of AzurePIM is better than that of local PAM. The local PAM is a data center, and AzurePIM is implemented for multi-tenancy, providing JEA, JIT and PAM experiences for each tenant.

So what is the main role of MIM? MIM 2016 itself is a continuation of FIM, with cross-application identity synchronization, password self-service reset, certificate management, password change notification, PAM implementation, and AzureAD integration mixed synchronization and mixed reporting.

In the PAM system, MIM can achieve the three processes of protection-operation-upgrade. Unlike individual Powershell, users can be configured to log in with multiple factors through MIM. MIM will set up a set of portals based on Sharepoint for permission application and approval, with its own workflow.

In addition, the MIM portal also has the native function of report and audit, which can see the history of each application, as well as the approver.

The MIM implementation of PAM is more standardized than the native Powershell, but the underlying implementation uses the same function. It creates each security principal into roles for users to apply for approval.

MIM architecture supports highly available deployment

MIM cannot be deployed on domain control, multiple MIM servers can be deployed with fault-tolerant MIM services, fortress forest domain control can deploy multiple servers, background SQL database supports high availability of AG/FC/ images, and Sharepoint supports field architecture.

As the deployment of MIM portals is very complex, it is not necessary to deploy MIM only for the portal application and upgrade function of PAM. You can try the Sharepoint+SCO idea mentioned by Lao Wang.

MIM PAM deployment reference link

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/

So we sort out the concepts and logical relationships of JIT, shadow subject and MIM, so what does JEA do? it's a new feature of Powershell5.0 that helps minimize privilege management.

Reduce the number of administrators on your computer by using virtual accounts or group managed service accounts that perform privileged operations on behalf of regular users. We will open the function of a virtual account, and when users want to perform privileged operations, they will wake up the virtual account to actually execute it. Similar technology can be seen in other early Microsoft products.

Control the cmdlet, functions, and external command operations that users can run by creating configuration files

Transcripts and logs provide a better understanding of what the user is doing, which can accurately show the commands that the user executes during the session

Removing administrative permissions is not always easy. Consider common scenarios where the DNS role is installed on the same computer as the Active Directory domain controller. Your DNS administrators need local administrator privileges to resolve problems with DNS servers, but to do so, you must make them members of the highly privileged "Domain Admins" security group. This method effectively enables DNS administrators to control the entire domain and access all resources on that computer.

JEA helps solve this problem by helping you adopt the principle of least permissions. With JEA, you can configure management endpoints for DNS administrators so that they can access all the PowerShell commands they need to get the job done, but that's it. This means that you can provide appropriate access to repair poisoned DNS caches or restart DNS servers without inadvertently granting them Active Directory permissions, or browsing the file system or running potentially dangerous scripts. Better yet, when a JEA session is configured to use a temporarily privileged virtual account, the DNS administrator can use the non-administrator to connect to the server credentials and still be able to run commands that normally require administrator privileges. This feature allows you to remove users from the local / domain administrator role with extensive privileges and carefully control what they can do on each computer

JEA configuration reference: https://docs.microsoft.com/en-us/powershell/jea/prerequisites

JEA is especially suitable for some hosting accounts, such as VMM hosting accounts, SCOM monitoring accounts, some hosting accounts, task execution accounts, you no longer have to use a Domain Admins account, you just need to assign a user and hide it in a virtual account.

If we string together the technologies of JEA,JIT and shadow subject, we can fully realize the operation effect of PAM. When a user applies for permission in Fortress Forest, the shadow subject member will be added to the JIT timely after approval, and the shadow subject added is also a protection group defined by JEA. The application record and approval record will be audited by MIM or Sharepoint. After logging in, the user will connect to a workstation to perform management operations. With JEA, the privilege group may not have to be given to Domain Admins, and the ordinary administrator group can complete it, because there will be hidden virtual accounts behind the scenes to perform management operations. When users perform production forest management operations on the workstation, the command operations that can be performed are limited by the JEA configuration file, and the management operations are performed entirely through the virtual account, when the JIT expiration date. The user will completely lose the administrative rights to the production forest and workstation.

Now let's string together the entire security model of 2016.

Sort out the production forest administrators, control the number of administrators, establish security subjects in the fortress forest, allocate timeliness membership as far as possible, and turn on multi-factor authentication for fortress forest users who need to obtain permissions.

For production forest main servers, fortress forest workstations, production forest workstations, open Credential guard,Remote guard, prevent hash cracking, configure Windows Defender security protection

Users' privileged operations are audited through other portals such as MIM or Sharepoint, and commands are executed through JEA log records.

Manage encryption through MBAM key server disk encryption

Perform security posture diagnosis on the server through SCOM or public cloud OMS, and availability / performance / security diagnosis on the application through APM or Application Insights.

Through the analysis of consanguinity detection by ATA, the cracking and abnormal login behavior of the remaining management account of the production forest are predicted, and the AD domain and syslog are analyzed as a whole.

Secure binding of hosts and virtual machines through Shielded VM ensures that virtual machines can only be started on allowed hosts. Each startup of virtual machines needs to be verified, and virtual machines cannot be copied to other hosts to start.

Through the JIT,JEA involved in PAM, the shadow subject manages and controls the life cycle of privileged execution, controls malicious copies of virtual disks through Shielded VM, and detects the intrusion of accounts in the domain through ATA. The three 2016 outermost security systems help each other to build a better security system. My good friend ZJUNSEN has written a good implementation blog about Shielded VM and ATA. If you are interested, you can read it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.