HackNotes Windows Security Portable Reference phần 5 pot

LAN Manager’s Longevity Upon finding LAN Manager authentication

enabled on a new Windows XP installation, a colleague of the author

was heard to remark, “ACK! Why are you still here?!?” A sentiment ech￾oed no doubt through much of the security community. Microsoft’s

continued support for LAN Manager authentication, finally ending

with the dawn of Windows 2003, has no doubt been the subject of many

heated debates in Redmond. However, when you look at the issue from

a product support perspective, there’s some logic to it.

Windows 95 and 98 were very well accepted by the business com￾munity. The new interface was deemed more intuitive, and the new ap￾plications ran faster and more elegantly than under the Windows 3.1

interface. Everyone upgraded, and Windows 9x, with LAN Manager

authentication only, became the new business platform very quickly.

However, the transition to the pure Windows NT workstation plat￾forms of NT 4.0, Windows 2000 Professional, and Windows XP were not

so complete. Many organizations had applications that didn’t require

NT technologies, and were slow to upgrade those clients. This meant

that a substantial portion of Microsoft’s user-base still required LAN

Manager support. While there were substantial security risks from run￾ning allowing the protocol, the default offering stood.

68 Part I: Hacking Fundamentals

HackNote / HackNotes Windows Security Portable Reference / O’Dea / 222785-0 / Chapter 5

Figure 5-2. Changing the LAN Manager Authentication Level in Windows XP and 2003.

Under Windows 2000, the setting lacks the Network security: prefix.

P:\010Comp\HackNote\785-0\ch05.vp

Friday, June 13, 2003 8:14:43 AM

Color profile: Generic CMYK printer profile

Composite Default screen

Microsoft has been very good, however, in working to remove that

requirement for organizations that deem the security risk unacceptable,

providing the Directory Services client (DSClient.exe on the Windows

2000 Server CD under \CLIENTS\WIN9X) to add support for the

NTLM and NTLMv2 authentication levels to Windows 9x/ME clients.

After installation of the client, the system can be configured to one of the

five LAN Manager compatibility levels like those shown in Figure 5-2.

More details on this process are available in Microsoft KB article

Q239869.

Windows Security Providers

So far, we have discussed the fundamentals of Windows users and

groups and the authentication processes that permit or deny access for

local or network logons. However, we have not yet covered the operat￾ing system facilities that manage authentication and access control.

These responsibilities are handled by two primary security providers, a

user mode component (the Local Security Authority ) and a kernel

mode component (the Security Reference Monitor). In this section, we’ll

discuss both of these components a little further.

The Local Security Authority (LSA)

As we mentioned earlier in the chapter, the LSA is responsible for ar￾ranging user authentication, either by communicating with a domain

controller or against the local SAM, for both local and network logons.

The LSA first determines whether authentication should take place lo￾cally or if the credentials supplied need to be validated against a domain

controller. If the authentication is local to the system, the LSA compares

the credentials to the SAM database; otherwise the LSA passes the au￾thentication request to a domain controller to validate the credentials.

When the authentication is successful, the Local Security Authority

generates a list of security identifiers (SIDs) associated with the user cre￾dentials supplied and combines these identifiers into the user’s security

token. After the token has been issued, most access control decisions take

place directly between the user process and the Security Reference

Monitor, as discussed in the following section. In addition to its authen￾tication tasks, the LSA is responsible for writing security events gener￾ated by the SRM to the event log.

The Security Reference Monitor (SRM)

The ultimate gatekeeper of the Windows security architecture, the Secu￾rity Reference Monitor is responsible for verifying that the process re￾questing a given resource is authorized to do so. When a user process

Chapter 5: Fundamentals of Windows Security 69

HackNote / HackNotes Windows Security Portable Reference / O’Dea / 222785-0 / Chapter 5 Components of the Windows Security Model

P:\010Comp\HackNote\785-0\ch05.vp

Friday, June 13, 2003 8:14:44 AM

Color profile: Generic CMYK printer profile

Composite Default screen

wants to access a resource, it requests a handle for the resource from the

operating system. This is where the SRM steps in.

The SRM compares the security token associated with the request￾ing process (usually, the token is that of the user who launched the pro￾cess) to the discretionary access control list (DACL) of the object

requested. The DACL contains a list of all approved SIDs for the re￾source and information on the access level to be granted. If the SRM is

able to locate a matching SID in the resource’s DACL, it will issue a han￾dle to the resource with any security controls pre-applied (for example,

a read-only file handle if the security token matched for Read access

only). After the process receives its handle, it will no longer have to

check with the SRM for access, but if the handle is closed and then re￾opened, the SRM will revalidate the process’ credentials.

The other notable responsibility of the SRM has to do with security

logging. When validating a resource request, the SRM will also check

the requested resource’s system access control list (SACL), which contains

descriptors related to auditing for the resource. If the activity requested

by the process matches a descriptor in the SACL, the SRM contacts the

LSA to write the corresponding event log entry.

Active Directory and Domains

Finally in this chapter, we want to briefly touch on the great extenders of

Windows security, Active Directory and the NT Domain model. When a

system participates in a domain, it hands off authentication responsibil￾ities (the activity of the system’s local SAM) to a domain controller. This

means that a domain user’s SID is the same anywhere in the domain be￾cause the bulk of the user’s SID consists of the domain identifier. When

a system joins the domain, any domain security policies are pushed to

the client, so that the LSA on the system can manage most security que￾ries without having to contact the domain controller.

Domains frequently operate in trust relationships, which allow ad￾ministrators to divide their networks into logical groupings to manage

disparate resources. For example, a technology company may have a

corporate domain, a sales domain, and an R&D domain, each hosting

different resources. The corporate domain hosts common resources,

such as e-mail servers, file and print servers, and the company intranet.

In the Sales and R&D domains, more specific (and potentially sensitive)

resources are present.

70 Part I: Hacking Fundamentals

HackNote / HackNotes Windows Security Portable Reference / O’Dea / 222785-0 / Chapter 5

P:\010Comp\HackNote\785-0\ch05.vp

Friday, June 13, 2003 8:14:44 AM

Color profile: Generic CMYK printer profile

Composite Default screen