Introduccion a la seguridad Windows 7

MODULE 1.
Windows
Logon and
Authentication
Operating System Security
By José Fernández Tamames

Objetives
•Lesson 1. Windows Authentication
Concepts
•Lesson 2. Windows Logon Scenarios
•Lesson 3. Windows Authentication
Architecture
•Lesson 4. Troubleshooting Logon and
Resource Access Issues

Less. 1.
Windows
Authentication
Concepts

Authentication is a process
for verifying the identity
of an object (genuine) or
person (no imposter)

In a networking context,
authentication is the act of
proving identity to a
network application or
resource

any user, service, group, or
computer that can initiate action
is a security principal
Security principals have
accounts, which can be local to a
computer or domain-based

is a means to identify a claimant —the
human user or service —requesting access or
resources

Users, groups of users, objects and
services can all have individual
accounts or share accounts

Accounts can be member of
groups and can be assigned
specific rights and
permissions

Accounts can be restricted to the
local computer, workgroup,
network, or be assigned
membership to a domain

Account/group name Windows Server 2003 Windows Server 2008 Windows Server 2008 R2
Administrator account Available Available Available
Guest account Available Available Available
Administrators group Available Available Available
Backup Operators group Available Available Available
Cryptographic Operators group No No Available
Distributed COM Users group No No Available
Event Log Readers group No No Available
Guests group Available Available Available
HelpServicesGroup group Available Available No
IIS_IUSERS group No No Available
Network Configuration Operators group Available Available Available
Performance Log Users group Available No Available
Performance Monitor Users group Available No Available
Print Operators Available No No
Power Users group Available Available Available
Remote Desktop Users group Available Available Available
Replicator group Available Available Available
Terminal Server Users Available No No
Users group Available Available Available
Offer Remote Assistance Helpers group No Available Available
RS_Query group No Available No

Managed service accounts
Managed service accounts and virtual accounts were
introduced in Windows Server 2008 R2 and Windows 7 to
provide crucial applications, such as Exchange Server and
Internet Information Services (IIS), with the isolation of their
own domain accounts, while eliminating the need for an
administrator to manually administer the service principal
name (SPN) and credentials for these accounts.

is a form of secret authentication
data that is used to control access to a
resource.

In Windows, passwords are
encrypted by whatever the
authentication protocol is chosen and
packaged with other authentication
information

The outcome of the encryption is a hashed password transformed
into ciphertext, a string of numbers and letters that appears
meaningless.
The hashing process occurs by means of a hashing
algorithm.
Windows uses the same algorithm (used by the authentication
protocol) to encrypt and decrypt a user’s password.
This authenticated packet is stored by Windows so that, as with
Interactive Logon, credentials do not require re-
authentication when logging on with a domain account.

Restriction/characteristic Windows Server 2003 Windows Server 2008 Windows Server 2008 R2
Password length Up to 127 characters Up to 127 characters
Up to 127 Unicode
characters
Complex password
requirement
Not by default but system
checked; set by policy
No No
Blank password
permitted
Yes, but warning is issued
Yes, for local accounts
only from the console’s
logon screen
Yes, for local accounts
only from the console’s
logon screen
Supports the extended
ASCII character set
Yes Yes Yes
Spaces allowed Yes Yes Yes

Personal identification
numbers (PIN),
certificates,
and smart cards

A personal identification number (PIN) is a secret shared between a user
and a system that can be used to authenticate the user to the system.
Smart card use for Windows authentication requires a non-confidential user
identifier or token, specifically a certificate issued for a user by a certification
authority (CA) from the organization granting the authentication.
In addition, the user is required to provide a confidential PIN to gain access to the
system.
Upon receiving the certificate and PIN, the system looks up the PIN based upon
the user’s identification encrypted in the certificate and compares the looked-up PIN
with the received PIN.
If they match, the user is granted access.
If they do not match, the user is not granted access.

Authorization and
Windows
authentication
architecture

Security identifiers
SID is a unique value
that identifies a user,
group, or computer
account within an
enterprise

The rights and permissions for a
user, group, or computer account
are determined by access control
lists (ACLs) and contain security
identifiers (SIDs) for a user, group,
or computer.

is re-created every time a
security principal is
authenticated (logs on)

and it contains the following information used for
accessing resources:
•The SID for the user’s account.
•A list of SIDs for security groups that include the user and the
privileges held on the local computer by the user and the user’s
security groups. This list includes SIDs both for domain-based
security groups, if the user is a member of a domain, and for local
security groups.
•The SID of the user or security group that becomes the default
owner of any object that the user creates or takes ownership of.

•The SID for the user’s primary group.
•The default discretionary access control lists (DACLs) that the operating system applies to
objects created by the user if no other access control information is available.
•A list of privileges associated with the user’s account.
•The source, such as the Session Manager or LAN Manager, that caused the access
token to be created.
•A value indicating whether the access token is a primary token, which represents the
security context of a process, or an impersonation token, which is an access token that a thread
within a service process can use to temporarily adopt a different security context, such as the
security context for a client of the service.
•A value that indicates to what extent a service can adopt the security context of a client
represented by this access token.
•Statistics about the access token that are used internally by the operating system.
•An optional list of SIDs added to an access token by a process to restrict use of the token.
•A session ID that indicates whether the token is associated with a Terminal Services
client session. (The session ID also makes fast user switching possible because it contains a list
of privileges.)

Security Groups and Windows Authentication
Implementation of security groups for authentication
purposes is useful in deployment scenarios across
forests.
Security groups are set at the domain level in Active
Directory.
By using security groups, you can assign
the same security permissions to many
users who successfully authenticate,
which simplifies access administration

Delegated
Authentication and
Trust Relationships

Delegated authentication occurs when a
network service accepts a request from a
user and assumes that user’s identity in
order to initiate a new connection to a
second network service.

To enable delegated authentication, you must
establish front-end or first-tier servers, such
as web servers, that are responsible for handling
client requests, and back-end or n-tier
servers, such as large databases, that are
responsible for storing information.

Authentication in
trust relationships

To provide authentication and authorization
capabilities between clients and servers in different
domains, there must be a trust between the two
domains.
Trusts are the underlying technology by which
secured Active Directory communications occur
and are an integral security component of the
Windows Server network architecture

Group Policy Settings Used in
Windows Authentication

You can manage authentication in Windows by adding user,
computer, and service accounts to groups and then applying
authentication policies to those groups. Authentication policies
consist of:
•Account policies, which include password, account
lockout, and Kerberos policies.
•Local policies, which are enforced through local security
settings, include security options, user rights assignment,
and audit policies.

Account policies affect computers running Windows in two ways.
When applied to a local computer, account policies apply to the local
account database that is stored on that computer.
When applied to domain controllers, the account policies affect domain
accounts for users logging on from Windows computers that are joined to
that domain.
Account policy
Account policies contain three subsets:
•Password policy
•Account lockout policy
•Kerberos policy

Password policy
Password policies affect the characteristics and
behavior of passwords.
Password policies are used for domain accounts or
local user accounts.
They determine settings for passwords, such as
enforcement and lifetimes.

Account lockout policy
Account lockout policy options disable accounts
after a set number of failed logon attempts.
Using these options can help you detect and
block attempts to break passwords.

Kerberos policy
Kerberos-related settings include ticket lifetimes and
enforcement rules.
Kerberos policy does not apply to local account
databases because the Kerberos authentication protocol is
not used to authenticate local accounts.
Therefore, the Kerberos policy settings can be configured only
by means of the default domain GPO, where it affects domain
logons.

Local security policy
A security policy is a combination of security settings that
affect the security on a computer.
You can use the local security policy to control the following
local policies:
• Security Options - Who accesses the computer.
• User Rights Assignment - What resources users are
authorized to use on your computer.
• Audit Policy - Whether or not a user’s or group's actions are
recorded in the event log.

User rights assignment
User rights are typically assigned on the basis
of the security groups to which a user belongs,
such as Administrators, Power Users, or Users.
The policy settings in this category are typically used to
allow or deny users’ permission to access their computer
based on the method of access and their security group
memberships.

Auditing policy
Auditing policy allows you to control and understand access
to objects, such as files and folders, and to manage user and
group accounts and user logons and logoffs.
Auditing policies can specify the categories of events that
you want to audit, set the size and behavior of the security
log, and determine which objects you want to monitor
access of and what type of access you want to monitor.

Credentials Management
in Windows
Authentication

Windows credentials management is
the process by which the operating system
receives the credentials from the service or
user and secures that information for
future presentation to the authenticating
target

Windows
Logon
Scenarios
Less. 2

Logon
Validar
al
usuario
• Autenticación
• Autorización
Control
de
recursos

Windows requires that all users must
validate their identities to successfully log
on to the computer.
The process of validating a user’s identity
is called authentication

Logons
User Logon
Application logon
User logon
user mode by using
Secur32.dll
Application logon
processes initiated at start up,
such as services, run in kernel
mode by using Ksecdd.sys.

Combined with supporting hardware, credential
providers can extend Windows to enable users to log on
through biometric (fingerprint, retinal, or voice
recognition), password, PIN and smart card
certificate, or any custom authentication package
and schema that a third-party developer creates
Credential provider architecture

Credential providers are registered on the
computer and are responsible for the following:
•Describing the credential information required for
authentication.
•Handling communication and logic with external
authentication authorities.
•Packaging credentials for interactive and network
logon.

Logon UI
The credential provider enumerates the tiles
for workstation logon.
he credential provider will typically serialize credentials for
authentication to the local security authority.
This displays tiles specific for each user and specific to each
user's target systems.

Unlock Workstation
The logon and authentication architecture allows a user to use
tiles enumerated by the credential provider to unlock a
workstation. Typically, the currently logged on user is the
default tile; however, if more than one user is logged on,
numerous tiles will be displayed.

Change Password
The credential provider enumerates tiles in
response to a user request to change their
password (or other private information, such as
a PIN). Typically, the currently logged on user is
the default tile; however, if more than one user
is logged on, numerous tiles will be displayed.

Applications and user mode
User mode in Windows is composed of two systems capable of passing I/O
requests to the appropriate kernel mode software drivers: the environment
system, which runs applications written for many different types of operating
systems, and the integral system, which operates system-specific functions on
behalf of the environment system.
Applications can run in user mode where it can run as
any principal, including in the security context of Local
System (SYSTEM).
Applications can also run in kernel mode where it would
run in the security context of Local System (SYSTEM).

SSPI is available through the Secur32.dll module, which is
an API used for obtaining integrated security services for
authentication, message integrity, and message privacy.
It provides an abstraction layer between application-level
protocols and security protocols.
Because different applications require different ways of
identifying or authenticating users and different ways of
encrypting data as it travels across a network, SSPI provides a
way to access dynamic-link libraries (DLLs) containing different
authentication and cryptographic functions.
These DLLs are called Security Support Providers (SSPs).

Managed service accounts and
virtual accounts were introduced in Windows
Server 2008 R2 and Windows 7 to provide crucial applications,
such as SQL Server and IIS, with the isolation of their own
domain accounts, while eliminating the need for an
administrator to manually administer the service principal
name (SPN) and credentials for these accounts

Services and kernel mode
Even though most Windows applications run in the
security context of the user who starts them, this is
not true of services.
Many Windows services, such as network and
printing services, are launched by the service
controller when the user starts the computer.
These services might run as Local Service or Local
System and might continue to run after the last
human user logs off.

Before starting a service, the service controller logs on by using the
account designated for the service and presents the service’s credentials
for authentication by the LSA.
(The Windows service implements a programmatic interface that the
service controller manager can use to control the service. A Windows
service can be started automatically when the system is started or
manually with a service control program.)
For example, when a Windows client computer joins a domain, the messenger service on the
computer connects to a domain controller and opens a secure channel to it. To obtain an
authenticated connection, the service must have credentials that the remote computer’s Local
Security Authority (LSA) trusts.
When communicating with other computers in the network, LSA uses the credentials for the
local computer’s domain account, as do all other services running in the security context of the
Local System and Network Service.
Services on the local computer run as SYSTEM so credentials do not need to be presented to
LSA.

The file Ksecdd.sys manages and encrypts these credentials and
uses a local procedure call into the LSA.
The file type is DRV (driver) and is known as the kernel-mode Security
Support Provider (SSP) and, in Windows Server 2008 R2, Windows
Server 2008, Windows 7, and Windows Vista, is FIPS 140-2 Level 1
compliant.
Kernel mode has full access to the hardware and system resources of
the computer.
The kernel mode stops user mode services and applications
from accessing critical areas of the operating system that
they should not have access to.

Interactive Logon (USER
LOGON)

Winlogon.exe is the executable file responsible
for managing secure user interactions.
The Winlogon service initiates the logon
process for Windows operating systems by
passing the credentials collected by user action
on the secure desktop (Logon UI) to the Local
Security Authority (LSA) through Secur32.dll.
Logon UI Winlogon.exe LSA

The interactive logon
process is the first step
in user authentication and
authorization

Interactive logon provides a way
to identify authorized users and
determine whether they are allowed
to log on and access the system

Tipos de Interactive Logon
Local
Dominio

Local Logon
A local logon requires that the user have a user account
in the SAM on the local computer.
The SAM protects and manages user and group
information in the form of security accounts stored in
the local computer registry
(HKEY_LOCAL_MACHINESECURITY).
The computer can have network access, but it is not
required.
Local user account and group membership information
is used to manage access to local resources.

A local logon grants a user access to
Windows resources on the local
computer (or resources on
networked computers).

Logon local
• Usuario
• Grupo
SAM
• Acceso a los recursos
locales
• Almacena en el Registro

A domain logon requires that the user have a user account in the
domain’s Active Directory.
The computer must be joined to the domain and have a network
connection to the domain.
Users must also have rights to log on to a local computer or a domain.
Domain user account and group membership information
is used to manage access to domain and local resources.

Application logon
Application or service logons not requiring interactive logon.
Processes initiated at start up, such as services, run in kernel mode by using
Ksecdd.sys.

Windows authentication
protocols
The authentication protocols are security support providers (SSPs) that are
installed in the form of dynamic-link libraries (DLLs).
()
()

The Windows operating systems
implements a default set of authentication
protocols —Kerberos, NTLM, TLS/SSL,
Digest, and PKU2U —as part of an extensible
architecture

These protocols and packages
enable authentication of
users,
computers,
and services

()
Security support provider
(SSP) A dynamic-link library (DLL) that implements the SSPI by
making one or more security packages available to applications.
Each security package provides mappings between an
application's SSPI function calls and an actual security model's
functions.
Security packages support security protocols such as Kerberos
authentication and the Microsoft LAN Manager

()
SSPI
A common interface between transport-level applications, such
as Microsoft Remote Procedure Call (RPC), and security providers,
such as Windows Distributed Security.
SSPI allows a transport application to call one of several security
providers to obtain an authenticated connection. These calls do
not require extensive knowledge of the security protocol's details.

Conventions that control or enable the
connection, communication, and data
transfer between computers in a
Windows environment by verifying the
identity of the credentials of a user, computer,
or process
authentication protocols()

Microsoft Negotiate is an
SSP that acts as an application layer
between the Security Support
Provider Interface (SSPI) and the
other SSPs
Provides authentication and
encryption

When an application calls into SSPI to log
on to a network, it can specify an SSP
to process the request.
If the application specifies Negotiate, Negotiate
analyzes the request and selects the best SSP to
handle the request based on the configured
security policy.

Negotiate SSP selecciona Kerberos o NTLM.
No lo hace por Kerberos si:
1. Unos de los componentes del proceso no habla con esos protocolos.
2. O no se ha proporcionado un nombre para el destino:¨
1. Un SPN, un nombre principal de destino
2. Un UPN, un nombre principal de Usuario
3. Un nombre NetBios de la maquina
En caso de que no hable por Kerberos pasa a NTLM.
Si es a un servidor al que llama el cliente, primero el cliente pregunta si es
capaz el servidor de hablar en Negotiate SSP.
A partir de Windows 2003 y XP los servidores hablan Negotiate SSP.

Reasons to Use the Negotiate Package
•Allows the system to use the strongest (most secure)
available protocol.
•Ensures forward compatibility for your application.
•Ensures that your application exhibits behavior that is
in accordance with the security policy set by the
customer.

Kerberos
The Kerberos version 5 (v5) authentication protocol provides a mechanism for
authentication —and mutual authentication— between a client and a server, or
between one server and another server.
Beginning with Windows Server 2003, Microsoft implements the Kerberos v5 protocol as an SSP,
which can be accessed through the SSPI.
In addition, Windows Server implements extensions to the protocol that permit initial
authentication by using public key certificates on smart cards.
Active Directory Domain Services (AD DS) is required for default NTLM and Kerberos
implementations.

NTLM
The NTLM version 2 (NTLMv2) authentication protocol is a
challenge/response authentication protocol.
NTLM is used when exchanging communications with a computer running
Windows NT Server 4.0 or earlier. Networks with this configuration are
referred to as mixed-mode.
NTLM is also the authentication protocol for computers that are not
participating in a domain, such as stand-alone servers and
workgroups.

NegoExts (NegoExts.dll)
is an authentication package that negotiates the
use of SSPs for applications and scenarios
implemented by Microsoft and other software
companies

The Windows Negotiate package treats the NegoExts SSP in the same
manner as it does for Kerberos and NTLM.
NegoExts.dll is loaded into the Local System Authority (LSA) at startup.
When an authentication request is received, based on the request's
source, NegoExts negotiates between the supported SSPs.
It gathers the credentials and policies, encrypts them, and sends that
information to the appropriate SSP, where the security token is then
created.
The SSPs supported by NegoExts are not stand-alone SSPs such as
Kerberos and NTLM.
Therefore, within the NegoExts SSP, when the authentication method
fails for any reason, an authentication failure message will be displayed or
logged.
No renegotiation or fallback authentication methods are possible.

The PKU2U protocol in Windows 7 and Windows
Server 2008 R2 is implemented as an SSP.
The SSP enables peer-to-peer authentication,
particularly through the Windows 7 media and file
sharing feature called Homegroup, which permits
sharing between computers that are not members
of a domain

Credential Security Support
Provider (CredSSP)

Provides a single sign-on (SSO) user
experience when starting new Terminal Services
sessions.
CredSSP enables applications to delegate users'
credentials from the client computer (by using the
client-side SSP) to the target server (through the
server-side SSP) based on client policies

The TLS/SSL protocols are used to authenticate servers
and clients, and to encrypt messages between the
authenticated parties.
The TLS/SSL protocols, versions 2.0 and 3.0, and the Private
Communications Transport (PCT) protocol are based on public
key cryptography.
The secure channel (Schannel) authentication protocol suite
provides these protocols.
All Schannel protocols use a client/server model and are
primarily used for Internet applications that require secure
Hypertext Transfer Protocol (HTTP) communications.

The Digest authentication protocol is a
challenge/response protocol that is designed
for use with HTTP and Simple
Authentication Security Layer (SASL)
exchanges.
These exchanges require that parties requesting
authentication must provide secret keys.

Less. 3
Windows
Authentication
Architecture

(A) Security subsystem
architecture
(B) Security Support
Provider Interface
(SSPI)

(A) Security subsystem
architecture

the logon screen to Winlogon.exe
which interacts with LSA
to the local or remote
computer
Security subsystem architecture
Standard logon or custom logon

Winlogon.exe, which interacts with
LSA to communicate with a
remote authentication
source, such as a domain controller,
and the protocol layer within the
LSA architecture.

(B) Security Support Provider
Interface (SSPI)

Abstract calls to
authentication
protocols
If the preferred protocol is not in this version
of Windows, developers can use a
custom Security Support Provider if it
meets interoperability requirements.

(A) Local Security Authority (LSA)
is a (A.1) protected subsystem that authenticates and logs users on
to the local computer
In addition
(A.2) LSA maintains information about all aspects of local
security on a computer (these aspects are collectively known as
the local security policy).
(A.3) provides various services for translation between names
and security identifiers (SIDs).

(A3) The local security policy identifies the
following:
• Who can have access to the system and in what
way (for example, interactively, over the
network, or as a service).
• Who is assigned what rights.
• What security auditing is performed.
• What the default memory quotas are for paged
and non-paged memory pool usage.

LSA
Provider
validating access
to objects
checking user
rights
generating audit
Messages
Procedure calls
local procedure
call (LPC)
occurs between
components on
the same system
A remote
procedure call
(RPC)
occur between
components on
different systems
between
components on
the same system

LSA (local)
In general, the LSA performs the following functions:
• Manages local security policy.
• Provides interactive user authentication services.
• Generates access tokens.
• Manages the audit policy and settings

The components on the domain
controller

LSA components for all systems

Lsasrv.dll
The LSA Server service, which
both enforces security policies
and acts as
the security package manager for
the LSA.

Credssp.dll
The default dynamic-link library (DLL) module that operates in the security
context of Winlogon.
Wdigest.dll
Simple challenge-and-response protocol that provides increased security over
.
Extended Protection for Authentication is enabled using the channel binding
token.
Schannel.dll
The Secure Sockets Layer (SSL) and Transport Layer Security (TLS)
authentication protocol.
This protocol provides authentication over an encrypted channel instead of
a less-secure clear channel.

Kerberos.dll
The Kerberos V5 authentication protocol. This protocol provides authentication using Kerberos protocol
instead of plaintext, NTLM, or digest method.
Extended Protection for Authentication is enabled using the channel binding token.
Pku2u.dll
The SSP enables peer-to-peer authentication, particularly through the Windows 7 media and file sharing
feature called Homegroup, which permits sharing between computers that are not members of a domain.
Negoexts.dll
An authentication package that negotiates the use of SSPs for applications and scenarios implemented by Microsoft
and other software companies.

Secur32.dll
The authentication provider that exposes the SSP interfaces to
applications

Components on the domain
controller

Kdcsvc.dll
The Kerberos Key Distribution Center (KDC) service, which is responsible for
the Kerberos authentication service and the ticket granting service.
Ntdsa.dll
The directory service module, which supports the Windows replication
protocol and LDAP, and manages partitions of data
Ntdsapi.dll
A directory service module which can communicate over RPC through a set of
COM interfaces used for accessing directory services to manage network
resources.

Cached credentials and validation
Validation mechanisms rely on the presentation of credentials at the time of logon.
However, when the computer is disconnected from a domain controller, and
the user is presenting domain credentials, then Windows uses the process of cached
credentials in the validation mechanism.
Each time a user logs on to a domain, Windows caches the credentials supplied and stores
them in the security hive of the operation system. The cached credentials is a function of
the NT hash in that the hashed credentials are salted by using the user name and hashed
again.
With cached credentials, the user can log on to a domain member without being
connected to a domain controller within that domain.

Credential storage and
validation

Credential storage and validation
It is not always desirable to use one set of credentials for
access to different resources.
For example, an administrator might want to use
administrative rather than user credentials when accessing
a remote server.
Similarly, if a user will be accessing external resources, such
as a bank account, he or she can only use credentials that
are different than their domain credentials

Windows Vault and Credential Manager
in Windows 7
In Windows Server 2008 R2 and Windows 7, the storage and
management of user names and passwords were integrated into
Credential Manager —a Control Panel feature.
Credential Manager allows users to store credentials to other
systems and websites in the secure Windows Vault. Some versions
of Internet Explorer use this feature for authentication to websites.

Credential management by using Credential Manager is controlled by
the user on the local computer.
Users can save and store credentials from supported browsers and
Windows applications to make it convenient when they need to sign
in to these resources.
Credentials are saved in special encrypted folders on the computer
under the user’s profile.
Applications that support this feature (through the use of the
Credential Manager APIs), such as web browsers and apps, can
present the correct credentials to other computers and websites
during the log on process.

When a website, an application, or another computer
requests authentication through NTLM or the Kerberos
protocol, an Update Default Credentials or Save Password
check box is presented to the user.
This dialog to request the saving of credentials locally is
generated by an application that supports the Credential
Manager APIs.
If the user selects the Save Password check box, Credential
Manager keeps track of the user's name, password, and
related information for the authentication service that is in
use.

The next time the service is used, Credential
Manager automatically supplies the credential
that is stored in the Windows Vault.
If it is not accepted, the user is prompted for the
correct access information.
If access is granted with the new credentials,
Credential Manager overwrites the previous
credential with the new one and then stores the
new credential in the Windows Vault.

Less. 4
Troubleshooting
Logon and
Resource Access
Issues

The logon process authenticates both computer and
user accounts. Domain controllers perform the
authentication:
(1) During the startup process for computer
accounts.
(2) When the user logs on for user accounts.

Windows 7 caches the credentials of the last 10 user accounts
to log onto a specific computer,
and you can modify this number either by editing the registry
(HKEY_LOCAL_MACHINESOFTWARE
MicrosoftWindows
NTCurrentVersionWinlogoncachedlogonscount)

by using Group Policy
(Computer ConfigurationPoliciesWindows
SettingsSecurity SettingsLocal
PoliciesSecurity
OptionsInteractive Logon: Number of
previous logons to cache).

(a) maximum of 50
(b) credentials to zero
Win7 must contact a domain
controller before users can obtain
access to the local computer

On-screen errors. Most user logon
errors provide an accurate description on
the screen.

Active Directory Users and
Computers. You can use this tool to verify the
user’s logon name and if the
account is disabled. You also can use this tool to
unlock the account and reset the password, if
necessary.

Event logs.
You can use Event Viewer to view event logs that may give
some indication why a logon error is occurring. The
Security logs on a computer or on a domain controller that
indicates if authentication errors are occurring.
The System log of a computer indicates if the computer
account is not authenticating correctly.

During the BIOS Initialization phase, the
platform firmware identifies and
initializes hardware devices, and then
runs a power-on self-test (POST)

The POST process ends when the BIOS
detects a valid system disk, reads the
master boot record (MBR), and starts
Bootmgr.exe.
Bootmgr.exe finds and starts Winload.exe
on the Windows boot partition, which begins
the OSLoader phase

BIOS version and firmware of all hardware components
to the latest versions.
In addition check the BIOS configuration (device boot
order, PXE boot-enabled, Quick/Fast boot (POST check)
enabled, AHCI settings, and so on).
optimize or troubleshoot

Windows Performance Toolkit
(included in the Windows 7.1 SDK )
optimize or troubleshoot
The Windows® Performance Toolkit consists of two independent tools:
Windows® Performance Recorder (WPR) and Windows® Performance
Analyzer (WPA).
In addition, support is maintained for the previous command-line tool, Xperf. However, Xperfview
is no longer supported. All recordings must be opened and analyzed by using WPA.

Controllers
Controllers are applications that define the size and location of the log file,
start and stop event tracing sessions, enable providers so they can log events
to the session, manage the size of the buffer pool, and obtain execution
statistics for sessions.
Session statistics include the number of buffers used, the number of buffers
delivered, and the number of events and buffers lost. For more information, see
Controlling Event Tracing Sessions.

Providers
Providers are applications that contain event tracing instrumentation.
After a provider registers itself, a controller can then enable or disable event tracing
in the provider.
The provider defines its interpretation of being enabled or disabled. Generally, an
enabled provider generates events, while a disabled provider does not. This lets
you add event tracing to your application without requiring that it generate events
all the time.

Consumers
Consumers are applications that select one or more event tracing sessions as
a source of events.
A consumer can request events from multiple event tracing sessions
simultaneously; the system delivers the events in chronological order.
Consumers can receive events stored in log files, or from sessions that
deliver events in real time. When processing events, a consumer can specify
start and end times, and only events that occur in the specified time frame
will be delivered.
Missing Events
Perfmon, System Diagnostics, and other system tools may
report on missing events in the Event Log and indicate that the
settings for Event Tracing for Windows (ETW) may not be
optimal.

During the OS Initialization phase, most of the
operating system work occurs.
This phase involves kernel initialization, Plug and
Play activity, service start, logon, and Explorer
(desktop) initialization.

Sub phase 1 - PreSMSS: Kernel Initialization
The PreSMSS subphase begins when the kernel is invoked. During this subphase, the kernel initializes data structures
and components. It also starts the PnP manager, which initializes the BOOT_START drivers that were loaded during
the OSLoader phase.
Sub phase 2 - SMSSInit : Session Initialization
The SMSSInit subphase begins when the kernel passes control to the session manager process (Smss.exe). During
this subphase, the system initializes the registry, loads and starts the devices and drivers that are not marked
BOOT_START, and starts the subsystem processes. SMSSInit ends when control is passed to Winlogon.exe. [1]
Sub phase 3 - WinLogonInit: Winlogon Initialization
The WinLogonInit subphase begins when SMSSInit completes and starts Winlogon.exe. During WinLogonInit, the
user logon screen appears, the service control manager starts services, and Group Policy scripts run.
WinLogonInit ends when the Explorer process starts. [1]
Sub phase 4 – ExplorerInit: Explorer Initialization
The ExplorerInit subphase begins when Explorer.exe starts. During ExplorerInit, the system creates the desktop
window manager (DWM) process, which initializes the desktop and displays it for the first time.

Group Policy processing
took around 160 seconds
to complete

The PostBoot phase includes
all background activity that
occurs after the desktop is
ready
The user can interact with the desktop, but the system might
still be starting services, tray icons, and application code in the
background, potentially having an impact on how the user
perceives system responsiveness

The ReadyBootPrefetcher
The Windows prefetcher (or ReadyBoot) helps to read data into
memory before Windows needs it. In addition each reboot will
allow the prefetcher to better predict what data is needed
During the Windows boot process a lot of data is read from disk
and I/O pressure is one of the determining factors for boot
performance
One way to analyze the prefetcher activities is to run
xperf.exe from the Windows Performance Toolkit
Xperf –i <boottrace.etl> - o prefetcher.txt –a bootprefetch – summary

(1) Windows Hardware Dev Center Archive
(2) Performance Analysis Whitepapers
On/Off Transition Trace Capture tool
CPU Power Management
Exploring Process Heaps Using Windows Performance Analyzer
(3) Root Causes for Slow Boots and Logons (sbsl)
(4) Tools for Troubleshooting Slow Boots and Slow Logons (sbsl)

Installing XPERF to capture a slow boot or logon trace
1.Install XPERF from the Windows SDK for Windows 7 and .NET Framework on the slow
boot or logon computer.
Hint 1: It is possible to install only the Windows Performance Toolkit from the
Windows SDK.
Hint 2: We suggest installing the WPT in an X:XPERF directory rather than the
default directory recommended by setup. It's easier to access and copy files in and
out of, and change paths, to the short-labeled directory.
Hint 3: Once installed on a computer, the XPERF installation directory can be copied
to other computers that you want to capture ETL traces from or view ETL traces on.
There are no external files, DLL registration or registry changes required to make or
view a capture. Make a copy of the X:XPERF directory and copy at will.
2.If taking a network trace on a 64-bit computer, enable the following registry key and
reboot before capturing ETL data. This prevents kernel mode data from being paged out
of memory.

Registry Path HKLMSystemCurrentControlSetControlSession
ManagerMemory Management
Setting DisablePagingExecutive
Data Type: REG_DWORD
Value: 1

Using XBOOTMGR to capture slow boots, or slow logons caused by slow boots
1.Logon as an Administrator of the computer you want to trace (either a local
Administrator or Domain Admin account that is a member of the local machine's
Administrators group).
2.Open an elevated command prompt.
3.Run the following command in the WPT directory (default path is C:Program
FilesMicrosoft Windows Performance Toolkit). This syntax is useful to capture slow boots
as well as slow logons thought to be caused by a delay in OS startup:
xbootmgr -trace boot -traceflags base+latency+dispatcher -stackwalk
profile+cswitch+readythread -notraceflagsinfilename -postbootdelay 10
This command will:
•Reboot the local computer
•Capture ETL tracing during the boot and logon operation (you provide user name, domain
name, and password for the slow logon account)
•Stop tracing at 10 seconds after disk and CPU utilization fall below a certain threshold after
user logon. Increase the value for "-postbootdelay" as required to troubleshoot user
desktops that are unresponsive to mouse and keyboard input post boot.

Using XPERF to capture slow logons
1.Logon as an Administrator of the computer you want to trace (either a local Administrator or Domain Admin
account that is a member of the local machine's Administrators group).
2.Open an elevated command prompt and run this command from WPT Install directory (default path is C:Program
FilesMicrosoft Windows Performance Toolkit.
xperf -on base+latency+dispatcher+NetworkTrace+Registry+FileIO -stackWalk
CSwitch+ReadyThread+ThreadCreate+Profile -BufferSize 128 -start UserTrace -on "Microsoft-Windows-Shell-
Core+Microsoft-Windows-Wininit+Microsoft-Windows-Folder Redirection+Microsoft-Windows-User Profiles
Service+Microsoft-Windows-GroupPolicy+Microsoft-Windows-Winlogon+Microsoft-Windows-Security-
Kerberos+Microsoft-Windows-User Profiles General+e5ba83f6-07d0-46b1-8bc7-7e669a1d31dc+63b530f8-29c9-
4880-a5b4-b8179096e7b8+2f07e2ee-15db-40f1-90ef-9d7ba282188a" -BufferSize 1024 -MinBuffers 64 -MaxBuffers
128 -MaxFile 1024
Note: This syntax works on Windows Vista (Windows Server 2008) and Windows 7 (Windows Server 2008 R2)
computers
3.Press CTRL+ALT+DEL and then Switch User.
4.Logon with the user account experiencing the slow user logon to reproduce the issue.
5.Stop the trace. While logged on with the slow user account, open an elevated CMD prompt and type:
xperf -stop -stop UserTrace -d merged.etl
Close the slow logon user session and the admin logon session opened in step 2 as required.

Core Security includes system security
functionality, such as authentication,
authorization, and access control
features, built into the Windows operating
system

Windows Logon
Windows License Verification
Event ID 4102
Event ID 4103
Windows Logon Availability
(I) Event ID 1002: Windows logon process is able to be completed successfully
(I) Event ID 4002: Windows logon process is able to be completed successfully
(E) Event ID 4003: EVENT_DESKTOP_SWITCH_FAILURE
(E) Event ID 4005: EVENT_WINLOGON_FATAL_FAILURE
(W) Event ID 4006: EVENT_CREATE_PROCESS_FAILURE
(I) Event ID 4101: EVENT_LICENSE_VALIDATED
(W) Event ID 6000: EVENT_SUBSCRIBER_UNAVAILABLE
(E) Event ID 6001: EVENT_SUBSCRIBER_FAILURE
(E) Event ID 6002: EVENT_REG_DB_FAILURE
(E) Event ID 6003: EVENT_SUBSCRIBER_UNAVAILABLE_FATAL
(E) Event ID 6004: EVENT_SUBSCRIBER_FAILURE_FATAL
Windows Logon Switching
(E) Event ID 4004: EVENT_SHUTDOWN_WINDOWS_FAILURE
(W) Event ID 4007: EVENT_DISCONNECT_FAILURE

Windows Initialization
Windows Shutdown
(W) Event ID 3003: EVENT_REMOTE_SHUTDOWN_INIT_FAILED
(E) Event ID 3005: EVENT_SHUTDOWN_WINDOWS_FAILURE
Windows Startup Availability
(I) Event ID 1000: EVENT_SESSION0_NOTIFICATION_DETECTED
(I) Event ID 1001: EVENT_AUTOCHK_DATA
(E) Event ID 1015: EVENT_.SYSTEM_PROCESS_FAILED
(E) Event ID 3002: EVENT_WININIT_EXIT
(W) Event ID 3004: EVENT_SETUP_LSA_STALL

Consultor y arquitecto de sistemas Office 365, SharePoint, Project Server y CRM
Dynamics CRM, Dynamics AX en los módulos Financials, Project Management y Supply Chain.
Docente en la Escuela de Negocios EAE
MBA por el Instituto de Empresa
MCT de Microsoft
Consultor y docente de ITIL
Consultor y docente de PMI
móvil: 685106684
@ : jftamames@gmail.com
tw : @jftamames
in : es.linkedin.com/in/jftamames
blogs: http://jftamames.wordpress.com/
Publicaciones
Cloud Spain Club | ITIL | Gestión de Proyectos |
SharePoint
Amazón Author
José Fernández Tamames

Introduccion a la seguridad Windows 7

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (18)

Destacado

Destacado (8)

Similar a Introduccion a la seguridad Windows 7

Similar a Introduccion a la seguridad Windows 7 (20)

Más de EAE

Más de EAE (20)

Último

Último (20)

Introduccion a la seguridad Windows 7