Figure 7-11. Using Computer Name/Domain Changes to Change the Computer’s Name and to Join a Workgroup, or Domain.
Step 4. Select the Workgroup radio button and type the name of the
workgroup in the box provided. This should match the workgroup name of the other computers in your workgroup.
Step 5. Optionally change the Computer name, and then click OK.
Step 6. Windows displays the Welcome to the Workgroup message box.
Click OK.
Step 7. Windows will inform you that you must restart the computer. Click OK.
Step 8. Click Close on the System Properties dialog box. When prompted, click the Restart Now button to restart the computer.
After Windows restarts, the computer will be a member of the workgroup you specified. Click the Network icon from the Start menu to see your network and the computers that you can access.
Domain Account Settings
Users on domain-joined Windows 10 computers can connect their domain
account to their Microsoft account. This will provide the capability to sync their settings, favorites, and Microsoft apps from their home PC or tablet with their domain-joined computer without signing into services separately.
The process is similar to that listed for a nondomain account, but domain users will be presented with an Add a Microsoft Account option on the
Accounts screen. When that option is selected, users can choose what settings to synchronize, as shown in Figure 7-12. Choose the desired sync settings and click Next, and the rest of the process is the same.
Figure 7-12. Selecting the PC Settings to Sync with Your Domain Account
HomeGroup
First introduced in Windows 7 and improved in Windows 10 is the concept of a HomeGroup, which is a small group of Windows 7, 8.1, or 10 computers connected together in a home or small office network that you have
designated in the Network and Sharing Center as a home network. Computers running any edition of Windows 7, 8.1 or 10 can join a HomeGroup, but you cannot create a HomeGroup using Windows RT or Windows 7 Starter or Home Basic editions. Computers running Windows Vista or earlier cannot join a HomeGroup. To create or join a homegroup, your computer's network location profile setting (discussed in Chapter 14) must be set to Private.
You can create a HomeGroup from the HomeGroup applet, which is accessed from the Network and Internet category of Control Panel by clicking
HomeGroup. You can also access this applet by using the Search bar or Cortana, or by clicking HomeGroup from the Network and Sharing Center.
From the Share with Other Home Computers dialog box shown in Figure 7- 13, click Create a Homegroup and then click Next. As shown in Figure 7-
14, the Create a Homegroup Wizard enables you to select the type of
resources you want to share with other computers. For each resource listed here, select Shared or Not Shared as required. After making your selections and clicking Next, the wizard provides you with a unique password that you can use to add other computers to the HomeGroup (see Figure 7-15). Make note of this password so that you can join other computers to the
HomeGroup, and then click Finish.
Figure 7-13. The HomeGroup Control Panel Applet
Figure 7-14. Determining the Type of Resources You Want to Share on the HomeGroup
Figure 7-15. The Create HomeGroup Wizard Displaying the HomeGroup Shared Password
Joining a HomeGroup
After you have created a HomeGroup, when you move to another computer on the network, the computer recognizes the HomeGroup, and the Share with Other Home Computers dialog box informs you of this (see Figure 7-16).
Click Join Now to join the HomeGroup, select the libraries you want to share, and then type the HomeGroup password when requested.
Figure 7-16. The HomeGroup Control Panel Applet Detecting an Existing HomeGroup on the Network
Note
If your computer is joined to a domain, you can still join a HomeGroup.
However, you cannot share libraries or printers to the HomeGroup. This feature enables you to bring a portable computer home from work and access shared resources on your home network. Furthermore, it is possible to use Group Policy to prevent domain computers from being joined to a
HomeGroup.
Modifying HomeGroup Settings
After you've joined a HomeGroup, you receive the Change HomeGroup settings dialog box shown in Figure 7-17 when you access the HomeGroup option in the Control Panel Network and Internet category. From here you can change the types of libraries and printers that are shared with other HomeGroup computers. You can also perform any of the other self-
explanatory actions shown in Figure 7-17 under Other HomeGroup actions.
Selecting the Change Advanced Sharing Settings option takes you to the Advanced Sharing Settings dialog box shown in Figure 7-18.
Figure 7-17. The Change HomeGroup Settings Dialog Box
Figure 7-18. Advanced Sharing Setting Dialog Box
From the dialog box shown in Figure 7-17, selecting the Allow All Devices on This Network Such as TVs and Game Consoles to Play My Shared Content option displays the dialog box shown in Figure 7-19. The list includes all computers and other media devices found on the network
including media players, electronic picture frames, and others. You can allow or block media access to each device individually by selecting the drop-down lists provided, or you can allow or block all devices by choosing from the
appropriate command buttons provided.
Figure 7-19. Choose Media Streaming Options for Computers and Devices Dialog Box Enabling You to Choose Which Devices Are Allowed to Access Shared Media
You can also modify the file-sharing options for subfolders located within any of your shared libraries. To do this, navigate to the desired library in File Explorer and select the folder. From the Share With section on the Share tab, choose one of the following:
• Homegroup (View): Shares the file or folder with Read permission to all users in the homegroup.
• Homegroup (View and Edit): Shares the file or folder with Full Control permission to all users in the homegroup.
• Specific People: Displays the Choose people to share with dialog box shown in Figure 7-20. Type the name of the user with whom you want to share the folder and then click Add.
Figure 7-20. File Sharing Dialog Allowing You to Manage the Share Permissions for Your Libraries
Configuring Device Registration
Large organizations and enterprises have lots of options from Microsoft for keeping the workforce connected, managing devices, providing access to resources and applications, and managing and securing the network.
Implementing a PKI infrastructure, a private and public domain in a forest, and configuring Active Directory Federation Services (AD FS) allows companies to provide their employees with secure and trusted access to workplace resources. Technologies like Workplace Join allows users to connect their devices to secured applications the organization has created over the Internet using their Windows 10 devices, mobile phones, and even Android and iOS devices.
Recent innovations from Microsoft in cloud-based services and technologies such as Microsoft Intune and Azure AD allow companies to leverage existing infrastructure by integrating with the cloud. This provides a way to evaluate technologies without investing in new infrastructure hardware and simplifies the deployment of new capabilities with integration between cloud services and internal company resources.
These cloud services can also help much smaller companies use technologies that would take a lot of resources and expertise to deploy from scratch. In Chapter 5, “Installing and Managing Software,” you learned about Windows Store apps and Office 365, and in Chapter 13, “Microsoft Intune,” you learn more about using Intune to manage devices, and learn more about Microsoft Azure in Chapter 17, “Managing Mobile Apps.” Device registration provides a way for users to securely authenticate to your organization and use a single, trusted credential from anywhere they have an Internet connection.
Implementation and configuration of the entire infrastructure required to enable this functionality is beyond the scope of this text; however, for the 70- 698 (and 70-697) exam you should understand how device registration works with Windows 10 and Azure AD.
When a device is registered, Azure Active Directory Device Registration provides it with a trusted identity that is used to authenticate the device when a user signs in. The device attributes can then be used to enforce access
policies for applications in the organizations or the cloud. Combined with
Microsoft Intune, administrations can create conditional access rules for devices that meet organization policies and security requirements.
To enable device registration, first enable devices in Azure AD, as shown in Figure 7-21. In your directory’s devices configuration, make sure that All is selected under Users May Join Devices to Azure AD, and select the
maximum devices that you want to allow per user. As shown in Figure 7-21, two-factor authentication is not enabled by default. To require two-factor authentication, you need to configure a two-factor authentication provider in Azure AD and configure your user accounts.
Figure 7-21. Enabling Device Registration in Azure AD
After you have configured the Azure AD , registering the device in Windows 10 is automatic when you join the device to the Azure AD. You will need to create user accounts in Azure AD for your users. Use the following steps to join Azure AD and register the device.
Step 1. Click Start and then select the Settings icon.
Step 2. Select the Accounts menu and then click Access Work or School.
Step 3. Click the Connect button. On the Set Up a Work or School Account page, shown in Figure 7-22, click the link Join This Device to Azure Active Directory.
Figure 7-22. Connecting to School or Work
Step 4. Enter your Azure AD credentials and then click Sign In. The
confirmation box shown in Figure 7-23 is displayed. Click Join to continue.
Figure 7-23. Confirming That You Want to Join an Organization’s Azure AD
Step 5. After a few minutes, the confirmation page shown in Figure 7-24 is displayed. Click Done.
Figure 7-24. Confirming Successful Connection to Azure AD
After registration, users can log in to their devices using the credentials for your organization’s Azure AD. You can manage devices from the Azure directory or from Intune. From the Azure AD administration console, you can view the devices that users have registered, as shown in Figure 7-25.
Figure 7-25. Viewing Devices That Users Have Registered in the Azure AD Administration Portal
Configuring Device Guard
Device Guard is a new security technology for Windows 10 and Windows Server 2016 that helps protect computers from malicious software or rogue applications. On devices that support virtualization, Device Guard leverages the virtualization capabilities of the processor to create a protected system using virtualization-based security (VBS). With Device Guard, you create a
“whitelist” of programs and applications that are allowed to run on the device, known as a Device Guard profile. The profile contains the digital signatures of approved applications, called code integrity policies, that
Device Guard will enforce. Any application that attempts to load but does not match the profile will not be allowed to run.
Device Guard and Credential Guard (discussed later in the section
“Configuring Credential Guard”) are a set of features that protect the system by using Virtual Secure Mode (VSM). VSM leverages the processor-based virtualization extensions to sequester critical processes and their memory against tampering from malicious entities or software. In this way, a separate operating system is created on top of the hypervisor where security sensitive operations can occur, independent of the host OS. Code integrity consists of both Kernel Mode Code Integrity (KMCI), which controls kernel and kernel- level device drivers, and Hypervisor Code Integrity (HVCI), which controls the security of user mode software.
Deploying Device Guard requires some specific hardware on the computers where it will be implemented, as described in the list that follows.
• A 64-bit CPU.
• CPU virtualization extensions, such as VT-x for Intel processors or AMD-V for AMD.
• Extended page tables, also called Second Level Address Translation (SLAT).
• UEFI firmware version 2.3.1.c or higher, with UEFI Secure Boot. The firmware must also support secure firmware update.
Also note that Device Guard is supported only in Windows 10 Enterprise, Windows 10 Education, Windows 10 Mobile, or Windows Server 2016.
Applications that you want to configure for Device Guard must be digitally signed, either through an embedded signature or using a catalog. Windows has required drivers to be signed since Windows 8, and most applications have digital signatures. Custom or LOB applications that your organization creates must also be signed or referenced in a catalog of digital certificates. If you use a catalog, it must be updated along with any updates to the
applications.
Implementation of Device Guard in an organization requires careful planning and consideration. You must ensure the devices you want to protect meet the hardware requirements. You will need reference computers that you can use to collect information on the allowed applications to create your code
integrity policies. You can run Device Guard in Audit mode, which will not block applications but will create event log entries when an application outside the policy is loaded. When you are satisfied with your code integrity policy, you should pilot the profile with a few users to ensure that critical processes and applications are working as expected.
One of the first steps to deploying Device Guard is to use a reference
computer, or golden computer, a device with the same hardware and software as the target devices in your organization, and begin creating your code
integrity policy. Use the following steps to create the code integrity policy:
Step 1. From an elevated PowerShell prompt, use the following example
commands to create the XML files and binary policy file. In this example, the files will be called DGScan.xml and DGPolicy.bin, respectively. The files will be written to the C:\DGPolicy directory.
$CIPolicyPath=”C:\DGPolicy\”
$InitialCIPolicy=”$CIPolicyPath+”DGScan.xml”
$CIPolicyBin=$CIPolicyPath+”DGPolicy.bin”
Step 2. Use the New-CIPolicy cmdlets to create the new code integrity policy. This will scan the system for installed applications.
New-CIPolicy -Level PcaCertificate -FilePath $InitialCIPolicy -UserPEs 3 > C:\DGPolicy\CIPolicyLog.txt
Step 3. Use the ConvertFrom-CIPolicy cmdlets to convert the code integrity policy to a binary format that Device Guard can use.
ConvertFrom-CIPolicy $InitialCIPolicy $CIPolicyBin
The original .xml file and the Device Guard binary file will be available in C:\DGPolicy. You can use these files when enabling Device Guard.
Microsoft provides a hardware readiness tool you can use to ensure your device can support Device Guard, and it enables the Device Guard features for you. The tool is distributed as a .zip file with a PowerShell script, default audit and enforcement policies, and instructions for using the tool. You need to run the DG_Readiness_Tool_v2.1.ps1 script using an elevated
(administrator) PowerShell prompt. Running the script with no parameters will produce the syntax instructions as shown in Figure 7-26.
Figure 7-26. Running the DG_Readiness_Tool Script with No Parameters Displays the Available Command Syntax
The first thing to do is to ensure your device is capable of running Device Guard by running the script with the -Capable command. When the script is first run, it runs Driver Verifier to check the code integrity of your drivers, which will require a reboot. You can add the -AutoReboot switch to let the script reboot the computer whenever it needs to do so. After validating your drivers, the script will check other software and hardware requirements, and then present a summary, as shown in Figure 7-27. The summary in the image tells us that we cannot use Device Guard or Credential Guard on this machine because Secure Boot Validate Failed. Several warnings are also included.
Warnings mean you can use VBS features, but it will be less secure and reliable because of the missing features. The script will also create a log file in C:\DGLogs, which you can use to review the tool’s output.
Figure 7-27. DG_Readiness_Tool Running with the -Capable Switch to Check Hardware and Software Compatibility
After you have confirmed that your computer meets the hardware and
software requirements, you can enable Device Guard. To use the tool, run it with the -Enable command-line switch. To use the specific policy you created, use the -Path switch and provide the path to your policy file. For example:
DG_CG_ReadinessTool_2.1.psi -Enable -Path C:\DGPolicy\DGPolicy.bin.
This turns on the Hyper-V hypervisor, IOMMU memory settings, and creates the Registry keys to set up Device Guard and Credential Guard.
You can also enable VBS and Device Guard using Group Policy Objects. The policies are located under Computer Configuration\Administrative
Templates\System\Device Guard. To install your custom policy, use the
Deploy Code Integrity Policy, as shown in Figure 7-28. You will need to copy your binary policy file to a server file share accessible to all the devices you are configuring.
Figure 7-28. Setting the Code Integrity Policy for Device Guard
To enable the policy on Windows devices, use Turn On Virtualization Based Security. You can enable both Device Guard and Credential Guard using this policy, as shown in Figure 7-29. You can select whether to use UEFI lock for each (Device Guard is called Virtualization Based Protection of Code
Integrity in the policy). If you select Enabled with UEFI Lock, you will not be able to disable the settings using Group Policy; the VBS protection will be locked down on the device.
Figure 7-29. Enabling Device Guard and Credential Guard Using Group Policy Objects
Note
To learn more about Device Guard and Credential Guard and details of how they work and how to deploy these technologies, see the “Device Guard Deployment Guide” at https://technet.microsoft.com/en-
us/itpro/windows/keep-secure/device-guard-deployment-guide.
Configuring Credential Guard
Credential Guard works the same as Device Guard in a VBS environment, but instead of protecting against malicious software, it works to protect
secrets in a similar way. To prevent credential theft attacks, Credential Guard stores NTLM password hashes and Kerberos tickets and passwords stored in Credential Manager in a secure virtualized location inaccessible to most credential theft attacks.
The hardware and software requirements for Credential Guard are the same as those for Device Guard. You can also use the same tools to validate your devices and enable Credential Guard, as you learned in the previous
discussion of Device Guard. When Credential Guard is enabled, it works automatically to protect your credentials from vulnerabilities.
Configuring Device Health Attestation
New to Windows 10 and Windows Server 2016 is Device Health Attestation (DHA). DHA helps enterprises improve security by monitoring devices and hardware and ensuring they are guarded against security threats. DHA is a service that monitors Windows devices and reports the status of the devices’
Secure Boot, BitLocker integrity, and the Early Launch Anti-Malware Driver (ELAM), which is loaded first after Secure Boot to protect against bootloader malware. DHA is implemented using hardware components of each device, and validating the health of these components is performed using the
Windows Health Attestation Service, which is available in several flavors:
• DHA Cloud Service is a Microsoft-managed service accessible from anywhere in the world.
• DHA On-Premises Service is enabled through a new server role in Windows Server 2016, available to any customers licensed for Windows Server 2016.