Windows Server 2003 NAME: Ashraf Fakhouri TITLE: Senior Technology Specialist EMAIL:Ashraff@microsoft.com Microsoft Corporation

New administration features File System Features & Shadow Copy Agenda Trustworthy Computing New administration features File System Features & Shadow Copy Customer Pains and why we are releasing Windows Server 2003 SP1 Goals for Windows Server 2003 SP1 Key enhancements and core functions of SP1 Roadmap – Tied to Security and Windows OS Additional resources to ramp up on Windows Server 2003 SP1 Summary Q&A

Windows Server 2003 Goals Microsoft’s Security Framework Secure by Design Secure by Default Secure in Deployment Communications Secure architecture Security aware features Reduce vulnerabilities in the code KEY MESSAGE: Microsoft has developed a framework to measure its progress towards building the security foundation for Trustworthy Computing. SLIDE BUILDS: 1 SLIDE SCRIPT: [BUILD1] To deliver on the security element of Trustworthy Computing, Microsoft has created a framework to track and measure its progress against the security objectives of Trustworthy Computing. Secure by Design The goal is to eliminate all security vulnerabilities before a product ships. This process begins with software architecture design, the process of specifying the fundamental features and components included in each product; it continues through the coding and testing of individual software modules. Securing a product by design requires: Building a secure architecture, adding security features (such as those listed below), reducing the number of vulnerabilities in new and existing code through aggressive process of code reviews. Secure by Default The key idea is to turn off unused features to reduce the “surface area” available for attack. Services and components that aren’t running can’t effectively be attacked. Furthermore, features that are enabled by default but that aren’t being used in deployment can pose a security risk because they are most likely not being managed and monitored by IT staff. To improve the security by default in Windows Server 2003, we have taken the following steps: 20 Services including IIS are turned off by default. Default settings for ACLs and policies have been strengthened Default share permissions are Read Anonymous is no longer a member of the Everyone group Lower privileged accounts have been created for Web access, including the Network Service and Local Service accounts. Reduce attack surface area Unused features off by default Only require minimum privilege Protect, detect, defend, recover, manage Process: How to’s, architecture guides People: Training Clear security commitment Full member of the security community Microsoft Security Response Center

Administration Features Drag and Drop Drag and drop is now supported Active Directory Users and Computers Active Directory Sites and Services Friendlier UI Works like other administrative tools Drag and drop users into: New containers or OUs Groups <SLIDETITLE> Drag and Drop </SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>You can drag and drop objects like users into containers or into groups using Active Directory tools. </KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> [BUILD 1] Drag and drop is now supported in Active Directory Users and Computers as well as Active Directory Sites and Services. [BUILD 2] The friendly user interface works like other tools such as Windows Explorer, allowing you to drag and drop and select multiple objects. [BUILD 3] Drag and drop allows you to drag users and groups into new groups, containers, or organizational units (OUs). You can also drag and drop servers from one site to another. For many operations you no longer need to open user properties and can accomplish tasks with fewer clicks. </SLIDESCRIPT> <SLIDETRANSITION> Another new feature is saved queries. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM> http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/activedirectory.mspx#newfeatures </ITEM> <ITEM> Help and Support: New features for Active Directory : Active Directory </ITEM> </ADDITIONALINFORMATION>

Administration Features Saved Queries A query saved in the Active Directory Users and Computers Accessed like a folder Only displays a specific set of objects based on the query Example – define queries to display accounts based on: User\Group name or description Account and password status Days since last logon <SLIDETITLE> Saved Queries </SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>Saved Queries help you filter for specific objects and reuse the results any time you need to manage them. </KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> [BUILD 1] Saved Queries help you filter for specific objects and reuse the results any time you need to manage them. The query is saved in Active Directory Users and Computers and can be accessed like any folder. [BUILD 2] By taking advantage of saved queries, you only see the specific set of objects you define in the query. [BUILD 3] For example, you can search for a user or group that starts with the word “Domain”, list accounts with non-expiring passwords, show disabled accounts, show accounts with non-expiring passwords, or view accounts that have not been logged onto in a specified number of days. </SLIDESCRIPT> <SLIDETRANSITION>Now we will look at how you create a Saved Query. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM> http://www.microsoft.com/windowsserver2003/evaluation/overview/technologies/activedirectory.mspx </ITEM> <ITEM>Help and Support: New features for Active Directory : Active Directory </ITEM> </ADDITIONALINFORMATION>

Administration Features Saved Queries Graphic <SLIDETITLE> Saved Queries Graphic </SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE>This is a graphic that shows the Saved Queries tool.</KEYMESSAGE> <SLIDEBUILDS>3</SLIDEBUILDS> <SLIDESCRIPT> This graphic shows the Saved Queries tool. You can see in the background there is already a query defined named Domain Admins Group. This screenshot shows some of the options you have available when defining your query. [BUILD 1] You can start a new query by right-clicking Saved Queries in the console window and selecting New | Query. You can right-click Saved Queries in the console to create a new Saved Query. Then you can specify the query root, which determines the starting point for the search. [BUILD 2] The Find drop-down menu lets you specify users, contacts, and groups; computers; shared folders; and other common queries. You then define further variables such as “Name: starts with:” or “Description: ends with:”. [BUILD 3] You can see at the bottom of this dialog, you can select special query options to look for disabled accounts, accounts with non-expiring passwords, or accounts based on the number of days since last logon. By using Saved Queries, you can perform administrative tasks on the accounts you are most interested in directly from the Saved Queries folder; no more navigating through the domain, organizational unit, and container hierarchy to locate these objects. </SLIDESCRIPT> <SLIDETRANSITION>Now we will look at Active Directory command-line tools. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM> Help and Support: Using saved queries : Active Directory </ITEM> </ADDITIONALINFORMATION>

Active Directory Administration Using Scripts for Repetitive Tasks <SLIDETITLE> Using Scripts for Repetitive Tasks </SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE> You can use scripts like these to automate changes. </KEYMESSAGE> <SLIDEBUILDS>4</SLIDEBUILDS> <SLIDESCRIPT> This is an example of a script that you could create with these tools to automate repetitive administration tasks. You could script these bulk updates instead of making each change manually. [BUILD1] The first two lines of the script add two organizational units—Sales, and Marketing and Finance—to the directory. [BUILD2] The next group of lines add several user accounts, some to the Sales OU, and some to the Marketing and Finance OU. [BUILD3] Next, groups are added. [BUILD4] Finally, some computer accounts are added. </SLIDESCRIPT> <SLIDETRANSITION>Now we will look at these files in a script. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM> http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnanchor/html/scriptinga.asp </ITEM> </ADDITIONALINFORMATION> Also see Microsoft Scripting home page http://msdn.microsoft.com/library/default.asp?url=/library/ en-us/dnanchor/html/scriptinga.asp

demonstration Active Directory Administration Drag-and-drop management Saved queries <SLIDETITLE>Demonstration</SLIDETITLE> <KEYWORDS></KEYWORDS> <KEYMESSAGE> In this demonstration you will see the new Active Directory features such as drag and drop, saved queries, and command-line tools. </KEYMESSAGE> <SLIDEBUILDS>0</SLIDEBUILDS> In this demonstration you will see the new Active Directory features such as drag and drop, saved queries, and command-line tools. <SLIDESCRIPT> </SLIDESCRIPT> <SLIDETRANSITION>Next, we will look at the replication features. </SLIDETRANSITION> <ADDITIONALINFORMATION> <ITEM> </ITEM> </ADDITIONALINFORMATION> [JS: modified slide]

File System Features General Improvements Offline Folders Encrypting File System New Command Line Tools NTFSUtil, Diskpart, Defrag, Mountvol Easier to manage permissions Effective Permissions tab KEY MESSAGE: These are some of the improvements made to File System related features based on customer feedback. SLIDE BUILDS: 5 SLIDE SCRIPT: [BUILD1] Offline Folders can be cached from DFS namespace, and can be encrypted with EFS. [BUILD2] Encrypting File System is improved. Users can now authorize other users to access encrypted files. Encrypted files can be stored in web folders (they are encrypted and decrypted at the client). EFS used a new DESX encryption algorithm (replacing Triple DES). Future algorithms (AES) can be added. [BUILD3] New command line tools are available to allow administrators to automate disk defragmentation, disk partitioning, mount volumes and perform most other disk related tasks. [BUILD4] Easier to manage permissions. Properties of folders and files on NTFS volumes include an effective permissions tab which calculates the effective combined NTFS permissions for users making it easier to resolve permissions issues. SLIDE TRANSITION: Distributed File System is also improved. ADDITIONAL INFORMATION FOR PRESENTER:

File System Features Distributed File System Closest site selection Multiple roots allowed on servers Allows highly-available DFS Configurable replication Control who replicates and when File Replication Service is improved Management and Delegation KEY MESSAGE: DFS supports more granular configuration and management. SLIDE BUILDS: 5 SLIDE SCRIPT: Distributed File System (DFS) unifies distributed physical storage by allowing users to connect to single share that has links to folders on other servers. There are two types of DFS, Standalone, or Domain (Active Directory). DFS centralizes access to files, and makes backup easier. [BUILD1] Closest Site Selection. For Domain DFS roots, DFS clients connect to DFS servers in their site. If there is no DFS server in their site, DFS uses Active Directory Site Link costs to determine the closest site with a DFS server. [BUILD2] Multiple Roots allowed on servers. This is helpful if you wish to couple DFS with clustering to make DFS roots highly available. Previously this could not be done because only one DFS Root was allowed per server. [BUILD3] Configurable Replication. For Domain DFS, DFS replication topologies can be configured that are separate from other File Replication service and Active Directory replication topologies. This is beneficial because the information replicated is often very different. Active Directory replicates small amounts of data all the time, whereas DFS may replicate large amounts of data. You now can control when that replication happens, and between which DFS servers. [BUILD4] File Replication Service is improved. FRS compresses replication traffic and supports replication dampening, (it can figure out when updates have propagated). [BUILD5] Management and Delegation. You can grant administrative control for a specific portion of the DFS namespace, you no longer need to grant rights to the entire namespace. You can create scripts that use WMI calls for DFS management. SLIDE TRANSITION: Another new feature is the Shadow Copy Service. ADDITIONAL INFORMATION FOR PRESENTER:

File System Features Shadow Copy Service Shadow copies Point-in-time copy of data Read-only -- cannot be edited Virtual Shadow Copy Service (VSS) Coordinates shadow copies for NTFS volumes and applications Makes APIs available to applications Example: Open file backup in Windows Server 2003 Enables shadow copies of shared folders Slide Message: Shadow Copies are support by the Shadow Copy Service. Slide Builds: 3 Slide Script: [BUILD 1] Shadow copies are a point-in-time copy of data. The copy is read-only and cannot be edited. Designed to provide enhanced backup and restore capabilities as well as make APIs available to applications. [BUILD 2] Virtual Shadow Copy Service (VSS): Coordinates shadow copies for NTFS volumes and applications. Makes APIs available to applications such as Open file backup in Windows Server 2003. [BUILD 3] Enables shadow copies of shared folders: Enabling Shadow Copies also makes available shadow copies of shared folders which will be discussed in two slides. Slide Transition: You have several configuration options when you enable Shadow Copies. ADDITIONAL INFORMATION FOR PRESENTER:

File System Features Shadow Copy Configuration Enabled per volume Not for individual shares Configuration Select location of shadow copies Recommendation: place on a different volume Set storage limits Default is 10% of volume being copied 100mb minimum If limit is reached, oldest copy is deleted Schedule times when copies are taken Creates a task scheduler task Slide Message: When you enable Shadow Copies you should configure where they will be stored, the storage limit and the backup schedule. Slide Builds: 4 Slide Script: [BUILD 1] Enabled per volume: Shadow copies are enabled on a per-volume basis, not for individual shares. You can use mounted volumes to work around this limitation. [BUILD 2] Configuration: When you enable shadow copies you should configure the following: Select location of shadow copies. This is where the backups will be stored. It’s recommended that the backups be placed on a different volume both for performance and fault tolerance. [BUILD 3] Set storage limits: You should also configure limits for shadow copy backup size based on the amount of disk space available. The default is 10% of volume being copied, with a 100mb minimum. If the limit is reached, oldest copy is deleted. [BUILD 4] Schedule times when copies are taken: You will also configure a schedule of when new shadow copy backups will be made. This creates a new Task Scheduler task. Slide Transition: Once Shadow Copies are enabled, your users can use them to restore and compare files on shares. ADDITIONAL INFORMATION FOR PRESENTER:

File System Features Utilizing Shadow Copies Users have access to shadow copies Open previous versions of shares Requires XP or Windows Server 2003 Users can: Restore accidentally deleted files Recover previous versions of files Compare document versions Reduces administration Users can restore their own files Slide Message: When you enable Shadow Copies you should configure where they will be stored, the storage limit and the backup schedule. Slide Builds: 3 Slide Script: [BUILD 1] Users have access to shadow copies: They can open and view the read-only backups by viewing previous versions of shares. This requires XP or Windows Server 2003. [BUILD 2] Users can: Restore accidentally deleted files. Recover previous versions of files. Compare document versions. [BUILD 3] Reduces administration: users can restore their own files without having to call the helpdesk to have the files restored. This saves costly and time consuming restores. Slide Transition: Now let’s look at Shadow Copies of shared folders. ADDITIONAL INFORMATION FOR PRESENTER:

What Is A Shadow Copy? Data “Snapshot” Infrastructure for creating a point-in-time copy of a single volume or multiple volumes Appears static, even though the original data is changing Write some data Data is written to the disk t0 t1 t2 Create a shadow copy Backup the static shadow copy while…

Demonstration 2 Configuring Shadow Copy Restore Configure Your Server Wizard Manage Your Server Wizard KEY MESSAGE: In this demonstration you will see how to configure Shadow Copies and see a restore from Shadow Copy. SLIDE BUILDS: SLIDE SCRIPT: In this demonstration you will see how to configure Shadow Copies and see a restore from Shadow Copy. SLIDE TRANSITION: Now the next agenda item.

Days between patch and exploit Windows Server 2003 SP1 151 180 331 Blaster Welchia/ Nachi Nimda 25 SQL Slammer Days between patch and exploit Why? Patch management too complex Time to exploit accelerating Exploits are more sophisticated Current approach is not sufficient How? Role based approach will give flexibility to our customers in terms of time to test/deploy Proactive instead of reactive engineering i.e. Windows Firewall and AD policy for Windows Firewall rule sets A step in the journey to more secure computing platforms, applications, and devices.

What are the Goals of SP1? Enhanced Security Enhanced Reliability reduced attack surface new security enhancements Stronger Defaults and privilege reduction on services RPC DCOM Support for no execute hardware Intel AMD Windows Firewall enabled by default New install scenario Provide a Security Configuration Wizard to assist IT Admins Role-based configuration and lockdown IIS 6.0 metabase auditing Enhanced Reliability Enhanced Performance 10%+ improvement in TPC, TPC-H, SAP, SSL, etc. Key Benefits & Features SP1 benefits fall into 3 main categories: Enhanced security-By continuing the efforts to reduce surface attack area that we began in Windows Server 2003, we have made this OS even more secure by default. Also, with the addition of several new security enhancements, keeping systems up to date and exploit-free has become easier. Key new security features in SP1 include: Stronger defaults and privilege reduction on services like RPC, DCOM Support for “No Execute” (NX) hardware Windows Firewall enabled for new install scenario Security Configuration Wizard-role based lockdown tool that leads admins through the process of turning off unused services within a given role. VPN quarantine-Client inspection, fix-up and isolation for VPN connections IIS 6.0 Metabase auditing Enhanced reliability Enhanced performance

SP1 Features and Enhancements Relevant XP SP2 enhancements RPC, DCOM lockdown Windows Firewall Post-Setup Security Updates Boot-time network protection for clean installs Security Configuration Wizard Base 64-bit extension system

RPC and DCOM Enhancements Dovetails with Windows XP SP2 RPC attack surface reduced Run RPC objects with reduced credentials New RPC registry keys Allow server applications to restrict access to the interface, typically through a security call back Enables application developers to more closely control access Additional DCOM access control restrictions Strengthening of DCOM authentication security model Overall reduction of risk of a successful network attack RPC and DCOM ports handled as a special case by Windows Firewall Overview of Windows XP Service Pack 2 Security Technologies – RPC and DCOM Many customers do not or cannot roll out security updates as soon as they become available, but still need to be protected against the risks that these security updates are designed to mitigate. Each security bulletin that Microsoft delivers includes information that customers can use to help mitigate risk while they deploy the update. However, Microsoft is delivering other security technologies that provide additional mitigation when a security update cannot be deployed immediately. These security technologies cover the following areas: · Network protection. These security technologies help to provide better protection against network-based attacks, like MSBlaster, through a number of innovations, including enhancements to Windows Firewall. The enhancements include turning on Windows Firewall in default installations of Service Pack 2, closing ports except when they are in use, improving the user interface for configuration, improving application compatibility when Windows Firewall is on, and enhancing enterprise administration of Windows Firewall through Group Policy. The attack surface of the Remote Procedure Call (RPC) service is reduced, and you can run RPC objects with reduced credentials. The Distributed Component Object Model (DCOM) infrastructure also has additional access control restrictions to reduce the risk of a successful network attack. RestrictRemoteClients Registry Key Detailed description When an interface is registered using RpcServerRegisterIf, RPC allows the server application to restrict access to the interface, typically through a security callback. The RestrictRemoteClients registry key forces RPC to perform additional security checks for all interfaces, even if the interface has no registered security callback. RPC clients that use the named pipe protocol sequence (ncacn_np) are exempt from all restrictions discussed in this section. The named pipe protocol sequence cannot be restricted by default, due to several significant backwards compatibility issues. The RestrictRemoteClients registry key can have the three values described below. If the key is not present, it is equivalent to having the RPC_RESTRICT_REMOTE_CLIENT_DEFAULT value. · The RPC_RESTRICT_REMOTE_CLIENT_NONE (0) value causes the system to bypass the new RPC interface restriction. It is entirely the responsibility of the server application to impose appropriate RPC restrictions. This setting is equivalent to the behavior in previous versions of Windows. · The RPC_RESTRICT_REMOTE_CLIENT_DEFAULT (1) value is the default value in Windows XP Service Pack 2. This value restricts access to all RPC interfaces. All remote anonymous calls are rejected by the RPC runtime. If an interface registers a security callback and provides the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag, then this restriction does not apply to that interface. · The RPC_RESTRICT_REMOTE_CLIENT_HIGH (2) value is the same as the RPC_RESTRICT_REMOTE_CLIENT_DEFAULT value, except that the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag will no longer exempt an interface. With this value, a system cannot receive remote anonymous calls using RPC. Why is this change important? What threats does it mitigate? It is much more difficult to attack an interface if you require calls to perform authentication, even a relatively low level of authentication. This is a particularly useful mitigation against worms which rely on exploitable buffer overruns that can be invoked remotely through anonymous connections. What works differently or stops working? If your RPC application expects to receive calls from remote anonymous RPC clients, this change might break your application. How do I fix these issues? There are three options to fix these issues. These options are listed in order of preference. · Require your RPC clients to use RPC security when contacting your server application. This is the best method to mitigate security threats. · Exempt your interface from requiring authentication by setting the RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH flag during interface registration. This configures RPC to allow anonymous connections to only your application’s interface. Force RPC to exhibit the same behavior as earlier versions of Windows by setting the registry key to RPC_RESTRICT_REMOTE_CLIENT_NONE (0). RPC will then accept anonymous connections to all interfaces. This option should be avoided if possible, as it reduces the overall security of the computer. New RPC Interface Registration Flags Three new interface registration flags have been created which make it easier for an application developer to secure an RPC interface. · RPC_IF_ALLOW_CALLBACKS_WITH_NO_AUTH When this flag is registered, the RPC runtime invokes the registered security callback for all calls, regardless of the call security settings. Without this flag, RPC rejects all unauthenticated calls before they reach the security callback. This flag works only when a security callback is registered. · RPC_IF_SEC_NO_CACHE A security callback is registered for an interface in order to restrict access to that interface. The typical security callback impersonates the client to determine if the client has sufficient rights to make a call to the interface. If a particular client identity passes a security callback once, it usually passes the same security callback every time. The RPC runtime takes advantage of this pattern by remembering when an individual client identity passes a security callback and skips the security callback for subsequent calls by that client to the same interface. This feature is called security callback caching and has existed since Windows 2000. For Windows XP Service Pack 2, you can use the RPC_IF_SEC_NO_CACHE flag to disable security callback caching for a given interface. This is useful if the security check might change, possibly rejecting a client identity which was previously permitted. · RPC_IF_LOCAL_ONLY When an interface is registered with this flag, RPC rejects calls made by remote RPC clients. In addition, local calls over all ncadg_* protocol sequences and all ncacn_* protocol sequences (except for named pipes, using ncacn_np) are also rejected. If a call is made on ncacn_np, RPC only allows the call if it does not come from SVR, which filters out all remote calls. Ncalrpc calls are always allowed through. Why is this change important? This change provides RPC application developers with additional security tools to help secure their RPC interface. These flags will not change or break any existing Windows XP application. The use of these new flags is at the discretion of the application developer. What settings are added or changed in Windows XP Service Pack 2? Setting name Location Default value Possible values RestrictRemoteClients \\HKLM\SOFTWARE\Policies\Microsoft\Windows NT\RPC 1 - Default 0 – None 1 – Default 2 – High EnableAuthEpResolution 0 - Disabled 0 – Disabled 1 – Enabled Do I need to change my code to work with Windows XP Service Pack 2? You may need to change your code to work with Windows XP Service Pack 2. For more information about application changes which might be required, see the previous sections on RestrictRemoteClients and EnableAuthEpResolution. DCOM Security Enhancements What does DCOM do? The Microsoft Component Object Model (COM) is a platform-independent, distributed, object-oriented system for creating binary software components that can interact. The Distributed Component Object Model (DCOM) allows applications to be distributed across locations that make the most sense to you and to the application. The DCOM wire protocol transparently provides support for reliable, secure, and efficient communication between COM components. For more information, see “Component Object Model” on the Microsoft Web site at http://go.microsoft.com/fwlink/?LinkId=20922 Who does this feature apply to? If you only use COM for in-process COM components, this section does not apply to you. This feature applies to you if you have a COM server application that meets one of the following criteria: · The access permission for the application is less stringent than the permission that is necessary to run it. · The application is usually activated on a computer running Microsoft Windows XP by a remote COM client without using an administrative account. · By default, the application uses unauthenticated remote callbacks on a computer running Windows XP. · The application is only meant to be used locally. This means you can restrict your COM server application so it is not remotely accessible. Inbound connections on RPC and DCOM ports Description Some applications and services require the use of RPC ports either through DCOM or RPC directly for inbound connections. Because of the significant security implications when opening RPC ports, these ports are handled as a special case, and developers should only try to enable RPC through Windows Firewall when absolutely necessary. Action Required Windows Firewall includes an explicit setting in the firewall to enable the automatic opening and closing of ports for RPC. Thus, applications and services do not have to open specific ports in order to use RPC for inbound connections. By default, however, RPC will be blocked by Windows Firewall. This means that an application or service needs to allow the RPC ports in Windows Firewall. If the RPC ports are already allowed, then the application or service does not need to do anything in order to function correctly. If the user consents to allowing the RPC ports, then the application or service should use the INetFwProfile API to set AllowRpcPorts to TRUE in order to allow traffic over RPC ports. If the user does not consent to allowing the RPC ports, then the application or service should not configure Windows Firewall to allow the RPC ports. Note the following: An application or service must be running in the context of a user with Administrator rights to enable or disable the automatic opening of RPC ports in Windows Firewall. An application or service should get user consent before allowing RPC ports through Windows Firewall. An application or service should try to allow the RPC ports through Windows Firewall only when absolutely necessary. The RPC ports setting only works for RPC servers which run in the context of Local System, Network Service or Local Service. Ports opened by RPC servers running in other user contexts will not be enabled through this setting. Instead, those RPC servers should use the Windows Firewall exceptions list.

Windows Firewall/RPC Goals and customer benefit What we’re doing Provide by default better protection from network attacks Focus on role-based server configuration What we’re doing Windows Firewall (formerly ICF) will be on by default in almost all configurations More configuration options Group policy, command line, unattended setup Better user interface Boot time protection Restrict anonymous connections to DCOM/RPC interfaces Application impact In-bound network connections will not be permitted by default Listening ports only open as long as the application is running NOTE: THIS INFORMATION IS PRIMARILY FROM XP SP2 DOCUMENTATION A new XP SP2 security feature that will be migrated into Windows Embedded (XPE) SP2 is the enhanced Internet Connection Firewall (WINDOWS FIREWALL) functionality. This includes the ability to turn on WINDOWS FIREWALL in default installations of SP2, closing ports except when they are in use, improving the user interface for configuration, improving application compatibility when WINDOWS FIREWALL is on, and enhancing enterprise administration of WINDOWS FIREWALL through Group Policy. XPE WINDOWS FIREWALL makes use of active packet filtering, which means that ports on the firewall are dynamically opened only for as long as needed to enable access to specific services. This type of firewall technology prevents would-be hackers from scanning ports and resources—including file and printer shares. This significantly reduces the threat of external attacks. The WINDOWS FIREWALL is enabled on a per-connection basis. B. What does Internet Connection Firewall do? Internet Connection Firewall (WINDOWS FIREWALL) is a stateful filtering firewall. WINDOWS FIREWALL provides protection for network connections by preventing unsolicited inbound connections through TCP/IP version 4 (IPv4). Configuration options include: • Enabling on a per-interface basis • Static port openings • Configure basic ICMP options • Log dropped packets and successful connections Note: Microsoft now hosts two versions of WINDOWS FIREWALL, IPv4 and IPv6. We will need to support both versions of WINDOWS FIREWALL for XPE SP2. Support for Internet Protocol version 6 (IPv6), a new suite of standard protocols for the network layer of the Internet, is built into the latest versions of Windows. IPv6 is designed to solve many of the problems of the current version of IP (known as IPv4) with regard to address depletion, security, auto-configuration, extensibility, and more. Its use will also expand the capabilities of the Internet to enable a variety of valuable scenarios, including peer-to-peer and mobile applications.

Windows Firewall Internet User Or Employee Customer Enhanced settings enable more granular control More configuration options, improved interface provide customers greater ability to control network communications Key Messages Talking Points Internet User Or Employee Customer

Windows Firewall and AD Firewall Policy Deployment

Post-Setup Security Updates A new feature designed to protect servers between first boot and application of most recent security updates Opens on first admin login if Windows Firewall was not explicitly enabled using unattend script or GP Blocks inbound connections until customer clicks “Finish” on PSSU dialog box Post-Setup Security Updates is a new feature in Windows Server 2003 Service Pack 1. Post-Setup Security Updates is designed to protect the customer from risk of infection between the first boot of the server and the application of the most recent security updates from Windows Update. In order to protect the server, Windows Firewall is enabled during a new installation of any version of Windows Server 2003 that includes a Service Pack. If Windows firewall is enabled and the customer did not explicitly enable it using an unattend script or group policy, Post-Setup Security Updates opens the first time an administrator logs on. Inbound connections to the server are blocked until the customer has clicked the Finish button on the Post-Setup Security Updates dialog box. If the customer set exceptions to the firewall through group policy or by enabling Remote Desktop during installation, inbound connections assigned to these exceptions remain open. Post-Setup Security Updates is not available from the Start menu. If Post-Setup Security Updates appears, Manage Your Server (MYS) opens after Post-Setup Security Updates is closed (unless MYS has been suppressed by policy). If Post-Setup Security Updates does not appear, Manage Your Server opens as it does in Windows Server 2003 with no Service Packs. Post-Setup Security Updates does not appear in any upgrade or update cases, including Windows 2000 to Windows Server 2003 or Windows Server 2003 to Windows Server 2003 Service Pack 1.

Post-Setup Security Updates Offers links to Windows Update Creates an opportunity to configure Automatic Updates Re-opens if not completed before first restart Forced closure (ALT+F4) makes no change to the firewall, system runs tests to display PSSU again at next log on Post-Setup Security Updates offers links to Windows Update to allow the customer to download any security updates that have been released since this operating system version was released. The customer also has the opportunity to configure Automatic Updates to help protect this server in the future. If Windows Update or any other configuration change causes a reboot before the administrator has clicked the Finish button on Post-Setup Security Updates, it reopens when the administrator re-logs on. If the administrator closes Post-Setup Security Updates using ALT+F4, no change is made to the firewall. The tests to determine whether Post-Setup Security Updates should be displayed run again the next time a user logs on. NOTE: The text on Post-Setup Security Updates is not refreshed if the firewall status changes after the initial display. If the status of the firewall changes after it appears and before the Finish button is clicked, the text may state that all inbound connections are blocked when, in fact, they are not. When the customer clicks Finish, Post-Setup Security Updates checks the status of the firewall again before displaying a dialog explaining any changes to be made on closure. Details of Conditions for Display of Post-Setup Security Updates The following tests are run to determine whether or not to display Post-Setup Security Updates. Test #1 Check if the logged-on user is an administrator a. If the user is an administrator, continue to test 2. b. If the user is not an administrator, skip the remaining tests and do not display Post-Setup Security Updates. Display MYS if appropriate. These tests run again the next time a user logs on. Test #2 Check if this is a new installation of a version of Windows Server 2003 that includes a Service Pack (not an upgrade) a. If this is a new installation, continue to test 3. b. If this is not a new installation, skip the remaining tests and do not display Post-Setup Security Updates. Set registry value to suppress Post-Setup Security Updates in the future. Test #3 Check that Post-Setup Security Updates has not been disabled This feature may have been disabled either because it has already been finished during a previous login or because the administrator wishes to suppress it. This check is based on the presence of the following registry value: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\ServerOOBE\SecurityOOBE Value Name (DWORD): (“DontLaunchSecurityOOBE”) a. If this registry key does not exist, continue to test 4. b. If this registry key exists, skip the remaining tests and do not display Post-Setup Security Updates. Test #4 Check if the firewall is enabled and was not explicitly enabled by the customer Check to see if the Windows Firewall/Internet Connection Sharing service is running. a. If the service is started, continue to step (b). b. If the service is stopped, keep checking for up to 2 minutes. If it does start, continue to test 4b. If the service does not start within 2 minutes, do not display Post-Setup Security Updates. Display the Manage Your Server interface if appropriate. These tests are run again the next time a user logs on. Request the status of Windows Firewall. If there is no response to this test, keep checking for up to 2 minutes. If this test tells us that the customer enabled the firewall or that the firewall is disabled, skip the remaining tests and do not display Post-Setup Security Updates. Set registry value to suppress Post-Setup Security Updates in the future. Note: The customer may have enabled or disabled the firewall using an unattend script at the time of installation or through the application of group policy or by opening the Windows Firewall control panel and clicking OK to confirm the firewall settings. If this test tells us that the firewall is enabled and the customer did not enable it, display Post-Setup Security Updates. If this test does not return a response within 2 minutes, do not display Post-Setup Security Updates. Display the Manage Your Server interface if appropriate. These tests are run again the next time a user logs on.

Post-Setup Security Updates Applies To: Windows server admins who are concerned that new Windows Server 2003 servers may not be fully protected before application of updates Admins who perform new installs of Windows Server 2003 with a Service Pack Does Not Apply When: OS install with an unattend script enabling or disabling Windows Firewall Windows Firewall is enabled or disabled through GP before PSSU is displayed Performing OS updates to existing Windows Server 2003 server, or upgrading existing NT or 2000 server to Windows Server 2003 The Post-Setup Security Updates feature applies when a server is installed as a new installation of a version of Windows Server 2003 that includes a Service Pack (also known as a slipstream installation) and Windows Firewall was not enabled or disabled using an unattend script during the installation or by application of group policy on first boot. When Windows Server 2003 SP1 is installed using a slipstream installation Windows Firewall is enabled by default on first boot and login in order to allow the administrator to securely download and install updates from Windows Update. All inbound connections are blocked with the following exceptions. If Remote Desktop was enabled using an unattend script during installation, port 3389 is not blocked. If group policy is applied that does not enable or disable Windows Firewall, but defines exceptions to the firewall, exceptions defined by the policy are not blocked. If the firewall is enabled and the customer did not enable it, Post-Setup Security Updates appears when an administrator logs on.

Post-Setup Security Update

Security Configuration Wizard Guided Attack Surface Reduction for Windows Servers Security Coverage Roles-Based Metaphor Disables Unnecessary Services Disables Unnecessary IIS Web Extensions Blocks unused Ports, inlcuding multi-homed scenarios Helps Secure Ports that are left open using IPSEC Reduces protocol exposure (LDAP, NTLM, SMB) Configures Audit Setting with high Signal to Noise Security for mere mortals Roles-based makes answering questions easy Automated versus Paper-Based Guidance Fully tested and supported by Microsoft Attack surface reduction is a fundamental security best practice, yet it is too difficult for most resource-constrained administrators to find the time to properly secure, test, and deploy a Windows server without breaking required functionality. Paper based guidance offers some relief, but who has the time and expertise necessary to sift through the thousands of pages of documentation to figure out the settings that can successfully be applied to a given scenario? Security Configuration Wizard automates the lockdown process, adapts to your environment, and is fully tested and supported by Microsoft. Reducing the attack surface of Windows servers increases the diversity of the Windows landscape and minimizes the number of servers that need to be immediately patched when a vulnerability is exploited. Servers that are not exposed to a specific vulnerability can be patched during the next scheduled maintenance cycle for the server. What does Security Configuration Wizard do? Security Configuration Wizard (SCW) provides guided attack surface reduction for Windows Servers running Service Pack 1. SCW asks the user a series of questions designed to solicit the functional requirements of a server. Functionality not required by the roles the server is performing is then disabled. In addition to being a fundamental security best practice, attack surface reduction increases the diversity of the Windows landscape thus reducing the number of systems that need to be immediately patched when a vulnerability is exposed. Today, Windows administrators typically define security policies using the Security Template snap-in on their own or in conjunction with paper-based guidance or pre-canned security templates designed for specific scenarios. In contrast, Security Configuration Wizard is an authoring tool that allows you to create a custom security policy by answering simple questions rather than reading a lot of documentation that is often inconsistent, not maintained, and untested. For settings that are not configured by the wizard, SCW allows the admin to import existing security templates. Detailed description Don’t be fooled by the term “wizard”. Security Configuration Wizard uses a roles-based metaphor driven by an extensible XML knowledge base that defines the service, port, and IIS requirements for over 50 different server roles including roles for applications such as Microsoft Exchange and SQL Server: Security Configuration Wizard uses this extensible XML knowledge base to perform role discovery, solicit user input, and author security policies that disable services, block ports, tweak registry values, and configure audit settings. Even ports that are left open can be restricted to specific populations or secured using IPsec. Security Configuration Wizard also allows you to rollback previously applied policies and is accompanied by a full-blown command line tool that allows you to perform configuration and compliance analysis en-masse. Security Configuration Wizard also integrates with Active Directory to support deployment of SCW-generated policies through Group Policy. Summary of SCW Security Coverage Security Configuration Wizard allows users to easily: Disable unnecessary Services. Disable unnecessary IIS web Extensions. Block unused Ports, including support for multi-homed scenarios. Secure Ports that are left open using IPsec. Reduce protocol exposure for LDAP, NTLM, and SMB. Configure Audit Settings with a high Signal to Noise ratio. Import Windows Security Templates for coverage of settings that are not configured by the wizard. Summary of SCW Operational Features In addition to roles-based, guided security policy authoring, SCW also supports: Rollback, when applied policies disrupt service expectations. Analysis, to check that machines are in compliance with expected policies. Remotability for configuration and analysis operations. Command Line Support for remote configuration and analysis en-masse. Active Directory Integration for Group Policy-based deployments. Editing of previously created policies, when machines are repurposed. XSL Views of the knowledge base, policies and analysis results. Do I need to change my code to work with Windows Server 2003 Service Pack 1? No, but SCW is extensible so that ISV’s can create their own SCW role definitions for their own applications. After installing SCW, view %windir%\security\msscw\kbs\kbext.xsd. This schema definition file documents the requirements for creating an xml file that extends the SCW knowledge base. There are also numerous examples of SCW extensions that ship with SCW in the same directory location. What do I need to change in my environment to deploy Windows Server 2003 Service Pack 1? Nothing, however SCW can be used during the deployment process to ensure servers are deployed with the expected security policy. Note the following deployment information: If unattended setup is used to deploy servers, Install the SCW optional component automatically during unattended setup by adding the following entry to the [ Components] section of unattend.txt: SCW = On To apply an SCW-generated policy during unattend.txt, use scwcmd.exe as part of cmdlines.txt. For example: “scwcmd.exe configure /p:webserverpolicy.xml”. In this example, webserverpolicy.xml was previously generated by SCW and is accessible from the $OEM$ directory structure on the Windows distribution share. If an imaging solution is used to deploy servers, run SCW on the reference machine that will be imaged.

SCW Operational Coverage Rollback, when applied policies disrupt service expectation Analysis, to check that machines are in compliance with policies Remotability for configuration and analysis operations Command Line Support for remote config and analysis en-masse Active Directory Integratation for Group Policy-based deployment Editing of previously created policies, when machines are repurposed XSL Views of Knowledge base, policies and analysis results

Security Configuration Wizard

How To Get Involved WindowsServerFeedback.com Share your ideas with the Windows Server Development Team via WindowsServerFeedback.com You can also participate in: Online surveys about product feature priorities Product focus groups TechBeta

Summary SP1 Security-focused service pack, and includes performance and reliability improvements Exciting roadmap – complement to XP SP2, precursor to Windows Server 2003 R2 and Longhorn Windows Server Roadmap is solid What you can do: Test the product RC Communicate to your company on our roadmap Provide your ideas on how we can make further improvements in this area To summarize… …please review the slides in the appendix for additional information.

More Information: Windows Server 2003: http://www.microsoft.com/windowsserver2003/ Windows XP SP2 on Microsoft TechNet: http://www.microsoft.com/technet/prodtechnol/winxppro/maintain/winxpsp2.mspx Security home page on Microsoft Trustworthy Computing: http://www.microsoft.com/security Microsoft SGC Center : http://www.microsoft.com/security/guidance/ Enhancing Customer Security on Microsoft TechNet: http://www.microsoft.com/technet/security/news/custsec.mspx Microsoft IT practices: http://www.microsoft.com/itshowcase

MICROSOFT CONFIDENTIAL © 2004 Microsoft Corporation MICROSOFT CONFIDENTIAL © 2004 Microsoft Corporation. All rights reserved.