All user accounts are identified with a logon name. In Windows 8.1, the logon name for a regular account has the following two parts:

For the user WilliamS, whose account is created for the computer ENGPC85, the full logon name for Windows 8.1 is ENGPC85WilliamS. With a local computer account, WilliamS can log on to his local workstation and access local resources but is not able to access domain resources.

When you create a Microsoft account for a user, Windows 8.1 uses the name information you specify as the logon name. The user’s first and last names are set as part of the display text. The full email address serves as the logon name because this is what’s stored locally on the computer. When the user logs on and the computer is connected to the Internet, the user’s settings and content can be synced and updated according to their preferences. If the computer isn’t connected to the Internet, the user’s settings and content come from their profile, as with regular user accounts.

When you are working with domains, the full logon name can be expressed in two different ways:

Although Windows 8.1 displays user names when describing account privileges and permissions, the key identifiers for accounts are security identifiers (SIDs). SIDs are unique identifiers generated when security principals are created. Each SID combines a computer or domain security ID prefix with a unique relative ID for the user. Windows 8.1 uses these identifiers to track accounts and user names independently. SIDs serve many purposes, but the two most important are to enable you to easily change user names and to delete accounts without worrying that someone might gain access to resources simply by re-creating an account.

When you change a user name, you tell Windows 8.1 to map a particular SID to a new name. When you delete an account, you tell Windows 8.1 that a particular SID is no longer valid. Even if you create an account with the same user name later, the new account won’t have the same privileges and permissions as the previous one because the new account will have a new SID.

User accounts can also have passwords, biometrics, and certificates associated with them. Passwords are authentication strings for an account. Passwords must conform to specific requirements. For examples, typical passwords must be at least eight characters.

Regarding biometrics, fingerprints are the only biometric factor supported by Windows at this time. By default, fingerprints are an authentication option for local logons whenever a computer has a fingerprint reader installed that supports the Windows Biometrics Framework. Additional configuration is required before fingerprints can be used for domain logons.

In Group Policy under Computer ConfigurationWindows ComponentsBiometrics, you’ll find several settings for managing how biometrics can be used. These settings include the following:

Windows 8.1 replaces the biometrics control panel previously available. Now fingerprint registration is a standard logon option when a compatible fingerprint reader is installed and fingerprints are permitted for authentication. To register fingerprints, navigate to PC SettingsAccountsSign-in Options. You’ll then be prompted to add a fingerprint to the current account by swiping a finger on the fingerprint reader. Because several scans are necessary, you’ll need to swipe the same finger several times. After registering a fingerprint, you’ll be able to swipe a registered finger on the fingerprint reader and use this for logon and privilege elevation.

Certificates combine a public and private key to identify a user. You log on with a password or fingerprint interactively, whereas you log on with a certificate by using its private key, which is stored on a smart card. Although physical smart cards that users must carry with them require swiping the card in a smart card reader, Windows 8.1 also support virtual smart cards. With virtual smart cards, Windows 8.1 stores the smart card’s certificate on the local computer and protects the smart card by using the computer’s Trusted Platform Module (TPM) security chip. Virtual smart cards meet two-factor authentication requirements because the virtual smart card must be set up on the computer and any user who wants to use the virtual smart card must know the related PIN.

When you install Windows 8.1, the operating system installs default user accounts. You’ll find several built-in accounts, which have purposes similar to those of accounts created in Windows domains. The key accounts are the following:

By default, these accounts are members of various groups. Before you modify any of the built-in accounts, you should note the property settings and group memberships for the account. Group membership grants or limits the account’s access to specific system resources. For example, Administrator is a member of the Administrators group, and Guest is a member of the Guests group. Being a member of a group makes it possible for the account to use the privileges and rights of the group.

In addition to the built-in accounts, Windows 8.1 has several pseudo-accounts that are used to perform specific types of system actions. The pseudo-accounts are available only on the local system. You can’t change the settings for these accounts with the user administration tools, and users can’t log on to a computer with these accounts. The pseudo-accounts available include the following:

Windows 8.1 also provides groups, which you use to grant permissions to similar types of users and to simplify account administration. If a user is a member of a group that has access to a resource, that user has access to the same resource. You can give a user access to various work-related resources just by making the user a member of the correct group. Although you can log on to a computer with a user account, you can’t log on to a computer with a group account. Because different Active Directory domains or local computers might have groups with the same name, groups are often referred to by DomainGroupName or ComputerGroupName (for example, TechnologyGMarketing for the GMarketing group in a domain or on a computer named Technology).

Windows 8.1 uses the following three types of groups:

As with user accounts, group accounts are tracked by using unique SIDs. This means that you can’t delete a group account and re-create it and then expect all the permissions and privileges to remain the same. The new group will have a new SID, and all the permissions and privileges of the old group will be lost.

When you assign user access levels, you have the opportunity to make the user a member of the built-in or predefined groups, including:

In most cases, you configure user access by using the Users or Administrators group. You can configure user and administrator access levels by setting the account type to Standard User or Administrator, respectively. Although these basic tasks can be performed by using the User Accounts options of Control Panel, you make a user a member of a group by using Local Users And Groups under Computer Management.

When computers are members of a domain, you typically use domain accounts to log on to computers and the domain. All administrators in a domain have access to resources on the local workstations that are members of the domain. Users, on the other hand, can access resources only on the local workstations they are permitted to log on to. In a domain, any user with a valid domain account can by default log on to any computer that is a member of the domain. When logged on to a computer, the user has access to any resource that his or her account or the groups to which the user’s account belongs are granted access, either directly or indirectly with claims-based access policies. This includes resources on the local machine, in addition to resources in the domain.

You can restrict logons to specific domain workstations on a per-user basis by using Active Directory Users And Computers. In Active Directory Users And Computers, press and hold or right-click the user account, and then tap or click Properties. On the Account tab of the user’s Properties dialog box, tap or click Log On To, and then use the options in the Logon Workstations dialog box to designate the workstations to which the user is permitted to log on.

When you work with Windows 8.1, however, you aren’t always logging on to a domain. Computers configured in workgroups have only local accounts. You might also need to log on locally to a domain computer to administer it. Only users with a local user account can log on locally. When you log on locally, you have access to any resource on the computer that your account or the groups to which your account belongs are granted access.

In early releases of Windows, malicious software programs could exploit the fact that most user accounts were configured as members of the local computer’s Administrators group. Not only did this allow malicious software to install itself, but it also allowed malicious software to use these elevated privileges to wreak havoc on the computer, because programs installed by administrators could write to otherwise secure areas of the registry and the file system.

To combat malicious software, organizations have locked down computers, required users to log on using standard user accounts, and required administrators to use the Run As command to perform administrative tasks. Unfortunately, these procedural changes could have serious negative consequences on productivity. A person logged on as a standard user couldn’t perform some of the most basic tasks, such as changing the system clock and calendar, changing the computer’s time zone, or changing the computer’s power management settings. Many software programs designed for early releases of Windows simply would not function properly without local administrator rights—these programs used local administrator rights to write to system locations during installation and during normal operations. Additionally, early releases of Windows didn’t let you know beforehand when a task you were performing required administrator privileges.

User Account Control was introduced to improve usability while at the same time enhancing security by redefining how standard user and administrator user accounts are used. UAC represents a fundamental shift in computing by providing a framework that limits the scope of administrator-level access privileges and requires all applications to run in a specific user mode. In this way, UAC prevents users from making inadvertent changes to system settings and locks down the computer to prevent unauthorized applications from being installed or performing malicious actions.

Because of UAC, Windows 8.1 defines two levels of user accounts: standard and administrator. Windows 8.1 also defines two modes (run levels) for applications: standard user mode and administrator mode. Although standard user accounts can use most software and can change system settings that do not affect other users or the security of the computer, administrator user accounts have complete access to the computer and can make any changes that are needed. When an administrator user starts an application, her access token and its associated administrator privileges are applied to the application, giving her all the rights and privileges of a local computer administrator for that application. When a standard user starts an application, her access token and its associated privileges are applied to the application at run time, limiting her to the rights and privileges of a standard user for that application. Further, all applications are configured to run in a specific mode during installation. Any tasks run by standard-mode applications that require administrator privileges not only are identified during setup but require the user’s approval to run.

In Windows 8.1, the set of privileges assigned to standard user accounts includes:

Windows 8.1 also defines two run levels for applications: standard and administrator. Windows 8.1 determines whether a user needs elevated privileges to run a program by supplying most applications and processes with a security token. If an application has a standard token, or an application cannot be identified as an administrator application, elevated privileges are not required to run the application, and Windows 8.1 starts it as a standard application by default. If an application has an administrator token, elevated privileges are required to run the application, and Windows 8.1 prompts the user for permission or confirmation prior to running the application.

The process of getting approval prior to running an application in administrator mode and prior to performing tasks that change system configuration is known as elevation. Elevation enhances security and reduces the impact of malicious software by notifying users before they perform any action that could affect system settings and by preventing applications from using administrator privileges without first notifying users. Elevation also protects administrator applications from attacks by standard applications. For more information on elevation and how UAC works with applications, see Chapter 7.

By default, Windows 8.1 switches to the secure desktop prior to displaying the elevation prompt. The secure desktop restricts the programs and processes that have access to the desktop environment, and in this way reduces the possibility that a malicious program or user could gain access to the process being elevated. If you don’t want Windows 8.1 to switch to the secure desktop prior to prompting for elevation, you can choose settings that use the standard desktop rather than the secure desktop. However, this makes the computer more susceptible to malware and attack.

Every computer has a built-in local Administrator account. This built-in account is not protected by UAC, and using this account for administration can put your computer at risk. To safeguard computers in environments in which you use a local Administrator account for administration, you should create a new local Administrator account and use this account for administration.

UAC can be configured or disabled for any individual user account. If you disable UAC for a user account, you lose the additional security protections UAC offers and put the computer at risk. To completely disable UAC or to reenable UAC after disabling it, the computer must be restarted for the change to take effect.

Admin Approval Mode is the key component of UAC that determines whether and how administrators are prompted when running administrator applications. The default way that Admin Approval Mode works is as follows:

If you are logged on as an administrator, you can modify the way UAC works for all users by completing the following steps:

In Group Policy, you can manage Admin Approval Mode and elevation prompting by using settings under Computer ConfigurationWindows SettingsSecurity SettingsLocal PoliciesSecurity Options. These security settings are:

In a domain environment, you can use Active Directory–based Group Policy to apply the security configuration you want to a particular set of computers. You can also configure these settings on a per-computer basis using local security policy by following these steps:

Windows 8.1 supports two types of local user accounts: regular and connected. For a computer that is a member of a homegroup or a workgroup, you can create a regular local user account by following these steps:

A connected account is a Microsoft account. For a computer that is a member of a homegroup or a workgroup, you can create a Microsoft account by following these steps:

You must be connected to the Internet to create a Microsoft account. When you create a Microsoft account, Windows 8.1 connects to the Microsoft Store to determine whether an account has been set up for the email address you specified. If an account hasn’t been set up, you are prompted to set up the account. To do this, you enter the email address and password to be associated with the account, as well as the user’s first name, last name, and country/region.

Next, you are prompted to add security verification information, including the user’s birth date, a phone number for sending a code to reset the account password as a text message or automated call, an alternate email address to use to send a message for resetting the account password, and a secret question and answer for verifying the user’s identity if needed.

Finally, you must specify communication preferences and then enter verification text. When you click Finish, the Microsoft account is created online and on the local computer.

Synchronizing an account allows app settings, profile configuration options, and some profile content to be synced between the devices the account uses. Exactly what settings are and aren’t synced is controlled with the options on the SkyDrive Sync Settings page in PC Settings.

If a user needs to be able to log on locally to a computer and has an existing domain account, you can grant the user permission to log on locally by completing the following steps:

The User Accounts utility provides an easy way to change account types for local users. You can quickly set the default account type as either standard user or administrator user. For more advanced control, however, you need to use Local Users And Groups to assign group membership to individual accounts. (See the Adding and removing local group members section later in this chapter.)

In a homegroup or workgroup, you can change the account type from standard local user to administrator local user and vice versa by completing the following steps:

In a domain, you can change the account type for a local computer user by completing the following steps:

The PC Settings utility provides an easy way to switch between connected and regular accounts. In a homegroup or workgroup, you can change the account type from a regular local account to a Microsoft account and vice versa by completing the following steps:

In a domain, you can change the account type from a regular domain account to a connected domain account and vice versa by completing the following steps:

In a homegroup or workgroup configuration, local user accounts can be created without passwords by default. This means that a user can log on simply by tapping or clicking his account name on the Welcome screen. To improve security, all local accounts should have passwords.

For the easiest management of local accounts, log on to each account that should have a password, and then assign a password by completing the following steps:

You can create a password without logging on as the user. However, if you create a password without logging on as the user, the user will lose access to her encrypted files, encrypted email, personal certificates, and stored passwords. This occurs because the user’s master key, which is needed to access her personal encryption certificate and unlock this data, is encrypted with a hash that is based on an empty password. So when you create a password, the hash doesn’t match, and there’s no way to unlock the encrypted data. The only way to resolve this is to restore the original settings by removing the password from the account. The user should then be able to access her encrypted files. Again, this issue is related only to local user accounts for computers and not to domain user accounts. Administrators can change or reset passwords for domain user accounts without affecting access to encrypted data.

You can create a password for a local user account by completing the following steps:

Figure 5-5. Create a password with a password hint.

As discussed previously, in order to preserve access to any encrypted data and stored passwords that a user might have, it is preferable to try and recover a user password rather than change or remove the password.

Windows 8.1 provides two ways to recover user passwords:

Passwords for local machine accounts can be stored in a secure, encrypted file on a password reset disk, which can be a floppy disk or a USB flash device. You can create a password reset disk for the current user as discussed in the Creating and Using a Password Reset Disk section in Chapter 1. You can reset a password for a local machine account as discussed in the Resetting a User’s Password section in Chapter 1.

By default, Windows 8.1 displays a Lock screen and a Welcome screen whether a computer is part of a homegroup or workgroup or a domain. The difference between the Lock screen and the Welcome screen is an important one.

The Lock screen is displayed when no one is logged on. In PC Settings, you select PC And Devices, and then use the options on the Lock Screen page to set related settings. You can select a lock screen picture, choose apps to run in the background, and specify whether and how those apps display quick status and notifications. By default, the Messaging, Calendar, and Mail apps display quick status and notifications information. As an administrator, you can override these settings in Group Policy, by enabling Turn Off App Notifications On The Lock Screen in the Administrative Templates policies for Computer Configuration under the SystemLogon path.

When you press and hold or click and then drag up on the Lock screen, the Welcome screen appears. When the Lock screen is displayed, pressing Enter on the keyboard also displays the Welcome screen. In a domain, the name of the last user to log on is displayed by default. You can log on with this account by entering the required password. You can log on as another user as well. On the Welcome screen, note the button to the left of the user picture. This is the Switch User button. Tap or click Switch User, select one of the alternative accounts listed, and then provide the password for that account, or tap or click Other User to enter the user name and password for the account to use.

On the Welcome screen for computers that are part of a homegroup or workgroup, a list of accounts on the computer is displayed. To log on with one of these accounts, tap or click the account and enter a password, if required. Contrary to what many people think, the Welcome screen doesn’t display all the accounts that have been created on the computer. Some accounts, such as Administrator, are hidden from view automatically.

The Welcome screen is convenient, but it also makes it easier for someone to try to gain access to the computer. Whether in a homegroup, workgroup, or domain, you can hide the accounts and require users to enter a logon name. Hiding the user name of the last user to log on can improve security by requiring users to know a valid account name for the computer. In Group Policy, you can hide the user name by enabling Interactive Logon: Do Not Display Last User Name. This Computer Configuration option is under Windows SettingsSecurity SettingsLocal PoliciesSecurity Options.

By default, domain users can’t use PIN passwords but can use picture passwords. These Administrative Templates policies for Computer Configuration under the SystemLogon path allow you to modify this behavior: Turn On PIN Sign In and Turn Off Picture Password Sign-In.

In a domain environment, you can use Active Directory–based Group Policy to apply your desired security configuration to a particular set of computers. You can also configure this setting on a per-computer basis by using local security policy. To configure local policy for a homegroup or workgroup computer, follow these steps:

Domain administrators are automatically granted access to local resources on workstations. Other users aren’t granted access to local resources on workstations other than to the computers to which they are permitted to log on. As workstations are moved around an organization, you might find that previous owners of a workstation still have access to its resources or that users who were granted temporary access to a workstation were never removed from the access list.

In a domain, you can control the workstations to which users can log on by using the account properties in Active Directory Users And Computers. Double-tap or double-click the account to display the Properties dialog box. On the Account tab, tap or click Log On To.

You can remove a user’s local account and effectively deny logon by completing these steps:

The contents of the user’s local profile, including the user’s desktop and documents folders, are not removed along with the account. Anyone with administrator access to the local computer can access the user’s profile folder in File Explorer. Profile folders are stored under %SystemRoot%Users. Keep in mind that in a domain, unless further restrictions are in place with regard to logging on to a workstation, a user might still be able to gain access to the workstation by logging on with a domain account.

When a website, app, or another computer requests authentication through NTLM or the Kerberos protocol, you are prompted to save the credentials. This prompt has Save Password or Update Default Credentials options. If you choose the Save Password option, your credentials are saved and the next time you access the same website, app, or computer, Credential Manager can automatically provide the stored credentials. If you choose to update existing credentials, Credential Manager overwrites the previous credential with the new one and then stores the new credentials for future use.

Credential Manager supports four types of stored credentials:

When you connect a local or domain account to a Microsoft account, credentials can be stored in SkyDrive to allow the same credentials to be used from any computer or device you use to access resources. Roaming with credentials in this way is enabled by default for non-domain–joined computers. However, credential roaming is blocked on domain-joined computers to prevent credentials that are stored on domain-joined computers from leaving the enterprise.

In domains, credentials in Microsoft accounts will not roam if you are using Credential Roaming. Additionally, because roaming user profiles use Credential Manager, there might be credentials conflicts between the credentials stored to support roaming and those credentials stored for general credential management. Because of this, Microsoft recommends that you use either stored credentials or roaming user profiles in domains, but not both.

In Group Policy, you can prevent Windows from storing credentials for domain authentication on a computer and in this way ensure that credentials used for roaming user profiles are not saved in Credential Manager. To do this, enable the Network Access: Do Not Allow Storage Of Passwords And Credentials For Network Authentication option, which is under Windows SettingsSecurity SettingsLocal PoliciesSecurity Options.

Each user account has unique credentials. Individual credential entries are stored in the user’s profile settings and contain information needed to log on to protected resources. If you are logged on to a domain account when you create a credential, and the account has a roaming profile (instead of a local or mandatory profile), the information stored in the credential is available when you log on to any computer in the domain. Otherwise, the information in the credential is available only on the computer on which you create the entry.

To add an entry to the currently logged-on user’s credentials, follow these steps:

The Personal certificate store in the user’s profile stores certificates that have been issued to authenticate the user. After you’ve added a certificate for the user, you can create a credential that uses the certificate to access a resource.

To add an entry for a certificate-based credential to the currently logged-on user’s stored credentials, follow these steps:

You can edit credential entries at any time, but keep in mind that local entries are visible only on the computer on which they were created. This means that if you want to modify an entry, you must log on to the local workstation where the entry was created. The only exception is for users with roaming profiles. When a user has a roaming profile, credential entries can be edited from any computer to which the user is logged on.

Use the following steps to edit a user’s credentials entries:

You can back up a user’s stored credentials separately from his computer data. After you back up credentials, you can restore the credentials or transfer them to a new computer simply by restoring the backup. In most cases, you should back up the credentials to removable media.

To back up a user’s credentials, follow these steps:

To restore a user’s credentials on the same or a different computer, follow these steps:

When a user no longer needs a credential entry, you should remove it. To remove a user’s credential entry, follow these steps:

As stated previously, local credential entries can be removed only on the computer on which they were created. When a user has a roaming profile, however, credential entries can be deleted from any computer to which the user is logged on.

You can access Local Users And Groups and create a user account by completing the following steps:

You can access Group Policy and use a preference item to create a user account by completing the following steps:

You create local groups with Local Users And Groups or with Group Policy. You can access Local Users And Groups and create a local group by completing the following steps:

You can access Group Policy and use a preference item to create a local group by completing the following steps:

You can use Local Users And Groups to add or remove local group members by completing the following steps:

You can access Group Policy and use a preference item to add or remove members from a local group by completing the following steps:

Local user accounts can become disabled for several reasons. If a user forgets a password and tries to guess it, he might exceed the account policy for bad logon attempts. Another administrator could have disabled the account while a user was on vacation. When an account is disabled or locked out, you can enable it by using the methods described here.

When an account is disabled, you can enable it on a local computer by completing the following steps:

When an account is locked out, you can enable it on a local computer by completing the following steps:

You can enable or disable accounts and set other account options through policy preferences by completing the following steps:

In some environments, you might need to set up a Guest account that can be used by visitors. Most of the time, you’ll want to configure the Guest account on a specific computer or computers and carefully control how the account can be used. To create a secure Guest account, I recommend that you perform the following tasks:

When you rename an account, you give it a new label. Because the SID for the account remains the same, the permissions and properties associated with the account don’t change. To rename an account while you are accessing a local computer, complete the following steps:

To rename an account using Group Policy, complete the following steps:

Deleting an account permanently removes it. After you delete an account, if you create another account with the same name, you can’t automatically get the same permissions because the SID for the new account won’t match the SID for the account you deleted.

Because deleting built-in accounts can have far-reaching effects on the workstation, Windows 8.1 doesn’t let you delete built-in user accounts or group accounts. In Local Users And Groups, you can remove other types of accounts by selecting them and pressing the Delete key or by pressing and holding or right-clicking and then tapping or clicking Delete. When prompted, tap or click Yes.

To delete an account by using Group Policy, complete the following steps: