Category Archive : Authentication methods

Monitor and troubleshoot deployment – Deploy and upgrade operating systems

Monitor and troubleshoot deployment

If you experience problems with deployment by using MDT, review the configuration settings for your deployment share. If you’re confident that everything is properly configured, then you can consider reviewing MDT logs. Each MDT script automatically generates logs.

Depending on the type of deployment you’re performing, after deployment, the log files are moved to either:

  • %WINDIR%\SMSOSD
  • %WINDIR%\TEMP\SMSOSD

For LTI deployments, the logs are moved to:

  • %WINDIR%\TEMP\DeploymentLogs

Table 1-15 describes the available MDT logs.

TABLE 1-15 MDT logs

LogDescription
BDD.logCopied to a network location at the end of the deployment. You must specify the SLShare property in the Customsettings.ini file in order to create this log.
LiteTouch.logCreated during LTI deployments and stored in the %WINDIR%\TEMP\DeploymentLogs folder.
Scriptname*.logCreated by each MDT script. The log name is the same as the script name.
SMSTS.logCreated by the Task Sequencer. Describes all Task Sequencer transactions. Stored in %TEMP%, %WINDIR%\System32\ccm\logs, C:\_SMSTaskSequence, or C:\SMSTSLog depending on your specific deployment scenario.
Wizard.logCreated and updated by the deployment wizards.
WPEinit.logCreated during the Windows PE initialization process. This log is useful for troubleshooting errors encountered when starting Windows PE.
DeploymentWorkbench_id.logCreated in the %temp% folder when you specify a /debug when you start the Deployment Workbench.

Exam Tip

The MDT log file format is designed to be read by CMTrace.

When you investigate the logs, you’ll want to identify any errors. There are numerous error codes with specific meanings. For example, error codes 5201, 5203, and 5205 all mean that a connection to the deployment share could not be made, and deployment cannot proceed.

Need More Review? Error Codes and Their Descriptions

To review further details about error codes with MDT, refer to the Microsoft website at https://docs.microsoft.com/troubleshoot/mem/configmgr/troubleshooting-reference#table-1-error-codes-and-their-description.

Need More Review? Troubleshooting Reference for MDT

To review further details about troubleshooting MDT, refer to the Microsoft website at https://docs.microsoft.com/troubleshoot/mem/configmgr/troubleshooting-reference.

Manage accounts, VPN connections, and certificates on Windows 10 – Deploy and upgrade operating systems

Skill 1.4: Manage accounts, VPN connections, and certificates on Windows 10

Microsoft is developing modern authentication methods that rely less on the user’s ability to recall a password and place more reliance on technological advancements, such as multifactor authentication (MFA), device-based authentication, and authentication that supports biometric attributes. These all help secure privileged accounts in your environment. You must understand how Windows 10 offers support for modern authentication methods and how Azure Active Directory provides a secure identity and authentication platform for your modern environment.

When users connect to your workplace across the internet, it’s important that they can authenticate themselves and their devices to help ensure data privacy and security. Knowing how to implement and configure virtual private networks (VPNs) can help you achieve this crucial goal.

An increasingly common way in which devices can authenticate is the use of digital certificates. Managing aspects of a public key infrastructure (PKI), notably the management of certificates, plays a critical role in helping secure your infrastructure.

This skill covers how to:

Secure privileged accounts on Windows 10

Authentication is the primary means through which you can secure privileged and standard user accounts. Windows 10 provides many security features that can help you secure authentication. And when considering cloud-based authentication to services such as Microsoft 365, Azure AD enables you to manage your cloud-based identities and access-management requirements.

Self-Service Password Reset – Deploy and upgrade operating systems

Self-Service Password Reset

If you have ever worked in an IT service desk support function, you know that password-related issues are in the top three of all help desk calls. By implementing self-service password reset, you provide your users with the ability to reset their passwords, with no administrator intervention, whenever they need to.

Self-service password reset includes the following functionality:

  • Password change Users know their password and want to change it to something new.
  • Password reset A user can’t sign in and wants to reset the password.
  • Account unlock A user can’t sign in because the account is locked out. If the user provides a password or passes more approved authentication methods, the account will be unlocked.

Once configured, a user can select the Can’t Access Your Account link on a cloud-based resource access page, or the user can visit the Password Reset Portal at https://aka.ms/sspr to reset the password.

Note Azure AD Self-Service Password Reset

You can review how Azure AD Self-Service Password Reset works in detail and how to implement a Password Reset Portal by viewing this Microsoft website: https://docs.microsoft.com/azure/active-directory/authentication/concept-sspr-howitworks.

Understand MFA

Traditional computer authentication is based on users providing a name and password. This allows an authentication authority to validate the exchange and grant access. Although password-based authentication is acceptable in many circumstances, Windows 10 provides for several additional, more secure methods for users to authenticate their devices, including multifactor authentication (also referred to as two-factor authentication).

MFA is based on the principle that users who want to authenticate must have two (or more) things with which to identify themselves. Specifically, they must have knowledge of something, they must be in possession of something, or they must be something. For example, a user might know a password, possess a security token (in the form of a digital certificate), and be able to prove who they are with biometrics, such as fingerprints.

Explore Biometrics – Deploy and upgrade operating systems

Explore Biometrics

Biometrics, like a fingerprint, provides a more secure (and often more convenient) method—for both the user and administrator—to be identified and verified. Windows 10 includes native support for biometrics through the Windows Biometric Framework (WBF), and when used as part of a multifactor authentication plan, biometrics is increasingly replacing passwords in modern workplaces.

Biometric information is obtained from the individual and stored as a biometric sample, which is then securely saved in a template and mapped to a specific user. To capture a person’s fingerprint, you use a fingerprint reader (you “enroll” the user when configuring this). Also, you can use a person’s face, retina, or even the user’s voice. The Windows Biometric service can be extended to also include behavioral traits, such as the gait of a user while walking or the user’s typing rhythm.

Windows includes several Group Policy settings related to biometrics, as shown in Figure 1-16, that you can use to allow or block the use of biometrics from your devices. You can find Group Policy Objects here: Computer Configuration > Administrative Templates > Windows Components > Biometrics.

Figure 1-16 Biometrics Group Policy settings

Azure MFA

Azure MFA provides organizations with a highly scalable two-step verification solution, which can be used to safeguard access to data and applications and provide users with a simple sign-in process.

There are several methods you can use enable Azure MFA:

  • Enabled by conditional access policy Conditional access policy is available for Azure MFA in the cloud if you have Azure AD premium licensing. It requires Azure AD P1 or P2 licensing.
  • Enabled by Azure AD Identity Protection This method uses an Azure AD Identity Protection risk policy to enforce two-step verification for sign in to all cloud applications. It requires Azure AD P2 licensing.
  • Enabled by changing user state This is the traditional method for requiring two-step verification. An administrator can configure Azure MFA so that users must perform two-step verification every time they sign in, and it overrides conditional access policies.

When enabling Azure MFA, users are required to configure their preferred authentication methods using the registration portal at https://aka.ms/mfasetup, as shown in Figure 1-17.

Figure 1-17 Configuring additional settings for security verification

Configure Azure MFA – Deploy and upgrade operating systems

Configure Azure MFA

To enable Azure MFA for a single cloud-based Azure AD user, you must configure the MFA Service Settings. Then you can create a conditional access policy by using this procedure:

  1. Open the Azure Active Directory admin center (at https://aad.portal.azure.com) and sign in with a global administrator account.
  2. On the Overview blade, under Manage, select Users.
  3. On the menu bar, select Multi-Factor Authentication. A new browser windows opens.
  4. On the multi-factor authentication page, select the service settings tab.
  5. Under verification options, select all the boxes for Methods available to users (Call to phone, Text message to phone, Notification through mobile app, Verification code from mobile app or hardware token).
  6. Select Save.
Create a Conditional Access Policy for MFA

Once MFA settings have been configured, you need to assign them to users by creating a conditional access policy:

  1. In the Azure Active Directory admin center, under favorites, select Azure Active Directory.
  2. Select Security, and then select Conditional Access.
  3. Select New policy.
  4. On the Conditional Access Policy blade, provide a name for your policy.
  5. Under Assignments, select 0 users and groups selected.
  6. Choose between including and excluding specific users, groups, directory roles, and all guest and external users. For example, select Directory roles; then, in the drop-down list, select Global administrator.

Note Don’t Lock Yourself Out

Creating restrictive policies in conditional access for the global administrator account requires caution. Ensure you don’t configure settings that result in you locking yourself out.

  1. Under Cloud apps or actions, select the No cloud apps, actions, or authentication contexts selected link, and then choose the cloud apps or actions you want to protect with MFA. For example, select Microsoft Intune.
  2. Under Conditions, select the 0 conditions selected link, and configure the required settings. For example, select High and Medium Sign-in risk.
  3. Under Access controls, select the 0 controls selected link, ensure the Grant access radio button is selected, and select the check box for Require multi-factor authentication, as displayed in Figure 1-18.

Figure 1-18 Creating a conditional access policy to require MFA

  1. Click Select.
  2. Under Enable policy, toggle the setting to On.
  3. Select Create.
  4. The policy is validated, and it appears in the Conditional Access Policies blade as Enabled.

After you have enabled Azure MFA, you can test it to ensure that the conditional access policy works. Test logging in to a resource, such as the Microsoft Endpoint Manager admin center, with a user who has MFA enabled, and verify that the user is required to provide additional authentication to access the resources.

Note Azure MFA For Administrators

Microsoft offers basic Azure MFA features to Office 365 and Azure AD administrators for no extra cost. All other users require Azure AD premium licensing.