Windows has supported the execution of applications or services using alternate credentials for many versions. With the introduction of UAC, the ability to elevate tasks to run as another user or as the local administrator is required when the currently signed-in user does not have the authority to perform a task.
For example, if Bob is signed in to a computer and wants to install his favorite music application, Windows will produce a prompt asking Bob for credentials with authorization to install this application. Previously, the installation would have been either denied or allowed when attempted. Bob would have needed to initiate the use of other credentials by selecting Run As from the context menu of the music application.
When selected, the task chosen to be run as administrator will be elevated to do that. This operation will prompt as needed so that a standard user account might need to provide alternate credentials. When an administrator signs in, the prompt disappears, and a dialog box in a darkened screen appears, asking whether you are sure you want to allow this level of execution. The elevated dialog box with no credential request is shown in Figure 4.
Figure 4. UAC also prompts for actions run by administrators
UAC is the result of feedback from customers at all levels. Considering how UAC operates, the prompt to confirm decisions or to provide administrative credentials to perform actions that could potentially damage the computer are steps in the right direction. These improvements, along with a certification program for applications, allow more applications to run without default administrative privilege for the primary user, which significantly decreases the odds of accidental malware installation.
To ensure the best security for your organization, you should make a concerted effort to leave UAC enabled at some level unless high-priority applications used in your organization cannot run with the feature enabled. It is likely that, as these applications are upgraded and new releases become available, the application’s creator will begin to work UAC into the design. Because UAC is designed to help applications operate within the boundaries of the user account running them, Windows will become a more secure environment.
In addition to using user names and passwords, smart cards, and other types of authentication or authorization methods to access resources, you can use digital certificates to ensure that the requesting party is who he claims to be. There are many types of digital certificates, some for authorization of resources (examined in detail here) and others, such as SSL or Unified Communications certificates, which verify the identity of websites to users who access them or ensure that your email client can verify the identity of the Microsoft Exchange server at your company.
Certificates use public keys to bind digital signatures to identities. Certificates are issued for identities by CAs. These servers, either within an organization or publicly available on the Internet, are trusted entities on which organizations rely to ensure the validity of the items bound to the certificates. CAs inside an organization only need to be trusted by known accounts and employees within the organization, in the case of identity certificates. Public CAs work differently, by maintaining a trusted and visible presence and charging a fee to secure identities (and other content).
When a certificate request is passed to a CA, information about the identity to which the certificate will be assigned must be provided. In many cases, this will include the following:
Distinguished Name (DN)
Business/Organization Name
Department/Organizational Unit
City/Town
Province/Region/County/State
Country/Region
Email address
From the information collected during the request-generation process, a hash, or summary value of the collected information, is created to be submitted to the CA. The CA will use this signature to create the certificate that is bound to the identity provided.
After the certificate has been created, it can be installed on a smart card or loaded into a certificate store on a computer and used to access resources by using the certified identity. Using a certificate provides proof that this identity is valid because of the signature used to create it. Whenever the digital signature is incorrect, the identity cannot be trusted because it does not match the certificate.
Windows has a special location called the certificate store for keeping and managing certificates. The certificate store is a folder containing all the certificates for a user and is managed by Certificate Manager (Certmgr). The folders displayed by Certmgr are a collection of known locations where different types of certificates are installed and managed for use by a computer. Figure 5 shows the certificate store in Windows 8 for the currently signed-in user account.
Figure 5. Certificate Manager displaying the certificate store for the current user
There are many certificate stores within Certificate Manager, including the following:
Personal Certificates with private keys known to the user
Trusted Root Certification Authorities CAs that are implicitly trusted by the user account, including all certificates in the third-party root certificates store and Microsoft
Enterprise Trust Certificate trust lists that allow self-signed certificates to be trusted
Intermediate Certification Authorities Certificates issued to subordinate (non-root) CAs
Active Directory User Object Certificates assigned to the current user’s Active Directory user object and published in the directory
Trusted Publishers Certificates generated by CAs that are allowed by software restriction policies
Untrusted Certificates Certificates whose CA could not be verified or is explicitly not trusted
Third-Party Root Certification Authorities Certificates from root CAs other than those within your organization or at Microsoft
Trusted People Certificates issued to people or other entities with explicit trust
Client Authentication Issuers Certificates used by applications to authenticate to servers
Smart Card Trusted Roots Certificates obtained by root CAs for use with smart cards
Certificates can also be assigned at the computer level to allow one computer to verify another or to authenticate with a server. All certificates are managed using the Microsoft Management console; the set of stores made available to the snap-in depends on the choices made when adding the certificate snap-in. Options include the following:
My User Account Manages certificates for the signed-in (or current) user (as described previously)
Service Account Manages the certificate store for certificates assigned to service accounts
Computer Account Manages the certificate store for any certificates assigned to the computer itself
To be used, certificates obtained from a CA must be imported into a certificate store so they can be managed by the system. The purpose of the store is to organize certificates on a computer and make them easier to manage.
