Title |  | Body | Categories | OS concerned | Technologies |
|---|
| | In Windows 7, BitLocker Drive Encryption technology is extended from operating system drives and fixed data drives to include removable storage devices such as portable hard drives and USB flash drives.
This allows you to take your protected data with you when traveling and use it with any computer running Windows 7.
Setting up BitLocker
In Windows 7, drives are automatically prepared for use by BitLocker; there is no need to create separate partitions before turning on BitLocker. The system partition is automatically created and does not have a drive letter, so it is not visible in Windows Explorer and data files will not be written to it inadvertently.
In a default installation, a computer will have a separate system partition and an operating system drive. The system partition is smaller in Windows 7 than in Windows Vista, requiring only 100 MB of space.
BitLocker can be used to encrypt operating system drives, fixed data drives, and removable data drives in Windows 7 and Windows Server 2008 R2.
When BitLocker is used with data drives, the drive can be formatted with the exFAT, FAT16, FAT32, or NTFS file system and must have at least 64 MB of available memory.
When BitLocker is used with operating system drives, the drive must be formatted with the NTFS file system.
Using BitLocker To Go with removable drives
In Windows 7, users can encrypt their removable media by opening Windows Explorer, right-clicking the drive, and clicking Turn On BitLocker. They will then be asked to choose a method to unlock the drive.
These options include:
Password. This is a combination of letters, symbols, and numbers the user will enter to unlock the drive.
Smart card. In most cases, a smart card is issued by your organization and a user enters a smart card PIN to unlock the drive.
After choosing the unlock methods, users will be asked to print or save their recovery password. This is a 48-digit password that can also be stored in Active Directory Domain Services (AD DS) and used if other unlock methods fail (for example, when a password is forgotten).
Finally, users will be asked to confirm their unlock selections and to begin encryption.
Unlocking BitLocker-protected drives
When you insert a BitLocker-protected drive into your computer, Windows will automatically detect that the drive is encrypted and prompt you to unlock it.
While the ability to encrypt drives is only available on some versions of Windows 7, all versions will permit unlocking of BitLocker-protected drives.
New Group Policy settings
BitLocker in Windows 7 introduces several new Group Policy settings that permit easy management of features. For example, administrators will be able to:
Require all removable drives be BitLocker-protected before data can be saved on them.
Require or disallow specific methods for unlocking BitLocker-protected drives.
Configure methods to recover data from BitLocker-protected drives if the user's unlock credentials are not available.
Note
In addition to recovery passwords, administrators can use Group Policy to configure a domain-wide public key called a data recovery agent that will permit an administrator to unlock any drive encrypted with BitLocker.
Before a data recovery agent can be used, it must be added from the Public Key Policies item in either the Group Policy Management Console (GPMC) or the Local Group Policy Editor.
To use a data recovery agent with BitLocker, you must enable the appropriate Group Policy setting for the drives that you are using BitLocker with.
These settings are:
- Configure how BitLocker-protected operating system drives can be recovered,
- Configure how BitLocker-protected removable data drives can be recovered,
- Configure how BitLocker-protected fixed data drives can be recovered,
- and Configure how BitLocker-protected drives can be recovered (Windows Server 2008 and Vista).
When you enable the policy setting, select the Enable data recovery agent check box.
There is a policy setting for each type of drive, so you can configure individual recovery policies for each type of drive on which you enable BitLocker. You must also enable and configure the Provide the unique identifiers for your organization policy setting to associate a unique identifier to a new drive that is protected with BitLocker. Identification fields are required for management of data recovery agents on BitLocker-protected drives. BitLocker will manage and update data recovery agents only when an identification field is present on a drive and is identical to the value configured on the computer.
In Windows 7, Group Policy settings for BitLocker have been extended to include configurable options for removable data drives as well as fixed data drives.
Most of the Group Policy settings have separate settings to be applied to operating system drives, fixed drives, and removable drives as appropriate. BitLocker Group Policy settings can be viewed by using either the Local Group Policy Editor or the GPMC.
Using these policy settings helps enforce standard deployment of BitLocker Drive Encryption in your organization.
Group Policy settings that affect BitLocker are located in Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption. Globally applied BitLocker Group Policy settings are located in this folder. Subfolders for fixed data drives, operating system drives, and removable drives support configuration of policy settings specific to those drives.
Note
If you want to use BitLocker to protect an operating system drive on a computer that does not have a Trusted Platform Module (TPM), you must enable the Require additional authentication at startup Group Policy setting, and then within that setting click Allow BitLocker without a compatible TPM.
To learn more, click this link: BitLocker Drive Encryption Step-by-Step Guide for Windows 7,
| Architect | Windows Server 2003 | Active Directory |
| | included in some editions of the Windows Server 2008 R2 and Windows 7 operating systems.
To optimize WAN bandwidth, BranchCache copies content from your main office content servers and caches the content at branch office locations, allowing client computers at branch offices to access the content locally rather than over the WAN. This deployment guide provides instructions on deploying BranchCache in both distributed cache mode and hosted cache mode, and allows you to deploy Hypertext Transfer protocol (HHTP), Background Intelligent Transfer Service (BITS), and Server Message Block (SMB)-based content servers that are Web servers, application servers, and file servers, respectively.
To learn more, click this links:
| Architect | Windows Server 2003 | Active Directory |
| | | Architect | Windows Server 2003 | Active Directory |
|  | This white paper describes the basic architecture of the Single Instance Storage (SIS) feature of the Microsoft® Windows® Storage Server 2003 R2 operating system. This feature helps organizations reduce storage needs for file servers by identifying duplicate files within hard disk volumes and providing an efficient mechanism for consolidating them. The paper also examines the benefits of using SIS, based upon deployment by the Microsoft Information Technology (Microsoft IT) group for Microsoft branch offices and data-center servers. The paper closes with a collection of best practices. | Architect | Windows Server 2003 | Active Directory |
| | To discover all Microsoft Virtualization Technologies:
Enjoy!
| Architect | Windows Server 2003 | Active Directory |
| | Hyper-V, Microsoft’s first-generation hypervisor-based virtualization role for Windows Server 2008, has been released and can be downloaded as an update to 64-bit editions of the server. Hyper-V offers customers a new Windows Server 2008 virtualization role for consolidating servers. Windows Server 2008 Hyper-V and its stand-alone counterpart, Hyper-V Server, will allow Microsoft to compete for the production and consolidation hardware virtualization market. This report from Directions on Microsoft covers Microsoft’s first-generation, hypervisor-based hardware virtualization platform.
To learn more,
| Architect | Windows Server 2003 | Active Directory |
| | Brief Description
This download contains documentation for System Center Operations Manager 2007.
Overview
This download contains the following documentation for System Center Operations Manager 2007:
• Operations Manager 2007 Deployment Guide:
This guide steps you through the deployment process for System Center Operations Manager 2007.
• Active Directory Management Pack Guide for Operations Manager 2007:
This document includes a Management Pack overview, deployment procedures, and monitoring scenarios for the two Active Directory Domain Services (AD DS) Management Packs
• Exchange Management Pack Guide for Operations Manager 2007: This guide includes a Management Pack overview, deployment procedures, and monitoring scenarios for the Microsoft Exchange Server 2003 Management Pack for Microsoft System Center Operations Manager 2007.
• SQL Management Pack Guide for Operations Manager 2007:
The SQL Server Management Pack provides both proactive and reactive monitoring of SQL Server 2000 and SQL Server 2005 for an enterprise environment.
• Windows Server Operating System Management Pack Guide for Operations Manager 2007:
The Microsoft Windows Server Management Packs monitor the performance, health, and availability of Microsoft Windows 2000 Server and Microsoft Windows Server 2003.
• Windows Client Operating System Management Pack Guide:
The Windows client operating system Management Packs are intended for use in gathering data on client computers or individually monitoring designated mission-critical client computers.
• Operations Manager 2007 Terminal Services Management Pack: This guide includes an overview of the Management Pack, deployment procedures, and monitoring scenarios for the Terminal Services Management Pack.
• Operations Manager 2007 Security Guide:
This guide provides you with security-related information as it pertains to Operations Manager 2007.
• Operations Manager 2007 Management Pack Guide:
This guide includes a Management Pack overview, deployment procedures, and monitoring scenarios for the Microsoft Windows Server Internet Information Services 2000 and 2003 Management Packs for Microsoft System Center Operations Manager 2007.
• Operations Manager 2007 Management Pack Terminal Services:
This guide includes an overview of the Management Pack, deployment procedures, and monitoring scenarios for the Terminal Services Management Pack.
• The Operations Manager 2007 Design Guide:
This guide steps the reader through the steps necessary to develop a complete architectural plan for their OpsMgr2007 implementation.
• Operations Manager 2007 Backup and Recovery Guide:
This guide provides guidance in planning for backup and recovery of System Center Operations Manager 2007 server roles and components. The information in this guide will complement your existing recovery strategy to avoid service disruption.
To download, click this link:
| Architect | Windows Server 2003 | Active Directory |
| | This article describes the benefits of wireless LANs, the support for 802.11 wireless LAN and wireless LAN security standards in Microsoft® Windows®, and general guidelines for wireless LANs in medium to large organizations and small office/home office networks.
On This Link, you can find:
- Benefits of Wireless LANs
- Support for IEEE 802.11 Standards
- Support for IEEE 802.11 Security Standards
- Checklists and Resources
| Architect; Deploy; Security Services | Windows Server 2003; WIndows XP Professional | Active Directory |
| | Although public key cryptography simplifies key management by allowing one key pair to be used by many people, there is a problem: how to distribute a public key so that the user can find it and know that it is valid.
To read all, click this cool document!
| Architect; Security Services | Windows Server 2003 | Active Directory |
| | Network Access Protection (NAP) is a new platform to perform computer health policy validation, ensure ongoing compliance with health policies, and optionally restrict the access of computers that do not comply with system health requirements until their health state can be corrected.
Network Access Protection includes a client and server architecture. Administrators can configure Internet Protocol security (IPsec) Enforcement, IEEE 802.1X Enforcement, virtual private network (VPN) Enforcement, Dynamic Host Configuration Protocol (DHCP) Enforcement, or all four, depending on their network needs.
Network Access Protection provides an infrastructure and an API set for extending Network Access Protection functionality. Vendors and software developers can use the API set to build their own network policy validation, ongoing network policy compliance, and network isolation components that are compatible with Network Access Protection.
For a Webcast version of this white paper, click here:
Note The Network Access Protection platform is not the same as Network Access Quarantine Control, which is a capability provided with Windows Server 2003 to provide additional protection for remote access (dial-up and virtual private network [VPN]) connections. For more information, see Network Access Quarantine Control in Windows Server 2003.
For More Information:
| Architect | Windows Server 2003 | Active Directory; DHCP; DNS |
| | European Telecommunications Standards Institute (ETSI) doubled the frame rate display – from 15 frames per second to 30 frames per second – by upgrading to the Microsoft Windows Server 2003 Enterprise Edition operating system and Windows Media Services 9 Series. The doubling of frame rates – which provides an appreciable benefit for viewers – was seen on the same hardware that had previously been running the Windows 2000 Server operating system and Windows Media Services 8.0. ETSI also gained tighter security measurements and easier system administration with its upgrade to Windows Server 2003. | Case Study | Windows Server 2003 | Active Directory; MSCS |
| | The Volume Shadow Copy Service provides the backup infrastructure for the Microsoft Windows XP and Microsoft Windows Server 2003 operating systems, as well as a mechanism for creating consistent point-in-time copies of data known as shadow copies.
The Volume Shadow Copy Service can produce consistent shadow copies by coordinating with business applications, file-system services, backup applications, fast-recovery solutions, and storage hardware. Several features in the Windows Server 2003 operating systems use the Volume Shadow Copy Service, including Shadow Copies for Shared Folders and Backup.
To read all, click this link:
or the attached file !
| Architect | Windows Server 2003 | Active Directory |
| | Doing more with less just got better! Windows Server 2003 R2 simplifies branch server management, improves identity and access management, reduces storage management costs, provides a rich Web platform, and offers cost-effective server virtualization.
Built on Windows Server 2003 with Service Pack 1 (SP1), Windows Server 2003 R2 takes advantage of the stability and security of a proven code base, while introducing new features and scenarios. In these webcasts for IT professionals, Microsoft subject matter experts walk through the new R2 enhancements and best practices for how to plan and deploy Windows Server 2003 R2.
| Architect | Windows Server 2003 | Active Directory |
| | This document provides an introduction to the methods and concepts of Virtual Server host clustering. With Virtual Server host clustering, you can provide a wide variety of services through a small number of physical servers and, at the same time, maintain availability of the services you provide. If one server requires scheduled or unscheduled downtime, another server is ready to quickly begin supporting services. Users experience minimal disruptions in service.
Virtual Server host clustering is a way of combining Microsoft® Virtual Server 2005 R2 with the server cluster feature in Microsoft Windows Server™ 2003. This document describes a simple configuration in which you use Microsoft Virtual Server 2005 R2 to configure one guest operating system, and configure a server cluster that has two servers (nodes), either of which can support the guest if the other server is down. You can create this configuration and then, by carefully following the pattern of the configuration, develop a host cluster with additional guests or additional nodes.
| Architect | Windows Server 2003 | Active Directory; MSCS |
| | Terminal Server Session Directory is a feature that allows users to easily and automatically reconnect to a disconnected session in a load balanced Terminal Server farm.
The session directory keeps a list of sessions indexed by user name and server name. This enables a user, after disconnecting a session, to reconnect to the correct terminal server where the disconnected session resides to resume working in that session.
This reconnection will work even if the user connects from a different client computer.
This white paper discusses how to plan and deploy a load balanced terminal server farm using session directory, and how the session directory operates in a load balanced environment.
Included in This Document
• Session Directory Overview
• Load Balanced Configurations
• Session Directory
• Summary
• Appendix
| Architect; Plan; Deploy; Support | Windows Server 2003 | Active Directory; MSCS |
| | Naming conventions in Active Directory for computers, domains, sites, and OUs
View products that this article applies to.
Article ID : 909264
Last Review : January 18, 2006
Revision : 1.0
INTRODUCTION
Computer names
NetBIOS computer names
DNS computer names
Domain names
NetBIOS domain names
DNS domain names
Other factors
Site names
OU names
INTRODUCTION
This article describes the naming conventions for computer accounts in Microsoft Windows, NetBIOS domain names, DNS domain names, Active Directory sites, and organizational units (OUs) that are defined in the Active Directory directory service. The topics that are discussed include the valid characters for names, the minimum and maximum name lengths, reserved names, names that we do not recommend, and general recommendations that are based on supporting Active Directory in small, medium, and large deployments.
Computer names
NetBIOS computer names
Allowed characters
NetBIOS computer names can contain all alphanumeric characters except for the extended characters that are listed in the "Disallowed characters" section. Names can contain a period, but names cannot start with a period.
Disallowed characters
NetBIOS computer names cannot contain the following characters:• backslash (\)
• slash mark (/)
• colon (:)
• asterisk (*)
• question mark (?)
• quotation mark (")
• less than sign (<)
• greater than sign (>)
• vertical bar (|)
Names can contain a period (.). However, the name cannot start with a period. The use of non-DNS names with periods is allowed in Microsoft Windows NT. However, periods should not be used in Microsoft Windows 2000 or in later versions of Windows. If you are upgrading a computer whose NetBIOS name contains a period, change the machine name. For more information, see the "Special characters" section.
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 244412 ( http://support.microsoft.com/kb/244412/) Windows 2000 does not permit all-numeric computer names Minimum name length 1 character. Maximum name length 15 characters.
Note The 16th character is reserved to identify the functionality that is installed on the registered network device.
Reserved names
See "Table of reserved words."
Special characters
Period (.).
A period character separates the name into a NetBIOS scope identifier and the computer name. The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.
DNS computer names
Allowed characters
DNS computer names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)
In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
Minimum name length
2 characters.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters.
Domain controllers must have an FQDN of less than 155 bytes.
Reserved names per RFC
• -GATEWAY
• -GW
• -TAC
• Top-level Internet domain names, such as com, .net, .org, .us, .fr, and .gr
Reserved names in Windows
See "Table of reserved words."
Best practices
When you create names for the DNS computers in a new Windows Server 2003 DNS infrastructure, use the following guidelines: • Choose computer names that are easy for users to remember.
• Identify the owner of the computer in the computer name.
• Choose a name that describes the purpose of the computer.
• Do not use character case to indicate the owner or the purpose of a computer. DNS is not case-sensitive.
• Match the Active Directory domain name to the primary DNS suffix of the computer name.
• Use a unique name for every computer in your organization. Do not assign the same computer name to computers in different DNS domains.
• Use ASCII characters. This guarantees interoperability with computers that are running versions of Windows that are earlier than Windows 2000.
• In DNS computer names, use only the characters that are listed in RFC 1123. These characters include A–Z, a–z, 0–9, and the hyphen (-). In Windows Server 2003, DNS allows most UTF-8 characters in names. However, do not use extended ASCII or UTF-8 characters unless all the DNS servers in your environment support them.
Domain names
NetBIOS domain names
Allowed characters
NetBIOS domain names can contain all alphanumeric characters except for the extended characters that are listed in the "Disallowed characters" section. Names can contain a period, but names cannot start with a period.
Disallowed characters
NetBIOS computer names cannot contain the following characters:• backslash (\)
• slash mark (/)
• colon (:)
• asterisk (*)
• question mark (?)
• quotation mark (")
• less than sign (<)
• greater than sign (>)
• vertical bar (|)
Names can contain a period (.). However, the name cannot start with a period. The use of non-DNS names with periods is allowed in Microsoft Windows NT. However, periods should not be used in Active Directory domains. If you are upgrading a domain whose NetBIOS name contains a period, change the name by migrating the domain to a new domain structure. Do not use periods in new NetBIOS domain names.
In Windows 2000 and in later versions of Windows, computers that are members of an Active Directory domain cannot have names that are composed completely of numbers. This restriction is because of DNS restrictions.
Minimum name length
1 character.
Maximum name length
15 characters.
Note The 16th character is reserved to identify the functionality that is installed on the registered network device.
Reserved names in Windows
See "Table of reserved words."
The names of an upgraded domain can include a reserved word. However, trust relationships with other domains fail when this is true. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 836182 ( http://support.microsoft.com/kb/836182/) You cannot establish a trust relationship to another Windows 2000 domain Special characters Period (.).
A period character separates the name into a NetBIOS scope identifier and the computer name. The NetBIOS scope identifier is an optional string of characters that identify logical NetBIOS networks that run on the same physical TCP/IP network. For NetBIOS to work between computers, the computers must have the same NetBIOS scope identifier and unique computer names.
Warning The use of NetBIOS scopes in names is a legacy configuration and should not be used with Active Directory forests.
DNS domain names
Allowed characters
DNS host names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)
In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
Minimum name length
2 characters.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters. For more information, click the following article number to view the article in the Microsoft Knowledge Base: 245809 ( http://support.microsoft.com/kb/245809/) Windows 2000 supports fully qualified domain names up to 64 UTF-8 bytes long
Single-label domain namespaces
Single-label DNS names are names that do not contain a suffix such as .com, .corp, .net, .org or companyname. For example, "host" is a single-label DNS name. Most Internet registrars do not allow the registration of single-label DNS names.
Generally, we recommend that you register DNS names for internal and external namespaces with an Internet registrar. This includes the DNS names of Active Directory domains, unless such names are subdomains of DNS names that are registered by your organization name. For example, "corp.example.com" is a subdomain of "example.com." Registering your DNS name with an Internet registrar may help prevent a name collision. A name collision may occur if another organization tries to register the same DNS name or if your organization merges with another organization that uses the same DNS name.
Problems that are associated with single-label namespaces include the following: • Single-label DNS names cannot be registered by using an Internet registrar.
• Domains that have single-label DNS names require additional configuration.
• The DNS Server service may not be used to locate domain controllers in domains that have single-label DNS names.
• By default, Windows Server 2003-based domain members, Windows XP-based domain members, and Windows 2000-based domain members do not perform dynamic updates to single-label DNS zones.
Disjointed namespaces
Definition of a disjointed namespace
A disjointed namespace occurs when a computer's primary DNS suffix does not match the DNS domain of which it is a member. For example, a disjointed namespace occurs when a machine that has the DNS name of dc1.contosocorp.com is in a domain that has the DNS name of contoso.com.
How disjointed namespaces occur1. A Windows NT 4.0 primary domain controller is upgraded to a Windows 2000 domain controller by using the original release version of Windows 2000. In the Networking item in Control Panel, multiple DNS suffixes are defined.
2. The domain is renamed when the forest is at the Windows Server 2003 forest functional level, and the primary DNS suffix is not changed to reflect the new DNS domain name.
Effects of a disjointed namespace
Suppose a domain controller named DC1 resides in a Windows NT 4.0 domain whose NetBIOS domain name is contoso. This domain controller is upgraded to Windows 2000. When this upgrade occurs, the DNS domain is renamed contoso.com. In the original release version of Windows 2000, the upgrade routine clears the check box that links the primary DNS suffix of the domain controller to its DNS domain name. Therefore, the primary DNS suffix of the domain controller is the DNS suffix that was defined in the Windows NT 4.0 suffix search list. In this example, the DNS name is DC1.northamerica.contoso.com.
The domain controller dynamically registers its service location (SRV) records in the DNS zone that corresponds to its DNS domain name. However, the domain controller registers its host records in the DNS zone that corresponds to its primary DNS suffix.
Note Host records are also known as "A records" or "glue records."
When you intentionally create a disjointed namespace, configure forwarders or delegations in the DNS zones. Configure these forwarders or delegations between both forward lookup zones so that the host records can be located. For example, configure forwarders between the contoso.com and northamerica.contoso.com. If a disjointed namespace is created unintentionally, if no forwarders are configured, and if the DNS zones are created by the Active Directory Installation Wizard, no zone is created for the primary DNS suffix zone. When this configuration requirement is not satisfied, clients cannot resolve DNS requests for services to the IP addresses of the domain controllers that provide these services. In this scenario, AD replication and other operations experience a DNS lookup error. These operations fail because the SRV record request points to a host record that does not exist in the zone. Or, these operations fail because the host record is in a zone that cannot be reached through a forwarder.
Preventing disjointed namespace problems
When a Windows NT 4.0 primary domain controller is upgraded to the original release version of Windows 2000, the Change primary DNS suffix when domain membership changes check box is unchecked. This problem was corrected in Windows 2000 Service Pack 1. To work around this problem, use one of the following methods: • Select the Change primary DNS suffix when domain membership changes check box.
• Perform a slipstream of the service pack with the installation media so that the upgrade automatically upgrades the domain controller to the current service pack.
After you perform a domain rename, make sure that you modify the DNS suffix of the domain controllers so that it matches the new domain namespace.
Best practices
• Before you upgrade a Windows NT 4.0 domain controller, modify the DNS suffix of the computer in the TCP/IP Properties dialog box to match the DNS suffix of the Windows 2000 domain of which it will be a member.
• Before you run the Active Directory Installation Wizard on a Windows 2000 member server, make sure that the Change primary DNS suffix when domain membership changes check box is selected. To locate this check box, follow these steps: 1. Right-click My Computer, and then click Properties.
2. In the System Properties dialog box, click the Network Identification tab, and then click Properties.
3. In the Identification Changes dialog box, click More.
By default, the Change primary DNS suffix when domain membership changes check box is selected on a Windows 2000-based computer, unless it has been upgraded from Windows NT 4.0.
• Before you upgrade the first domain controller, plan the DNS namespace. Otherwise, you may incorrectly answer namespace questions in the Active Directory Installation Wizard.
Do not use top-level Internet domain names on the intranet. Top-level Internet domain names include .com, .net, .org, .us, .fr, and .gr. If you use top-level Internet domain names on the intranet, computers on the intranet that are also connected to the Internet may experience resolution errors.
Other factors
Forests that are connected to the Internet
A DNS namespace that is connected to the Internet must be a subdomain of a top-level or second-level domain of the Internet DNS namespace.
Maximum number of domains in a forest
In Windows 2000, the maximum number of domains in a forest is 800.
In Windows Server 2003, the maximum number of domains at Forest Functional Level 2 is 1200. This restriction is a limitation of multivalued non-linked attributes in Windows Server 2003.
Best practices
• Because the DNS names of all the nodes that require name resolution include the Internet DNS domain name for the organization, choose an Internet DNS domain name that is short and easy to remember. Because DNS is hierarchical, DNS domain names grow when you add subdomains to your organization. Short domain names make the computer names easy to remember.
• If the organization has an Internet presence, use names that are relative to the registered Internet DNS domain name. For example, if you have registered the Internet DNS domain name contoso.com, use a DNS domain name such as corp.contoso.com for the intranet domain name.
• Do not use the name of an existing corporation or product as your domain name.
• Do not use an acronym or an abbreviation as a domain name. Users may have difficulty recognizing the business unit that an acronym represents.
• Do not use the name of a business unit or of a division as a domain name. Business units and other divisions change periodically, and these domain names can be misleading or become obsolete.
• Do not use geographic names that are difficult to spell and remember.
• Avoid extending the DNS domain name hierarchy more than five levels from the root domain. You can reduce administrative costs by limiting the extent of the domain name hierarchy.
• If you are deploying DNS in a private network, and you do not plan to create an external namespace, register the DNS domain name that you create for the internal domain. Otherwise, you may find that the name is unavailable if you try to use it on the Internet, or if you connect to a network that is connected to the Internet.
Site names
We recommend that you use a valid DNS name when you create a new site name. Otherwise, your site will be available only where a Microsoft DNS server is used. For more information about valid DNS names, see the "DNS computer names" section.
Allowed characters
DNS host names can contain only alphabetical characters (A-Z), numeric characters (0-9), the minus sign (-), and the period (.). Period characters are allowed only when they are used to delimit the components of domain style names.
In the Windows 2000 domain name system (DNS) and in the Microsoft Windows Server 2003 DNS, the use of Unicode characters is supported. Other implementations of DNS do not support Unicode characters. Avoid Unicode characters if queries will be passed to the servers that use non-Microsoft implementations of DNS.
Disallowed characters
DNS host names cannot contain the following characters:• comma (,)
• tilde (~)
• colon (:)
• exclamation point (!)
• at sign (@)
• number sign (#)
• dollar sign ($)
• percent (%)
• caret (^)
• ampersand (&)
• apostrophe (')
• period (.)
• parentheses (())
• braces ({})
• underscore (_)
In DNS, a period breaks the name into a different namespace. In this scenario, such use is not valid.
The DNS host name cannot contain blank or space characters.
No distinction is made between upper and lowercase.
The first character must be alphabetical or numeric.
The last character must not be a minus sign or a period.
Minimum name length
1 character.
Maximum name length
24 characters.
The maximum length of the host name and of the fully qualified domain name (FQDN) is 63 octets per label and 255 bytes per FQDN. This maximum includes 254 bytes for the FQDN and one byte for the ending dot.
In Windows 2000 and in Windows Server 2003, the maximum host name and the FQDN use the standard length limitations that are mentioned earlier, with the addition of UTF-8 (Unicode) support. Because some UTF-8 characters exceed one octet in length, you cannot determine the size by counting the characters.
OU names
Allowed characters
All characters are allowed, even extended characters. However, although Active Directory Users and Computers lets you name an OU with extended characters, we recommend that you use names that describe the purpose of the OU and that are short enough to easily manage. Lightweight Directory Access Protocol (LDAP) does not have any restrictions, because the CN of the object is put in quotation marks.
For more information, click the following article number to view the article in the Microsoft Knowledge Base: 886689 ( http://support.microsoft.com/kb/886689/) The Ntdsutil authoritative restore operation is not successful if the distinguished name path contains extended characters in Windows Server 2003 and in Windows 2000 Disallowed characters
No characters are not allowed.
Minimum name length
1 character.
Maximum name length
64 characters.
Special issues
When the OU has the same name as another object in the forest, a name collision may sometimes occur. We recommend that you do not give an OU the same name as another object in the forest.
For example, consider a scenario where the OU has the same name as other objects in the forest. An OU in the parent domain has the same name as the NetBIOS name of a child domain. The OU is deleted during the tombstone lifetime of the OU. Then, a child domain that has the same name is created, deleted, and created again. In this scenario, a duplicate object in the Jet database causes a phantom-phantom name collision when the child domain is re-created. This problem prevents the configuration container from replicating.
Table of reserved words
Reserved words for names Windows NT 4.0 Windows 2000 Windows Server 2003
NULL X X X
WORLD X X X
LOCAL X X X
CREATOR OWNER X X X
CREATOR GROUP X X X
NT DOMAIN X X X
NT AUTHORITY X X X
DIALUP X X X
NETWORK X X X
BATCH X X X
INTERACTIVE X X X
SERVICE X X X
BUILTIN X X X
SYSTEM X X X
ANONYMOUS X X X
CREATOR OWNER SERVER X X X
CREATOR GROUP SERVER X X X
SERVER X X
SELF X X
AUTHENTICATED USER X X
RESTRICTED X X
INTERNET X X
TERMINAL SERVER X X
PROXY X X
LOCALSERVICE X
NETWORKSERVICE X
REMOTE INTERACTIVE X
USERS X
NTLM AUTH X
DIGEST AUTH X
SCHANNEL AUTH X
THIS ORGANIZATION X
| Architect | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Background Intelligent Transfer Service (BITS) asynchronously transfers files in the foreground or background, throttles the transfers to preserve the responsiveness of other network applications, and automatically resumes file transfers after network disconnects and machine restarts.
Applications use the BITS application program interface (API) to create transfer jobs and to monitor the progress of jobs in the transfer queue. The BITS API is included in the Microsoft® Platform Software Development Kit (SDK).
This document is intended for IT professionals who are interested in using BITS from within their software.
| Architect | Windows Server 2003 | |
| | Federated identity management is a standards-based technology and information technology process that enables distributed identification, authentication, and authorization across organizational and platform boundaries. Federated systems interoperate across organizational boundaries and connect processes utilizing different technologies, identity storage, security approaches, and programming models. Within a federated system, an organization needs a standardized and secure way of expressing not only the services it makes available to trusted partners and customers, but also the policies by which it runs its business, such as which other organizations and users it trusts, what types of credentials and requests it accepts, and its privacy policies.
The Active Directory Federation Services (ADFS) solution in Windows Server 2003 R2 helps administrators address these challenges by enabling organizations to securely share a user's identity information.
To read all, open or download this document!
| Architect; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Novenci presentation on MS Management Products:
- WSUS
- SMS 2003
- MOM 2005
- SC SPM 2006
- Microsoft Products Roadmap
Presentation PPT ! | Architect | Windows Server 2003 | Active Directory |
| | Delegation of administration, a key capability of Active Directory, provides a means to manage an Active Directory environment successfully. This document discusses in depth the issues that are involved in delegating administrative responsibilities, and it can help you plan for, implement, and maintain an administrative delegation model that provides secure and efficient management for Active Directory.
This document provides all the information necessary to create, implement, and maintain a security-conscious and efficient delegation model for managing your Active Directory environments. This information includes an overview of delegation, in-depth explanations of rationales for delegation, technical descriptions of how delegation works in Active Directory, processes for creating delegation models for both service management and data management, the steps needed to implement and maintain the delegation models, and a detailed case study. Appendices to this document provide an exhaustive reference, including a comprehensive list of Active Directory administrative tasks and the associated permissions that are required to delegate every administrative task in Active Directory.
For more information about this topic, click this link:
| Architect; Plan; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | A PPT file (in french) to understand major concepts on WIndows security services.
| Architect; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Many of the techniques and products available to help secure an enterprise network rely on some form of cryptography. A Public Key Infrastructure (PKI) provides the certificates used by each party involved in a cryptographically secured electronic transaction. To help secure the Microsoft corporate network, the Microsoft internal Information Technology group—called Microsoft IT—needed to implement several initiatives that required cryptographic techniques. These initiatives included:
• Certificate-based 802.1X wireless authentication
• Secure Multipurpose Internet Mail Extensions (S/MIME) for digitally signing and encrypting e-mail
• Encrypting File System (EFS) for file and folder encryption
• Internet Protocol Security (IPsec) for the security of network transactions
• Secure Sockets Layer (SSL) for the security of Web connections
• Smart cards for two-factor remote access authentication
These initiatives required the presence of an enterprise-wide PKI to provide public key–based security services.
Running its own certification authorities (CAs) rather than using commercial, third-party services enabled Microsoft IT to more securely manage the infrastructure and reduce the costs associated with issuing certificates and managing an external CA relationship. Implementing an enterprise PKI enabled Microsoft IT to better secure its network-based communications.
Microsoft IT’s easy-to-manage, standards-based, scalable PKI solution resulted in a method to exchange sensitive data, compatibility with other Microsoft applications, and reduced infrastructure costs.
This white paper describes the deployment and use of the PKI features of Windows server and client products into the production environment at Microsoft. Certificate Services provides customizable services for managing certificates in a PKI infrastructure, such as when creating a CA that receives certificate requests, verifying both the information in the request and the identity of the requester, issuing and revoking certificates, and publishing a Certificate Revocation List (CRL).
Click this link, to read all!
| Architect; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory |
| | A highly secure server peripheral for the management of cryptographic keys and the protection of sensitive applications
With cryptography now a fundamental component of many business-critical processes—authentication, authorization, digital signatures, time-stamping, secure transactions and more—protection of all cryptographic keys as well as the application operations themselves is vital.
That’s why so many organizations around the world have turned to nCipher’s nShield hardware security modules (HSMs) to help them strengthen their security infrastructure.
To read all on Smart Card Deployment at Microsoft, access this White paper:
| Architect; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Windows 2000 introduced the concept of using certificate templates to define the format and content of a certificate. Certificate templates are used by Windows 2000 Enterprise CAs to define what certificates can be issued by the Windows 2000 Enterprise CAs. Associated with the certificate template is a discretionary access control list (DACL) that defines which security principals have permissions to read, enroll, and configure the certificate template. Enterprise CAs are integrated into Active Directory. The certificate templates and the DACLs of the certificate template objects are defined in Active Directory with a forest-wide validity. If more than one Enterprise CA is running in the Windows forest, permission changes would have an impact on all Enterprise CAs.
The certificate templates used by Windows 2000 Enterprise CAs are known as version 1 certificate templates. Windows 2000 shipped with a number of predefined version 1 certificate templates, but modification of these default certificate templates is not allowed. The only modification that is enabled is the changing of permissions to allow enrollment of the certificate template. The version 1 certificate templates are created by default when an Enterprise CA is installed.
Windows Server 2003 extends certificate templates by introducing version 2 templates. Version 2 templates allow customization of most settings in the template. Several preconfigured version 2 templates are supplied in the default configuration and more can be added as necessary. This allows complete configuration flexibility for administrators. Alternatively, a version 1 certificate template can be duplicated, resulting in a version 2 certificate template that can be modified and secured separately.
Note: Similar to Windows 2000, Windows Server 2003 supports only version 1 templates. Windows Server 2003, Enterprise Edition and Windows Server 2003, Datacenter Edition support both version 1 and version 2 templates. Certificates based on version 2 templates can only be issued by an Enterprise CA running Windows Server 2003, Enterprise Edition or Windows Server 2003, Datacenter Edition.
To read all best practices in designing, administering, and implementing version 2 Certificate Templates using Windows Server 2003, Enterprise Edition and Enterprise Certification Authorities (CAs), click this link:
| Architect; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory |
| | To resolve all certificates problems with encryption and signatures with Outlook, Exchange and Certificate Services, click this link:
| Architect; Security Services | Windows Server 2003 | Active Directory |
| | Microsoft Windows Server 2003, Enterprise Edition introduces the capability to automatically enroll users and computers for certificatesincluding smart cardbased certificates.
Using the autoenrollment feature, organizations can manage the certificate lifecycle for users, which includes:
• Certificate renewal
• Superseding of certificates
• Multiple signature requirements
Certificate autoenrollment is based on the combination of Group Policy settings and version 2 certificate templates. This combination allows the Windows XP Professional or Windows Server 2003 client to enroll users when they log on to their domain, or a machine when it boots, and keeps them periodically updated between these events.
Automatic enrollment of user certificates provides a quick and simple way to issue certificates to users and to enable public key infrastructure (PKI) applications, such as smart card logon, Encrypting File System (EFS), Secure Sockets Layer (SSL), Secure/Multipurpose Internet Mail Extension (S/MIME), and others, within an Active Directory directory service environment.
User autoenrollment minimizes the high cost of normal PKI deployments and reduces the total cost of ownership (TCO) for a PKI implementation when Windows XP Professional clients are configured to use Active Directory.
To read the full story, click here!
| Architect; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | A starting point for the descriptions of supported algorithms:
Key Exchange : RSA
Signature : RSA
Encryption : RC2 / RC4 / AES
Hashing : MD5 / SHA
To read all click this link:
- About SHA Secure Hash Algorithm
(SHA) A hashing algorithm that generates a message digest. SHA is used with the Digital Signature Algorithm (DSA) in the Digital Signature Standard (DSS), among other places. CryptoAPI references this algorithm by the algorithm's identifier (CALG_SHA), name (SHA), and class (ALG_CLASS_HASH). There are four varieties of SHA: SHA-1, SHA-256, SHA-384, and SHA-512. SHA-1 generates a 160-bit message digest. SHA-256, SHA-384, and SHA-512 generate 256-bit, 384-bit, and 512-bit message digests, respectively.
- SHA was developed by the National Institute of Standards and Technology (NIST) and by the National Security Agency (NSA).
- Secure Hash Standard
A standard designed by NIST and NSA. This standard defines the Secure Hash Algorithm (SHA-1) for use with the Digital Signature Standard (DSS).
- RC2 block encryption algorithm. Key length: 40 to 88 bits
- RC4 stream encryption algorithm. Key length: 40 to 88 bits
| Architect; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory |
| | Cryptographic keys are central to cryptographic operations. They must be kept secret because whoever possesses a given key has access to any data that the key is associated with.
For example, if a key is used to encrypt a file, anyone with a copy of that key can decrypt the file. Furthermore, anyone possessing a key used to sign messages can forge that message's signature.
There are two types of cryptographic keys:
Session Keys and Public/Private Key Pairs
Public/private key pairs are used for asymmetric encryption. Asymmetric encryption is used mainly to encrypt and decrypt session keys and digital signatures. Asymmetric encryption uses public key encryption algorithms.
Public key algorithms use two different keys: a public key and a private key. The private key member of the pair must be kept private and secure. The public key, however, can be distributed to anyone who requests it. The public key of a key pair is often distributed by means of a digital certificate. When one key of a key pair is used to encrypt a message, the other key from that pair is required to decrypt the message. Thus if user A's public key is used to encrypt data, only user A (or someone who has access to user A's private key) can decrypt the data. If user A's private key is used to encrypt a piece of data, only user A's public key will decrypt the data, thus indicating that user A (or someone with access to user A's private key) did the encryption.
If the private key is used to sign a message, the public key from that pair must be used to validate the signature. For example, if Alice wants to send someone a digitally signed message, she would sign the message with her private key, and the other person could verify her signature by using her public key. Because presumably only Alice has access to her private key, the fact that the signature can be verified with Alice's public key indicates that Alice created the signature.
Unfortunately, public key algorithms are very slow, roughly 1,000 times slower than symmetric algorithms. It is impractical to use them to encrypt large amounts of data. In practice, public key algorithms are used to encrypt session keys.
Symmetric algorithms are used for encryption/decryption of most data.
Similarly, because signing a message in effect encrypts the message, it is not practical to use public key signature algorithms to sign large messages. Instead, a fixed-length hash is made of the message and the hash value is signed. For more details, see Hashes and Digital Signatures.
Each user generally has two public/private key pairs. One key pair is used to encrypt session keys and the other to create digital signatures. These are known as the key exchange key pair and the signature key pair, respectively.
Note that although key containers created by most cryptographic service providers (CSPs) contain two key pairs, this is not required. Some CSPs do not store any key pairs while other CSPs store more than two pairs.
All keys in CryptoAPI are stored within CSPs. CSPs are also responsible for creating the keys, destroying them, and using them to perform a variety of cryptographic operations.
Exporting keys out of the CSP so that they can be sent to other users is discussed in Cryptographic Key Storage and Exchange.
To read all concerning session keys, click this link!
The default CSP and default key length may change between operating system versions. It is important that both the encryption and decryption use the same CSP and that the key length be explicitly set using the dwFlags parameter to ensure interoperability on different operating system platforms.
In particular, the default RSA Full Cryptographic Service Provider is the Microsoft RSA Strong Cryptographic Provider. The default DSS Signature Diffie Hellman Cryptographic Service Provider is the Microsoft Enhanced DSS Diffie Hellman Cryptographic Provider. Each of these CSPs has a default 128-bit symmetric key length for RC2 and RC4 and a 1,024-bit default key length for public key algorithms.
The following table lists minimum, default, and maximum signature and exchange key lengths beginning with Windows XP.
Key type and provider Minimum length Default length Maximum length
RSA Base Provider
Signature and ExchangeKeys 384 512 16,384
RSA Strong and Enhanced Providers
Signature and Exchange Keys 384 1,024 16,384
DSS Base Providers
Signature Keys 512 1,024 1,024
DSS Base Providers
Exchange Keys Not applicable Not applicable Not applicable
DSS/DH Base Providers
Signature Keys 512 1,024 1,024
DSS/DH Base Providers
Exchange Keys 512 512 1,024
DSS/DH Enhanced Providers
Signature Keys 512 1,024 1,024
DSS/DH Enhanced Providers
Exchange Keys 512 1,024 4,096
The following table lists minimum, default, and maximum signature and exchange key lengths through Windows 2000.
Key type and provider Minimum length Default length Maximum length
RSA Base and Strong Providers
Signature Keys 384 512 16,384
RSA Base Provider
Exchange Keys 384 512 1,024
RSA Strong Provider
Exchange Keys 384 512 16,384
RSA Enhanced Provider
Signature and Exchange Keys 384 1,024 16,384
| Architect; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory; EFS |
| | A Cryptographic Service Provider (CSP) contains implementations of cryptographic standards and algorithms. At a minimum, a CSP consists of a dynamic-link library (DLL) that implements the functions in CryptoSPI (a system program interface).
To learn more on CSP inclued in Windows Server 2003, click this link:
| Architect; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory |
| | To secure the Microsoft corporate network, the Microsoft internal Information Technology group—called Microsoft IT—needed to implement multiple technologies and services based on cryptographic techniques.
On this link, you'll know how MS ITG does:
- PKI Deployment Inside Microsoft
- Windows Rights Management Services Deployment at Microsoft
- Desktop Patch Management
- Improve Security at Microsoft through Deployment of Windows XP Service Pack 2
- Improve Security on Domain Isolation with IP Security (IPsec)
- Incident Response-Managing Security at Microsoft
- Messaging Hygiene at Microsoft
- Microsoft Helpdesk Use of Remote Assistance in Windows XP Professional
- Microsoft IT Attack and Penetration Testing Team
- Patch Management for Servers
- Security Enhancements for Remote Access at Microsoft
- Server Security Patch Management at Microsoft
- Smart Card Deployment at Microsoft
- Systems Management Server 2003: Deployment at Microsoft
- Desktop Patch Management at Microsoft
- Systems Management Server 2003: How Microsoft Does Patch Management
All theses documents are available for download here:
| Architect; Plan; Deploy; Top IT Tasks; Case Study; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional | Active Directory |
| | Detailed discussion of how Microsoft IT installed a Public Key Infrastructure, built originally with Windows 2000 Server Certificate Services and later upgraded with Windows Server 2003, to implement a secure communications and remote authentication infrastructure. This enabled the use of S/MIME signatures and encryption, secured Web connections by using SSL or TLS, ensured the confidentiality of stored data by using EFS, ensured the confidentiality and integrity of transmitted date by using IPSec, and enabled strong network user authentication by using Smart Cards.
| Architect; Plan; Deploy; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Although Group Policy is the recommended and easiest method to deploy Windows Firewall settings for computers running Windows XP with SP2, there are situations in which this method is not possible or not used. For example, an environment that uses Windows NT® 4.0 domains or that uses workgroups cannot use Active Directory and Group Policy to propagate Windows Firewall settings to multiple computers on an organization network.
Another example is an organization that uses Active Directory, but does not use Group Policy to centrally configure user or computer configuration settings.
For more information about deploying Windows Firewall settings in your enterprise, please, click this link:
To learn more, download this white paper! This document describes how to deploy the appropriate configuration settings for Windows Firewall on an organization network so that it is enabled and providing protection, and so that needed communications are not impaired.
| Architect; Plan; Deploy; Security Services | Windows Server 2003; WIndows XP Professional | Active Directory |
| | This document provides an overview of the upgrade process and provides information on some of the basic decisions you will make during the process—whether upgrading an existing system, or performing a new installation. This document also provides pointers to the complete set of documents, including Getting Started and the onscreen Help and Support Center that provide detailed instructions on moving from Windows NT Server 4.0 to Windows Server 2003. | Architect; Plan; Deploy | Windows Server 2003; Windows 2000 Server | Active Directory |
| | It is not sufficient to simply put secure systems in place to maintain a truly secure environment. It is a dangerous assumption that either you will not be attacked, or that your defenses will adequately protect you.
To maintain the security of your systems it is also necessary to actively monitor for intrusion and attack.
There are a number of reasons why monitoring and auditing for intrusion are very important.
These include:
• Any functional computer environment is potentially open to attack. No matter how high your level of security, there is a risk that you may be attacked.
• Successful attacks often follow a series of unsuccessful ones. If you do not monitor for attacks you will not detect intruders before they are successful.
• Once a successful attack occurs, the earlier you find out, the easier it will be to contain the damage.
• In order to recover from an attack, you need to know what damage has been done.
• Auditing and intrusion detection helps you determine who was responsible for the attack.
• The combination of auditing and intrusion detection helps correlate information to identify attack patterns.
• Regular review of security logs helps identify unknown security configuration issues, such as incorrect permissions, or lax account lockout settings.
• After an attack is detected, auditing can assist in determining what network resources are compromised.
Objectives
Use this module to:
• Implement auditing in your organization using best practices.
• Protect key log files and prevent attackers from interfering with evidence.
• Combine passive and active detection methods.
• Identify which tools and technologies need to be made available to surveillance and monitoring staff, and how they will be used in the auditing process.
To download the complete solution, clickk this link:
To access all web content, click this link:
| Architect | Windows Server 2003 | Active Directory |
| | The material explains the different requirements to secure three distinct environments, as well as what each prescribed server setting addresses in terms of client dependencies. The three environments considered are called Legacy Client, Enterprise Client, and High Security.
• The Legacy Client settings are designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 98, Windows NT 4.0, and later client computers and member servers.
• The Enterprise Client settings are designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 2000, Windows XP, and later client computers and member servers.
• The High Security settings are also designed to work in an Active Directory domain running on Windows Server 2003 domain controllers with Windows 2000, Windows XP, and later client computers and member servers. However, the High Security settings are so restrictive that many applications may not function, performance of the servers may be noticeably slower, and managing the servers will be more challenging.
See full-sized image.
These levels of hardening guidance are provided for a baseline member server as well as a group of distinct server roles. The documents included as part of this guidance are discussed below.
To download, click this link,
| Architect; Plan; Deploy; Security Services | Windows Server 2003 | Active Directory |
| | Download this to learn more on Windows security and PKI fondamentals. This document is in French.
| Architect; Security Services | Windows Server 2003 | |
| | Intended for system administrators, architects, and others who need to create and manage Group Policy settings, this paper explains Group Policy infrastructure and shows how Group Policy Management Console (GPMC), a new MMC snap-in with scripting interfaces, fits into this infrastructure.
Administrators use Group Policy to specify managed configurations for groups of computers and users. Group Policy includes options for registry-based policy settings, security settings, software installation, scripts, folder redirection, Remote Installation Services, and Internet Explorer maintenance. Intended for system administrators, architects, and others who need to create and manage Group Policy settings, this paper explains Group Policy infrastructure and shows how Group Policy Management Console (GPMC), a new MMC snap-in with scripting interfaces, fits into this infrastructure. The paper includes detailed information about Group Policy processing as well as many best practices useful to the Group Policy administrator.
| Architect | Windows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 Professional | Active Directory |
| | A cool screen saver for security best practices... from MS
| Deploy; Security Services | Windows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 Professional | |
| | Today, Siemens has 417,000 people, 340,000 desktops, and 8,900 servers in 130 business units in 190 countries. A few years ago, Siemens supported its business with 1,000 domains in a highly decentralized structure.
It wanted a single, centralized Active Directory to streamline user management, e-mail, and collaboration. Siemens was also developing an Entitlement Architecture based on a Siemens DirX solution for its corporatewide Identity Management infrastructure.
| Architect; Collaboration; Plan; Case Study | Windows Server 2003 | Active Directory |
| | Please, read this MS link to learn more on Active Directory sizing.
| Architect | Windows Server 2003 | Active Directory |
| | This Microsoft Project 2003 file describes all tasks and actions required to design, plan and deploy the Active Directory Service...
A good starting point to begin the work... | Architect; Plan; Deploy | Windows Server 2003; Windows 2000 Server | Active Directory |
| | Ce document Microsoft en format PDF décrit de manière détaillée toutes les différences qui existent entre Microsoft Windows Server 2003 et Microsoft Windows 2000.
Ce document est particulièrement axé sur les services d'annuaire Active Directory.
| Architect; Plan; Deploy; Support; Top IT Tasks; Case Study; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | This 30-minute multimedia presentation, published January 2004, discusses how Microsoft IT patches its desktop and server environment using Microsoft Systems Management Server (SMS) 2003.
Microsoft IT turned to SMS 2003 to manage the application deployment process, improve hardware and software asset management, and to manage the deployment of security and software updates across the enterprise.
Microsoft IT’s lessons learned and best practices for using SMS 2003 for desktop and server patch management.
This multimedia presentation is intended for enterprise technical decision makers who want to gain a better understanding of the processes and implementation of SMS 2003 for patch management. This multimedia presentation does not include a detailed discussion of the SMS 2003 feature set.
| Architect; Plan; Deploy; Support | Windows Server 2003; Windows 2000 Server; WIndows XP Professional; Windows 2000 Professional | Active Directory |
| | Network Working Group
Request for Comments: 3279
Obsoletes: 2528
Category: Standards Track
W. Polk - NIST
R. Housley - RSA Laboratories
L. Bassham - NIST
April 2002
Algorithms and Identifiers for the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Profile
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
Table of Contents
- 1 Introduction
- 2 Algorithm Support
- 2.1 One-Way Hash Functions
- 2.1.1 MD2 One-Way Hash Functions
- 2.1.2 MD5 One-Way Hash Functions
- 2.1.3 SHA-1 One-Way Hash Functions
- 2.2 Signature Algorithms
- 2.2.1 RSA Signature Algorithm
- 2.2.2 DSA Signature Algorithm
- 2.2.3 Elliptic Curve Digital Signature Algorithm
- 2.3 Subject Public Key Algorithms
- 2.3.1 RSA Keys
- 2.3.2 DSA Signature Keys
- 2.3.3 Diffie-Hellman Key Exchange Keys
- 2.3.4 KEA Public Keys
- 2.3.5 ECDSA and ECDH Public Keys
- 3 ASN.1 Module
- 4 References
- 5 Security Considerations
- 6 Intellectual Property Rights
- 7 Author Addresses
Copyright Notice - Copyright (C) The Internet Society (2002). All Rights reserved.
Click the link bellow to see the full RFC or connect to http://www.rfc-editor.org/ and search in the RFC database 3279
| Architect; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| |
This article provides a Microsoft Exchange 2000 Server deployment case scenario for an imaginary company.
This article guides you through the following six steps of an Exchange deployment:
- Create a detailed deployment plan.
- Begin a successful deployment of Microsoft Windows 2000.
- Prepare Active Directory directory service and Exchange directories.
- Install your first Exchange 2000 server.
- Upgrade the information stores and other Exchange components.
- Switch to Exchange native mode.
The purpose of this article is to provide you with a clear picture of upgrading from Exchange 5.5 to Exchange 2000, which you can use as a basis for your own deployment.
| Architect; Plan; Deploy | Windows Server 2003 | Active Directory |
| | Microsoft® Office Live Communications Server 2003 Standard Edition provides enterprise-ready instant messaging (IM), presence technology, and an extensible platform for connecting people, information and business processes all within a familiar, integrated user experience enabling better and faster decision making.
Live Communications Server 2003 also offers standards-based, managed IM with functionality that includes logging, archiving, file transfer, audio and video conferencing, and application sharing.
Live Communications Server supports:
- SIP - Session Initiation Protocol (SIP)
- SIMPLE - SI for Instant Messaging and Presence Leveraging Extensions (SIMPLE).
All these standards ensure an extensible platform for all real-time communications like:
- Audio and visual communication
- Instant messaging
- Application sharing
- Notifications
- SharePoint sites
- Microsoft Office System programs like Outlook and others
- Remote assistance
- File transfer
- TLS - All server-to-server traffic can be encrypted with Transport Layer Security (TLS)
- Clients have the option of encrypting traffic to the server by using Transport Layer Security (TLS)
- RTP - Real-Time Transfer Protocol encryption is also supported.
- User Authorization through Active Directory with Kerberos V5 and NTLM.
- GPO - Group Policy Object (GPO) via Active Directory to manage bandwidth policies to set maximum limits on how much bandwidth is used in audio, video and file-transfer sessions.
For more information about implementing a centralized, secure and extensible IM solution, go on:
http://www.microsoft.com/office/system/realtime.mspx
http://www.microsoft.com/office/livecomm/prodinfo/default.mspx
| Architect; Collaboration; Instant Messaging; Security Services | Windows Server 2003 | Active Directory |
| | Windows Powered NAS - White Papers are available on this web link:
| Architect; Plan; Deploy | Windows Server 2003; Windows 2000 Server | |
| | The purpose of this guide is to provide a reference to many of the security settings available in the current versions of the Microsoft® Windows® operating systems.
This is a companion guide for The Windows Server 2003 Security Guide, available at http://go.microsoft.com/fwlink/?LinkId=14845 and the Windows XP Security Guide available at http://go.microsoft.com/fwlink/?LinkId=14839.
The chapters of this guide are split up to reflect the major sections that appear in the group policy editing user interface.
Each chapter begins with a brief explanation of what will be covered, followed by a list of subsection headers, each one of these corresponds to a setting or group of settings. Each of these, in turn, has a brief explanation of what the countermeasure does.
While many of the settings available in group policy are documented in this guide, not all of them are. That is because many of the group policy settings are intended to help organizations manage their environments but they aren't necessary directly related to security.
This guide only examines the settings and features available in Microsoft® Windows Server 2003™ and Windows XP® that can help an organization secure their enterprises.
The information provided within this guide should help you and your organization decide which specific countermeasures need to be put in place and how to prioritize that list.
http://www.microsoft.com/technet/treeview/default.asp?url=/technet/security/topics/hardsys/TCG/TCGCH00.asp
Downloads and Resources
Download Threats and Countermeasures: Security Settings in Windows Server 2003 and Windows XP at http://www.microsoft.com/downloads/details.aspx?FamilyId=1B6ACF93-147A-4481-9346-F93A4081EEA8&displaylang=en
Download the Windows Server 2003 Security Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=8A2643C1-0685-4D89-B655-521EA6C7B4DB&displaylang=en
Download the Windows XP Security Guide at http://www.microsoft.com/downloads/details.aspx?FamilyId=2D3E25BC-F434-4CC6-A5A7-09A8A229F118&displaylang=en
| Deploy; Maintain; Support; Security Services | Windows Server 2003; WIndows XP Professional | Active Directory |
| | This guide is designed to provide you with the best information available to assess and counter security risks specific to Microsoft® Windows Server™ 2003 in your environment. The chapters in this guide provide detailed guidance on enhancing security setting configurations and features wherever possible in Windows Server 2003 to address threats identified in your environment.
If you are a consultant, designer, or systems engineer involved in a Windows Server 2003 environment, this guide has been designed with you in mind.
The guidance has been reviewed and approved by Microsoft engineering teams, consultants, support engineers, as well as customers and partners to make it:
Proven — Based on field experience
Authoritative — Offers the best advice available
Accurate — Technically validated and tested
Actionable — Provides the steps to success
Relevant — Addresses real – world security concerns
Working with consultants and systems engineers who have implemented Windows Server 2003, Windows® XP, and Windows® 2000 in a variety of environments has helped establish the latest best practices to secure these servers and clients.
All informations you can need is provided in detail in this guide.
Connect on this link, and download each chapter!
| Deploy; Maintain; Support; Security Services | Windows Server 2003; Windows 2000 Server | Active Directory |
| | This article provides an overview of how the Microsoft® Windows® Server operating system works with Intel® Hyper-Threading technology. It explains the implications for performance, compatibility, and licensing. | Support | Windows Server 2003; Windows 2000 Server | |
| | The Microsoft® Windows Server™ 2003 operating system supports Schannel, an implementation of three protocols (TLS 1.0, SSL 3.0 & SSL 2.0) that provide network security for applications and services. This paper focuses on the Secure Sockets Layer (SSL 3.0) protocol and Transport Layer Security (TLS 1.0) protocol. These protocols offer certificate-based authentication and secure data transfers using symmetric encryption keys. | Top IT Tasks | Windows Server 2003 | |
| | The Microsoft® Windows® Server 2003 family provides change and configuration management solutions with new and enhanced tools that lower total cost of ownership (TCO). This paper provides a technical overview of Microsoft IntelliMirror® management technologies and related management tools and services including command-line management, managing security and software restriction policies, remote installation, Windows Management Instrumentation (WMI), user state migration, Windows Installer, and remote administration. In addition, this paper explains when you should consider other solutions such as Microsoft Systems Management Server (SMS) to meet the demands of more advanced and complex scenarios. | Maintain; Support; Top IT Tasks; Security Services | Windows Server 2003 | |
| | Developing a Certificate Strategy: People, Process and Technology Elements of a PKI | Architect; Security Services | Windows Server 2003 | |
| | A strategic PPT about good practices and technologies used to implement a more secured environnment .... (French)
| Security Services | Windows Server 2003 | |
| | The Federal Information Processing Standards Publication Series of the National Institute of Standards and Technology (NIST) is the official series of publications relating to
standards and guidelines adopted and promulgated under the provisions of Section 5131 of the Information Technology Management Reform Act of 1996 (Public Law 104-106)
and the Computer Security Act of 1987 (Public Law 100-235). These mandates have given the Secretary of Commerce and NIST important responsibilities for improving the utilization and management of computer and related telecommunications systems in the Federal government. The NIST, through its Information Technology Laboratory, provides leadership, technical guidance, and coordination of government efforts in the development of standards and guidelines in these areas. | Security Services | Windows Server 2003; WIndows XP Professional | |
| | A good presentation to download quickly!
Made by
- UK National Infrastructure Security Co-ordination Centre (NISCC), an interdepartmental organisation set up to co-ordinate and develop existing work within Government departments and agencies and organisations in the private sector to defend against electronic attack.
http://www.niscc.gov.uk
- The US Department of Homeland Security
- SANS Institute : http://www.sans.org
| Architect; Plan; Maintain; Top IT Tasks | Windows Server 2003 | |
| | REDMOND, Wash., Sept. 15, 2003 -- Now more than ever, businesses are looking for substantive data to help them quantify IT costs and determine the overall value of their IT investments in an effort to watch their bottom line. This concern has raised questions about software alternatives to Microsoft. To help address customers' questions about performance and cost when comparing Microsoft products to Linux-based offerings, and to give them third-party comparative data, Microsoft commissioned two new pieces of research.
Microsoft asked Giga Research, now a wholly owned subsidiary of Forrester Research Inc., to run a detailed, objective comparison and analysis of portal application development and deployment for .NET on Microsoft Windows and J2EE on Linux for medium and large-sized companies. Microsoft also commissioned an independent third-party performance benchmark, audited by Meta Group, to compare server consolidation using Microsoft Windows Server 2003 versus a Linux-based IBM mainframe. (See links to both studies at right.)
Giga's findings indicate that, as a portal application development platform, running .NET on Windows offers substantial cost savings over Linux and the J2EE development environment -- as much as 25 to 28 percent less over a four-year period. Additionally, the IBM/Linux benchmark indicates that an Intel server running Windows Server 2003 performs significantly better -- 20 to 300 percent better -- than an IBM zSeries 900 mainframe running Linux.
PressPass spoke with Martin Taylor, Microsoft's general manager of platform strategy, about the studies and the significance of the findings for customers, and with John Rymer, vice president at Forrester Research, regarding the methodology of Forrester's cost-comparison study.
| Plan; Case Study | Windows Server 2003 | Windows Storage; EFS; MSCS |
| | by Dave Sayers, Senior Consultant at Windows Team - Microsoft Services Organisation | Architect; Plan; Deploy | Windows Server 2003; Windows 2000 Server | Active Directory; DNS |
| | As both the rate of growth and the installed base of Microsoft® Windows Server™ operating systems increases, managing the deployment and administration of these systems becomes a significant driver of the overall cost of ownership.
Today automated operating system and application deployment technologies are typically script-based or rely on traditional imaging and deployment tools from third-party vendors. Script-based installation solutions provide flexibility across a wide range of hardware configurations but tend to be very slow, and few standard methodologies exist for them. Traditional imaging technologies, although much faster, are inflexible and require considerable effort to adapt and maintain an image collection over both hardware variations and time.
Script-based administration of a large number of Windows® servers traditionally has not been easy. Unlike in the UNIX environment, in which operators can use tools such as rsh, ssh, and rdist to perform remote administration on groups of servers, script-based administration in the Windows Server environment has required operators to deal with each server individually.
With Microsoft Windows Server 2003, Microsoft extends the platform to enable rapid, flexible deployment and seamless, script-based administration of a large number of Windows servers.
| Architect; Plan; Deploy | Windows Server 2003 | |
| | This whitepaper provides a fast recovery demonstration designed to enable system administrators to implement fast recovery solutions in their own Active Directory environments. | Plan; Support; Top IT Tasks | Windows Server 2003 | |
| | Businesses of all sizes are seeking cost effective storage management solutions that keep critical data protected and highly available. This white paper outlines the major storage challenges facing today's businesses, and shows how the integrated storage services in Microsoft Windows Server™ 2003 and Microsoft Windows Storage Server 2003 provide manageable, reliable, and cost effective solutions designed to meet those challenges.
| Deploy; Case Study | Windows Server 2003 | |
| | This white paper describes how to configure Internet Protocol version 6 (IPv6) in a test lab using five computers. Of the five computers, one is a DNS server, two are clients, and two are routers. This white paper also includes an exercise that severs network connectivity between intranets and then uses Intra-Site Automatic Tunnel Addressing Protocol (ISATAP) to restore communication. | Architect; Plan; Deploy; Support | Windows Server 2003 | |
| | This document explains the approach used to implement the Microsoft Windows Server 2003 embedded Windows Media Services solution to offer real-time video streaming to ETSI (the European Telecommunications Standards Institute)corporate users and external partners. This document presents strategic choices and related methodology to deploy the solution and take benefits of new performance, security, monitoring and logging features of the 9.0 version. | Architect; Plan; Deploy; Case Study | Windows Server 2003 | |