Run As
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.
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.
Using and managing certificates
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.
How do certificates work?
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.
Managing certificates in Windows 8
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.
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.
