Read Only Domain Controllers

Read Only Domain Controllers A new feature in Windows 2008 is a new type of domain controller the Read-Only Domain Controller known as RODCs. An RODC makes it possible for organizations to easily deploy a domain controller in scenarios where physical security cannot be guaranteed, such as branch office locations, or in scenarios where local storage of all domain passwords is considered a primary threat. The RODC also have copy of the Active Directory (AD) database, but the contents of the replica of the database on the domain controller is read-only and write operations are not supported. It is also important to know that the RODCs do not participate in Active Directory replication in the same way as writable domain controllers. The difference between RODC replication and the multimaster replication model between writable domain controllers is that RODC replication is unidirectional. This means all changes from a writable domain controller are propagated to the RODCs. The result of this is that the RODC receives changes, but does not partake in or perform outbound replication with other domain controllers. This provides an extra layer of security as any unauthorized data changes, will not replicate out to other domain controllers. Another new RODC functionality that improves security is the replication that happens between a writable domain controller and a RODC. Here, user account information is replicated, but account passwords are not.

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. However, the branch user cannot log on to any other domain controller or perform any other administrative task in the domain, and therefore compromising the security of the rest of the domain.

Read-Only AD DS Database Except for account passwords, an RODC holds most of 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.

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. 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 does not support client updates directly. Consequently, the RODC does not register name server NS resource records for any Active Directory integrated zone that it hosts.

Credential Caching

Credential caching is the storage of user or computer credentials, including the user password. You can configure credential caching on the RODC by modifying the Password Replication Policy for the specific domain controller. If you want the RODC to cache the credentials for all users in the branch office that routinely log on in the office location, you can add all user accounts in the branch office to the Password Replication Policy. Now users will be able to log on to the domain controller even if the wide area network WAN connection to a writable domain controller is down. You can also add all of the branch office computer accounts, so that these accounts can authenticate to the RODC even when the WAN link is down. In both cases, the WAN connection to writable domain controller must be available during the first logon for the credentials to be cached.

Prerequisite When Deploying an RODC The following things should be done and complete before installing RODCs: Active Directory running on Windows Server 2003 or Windows Server 2008 must already exist in the environment. The Active Directory schema must support the Windows 2008 Server extensions. The forest and domain functional level must be running Windows Server 2003 or higher. At least one domain controller within the domain must be running Windows 2008. The PDC Emulator FSMO role must be running Windows 2008. A regular non-read-only (writable) domain controller must already exist within the Active Directory infrastructure. The RODC cannot be the first domain controller within the Active Directory infrastructure. If the DNS service will be configured on a Server Core installation, a non-read-only DNS server must be present within the domain.

Limitations with Windows Server 2008 RODCs There are situations when RODCs cannot be used. This is the case with bridgehead servers and operations master role holders . Because an RODC can only perform inbound unidirectional replication, it cannot be designated as a bridgehead server, because these servers must support both inbound and outbound replication. An RODC cannot be a Flexible Single Master Operations (FSMO) role holder. Each FSMO role needs to write information to an Active Directory domain controller. There are more limitations to the out-of-the-box RODCs they cannot authenticate a smart card logon. This is because the Enterprise Read-Only Domain Controller (ERODC) group is not

defined in the domain controller certificate template by default. Unlike the limitations of RODCs talked about previous there is a way to work around this so an RODC can authenticate smart card logons. The following changes must be done in the certificate templates for an RODC to support smart card logons: ERODC group permissions for Enroll must be set to Allow on the Domain Controller certificate template. ERODC group permissions for Enroll and Auto enroll must be set to Allow on the Domain Controller Authentication and Directory E-Mail Replication certificate template. The Authenticated Users group permissions must be set to Allow Read on the Domain Controller Authentication and Directory E-Mail Replication certificate template.

Active Directory Lightweight Directory Services AD LDS, known as Active Directory Application Mode (ADAM) when it was released with Windows Server 2003, is a Lightweight Directory Access Protocol directory service that can replace AD DS functionality in some scenarios or be deployed together with AD DS. AD LDS provides much of the same directory service functionality as AD DS, but it does not require the deployment of domains or domain controllers. You can also configure AD LDS replication so that the same instance of AD LDS is distributed across multiple computers. AD LDS is designed to complement rather than replace AD DS. AD DS provides a network authentication and management directory, while AD LDS is designed to be used purely as a directory service for applications. AD LDS is designed to be deployed in the following scenarios:

Enterprise directory store: AD LDS can store application data in a local directory service either on the same computer as the application or on a different computer. Extranet authentication store: A lot of organizations have Web portal applications that require extranet access to corporate business applications but provide access for users who are outside the organization. These servers and portal applications require an authentication store to save authorization information for the users. AD LDS can provide this authentication store because it can host user objects that are not Windows security principals but can be authenticated with LDAP simple binds.

Directory consolidation solution: Enterprise organizations frequently have several directories deployed. User accounts may be located in multiple AD DS forests,domains, and OUs, or in several identity systems and other directories, such as human resource databases, AD LDS can integrate with a metadirectory, which means that identities created in AD LDS can be

synchronized with the metadirectory. AD LDS can also accept identity synchronization from the metadirectory. Development environment for AD DS and AD LDS Because AD LDS uses the same programming model and provides virtually the same administration experience as AD DS, developers can use AD LDS when staging and testing various AD DS integrated applications.

Active Directory Federation Services AD FS, first released with Windows Server 2003 R2,is designed to enable secure access to Webbased applications within an organization and between organizations without making an external or forest trusts between those organizations. (can be used in both Windows and non-Windows enviroments) providing browser-based clients with one-prompt access to protected applications,even when the accounts and applications are located on different networks. When a user need access to secure Web sites hosted outside of her own organization, the user has to provide secondary credentials meaning that the user has to provide a user name and password other from the one she used to log onto her personal computer. AD FS takes care of this by enabling organizations to establish trust relationships with the directory services system running at other organizations. Known as single sign-on (SSO) this, allows the systems at one organization to recognize the users of another organization without having to prompt them for credentials.

AD FS is composed of three different server components, as follows: Federation server: A federation server is the main AD FS component, which holds the Federation Service role. These servers route authentication requests between connected directories. Federation proxy server: A federation proxy server acts as a reverse proxy for AD FS authentication requests. This type of server normally resides in the demilitarized zone (DMZ) of a firewall, and is used to protect the back-end AD FS server from direct exposure to the untrusted Internet. AD FS Web Agents: The Web Agents component of AD FS hosts the claims-aware agent and the Windows token-based agent components that manage authentication cookies sent to web server applications. Each one of these components can be individually installed in an AD FS structure, or they can be all installed on the same system.

AD FS Deployment Requirements In order to deploy AD FS, you must ensure that the following network requirements are met:

TCP/IP connectivity For AD FS to function, TCP/IP network connectivity must exist between the client,and the computers that host the Federation Service, the Federation Service Proxy, and the AD FS Web Agents DNS requirements In order for AD FS to function, you must ensure that the client computers can resolve the names of all of the servers running AD FS components.

Client Web Browser requirements Any Web browser with JScript enabled can work as an AD FS client.AD FS creates authentication cookies that must be stored on client computers to provide SSO functionality. Therefore, the client browser must be configured to accept cookies. Authentication cookies are always Secure Hypertext Transfer Protocol (HTTPS) session cookies.

Account Store Requirements AD FS requires at least one account store to be used for authenticating users and extracting security claims for those users. AD FS supports two types of account stores: AD DS and AD LDS.

Web Server Requirements IIS is a mandatory requirement for all AD FS server components.

Public Key Infrastructure (PKI) Requirements In order to secure the communications between all of the AD FS components, AD FS requires that all Web sites that accept user authentication traffic or security tokens be configured with server authentication certificates. These certificates are used for account partner and resource partner authentication and for authentication between federation servers and federation server proxies. This means that you must obtain the required digital certificates from a certification authority (CA). You can use a trusted third party CA or an internal Active Directory Certificate Services (AD CS) CA to issue these certificates.

New in AD FS in Windows Server 2008 Improved installation: AD FS is included in Windows Server 2008 as a server role, and there are new server validation checks in the installation wizard Improved application support: AD FS is more tightly integrated with Microsoft Office SharePoint Server 2007 and Active Directory Rights Management Services (AD RMS

A better administrative experience when you establish federated trusts: Improved trust policy import and export functionality helps to minimize partner-based configuration issues that are commonly associated with federated trust establishment.

AD FS 2.0 AD FS 2.0 is a downloadable Windows Server 2008 update Active Directory Federation Services (AD FS) 2.0 provides support for claims-aware identity solutions that involve Windows Server and Active Directory technology. AD FS 2.0 supports the WS-Trust, WS-Federation, and Security Assertion Markup Language (SAML) protocols.

AD FS 2.0 has the following features: An enterprise claims provider for claims-based applications Provide a single-sign-on (SSO) experience across multiple claims-aware applications. Provide access to a claims-aware application to users in another organization. Reduce concern about developers of custom applications making processor-intensive authentication requests that unexpectedly burden an organizations directory services.A Federation Service for identity federation across domains You can configure AD FS 2.0 in the Federation Service role so that Web browser and Web service applications can use federated Web SSO across domains. This helps reduce administrative overhead, reduce security vulnerabilities as a result of lost or stolen passwords, and improve user productivity through SSO.

Improved support for federation trusts AD FS 2.0 has improved support for federation trusts that can speed up the process of establishing the trusts. AD FS 2.0 uses industry standard metadata formats when it establishes trusts between federation partners.An enhanced snap-in management console The AD FS 2.0 snap-in is a single Microsoft Management Console (MMC) 3.0 snap-in. It provides a graphical user interface (GUI) for configuring service and policy settings that are used most commonly with AD FS 2.0.

Support for issuance and use of Information Cards AD FS 2.0 supports the issuance and use of managed Information Cards in Web browsers and Web services scenarios to provide a phishing-resistant, extranet, log-in mechanism. With this support, you can issue a managed card that a user can use to log on to a federation server for an application that is enabled for WS-Federation Passive. AD FS 2.0 also can assist in providing access to a Web site that users can access to obtain a managed Information Card.

An enhanced snap-in management console The AD FS 2.0 snap-in is a single Microsoft Management Console (MMC) 3.0 snap-in. It provides a graphical user interface (GUI) for configuring service and policy settings that are used most commonly with AD FS 2.0.

Support for a Microsoft SQL Server based policy store AD FS 2.0 makes it possible for you to move away from a file-based policy store to a database-centric policy store that can scale dynamically to a large number of objects.

Unsupported features in AD FS 2.0 The following are the AD FS 1.x features and scenarios that are no longer supported in AD FS 2.0: AD LDS used as an account store The Windows NT token based Web agent The AD FS 1.x claims-aware Web agent configured for Microsoft Office SharePoint Server 2007 The Federated Web Single-Sign-On (SSO) with Forest Trust scenario is no longer supported

Network Drive for Users One of the most searched topics on our site is "how to map a drive". Unfortunately, until now, the searches on this topic didn't return any result for our users. As a consequence to this, we decided to create this article in which we show you how to create a drive mapping in Windows Vista . For those of you who don't know it, a drive mapping is a letter assigned to a disk or drive. The most common drive mappings are A: for the floppy disk and C: for the primary hard disk. If you are on a network, a drive mapping can reference remote drives to which you can assign a letter of your choice. For example, you can use the letter Z: to refer drive C: or a network server or a specific shared folder to which you have access to.

As you will see for yourself, the procedure of creating a map drive in Windows Vista is very simple. Just follow these steps: First, click on the Computer shortcut from your desktop or from the Start Menu. In the toolbar you will find several buttons, including one called Map network drive.

Click on it and the Map Network Drive window will open. Firstly, you need to assign a drive letter for the connection and then type the drive or the folder you want to connect to. The folder can be located on a remote server or computer you have access to, a FTP site or a shared folder on your own computer.

If you want to connect to a remote computer just type "\\" followed by the computer name or the IP address and then "\" followed by the location of the folder you want to connect to. If you want to create a drive mapping to a folder on your own computer type "\\127.0.0.1\" (this stands for the local host) or "\\computer_name\" and then the path towards that folder. Sometimes, when you create a drive mapping, you might need to use a special user name and password that allows you to connect to it. In this case, click on the Connect using a different user name link.

Type the appropriate user name and password and click on OK. Now you will return to the previous window. Click on Finish and the drive mapping will be created. If you access the Computer shortcut again you will see that a new drive having the letter you assigned is listed and you can access it at anytime.