- Objective 1.1: Support Windows Store and cloud apps
- Objective 1.2: Support authentication and authorization
Objective 1.2: Support authentication and authorization
Users need to be authenticated to access a computer or network before they can be authorized to access the resources on it. Windows 10 supports several authentication mechanisms and methods, and different ways to manage accounts. This chapter will help you to understand the important concepts needed to support Windows 10 authentication and authorization.
Support user authentication
User authentication can come in many forms in Windows 10. You need to understand the various methods for authentication as well as the different mechanisms for managing and supporting authentication.
Understanding multi-factor authentication
Multifactor authentication requires two (or more) types of authentication to gain access to a device or network. Most often, one type is a password, and the other is something else, such as a smart card, fingerprint, or digital certificate. This section focuses a little more on certificates as a means of achieving authentication, but this book has covered this topic in various places, and you need to review those entries when you can (for the most part, certificates have been associated with apps, because apps must be signed to ensure that they can be trusted).
A digital certificate is issued by a Certificate Authority (CA), such as Verisign or Active Directory Certificate Services (AD CS) in Windows Server 2012 R2. The certificate can be used to provide proof that the identity asking for authentication is trusted and true, and that the identity offering it is also trusted and authentic. Authentication with certificates involves a public key and a private key that can be matched to provide that authentication. If no match occurs, no authentication is provided. You can learn more about Certificate Authorities at http://technet.microsoft.com/en-us/library/cc732368.aspx.
AD CS can issue and manage public key infrastructure (PKI) in a domain, provide public key cryptography and the ability to create digital certificates, and offer digital signature capabilities. For the purposes here, AD CS provides authentication by associating certificate keys with computers, users, and device accounts on a network. This is called binding.
For the exam, you might be asked how to enable users to access a network resource and be given a specific scenario. A scenario that includes AD CS will note that the network has its own PKI infrastructure. You need to understand that the required certificates must be available to the computer and the user, and they need to be stored in the proper location for authentication to be granted. Client certificates are stored in the Personal certificate store for the applicable user account on the client computer. Computer accounts need trusted root certificates to be stored in the Trusted Root Certification Authorities store, again on the client computer.
You can explore many other certificate folders as well. To view these stores on a local computer, type certmgr.msc in a Run dialog box, and click OK. Open this console and review the available certificate folders before moving on. Figure 1-11 shows a local computer, not connected to a domain, and the related Personal certificates. Typically, you’ll see more certificates than those present in the example.
FIGURE 1-11 The Certmgr console
Understanding virtual smart cards
A virtual smart card works in the same general manner as a physical smart card does, but doesn’t require a connected or installed smart card reader. Instead, the virtual smart card works with a Trusted Platform Module (TPM) chip, which protects the virtual card information through encryption, installed on the computer. As with other more advanced security options, you’ll need a PKI domain infrastructure, complete with certificates and the ability to create and manage them, to incorporate this technology. Virtual smart cards offer the following:
- Authentication protection
- Confidentiality of the machine and its contents
- Private keys for security
- Encrypted card information that can’t be mined or removed (that is, it can’t be exported)
- Protection from rogue software that attacks at startup
- Multi-factor protection (smart card and PIN)
To use virtual smart cards, you need to meet more requirements than when you opt to use physical ones. These requirements include, but aren’t limited to the following:
- Computers must be running Windows 8 or higher and Windows Server 2012 or higher.
- A compatible TPM must be installed on those computers that adhere to TPM 1.2 or higher standards.
- A limit of ten smart cards (virtual or physical) can be used on a single computer.
- The PIN and the PIN Unlock Key must be a minimum of eight characters. These can include numbers, letters, and special characters.
One very important command that you need to understand for the exam is Tpmvscmgr.exe, the command-line tool you use to configure a virtual smart card. You can use the command locally or remotely. Parameters you can use include Create and Delete. Examples include /name (the name of the smart card), /admin key (administrator key), /PIN (the PIN), /generate (to create the files in storage necessary for the card to function), and others listed at http://technet.microsoft.com/en-us/library/dn593707.aspx.
To configure a virtual smart card environment from scratch in a domain, you need to follow these steps:
- Create a certificate template, a sixteen-step process performed on a Windows server in a domain that’s installed with and running a CA, as outlined at http://technet.microsoft.com/en-us/library/dn579260.aspx#BKMK_Step1.
Create the virtual TPM smart card, a four-step process that uses the Tpmvscmgr.exe command with parameters, as outlined at http://technet.microsoft.com/en-us/library/dn579260.aspx#BKMK_Step2.
tpmvscmgr.exe create /name tpmvsc /pin default /adminkey random /generate
- Enroll the certificate on the TPM virtual smart card, a six-step process, by using the Certmgr.msc console to add the certificate to the Personal store, as outlined at http://technet.microsoft.com/en-us/library/dn579260.aspx#BKMK_Step3.
To configure a Windows 10 virtual smart card on a stand-alone computer if you have the required technology and credentials available, follow these steps:
- Open an elevated command prompt.
- Type tpm.msc.
- Verify that a compatible TPM can be found that’s at least a TPM 1.2 or later. If you receive an error instead, but are sure a compatible module is available, enable it in the system BIOS before continuing.
- Close the TPM management console.
At the command prompt, enter:
TpmVscMgr create /name MyVSC /pin default /adminkey random /generate
To provide a custom PIN value when creating the virtual smart card, use /pin prompt instead.
Configuring a picture password
A picture password is a way to log on to a computer by using a series of three movements consisting of lines, circles, and/or taps. You can pick any picture you want. Picture passwords can’t be used to log on to domains; they are used to log on to stand-alone computers only. Picture password combinations are limitless because the pictures that can be used are limitless. Although picture passwords are considered more secure for stand-alone computers than typing a PIN or password, a hacker can get into a device by holding the screen up to light to see where most of the gestures are (by following the smudges on the screen). This is especially true if the user touches the screen only to input the password and rarely uses touch for anything else.
You create a picture password (or a four-digit PIN) from the Settings app:
- Open the Settings app, and then click Accounts.
- Click Sign-in Options.
- Under Picture Password, click Add.
- Input your current password, and then click Choose Picture to browse to and select the picture to use.
- Follow the instructions in the resulting wizard to configure the picture password.
Biometrics, like picture passwords, provides infinite possibilities for securing a computer and can be used as part of a multi-factor authentication plan (using it on its own isn’t recommended). Biometric options are generally configured by incorporating a person’s fingerprint and using a fingerprint reader (you “enroll” the user when configuring this), but you can also use a person’s face, eye, or even their voice.
Microsoft has made using biometrics easier than ever by including native support for biometrics through the Windows Biometric Framework (WBF), which includes an option in the Settings app for configuring the device on Windows 10 computers. Windows now also includes Group Policy settings related to biometrics, and you can enable or disable this feature as desired. You need to review the information at http://technet.microsoft.com/en-us/library/dn344916.aspx, and locate the available Group Policy settings, just in case. You can find Local Group Policy options here (and follow the same general path in Group Policy): Computer Configuration/ Administrative Templates/ Windows Components/ Biometrics/, as shown in Figure 1-12.
FIGURE 1-12 The Biometrics Group Policy settings
Support workgroup, homegroup, and domain membership
In this section, you’ll review the differences between some similar technologies and network configurations, such as workgroup versus homegroup, workgroup versus domain, and credential caching versus Credential Manager.
Homegroups, workgroups, and domains
In almost all instances and scenarios, using a computer to complete tasks involves connecting to a network of some sort, even if it’s just to access the Internet or to back up your work someplace other than your own PC. In homes, networked computers are often configured as homegroups. In a small business, the configuration is generally a workgroup. The purpose of both of these types of networks is frequently to share an Internet connection as well as files, folders, printers, and other resources. Domains are used in larger enterprises, which require more control and good protection of resource access. Domains are the only one of these three that employ AD DS to manage users, computers, and resources.
A homegroup lets home users easily share documents, printers, and media with others on their private local network. This is the simplest kind of network sharing and is limited in what permissions and restrictions can be placed on the data shared. By default, all users that join a homegroup (only one per network) have read-only access to what’s already shared by others. Users can reconfigure this, however, enabling both read and write access, if desired. When opting for a homegroup, users can:
- Create or join a homegroup from the prompt offered by Windows, assuming the network is configured as Private.
- Create or join a homegroup from the Network And Sharing Center, assuming the computers that want to join are running Windows 7, Windows 8, or Windows 10. Work through the applicable homegroup wizard to create or join a homegroup. Windows generates a random password other users will need to use to join.
- Share files from their original locations and their default libraries.
- Grant read-only or read/write access to the data they’ve shared.
- Limit access to only those network users who also have an account and password on their computers.
- Configure the same permissions for all network users, or set different permissions for individual users.
Because you can create and join a homegroup using a wizard, detailing the steps in this text isn’t really necessary. However, you need to create a homegroup on your own local network and let other computers join it, just so that you are familiar with the process. Note that users might already be joined to a homegroup because Windows detects and will prompt you to join existing homegroups automatically during setup.
In businesses where a little more control is required and a homegroup isn’t the ideal configuration, a workgroup is used. A workgroup is a manual grouping of computers (almost any operating system will do, including Windows RT) that doesn’t include an Active Directory domain controller, but still offers security options. A workgroup exists on a single network segment. Securing data here is a distributed concept similar to a homegroup; each user decides what to share, how to share it, and with whom to share. Note that Windows doesn’t create a password for joining the workgroup, nothing is shared automatically by default (except possibly the Public folders), and users join the workgroup from the System Properties dialog box under the Computer Name tab (see Figure 1-13). Click Change in the System Properties dialog box, and then enter the workgroup name in the Computer Name/Domain Changes dialog box.
FIGURE 1-13 The Computer Name/Domain Changes dialog box
Because this section is about authorization, you need to consider that concept with regard to a workgroup. Users decide what to share, and then share it. The person who wants access to shared items must have an account on the sharing computer (or be given one). Accounts are stored in the Security Account Manager (SAM) database in the sharing computer.. Because each computer maintains its own local database, users who need to access resources on multiple workgroup computers must be authenticated on each. The problem with this is that as the network grows, so does the amount of work required to maintain and manage these accounts.
Here is an overview of how authorization works:
- The first time a user tries to access a shared resource, he or she is asked for a user name and password.
- The user name and password that are entered must be from an approved account on the sharing computer and must be listed in the SAM database. The user can opt to have Windows remember the password for the next time.
- The Local Security Authority (LSA) looks to the SAM database to see whether the account that was entered is valid.
- If the account is valid, the user is granted access.
- The same user who wants to access another shared resource on the same computer during the same session can do so without re-entering the password.
- If this same user wants to access a shared resource on another computer in the workgroup, the process must be repeated.
Companies and enterprises configure networks as domains. You couldn’t successfully manage 100 computers by using a homegroup or workgroup, so a domain is an obvious choice for enterprise networks.
Domains are configured with at least one AD DS domain controller that authenticates users centrally and secures network resources. These larger networks can contain additional servers that manage data storage, email, faxes, and printers; maintain database replications, and so on. Managing all resources as a whole is important to keeping everything secure and available for users, and enables a simpler management solution for administrators. A large enterprise can have more than one domain. When multiple domains exist, a Global Catalog is used to locate objects in other domains. Authentication in a domain is handled by AD DS, a database that contains objects, such as user accounts, computers, groups, and so on. In this case, a network administrator creates user accounts, almost always puts those accounts into groups, and then assigns the desired permissions to the group. This makes managing users simpler than trying to manage users one at a time, and it enables administrators to deal with newly hired or recently fired employees. The authentication process includes and uses the Kerberos v5 authentication protocol to identify the user or the host. The Kerberos Key Distribution Center (KDC) uses the domain-specific AD DS as its security account database. AD DS is required for default Kerberos implementations within the domain or forest. If you aren’t familiar with Kerberos v5, the TechNet article “Kerberos Authentication Overview” at http://technet.microsoft.com/en-us/library/hh831553.aspx provides a good explanation of how this works and offers links to additional resources.
Understanding computer and user authentication
The previous section discusses AD DS and authentication with regard to user accounts. Network administrators create these accounts, users input their account credentials to log on to the domain, and authentication is handled by the applicable AD DS server and Kerberos v5. Computers that join domains acquire a computer account automatically. Like user accounts, computer accounts are used to authenticate the computer to enable it to access network and domain resources. Each computer account must be unique. A user doesn’t have to do anything to cause the computer to be authenticated. Note that computers have passwords that are automatically managed, and if a computer password on a client is out of sync with AD DS, then the computer can’t authenticate.
Computer accounts are necessary for auditing, for control, and for grouping purposes. You can apply changes to computer accounts that affect whoever logs on to the computer, and not the individual users. For instance, you can force policies regarding the desktop appearance, how updates are applied, and so on, and those policies will affect the computer and anyone who uses it.
Administrators can manage computer accounts in the same way they can user accounts—by adding, deleting, resetting, and disabling them in the Active Directory Users And Computers snap-in.
Understanding Secure Channel
When applications need network or Internet access, you have to ensure that the connection is secure. This is especially true if you are transmitting data over an untrusted network. You can use Transport Layer Security (TLS)/Secure Sockets Layer (SSL) security to authenticate servers and client computers, and then use that to encrypt messages between them. These two protocols are included in the Secure Channel set of security protocols. TLS and SSL aren’t interchangeable and SSL is the predecessor to TLS, but both protect against tampering and eavesdropping.
Secure Channel can authenticate an identity as well as provide a secure and private connection to another host by using encryption. It’s also called Schannel and is mostly used for applications that require secure HTTP communications. Schannel is a Security Support Provider (SSP), and the TLS/SSL protocol uses a client/server model that’s based on certificate authentication. This means you need to also have a PKI configured and available.
Exploring account policies
The weakest link when protecting computers that use a password as part of the authentication process is most often the password itself. The password could be nonexistent (not likely, especially with the advent of the Microsoft account for stand-alone computers), too short, too simple, too predictable, or the user might simply never change it. Often, users create and use the same password for multiple user IDs. This is a secondary weak link. To protect authentication in both workgroups and domains, you can create local policies and Group Policy Objects (GPOs) defining how passwords should be created, how often they can or must be changed, and what happens when a user fails to log on after attempting a specific number of times that you set. You can configure account policies in the Local Security Policy for a stand-alone computer or for computers in a workgroup, and in Group Policy for domains. In Local Security Policy, Account Policies is listed first. Click Account Policies, and then click Account Lockout Policy to see the options.
You can configure three account lockout policies, and in most instances they must be configured together:
- Account Lockout Duration If you’ve configured an account lockout threshold and if that threshold is met, this setting defines how long (in minutes) the user will be locked out of the computer. A setting of 5 to 15 minutes is common.
- Account Lockout Threshold You need to configure this to use the other options. This setting defines how many times a user can try to log on to the computer and fail, before being locked out.
- Reset Account Counter After This setting defines the number of minutes that must pass after a failed logon attempt before the failed logon attempt counter is reset to zero. If an account lockout threshold is defined, this must be less than or equal to the number of minutes set there.
Exploring Credential Manager
Using user names and passwords is a common way to authenticate users. Windows 10 includes Credential Manager to help manage and maintain those passwords. Credential Manager saves the credentials that users enter when they use their own computers to access network servers and resources on local networks (Windows credentials), and can be used to back up and restore them. When prompted, users have to check the box Remember My Credentials, or else the credentials won’t be saved. Credential Manager also offers Credential Locker, which saves user names and passwords associated with websites and Windows apps (Web Credentials). It saves all of these in an area called the Windows Vault.
If the user name or password has been changed since the last time it was saved and access is unsuccessful, the user is prompted to type the new credentials. When access to the resource or website is successful, Credential Manager and Credential Locker overwrite what was there.
The saved user names and passwords follow users when they move from one computer to another in a workgroup or homegroup, presuming they log on with their Microsoft accounts. However, this feature isn’t enabled on domains for security reasons. You can open Credential Manager from Control Panel. Figure 1-14 shows Credential Manager.
FIGURE 1-14 Credential Manager
Here are a few more points to understand about Credential Manager:
- You can program Windows Store apps to use Credential Locker.
- Credential roaming requires the Microsoft account for synchronization.
- Credential roaming is enabled by default on non-domain joined computers, and it is disabled on domain-joined computers.
- Credential Locker supports seamless sign in by using Windows Store apps that use Web Authentication Broker and remember passwords for services, such as Twitter and LinkedIn.
Configure local accounts and Microsoft accounts
The Microsoft account enables users to sync settings to the cloud and to other computers that they log on to using that same Microsoft account. With a Microsoft account, users can also access their own cloud storage, called OneDrive. Windows 10 comes with the OneDrive app, which can be accessed from compatible applications, various web browsers, and File Explorer.
Users are prompted to create a Microsoft account when they set up their Windows 10-based computers. They can opt to do that, or they can decline and create a local account instead. A user might also create a local account if the computer can’t access the Internet during setup (because they can’t create or confirm the Microsoft account if no Internet access is available). Users generally opt to create a Microsoft account later, even if they start with a local account, because many apps are inaccessible if the user is logged on with a local account. Users also can’t get apps from the Store without a Microsoft account.
After a Microsoft account is created, users don’t need to be connected to the Internet to log on during subsequent sessions. The account information is cached locally. If an Internet connection isn’t available, the last saved settings are also applied because they are also cached locally. You can switch from a local account to a Microsoft account from the Settings app.
A Microsoft account can be used in a domain, if it isn’t restricted through Group Policy. If possible at your place of business, when connected, users will see the same desktop background, app settings, browser history, and so on that they see on their main computers at home (or in another office). Again, you can make the change through the Settings app. There, you’ll opt to connect your Microsoft account and work through the setup process.
Configure Workplace Join
Personal devices have become part of the enterprise landscape, and if you don’t already, at some point you need to be able to enable users to access network resources from them. This is how Workplace Join came about. Workplace Join enables users to have a single sign-on (SSO) experience and enables them to get to the resources they need. You can also manage and secure the devices. In Windows Server 2012 R2, you can use Workplace Join with Windows 8.1, Windows 10, and iOS devices.
Workplace Join uses the Device Registration Service (DRS), part of the Active Directory Federation Services (ADFS) role in Windows Server 2012 R2, to create a device object in AD DS and use a certificate to identify the device in the future. If you add Web Application Proxy, users can join your enterprise from any Internet-enabled location.
Various walkthrough guides are available on TechNet to help you use this technology to join devices. Here are two of those:
- “Walkthrough Guide: Workplace Join with a Windows Device”: https://technet.microsoft.com/en-us/library/dn280938.aspx.
- “Walkthrough Guide: Workplace Join with an iOS Device”: https://technet.microsoft.com/en-us/library/dn280933.aspx.
Configure Windows Hello
Windows Hello enables you to use a combination of optical recognition and fingerprint data to sign in to a Windows 10 computer, and authenticate to apps, enterprise content, and online authentication providers. Windows Hello is designed to be a user-friendly interface for configuring biometric authentication in Windows 10.
You can configure Windows Hello from the Settings app, in the Sign-in Options section of the Accounts page.
- Multi-factor authentication lets you further secure the authentication process with certificates, virtual smart cards, picture passwords, and biometrics, by requiring more than one method of authentication before access is granted.
- Different networks exist for different needs. Homegroups enable simple sharing for home networks; workgroups let you share and manage shared data in a non-domain setting; and domains are used by larger enterprises and include Active Directory Domain Services (AD DS) to secure and manage authentication.
- You can further secure authentication by including Secure Channel, account policies, credential caching, and Credential Manager to help control access and manage logon credentials.
- Local accounts are good for homegroups and workgroups, but now even those networks rely on Microsoft accounts for authorization management. Microsoft accounts can also be incorporated into domains to sync settings, such as desktop backgrounds.
- Workplace Join enables you to enroll and control mobile devices on your domain for the purpose of letting your users bring their own devices to work.
- Windows Hello enables configuration of facial and fingerprint recognition for use with the Windows 10 authentication process.
Answer the following questions to test your knowledge of the information in this objective. You can find the answers to these questions and explanations of why each answer choice is correct or incorrect in the “Answers” section at the end of this chapter.
Which two of the following Windows PowerShell commands can you use to manage a CA database?
Which two of the following technologies offer authentication protection, confidentiality of the machine and its contents, private keys for security, and encrypted card information that can’t be mined or removed?
- Physical smart card
- A compatible TPM chip
- Virtual smart card
- A biometric fingerprint reader
- BitLocker Drive Encryption
You create a homegroup on one computer and join it from another. This process goes smoothly. However, when you try to access data shared with the homegroup from the second computer, you can’t. What’s most likely the problem?
- You aren’t connected to the network.
- You aren’t using BitLocker Drive Encryption.
- The time is configured incorrectly on the second computer.
- You aren’t running a compatible version of Windows.
Which of the following network types is a distributed concept, in which users manage their own data sharing?
- Workgroup or domain
You want to secure communications over an untrusted network for applications that need Internet access. You want to use TLS and SSL to achieve this. Which of the following technologies offers this? Must the solution include a PKI infrastructure?
- Remote Desktop Services
- Microsoft Application Virtualization (App-V)
- Secure Channel
You are trying to configure Group Policy to set an account lockout duration when users try and fail to authenticate their computers after a specific number of events. The options are grayed out. Why?
- You must first configure the policy Account Lockout Threshold.
- You must first configure the policy Reset Account Counter After.
- You are trying to configure the policy for a workgroup computer, but these policies are available only in domains.
- You are in the Group Security Policy console, but need to be in the Group Policy Editor.
Can Credential Manager and Credential Locker be used to store passwords for Windows Store apps? Can Credential Manager and Credential Locker be used to store passwords saved for local network resources?
You want to enable your domain users to access the same desktop background, app settings, browser history, and so on that they see on their main computers at home (or in another office). What should you do?
- A Microsoft account would be optimal, but can’t be used in a domain.
- Let the users associate their Microsoft accounts with their domain accounts.
- Use Workplace Join.
- Incorporate a Web Application Proxy server into your network.