Студопедия

Главная страница Случайная страница

КАТЕГОРИИ:

АвтомобилиАстрономияБиологияГеографияДом и садДругие языкиДругоеИнформатикаИсторияКультураЛитератураЛогикаМатематикаМедицинаМеталлургияМеханикаОбразованиеОхрана трудаПедагогикаПолитикаПравоПсихологияРелигияРиторикаСоциологияСпортСтроительствоТехнологияТуризмФизикаФилософияФинансыХимияЧерчениеЭкологияЭкономикаЭлектроника






Planning for RODCs in the perimeter network






Because RODCs are a new feature in Windows Server 2008, the rest of this document describes the AD DS perimeter network models that use RODCs. To gain the full benefits of using RODCs and to mitigate any negative impacts to the perimeter network, an understanding of the features and constraints of RODCs is necessary.

From a security perspective, RODCs should be thought about as one piece of a larger IT strategy to reduce the attack surface of a perimeter network. Compared to writeable domain controllers, RODCs provide the direct security benefit of having a smaller attack surface. The specific security boundaries of RODCs are described in the Read-Only Domain Controller Planning and Deployment Guide (https://go.microsoft.com/fwlink/? LinkID=135993).

An indirect benefit of RODCs is apparent when an IT architect or engineer examines the perimeter network as a part of the entire network. For example, consider an organization that provides a service that it sells to consumers and that it hosts in the perimeter network. This organization uses an application-specific account store and authentication mechanism (for example, Microsoft SQL Server® or Active Directory Lightweight Directory Services (AD LDS)). The organization decides to make the service available to its internal employees who register accounts with the service. The security engineer decides to audit the passwords of the employee accounts that are registered with the service and discovers that some employees used the same password for the service as they used to log on to the corporate network.

From a top-down security perspective, there is no actual trust relationship between the corporate logon accounts and the service accounts. However, in practical terms, if a sophisticated attacker takes over the service and has unfettered access to the account store that the service uses, that attacker can then use those passwords to gain access to the corporate network through remote access technologies or by gaining access to the physical corporate network. RODCs can help reduce the probability of this type of attack by ensuring that any employee that uses the service is using his or her corporate identity and authenticating through Windows Integrated Authentication. This eliminates the need to store any employee identities in the service for the purpose of authentication.

After security, the next biggest consideration for RODCs is application compatibility. An RODC is not a full, drop-in replacement for a writeable domain controller. This is for the most part intentional, to preserve the security boundaries discussed previously.

Application compatibility is a bigger consideration for an RODC in a perimeter network than for any other type of RODC deployment. This is because an RODC does not perform all the operations that a client computer or application may need from a domain controller. For example, an RODC does not process Lightweight Directory Access Protocol (LDAP) writes. Instead, it returns a referral for a writeable domain controller to the application. Depending on the network topology, the client computer may or may not be able to refer or forward the application to a writeable domain controller. Therefore, an RODC deployment in a perimeter network where client computers and applications can contact only an RODC must not be a scenario in which generic LDAP write operations are required.

IT architects and engineers must understand exactly how the client computers and applications interact with AD DS in the perimeter network. Group management and user provisioning are common scenarios that fail if they occur in the perimeter network and the application or client can contact only an RODC. RODCs can chain a limited number of scoped write operations, such as password updates, Service Principal Name (SPN) registration, and a few others. For a comprehensive list of the write operations that an RODC can perform see, the Read-Only Domain Controller Planning and Deployment Guide (https://go.microsoft.com/fwlink/? LinkID=135993).

The following sections contain information about:

· Application compatibility

· Replacing a writeable domain controller with an RODC

· Client computer updates

· Impact of data that is stored on RODCs in a perimeter network


Поделиться с друзьями:

mylektsii.su - Мои Лекции - 2015-2024 год. (0.006 сек.)Все материалы представленные на сайте исключительно с целью ознакомления читателями и не преследуют коммерческих целей или нарушение авторских прав Пожаловаться на материал