Saturday, May 2, 2009
Windows Server 2008 Reviewers Guide
The Windows Server 2008 Reviewers Guide provides a comprehensive technical overview of the innovative features and functions that make Windows Server 2008 the next-generation Microsoft Windows Server operating system and successor to Microsoft Windows Server 2003. This guide also provides information about the benefits Windows Server 2008 offers diverse users, as well as information about different scenarios.This document supports the release of Windows Server 2008.
Windows Server 2008 is upgrade IT can't refuse
As Windows Server 2008, formerly code-named Longhorn, makes its final way out of Microsoft's corral this week, our Test Center inspected the beast and was surprised."You who have followed Tom [Yager's] somewhat tepid Longhorn coverage may be shocked to discover that his in-depth review of Windows Server 2008 holds the new OS in high esteem," editor-in-chief Eric Knorr points out, in A long, long look at Windows Server 2008.Thanks in no small part to a smaller resource footprint that brings a host of capabilities, including virtualization, enhanced security and better networking, Microsoft’s 64-bit OS, Windows Server 2008, is what Tom Yager calls an upgrade that IT can't refuse."Microsoft has executed Windows Server 2008 in a way that makes commercial Linux far less appealing," Yager explains in Product review: Windows Server 2008 is the host with the most and the perfect guest. "In those places where Linux might be seen as a good fit for its performance and small footprint, any Windows Server 2008 SKU ... all but slams the door shut on Linux in a Windows shop."While Longhorn's features are already known to the public, Sean McCown shares Secrets of Windows Server 2008, those being what you need to know now, as well as "the actual impact that Longhorn will have on your organization." These include restartable ActiveDirectory Domain Services, NTFS enhancements, Server Core, Read-only domain controllers, and the list goes on.
Download Microsoft Hyper-V Server 2008 R2 Beta
Microsoft® Hyper-V™ Server 2008 R2 is a stand-alone product that provides a reliable and optimized virtualization solution enabling organizations to improve server utilization and reduce costs. With the addition of new features such as live migration and expanded processor and memory support for host systems, it allows organizations to consolidate workloads onto a single physical server and is a good solution for organizations who are consolidating servers as well as for development and test environments.By having the ability to plug into existing IT infrastructures Microsoft Hyper-V Server 2008 R2 enables companies to reduce costs, improve utilization and provision new servers. It allows IT professionals to leverage existing patching, provisioning, management and support tools and processes. IT Professionals can continue to leverage their individual skills and the collective knowledge of Microsoft tools, minimizing the learning curve to manage Microsoft Hyper-V Server 2008 R2. In addition, with Microsoft providing comprehensive support for Microsoft applications and heterogeneous guest operating systems support, customers can virtualize with confidence and peace of mind.Note: This is a pre-release version of Microsoft® Hyper-V™ Server 2008 R2 and not intended to be used in a production environment.
7 STEPS TO A SECURE WIRELESS NETWORKS
Although all wireless equipment marked as 802.11 will have standard features such as encryption and access control each manufacturer has a different way it is controlled or accessed. This means that the advice that follows may seem a bit technical because we can only tell you what you have to do not how to do it. You should read the manual or help files that came with your equipment in order to see how to make a secure wireless network.
1. Use encryption. This is the bedrock of any secure wireless network and means that the data that passes over the wireless can only be decoded with the correct system of encryption and the correct password. Currently there are three methods of encryption for wireless networks usually referred to by their acronyms: WPA2, WPA-PSK and WEP. Each method can only be used if all the equipment on the network has the capability. As WPA2 is the most recent method of encryption, unless you have recently obtained the latest PCs, laptops & network device you probably will not be able to use it. WPA-PSK is the next best and is available on most hardware. If you are using older access points and network cards, you may find that you can only use WEP. Each method requires a “key” (a word or phrase used to make the encryption work). Make sure you use a word or phrase that would not be easily guessed. For example, don’t use your address as the key.
2. Set up your network infrastructure as “access point” and not “ad-hoc” or “peer to peer”. These last two (ad-hoc and peer-to-peer) mean that network devices such as PCs and laptops can connect directly with each other without going through an access point. You have more control over how devices connect if you set the infrastructure to “access point” and so will make for a more secure wireless network.
3. choose an obscure name for the network - This important tip to having a secure wireless network is probably not used by about 99% of home users. The technical term for the name of the wireless network is “SSID”. The default SSID is usually the name and model of the wireless router or Internet provider e.g. NetgearDG834G or Sky9091. If you leave the SSID like this it makes hacking very easy so change the SSID as soon as you set up your network. Don’t use your address, house name or family name these are too easy to guess.4. Switch off the SSID broadcast. This tip goes hand in hand with No3 in creating a secure wireless network. This means that anyone wishing to connect to your wireless network must know its SSID i.e. the name of the network.
5. Change the name and password of the administration user for the wireless router but don’t forget to make a note of what you change it to. A secure wireless network will have an admin user ID that is difficult to guess and a strong password that uses letter and numbers.
6. Unplug the wireless router whenever you are going to be away from home (or the office). It’s also a good idea to set the time that the network can be used if the device allows it. For example, in an office you may not want to unplug the wireless router at the end of every day so you could set it to only allow connections between the hours of 7:30 AM and 7:30 PM.
7. Use MAC filtering If your wireless router or access point allows it, MAC filtering easily adds one more layer to make your wireless network secure. Every network card (the device installed in PCs and laptops that connect it to a network) has its own unique code, called a “MAC address”. In Windows XP you can see the MAC address by right-clicking on the network connection, choose “status” and then the “support” tab. In the support window click on “details”. The code labeled “physical address” is the MAC code for that network connection device. Make sure it’s the wireless network connection you select as the LAN connection will have a different MAC address. Most wireless routers or access points allow you to list the MAC codes that you wish to use the network. This means that you must grant permission to any PC or laptop that wants to connect to the network.
If you can put all seven of these tips in operation you will have a very secure wireless network
1. Use encryption. This is the bedrock of any secure wireless network and means that the data that passes over the wireless can only be decoded with the correct system of encryption and the correct password. Currently there are three methods of encryption for wireless networks usually referred to by their acronyms: WPA2, WPA-PSK and WEP. Each method can only be used if all the equipment on the network has the capability. As WPA2 is the most recent method of encryption, unless you have recently obtained the latest PCs, laptops & network device you probably will not be able to use it. WPA-PSK is the next best and is available on most hardware. If you are using older access points and network cards, you may find that you can only use WEP. Each method requires a “key” (a word or phrase used to make the encryption work). Make sure you use a word or phrase that would not be easily guessed. For example, don’t use your address as the key.
2. Set up your network infrastructure as “access point” and not “ad-hoc” or “peer to peer”. These last two (ad-hoc and peer-to-peer) mean that network devices such as PCs and laptops can connect directly with each other without going through an access point. You have more control over how devices connect if you set the infrastructure to “access point” and so will make for a more secure wireless network.
3. choose an obscure name for the network - This important tip to having a secure wireless network is probably not used by about 99% of home users. The technical term for the name of the wireless network is “SSID”. The default SSID is usually the name and model of the wireless router or Internet provider e.g. NetgearDG834G or Sky9091. If you leave the SSID like this it makes hacking very easy so change the SSID as soon as you set up your network. Don’t use your address, house name or family name these are too easy to guess.4. Switch off the SSID broadcast. This tip goes hand in hand with No3 in creating a secure wireless network. This means that anyone wishing to connect to your wireless network must know its SSID i.e. the name of the network.
5. Change the name and password of the administration user for the wireless router but don’t forget to make a note of what you change it to. A secure wireless network will have an admin user ID that is difficult to guess and a strong password that uses letter and numbers.
6. Unplug the wireless router whenever you are going to be away from home (or the office). It’s also a good idea to set the time that the network can be used if the device allows it. For example, in an office you may not want to unplug the wireless router at the end of every day so you could set it to only allow connections between the hours of 7:30 AM and 7:30 PM.
7. Use MAC filtering If your wireless router or access point allows it, MAC filtering easily adds one more layer to make your wireless network secure. Every network card (the device installed in PCs and laptops that connect it to a network) has its own unique code, called a “MAC address”. In Windows XP you can see the MAC address by right-clicking on the network connection, choose “status” and then the “support” tab. In the support window click on “details”. The code labeled “physical address” is the MAC code for that network connection device. Make sure it’s the wireless network connection you select as the LAN connection will have a different MAC address. Most wireless routers or access points allow you to list the MAC codes that you wish to use the network. This means that you must grant permission to any PC or laptop that wants to connect to the network.
If you can put all seven of these tips in operation you will have a very secure wireless network
Tuesday, April 14, 2009
5 rules to protect your laptop
Business laptops are a treasure for every hacker or corporate spy. The average corporate laptop is full of business email, confidential documents and more often then not, the user of the laptop has the same passwords on the laptop as on his corporate application and e-mail.Here is a truly bizarre example of what could happen: Lifetime of FREE BEER for LaptopPrivate laptops are also very interesting (especially those of celebrities)And yet, the security awareness of the owners of laptops is somewhat lacking. So here are 5 simple rules that can help you keep your laptop safe:
1. Do not leave a laptop unattended in areas accessible by the general public - Leaving a laptop anywhere where it can be seen and picked up by another person is a very bad idea. This includes the table in your favorite cafe, the company cafeteria, airport lounge or waiting room, even an unlocked office where there is a possibility for an untrusted person to walk in.
2. If you must leave your laptop, secure it - In the unlikely case where you must leave your laptop, make sure it is very difficult for someone to steal it. Either place it in a cabinet (preferably locked) or use a Kensington Lock to bind your laptop to something difficult to move (office furniture, central heating pipes).
3. Carry your laptop in an inconspicuous bag - Avoid manufacturer branded laptop cases, since they scream "there is a laptop in here". Simply, invest $30-$40 in a simple unmarked document bag which has a laptop compartment. NOTE O NOT go overboard and buy a designer bag costing as much as the laptop, since then the bag itself will be a target for theft.
4. Do not leave a laptop in a visible place in your car - A lot of petty criminals can see an excellent opportunity to steal any kind of bag left on a seat of a parked vehicle. Ideally, never leave your laptop in the car. If it must be left, place it in the trunk of the car, and check that you have locked the car and fully closed all windows.
5. Encrypt the entire hard drive - if all else fails, the value of the information within the laptop is usually much greater then the value of the hardware. Encrypting the entire hard drive will make much more difficult for the thief to extract the valuable information, and can prolong the extraction time to a point when the extracted information will be useless. Encrypting the entire hard drive will cause performance reduction of the disk subsystem, but this is always acceptable when compared to the protection it offers, even for home users. There are several products which can perform full drive encryption like Windows Vista BitLocker, a free TrueCrypt software, and several commercial add-on packages.
NOTE: Do not try encrypting only part of the hard drive or certain files. This will not add too much security, since the attacker has an entire computer full of data to search for clues to your decryption password.
sudheer.garikipati
Thursday, February 26, 2009
Windows 2008 - Read Only Domain Controlers
AD DS: Read-Only Domain Controllers
A read-only domain controller (RODC) is a new type of domain controller in the Windows Server® 2008 operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts read-only partitions of the Active Directory® Domain Services (AD DS) database.
Before the release of Windows Server 2008, if users had to authenticate with a domain controller over a wide area network (WAN), there was no real alternative. In many cases, this was not an efficient solution. Branch offices often cannot provide the adequate physical security that is required for a writable domain controller. Furthermore, branch offices often have poor network bandwidth when they are connected to a hub site. This can increase the amount of time that is required to log on. It can also hamper access to network resources.
Beginning with Windows Server 2008, an organization can deploy an RODC to address these problems. As a result, users in this situation can receive the following benefits:
Improved security
Faster logon times
More efficient access to resources on the network
What does an RODC do?
Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a way to deploy a domain controller more securely in locations that require fast and reliable authentication services but cannot ensure physical security for a writable domain controller.
However, your organization may also choose to deploy an RODC for special administrative requirements. For example, a line-of-business (LOB) application may run successfully only if it is installed on a domain controller. Or, the domain controller might be the only server in the branch office, and it may have to host server applications.
In such cases, the LOB application owner must often log on to the domain controller interactively or use Terminal Services to configure and manage the application. This situation creates a security risk that may be unacceptable on a writable domain controller.
An RODC provides a more secure mechanism for deploying a domain controller in this scenario. You can grant a nonadministrative domain user the right to log on to an RODC while minimizing the security risk to the Active Directory forest.
You might also deploy an RODC in other scenarios where local storage of all domain user passwords is a primary threat, for example, in an extranet or application-facing role.
Who will be interested in this feature?
RODC is designed primarily to be deployed in remote or branch office environments. Branch offices typically have the following characteristics:
Relatively few users
Poor physical security
Relatively poor network bandwidth to a hub site
Little knowledge of information technology (IT)
You should review this section, and the additional supporting documentation about RODC, if you are in any of the following groups:
IT planners and analysts who are technically evaluating the product
Enterprise IT planners and designers for organizations
Those responsible for IT security
AD DS administrators who deal with small branch offices
Are there any special considerations?
To deploy an RODC, at least one writable domain controller in the domain must be running Windows Server 2008. In addition, the functional level for the domain and forest must be Windows Server 2003 or higher.
For more information about prerequisites for deploying an RODC, see How should I prepare to deploy this feature?
What new functionality does this feature provide?
RODC addresses some of the problems that are commonly found in branch offices. These locations might not have a domain controller. Or, they might have a writable domain controller but not the physical security, network bandwidth, or local expertise to support it. The following RODC functionality mitigates these problems:
Read-only AD DS database
Unidirectional replication
Credential caching
Administrator role separation
Read-only Domain Name System (DNS)
Read-only AD DS database
Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.
Local applications that request Read access to the directory can obtain access. Lightweight Directory Application Protocol (LDAP) applications that request Write access receive an LDAP referral response. This response directs them to a writable domain controller, normally in a hub site.
RODC filtered attribute set
Some applications that use AD DS as a data store might have credential-like data (such as passwords, credentials, or encryption keys) that you do not want to be stored on an RODC in case the RODC is compromised.
For these types of applications, you can dynamically configure a set of attributes in the schema for domain objects that will not replicate to an RODC. This set of attributes is called the RODC filtered attribute set. Attributes that are defined in the RODC filtered attribute set are not allowed to replicate to any RODCs in the forest.
A malicious user who compromises an RODC can attempt to configure it in such a way that it tries to replicate attributes that are defined in the RODC filtered attribute set. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request can succeed.
Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan to configure the RODC filtered attribute set. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.
You cannot add system-critical attributes to the RODC filtered attribute set. An attribute is system-critical if it is required for AD DS; Local Security Authority (LSA); Security Accounts Manager (SAM; and Microsoft-specific Security Service Provider Interfaces (SSPIs), such as Kerberos; to function properly. A system-critical attribute has a schemaFlagsEx attribute value equal to 1 (schemaFlagsEx attribute value & 0x1 = TRUE).
The RODC filtered attribute set is configured on the server that holds the schema operations master role. If you try to add a system-critical attribute to the RODC filtered set while the schema master is running Windows Server 2008, the server returns an "unwillingToPerform" LDAP error. If you try to add a system-critical attribute to the RODC filtered attribute set on a Windows Server 2003 schema master, the operation appears to succeed but the attribute is not actually added. Therefore, it is recommended that the schema master be a Windows Server 2008 domain controller when you add attributes to RODC filtered attribute set. This ensures that system-critical attributes are not included in the RODC filtered attribute set.
Unidirectional replication
Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make at branch locations cannot replicate from the RODC to the rest of the forest. This also reduces the workload of bridgehead servers in the hub and the effort required to monitor replication.
RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. The RODC performs normal inbound replication for AD DS and SYSVOL changes.
Any other shares on an RODC that you configure to replicate using DFS Replication would be bidirectional.
Credential caching
Credential caching is the storage of user or computer credentials. Credentials consist of a small set of approximately 10 passwords that are associated with security principals. By default, an RODC does not store user or computer credentials. The exceptions are the computer account of the RODC and a special krbtgt account that each RODC has. You must explicitly allow any other credential caching on an RODC.
The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests.
After an account is successfully authenticated, the RODC attempts to contact a writable domain controller at the hub site and requests a copy of the appropriate credentials. The writable domain controller recognizes that the request is coming from an RODC and consults the Password Replication Policy in effect for that RODC.
The Password Replication Policy determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC. If the Password Replication Policy allows it, the writable domain controller replicates the credentials to the RODC, and the RODC caches them.
After the credentials are cached on the RODC, the RODC can directly service that user's logon requests until the credentials change. (When a TGT is signed with the krbtgt account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.)
By limiting credential caching only to users who have authenticated to the RODC, the potential exposure of credentials by a compromise of the RODC is also limited. Typically, only a small subset of domain users has credentials cached on any given RODC. Therefore, in the event that the RODC is stolen, only those credentials that are cached can potentially be cracked.
Leaving credential caching disabled might further limit exposure, but it results in all authentication requests being forwarded to a writable domain controller. An administrator can modify the default Password Replication Policy to allow users' credentials to be cached at the RODC.
Administrator role separation
You can delegate local administrative permissions for an RODC to any domain user without granting that user any user rights for the domain or other domain controllers. This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver. However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain. In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain.
Read-only DNS
You can install the DNS Server service on an RODC. An RODC is able to replicate all application directory partitions that DNS uses, including ForestDNSZones and DomainDNSZones. If the DNS server is installed on an RODC, clients can query it for name resolution as they query any other DNS server.
However, the DNS server on an RODC is read-only and therefore does not support client updates directly. For more information about how DNS client updates are processed by a DNS server on an RODC, see DNS updates for clients that are located in an RODC site.
What settings have been added or changed?
To support the RODC Password Replication Policy, Windows Server 2008 AD DS includes new attributes. The Password Replication Policy is the mechanism for determining whether a user's credentials or a computer's credentials are allowed to replicate from a writable domain controller to an RODC. The Password Replication Policy is always set on a writable domain controller running Windows Server 2008.
AD DS attributes that are added in the Windows Server 2008 Active Directory schema to support RODCs include the following:
msDS-Reveal-OnDemandGroup
msDS-NeverRevealGroup
msDS-RevealedList
msDS-AuthenticatedToAccountList
For more information about these attributes, see the Step-by-Step Guide for Planning, Deploying, and Using a Windows Server 2008 Read-Only Domain Controller (http://go.microsoft.com/fwlink/?LinkId=87001).
How should I prepare to deploy this feature?
The prerequisites for deploying an RODC are as follows:
The RODC must forward authentication requests to a writable domain controller running Windows Server 2008. The Password Replication Policy is set on this domain controller to determine if credentials are replicated to the branch location for a forwarded request from the RODC.
The domain functional level must be Windows Server 2003 or higher so that Kerberos constrained delegation is available. Constrained delegation is used for security calls that must be impersonated under the context of the caller.
The forest functional level must be Windows Server 2003 or higher so that linked-value replication is available. This provides a higher level of replication consistency.
You must run adprep /rodcprep once in the forest to update the permissions on all the DNS application directory partitions in the forest. This way, all RODCs that are also DNS servers can replicate the permissions successfully.
A read-only domain controller (RODC) is a new type of domain controller in the Windows Server® 2008 operating system. With an RODC, organizations can easily deploy a domain controller in locations where physical security cannot be guaranteed. An RODC hosts read-only partitions of the Active Directory® Domain Services (AD DS) database.
Before the release of Windows Server 2008, if users had to authenticate with a domain controller over a wide area network (WAN), there was no real alternative. In many cases, this was not an efficient solution. Branch offices often cannot provide the adequate physical security that is required for a writable domain controller. Furthermore, branch offices often have poor network bandwidth when they are connected to a hub site. This can increase the amount of time that is required to log on. It can also hamper access to network resources.
Beginning with Windows Server 2008, an organization can deploy an RODC to address these problems. As a result, users in this situation can receive the following benefits:
Improved security
Faster logon times
More efficient access to resources on the network
What does an RODC do?
Inadequate physical security is the most common reason to consider deploying an RODC. An RODC provides a way to deploy a domain controller more securely in locations that require fast and reliable authentication services but cannot ensure physical security for a writable domain controller.
However, your organization may also choose to deploy an RODC for special administrative requirements. For example, a line-of-business (LOB) application may run successfully only if it is installed on a domain controller. Or, the domain controller might be the only server in the branch office, and it may have to host server applications.
In such cases, the LOB application owner must often log on to the domain controller interactively or use Terminal Services to configure and manage the application. This situation creates a security risk that may be unacceptable on a writable domain controller.
An RODC provides a more secure mechanism for deploying a domain controller in this scenario. You can grant a nonadministrative domain user the right to log on to an RODC while minimizing the security risk to the Active Directory forest.
You might also deploy an RODC in other scenarios where local storage of all domain user passwords is a primary threat, for example, in an extranet or application-facing role.
Who will be interested in this feature?
RODC is designed primarily to be deployed in remote or branch office environments. Branch offices typically have the following characteristics:
Relatively few users
Poor physical security
Relatively poor network bandwidth to a hub site
Little knowledge of information technology (IT)
You should review this section, and the additional supporting documentation about RODC, if you are in any of the following groups:
IT planners and analysts who are technically evaluating the product
Enterprise IT planners and designers for organizations
Those responsible for IT security
AD DS administrators who deal with small branch offices
Are there any special considerations?
To deploy an RODC, at least one writable domain controller in the domain must be running Windows Server 2008. In addition, the functional level for the domain and forest must be Windows Server 2003 or higher.
For more information about prerequisites for deploying an RODC, see How should I prepare to deploy this feature?
What new functionality does this feature provide?
RODC addresses some of the problems that are commonly found in branch offices. These locations might not have a domain controller. Or, they might have a writable domain controller but not the physical security, network bandwidth, or local expertise to support it. The following RODC functionality mitigates these problems:
Read-only AD DS database
Unidirectional replication
Credential caching
Administrator role separation
Read-only Domain Name System (DNS)
Read-only AD DS database
Except for account passwords, an RODC holds all the Active Directory objects and attributes that a writable domain controller holds. However, changes cannot be made to the database that is stored on the RODC. Changes must be made on a writable domain controller and then replicated back to the RODC.
Local applications that request Read access to the directory can obtain access. Lightweight Directory Application Protocol (LDAP) applications that request Write access receive an LDAP referral response. This response directs them to a writable domain controller, normally in a hub site.
RODC filtered attribute set
Some applications that use AD DS as a data store might have credential-like data (such as passwords, credentials, or encryption keys) that you do not want to be stored on an RODC in case the RODC is compromised.
For these types of applications, you can dynamically configure a set of attributes in the schema for domain objects that will not replicate to an RODC. This set of attributes is called the RODC filtered attribute set. Attributes that are defined in the RODC filtered attribute set are not allowed to replicate to any RODCs in the forest.
A malicious user who compromises an RODC can attempt to configure it in such a way that it tries to replicate attributes that are defined in the RODC filtered attribute set. If the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2008, the replication request is denied. However, if the RODC tries to replicate those attributes from a domain controller that is running Windows Server 2003, the replication request can succeed.
Therefore, as a security precaution, ensure that forest functional level is Windows Server 2008 if you plan to configure the RODC filtered attribute set. When the forest functional level is Windows Server 2008, an RODC that is compromised cannot be exploited in this manner because domain controllers that are running Windows Server 2003 are not allowed in the forest.
You cannot add system-critical attributes to the RODC filtered attribute set. An attribute is system-critical if it is required for AD DS; Local Security Authority (LSA); Security Accounts Manager (SAM; and Microsoft-specific Security Service Provider Interfaces (SSPIs), such as Kerberos; to function properly. A system-critical attribute has a schemaFlagsEx attribute value equal to 1 (schemaFlagsEx attribute value & 0x1 = TRUE).
The RODC filtered attribute set is configured on the server that holds the schema operations master role. If you try to add a system-critical attribute to the RODC filtered set while the schema master is running Windows Server 2008, the server returns an "unwillingToPerform" LDAP error. If you try to add a system-critical attribute to the RODC filtered attribute set on a Windows Server 2003 schema master, the operation appears to succeed but the attribute is not actually added. Therefore, it is recommended that the schema master be a Windows Server 2008 domain controller when you add attributes to RODC filtered attribute set. This ensures that system-critical attributes are not included in the RODC filtered attribute set.
Unidirectional replication
Because no changes are written directly to the RODC, no changes originate at the RODC. Accordingly, writable domain controllers that are replication partners do not have to pull changes from the RODC. This means that any changes or corruption that a malicious user might make at branch locations cannot replicate from the RODC to the rest of the forest. This also reduces the workload of bridgehead servers in the hub and the effort required to monitor replication.
RODC unidirectional replication applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. The RODC performs normal inbound replication for AD DS and SYSVOL changes.
Any other shares on an RODC that you configure to replicate using DFS Replication would be bidirectional.
Credential caching
Credential caching is the storage of user or computer credentials. Credentials consist of a small set of approximately 10 passwords that are associated with security principals. By default, an RODC does not store user or computer credentials. The exceptions are the computer account of the RODC and a special krbtgt account that each RODC has. You must explicitly allow any other credential caching on an RODC.
The RODC is advertised as the Key Distribution Center (KDC) for the branch office. The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests.
After an account is successfully authenticated, the RODC attempts to contact a writable domain controller at the hub site and requests a copy of the appropriate credentials. The writable domain controller recognizes that the request is coming from an RODC and consults the Password Replication Policy in effect for that RODC.
The Password Replication Policy determines if a user's credentials or a computer's credentials can be replicated from the writable domain controller to the RODC. If the Password Replication Policy allows it, the writable domain controller replicates the credentials to the RODC, and the RODC caches them.
After the credentials are cached on the RODC, the RODC can directly service that user's logon requests until the credentials change. (When a TGT is signed with the krbtgt account of the RODC, the RODC recognizes that it has a cached copy of the credentials. If another domain controller signs the TGT, the RODC forwards requests to a writable domain controller.)
By limiting credential caching only to users who have authenticated to the RODC, the potential exposure of credentials by a compromise of the RODC is also limited. Typically, only a small subset of domain users has credentials cached on any given RODC. Therefore, in the event that the RODC is stolen, only those credentials that are cached can potentially be cracked.
Leaving credential caching disabled might further limit exposure, but it results in all authentication requests being forwarded to a writable domain controller. An administrator can modify the default Password Replication Policy to allow users' credentials to be cached at the RODC.
Administrator role separation
You can delegate local administrative permissions for an RODC to any domain user without granting that user any user rights for the domain or other domain controllers. This permits a local branch user to log on to an RODC and perform maintenance work on the server, such as upgrading a driver. However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain. In this way, the branch user can be delegated the ability to effectively manage the RODC in the branch office without compromising the security of the rest of the domain.
Read-only DNS
You can install the DNS Server service on an RODC. An RODC is able to replicate all application directory partitions that DNS uses, including ForestDNSZones and DomainDNSZones. If the DNS server is installed on an RODC, clients can query it for name resolution as they query any other DNS server.
However, the DNS server on an RODC is read-only and therefore does not support client updates directly. For more information about how DNS client updates are processed by a DNS server on an RODC, see DNS updates for clients that are located in an RODC site.
What settings have been added or changed?
To support the RODC Password Replication Policy, Windows Server 2008 AD DS includes new attributes. The Password Replication Policy is the mechanism for determining whether a user's credentials or a computer's credentials are allowed to replicate from a writable domain controller to an RODC. The Password Replication Policy is always set on a writable domain controller running Windows Server 2008.
AD DS attributes that are added in the Windows Server 2008 Active Directory schema to support RODCs include the following:
msDS-Reveal-OnDemandGroup
msDS-NeverRevealGroup
msDS-RevealedList
msDS-AuthenticatedToAccountList
For more information about these attributes, see the Step-by-Step Guide for Planning, Deploying, and Using a Windows Server 2008 Read-Only Domain Controller (http://go.microsoft.com/fwlink/?LinkId=87001).
How should I prepare to deploy this feature?
The prerequisites for deploying an RODC are as follows:
The RODC must forward authentication requests to a writable domain controller running Windows Server 2008. The Password Replication Policy is set on this domain controller to determine if credentials are replicated to the branch location for a forwarded request from the RODC.
The domain functional level must be Windows Server 2003 or higher so that Kerberos constrained delegation is available. Constrained delegation is used for security calls that must be impersonated under the context of the caller.
The forest functional level must be Windows Server 2003 or higher so that linked-value replication is available. This provides a higher level of replication consistency.
You must run adprep /rodcprep once in the forest to update the permissions on all the DNS application directory partitions in the forest. This way, all RODCs that are also DNS servers can replicate the permissions successfully.
Subscribe to:
Posts (Atom)
