IT Core Blog

Never stop questioning. Curiosity has its own reason for existing…

Posts Tagged ‘Active Directory

Domain Controllers and Active Directory Domains Part 5

with 5 comments

If you want to review part 1, part 2, part 3 or part 4 of these series click the hyperlinks.

In Part 4 of this series we talk about Child Domains and Domain Trees. To continue our discussion on Domain Controllers and Active directory Domains, let’s check How to Create a new Domain Tree in a Remote Site.

Check the next demo for “How to introduce Windows 2008 and 2008 R2 domain controllers in 2003 domains” in Part 6 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

March 9, 2010 at 12:00 AM

Posted in Deployment, How to..., Videos

Tagged with

Sysinternals Updates: AdExplorer v1.3, VMMap v2.6, Disk2vhd v1.5, LiveKd v3.14, Sigcheck v1.66

leave a comment »

AdExplorer v1.3: This update to AdExplorer, an Active Directory editor, has major node expansion performance improvements and a number of minor bug fixes.

VMMap v2.6: VMMap, a powerful process virtual and physical memory analysis tool, now shows both graphical and numeric breakdowns of private virtual memory, as well as heap configuration flags.

Disk2vhd v1.5: Disk2Vhd v1.5 works with Hyper-V SCSI direct-attached volumes and reports an error when a snapshot includes offline volumes.

LiveKd v3.14: This version of LiveKd has better detection of the Debugging Tools package installation and launches the debugger in a mode that skips the unnecessary root-cause analysis of the virtual dump file.

Sigcheck v1.66: This update to Sigcheck, a file version and signature checking utility, fixes a bug in the certificate revocation check logic.

From Sysinternals

Domain Controllers and Active Directory Domains Part 4

with 8 comments

If you want to review part 1, part 2 or part 3 of these series click the hyperlinks.

In Part 4 (“a” & “b“) I’ll show you “How to create a child domain in a remote site” additionally I’ll also show you “How to pre-configure the DNS Zones and Delegations for a child domain“. This pre-configurations tasks are useful when you’re running older versions of Windows (2000/2003). In Windows 2008 R2 those DNS pre-configurations are not mandatory nor necessary because Dcpromo.exe will take care of all necessary configurations for you.

As stated in What Are Domains and Forests & Domains and Forests Technical Reference
Domains and Forests are logical representations of the directory hierarchy in Active Directory.

Forests:
A forest is a complete instance of Active Directory. Each forest acts as a top-level container in that it houses all domain containers for that particular Active Directory instance. A forest can contain one or more domain container objects, all of which share a common logical structure, global catalog, directory schema, and directory configuration, as well as automatic two-way transitive trust relationships. The first domain in the forest is called the forest root domain.

Domains:
Each Domain is a container for a collection of administratively defined objects that share a common directory database, security policies, and trust relationships with other domains. In this way, each domain is an administrative boundary for objects.

Tree Root and Child Domains:
A domain tree represents a unique DNS namespace: it has a single root domain, known as the tree root domain, and is built as a strict hierarchy: Each domain above the tree root domain has exactly one superior, or parent, domain (the forest root domain). The namespace created by this hierarchy, therefore, is contiguous — each level of the hierarchy is directly related to the level above it and to the level below it. In other words, the names of domains created beneath the tree root domain (child domains) are always contiguous with the name of the tree root domain. The DNS names of the child domains of the root domain of a tree reflect this organization; therefore, the children of a root domain called Somedomain are always children of that domain in the DNS namespace (for example, Child1.somedomain, Child2.somedomain, and so forth).

Multiple domain trees can belong to a single forest and do not form a contiguous namespace; that is, they have noncontiguous DNS domain names. Although the roots of the separate trees have names that are not contiguous with each other, the trees share a single overall namespace because names of objects can still be resolved by the same Active Directory instance. A forest exists as a set of cross-reference objects and trust relationships that are known to the member trees. Transitive trusts at the root domain of each namespace provide mutual access to resources.
The domain hierarchy in a forest determines the transitive trust links that connect each domain. Each domain has a direct trust link with its parent and each of its children. If there are multiple trees in a forest, the forest root domain is at the top of the trust tree and, from a trust perspective, all other tree roots are children. That means authentication traffic between any two domains in different trees must pass through the forest root.

 
That said, here are some tips that you may need to consider before starting to think about additional domains within your forest:
– The First created Domain will ALWAYS be the ROOT Domain. It doesn’t matter if you rename it (only possible if your FFL is at 2003 or later) or if you move other domains within your forest logical structure.
– The ROOT domain is very important to the entire forest (this includes all existing domains) because it contains unique objects (for example: The Enterprise Admins and Schema Admins groups are located in this domain) and because by hierarchical design all domains will depend of the ROOT domain. This means that if you lose the forest ROOT domain , you’ll lose the entire forest logical structure. This also applies to to child domains and their parent domains.
– Each Domain should have at least 2 DCs (at minimum).
– When security boundaries are needed you need a second forest not a child domain nor a new Root Tree domain. Only forests are security Boundaries NOT Domains. Active Directory domains, unlike Windows NT domains, are always part of a forest, and they are not themselves the security boundary. For Windows 2000 and later networks, though, domains are the boundaries for administration and for certain security policies, such as password complexity and password reuse rules (Note: this has changed in Windows 2008 with Fine-Grained Password Policies), which cannot be inherited from one domain to another. Each Active Directory domain is authoritative for the identity and credentials of the users, computers, and groups that reside in that domain. However, service administrators have abilities that cross domain boundaries. For this reason, the forest is the ultimate security boundary, not the domain.
In most scenarios child domains or new Tree Root domains are created by the wrong reasons.
– Some reasons to create Multiple Domains: Meet security requirements, Meet administrative requirements, Optimize replication traffic, Retain Microsoft Windows NT domains. Do not create multiple domains to accommodate polarized groups or for isolated resources that are not easily assimilated into other domains. Both the groups and the resources are usually better candidates for organizational units (OUs).
When determining whether to create multiple Domains, keep the following items in mind:
– DNS structure becomes more complex.
– Hardware cost Increases.
– Each time a domain is added, a Domain Admins pre-defined global group is added as well. More administration is required to monitor the members of this group.
– Security principals. As domains are added, the likelihood that security principals will need to be moved between domains becomes greater. Although moving a security principal between OUs within a domain is a simple operation, moving a security principal between domains is more complex and can negatively affect users.
– Group policy and access control. Because group policy and access control are applied at the domain level (Note: in Windows 2008 Fine-Grained Password Policies can be applied at lower level), if your organization uses group policies or delegated administration across the enterprise or many domains, the measures must be applied separately to each domain.
– Domain controller hardware and security facilities. Each Windows Server 2003 domain requires at least two domain controllers to support fault-tolerance and multimaster requirements. In addition, it is recommended that domain controllers be located in a secure facility with limited access to prevent physical access by intruders.
– Trust links If a user from one domain must log on in another domain, the domain controller from the second domain must be able to contact the domain controller in the user’s original domain. In the event of a link failure, the domain controller might not be able to maintain service. More trust links, which require setup and maintenance, might be necessary to alleviate the problem.

That Said, let’s check the videos:

Domain Controllers and Active Directory Domains Part 4.a
 

Domain Controllers and Active Directory Domains Part 4.b
 

Check the next demo for “How to Create a new Domain Tree in a Remote Site” in Part 5 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

February 17, 2010 at 10:20 PM

Posted in Deployment, How to..., Videos

Tagged with

Active Directory Windows 2008 and 2008 R2 Documentation

with 8 comments

Here are some documents that may help you with some specific Active Directory tasks
(I’ll try to keep this list updated).

Global:
Changes in Functionality from Windows Server 2003 with SP1 to Windows Server 2008
Changes in Functionality in Windows Server 2008 R2 and from TechNet
Active Directory Design Guide
AD DS Deployment Guide
AD DS Installation and Removal Step-by-Step Guide
Active Directory Domain Services – Technet & Operations Guide.doc
Running Domain Controllers in Hyper-V

Licensing
Windows Server 2008 R2 Licensing Overview
Licensing Microsoft Server Products in Virtual Environments white paper

DNS:
DNS Step-by-Step Guide
DNSSEC Deployment Guide

Migration/Upgrade:
Upgrading Active Directory Domains to Windows Server 2008 and Windows Server 2008 R2 AD DS Domains & from TechNet
Migrate Server Roles to Windows Server 2008 R2
ADMT Guide: Migrating and Restructuring Active Directory Domains
Windows Server 2008 R2 Migration Utilities x64 Edition

Read Only Domain Controllers:
Read-Only Domain Controllers (RODC) Branch Office Guide and from TechNet
Read-Only Domain Controllers (RODC) in the Perimeter Network
Read-only Domain Controllers Step-by-Step Guide from TechNet
Read-only Domain Controllers Known Issues for Deploying RODCs
Read-Only Domain Controllers Planning and Deployment Guide

Firewall:
Active Directory and Active Directory Domain Services Port Requirements
Service overview and network port requirements for the Windows Server system
How to configure a firewall for domains and trusts
How to restrict FRS replication traffic to a specific static port
Restricting Active Directory replication traffic and client RPC traffic to a specific port
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Active Directory in Networks Segmented by Firewalls (Windows Server 2003)

Security/Delegation:
How to Delegate Basic Server Administration To Junior Administrators
Best Practice Guide for Securing Active Directory Installations.doc
Active Directory Domain Services in the Perimeter Network (Windows Server 2008)
Windows 2000 Security Event Descriptions (Part 1 of 2)
Windows 2000 Security Event Descriptions (Part 2 of 2)
Description of security events in Windows Vista and in Windows Server 2008
Description of security events in Windows 7 and in Windows Server 2008 R2

How to use Group Policy to configure detailed security auditing settings KB 921469
Security Auditing Windows Server 2008, Windows Server 2008 R2 TechNet

Backup/Recover:
Recovering Your Active Directory Forest
How to restore deleted user accounts and their group memberships in Active Directory KB840001
How to restore deleted user accounts and their group memberships in Active Directory
Best practices around Active Directory Authoritative Restores in Windows Server 2003 and 2008
The importance of following ALL the authoritative restore steps

Others:
The Net Logon service on Windows Server 2008 and on Windows Server 2008 R2 domain controllers does not allow the use of older cryptography algorithms that are compatible with Windows NT 4.0 by default – KB942564

Videos:
Domain Controllers and Active Directory Domains Series

How to introduce the First Domain Controller in Active Directory Domain
How to create the second domain controller in Active Directory
How to add a Domain Controller in a Remote Site using the new Windows 2008 R2
How to create a child domain in a remote site
How to Create a new Domain Tree in a Remote Site
How to introduce Windows 2008 and 2008 R2 domain controllers in 2003 domains
How to deploy a Read-only Domain Controller in a Windows 2003 domain

Written by IT Core

February 6, 2010 at 3:34 PM

Domain Controllers and Active Directory Domains Part 3

with 9 comments

If you want to review part 1 and part 2 of these series click in the hyperlinks.

As discussed in  part 2 of these series, having more than 1 DC per domain is a good bet, but what about remote sites? Should we have a Domain Controller for remote sites?

Well… The answer may differ from scenario to scenario. You may want to consider your real needs before invest money in a new DC to serve a given remote site, some of those question would be:

How many users are in that site? Do I have a reliable connection between my Main Site and that remote office? What applications are users using to perform their job in that site? Are those applications Active Directory dependent? If my WAN link crashes, can my company afford to have those users waiting for the WAN connection repair? If I introduce a Domain Controller in that Site, will I have advantages? What is the price to maintain a Domain Controller in that Site? Is that remote site a trusted site to have a Domain Controller in it? Do I have IT people in that Site? Will I need IT people in that site after I add a Domain Controller in it?

These are a few questions that you may need to consider before invest money in a domain controller for a remote site. In part 3 of this series I will NOT talk about design/planning considerations for Active Directory Domains, but I’ll show you an example of “How to add a Domain Controller in a Remote Site using the new Windows 2008 R2“.

In this demonstration, we’ll see how to set up additional Active Directory Sites and assign subnets, we’ll also see how to configure IPSiteLink replication intervals and how to set up replication schedule availability. I really hope that you enjoy it, have a look:

Check the next demo for  “How to create a child domain in a remote site” in Part 4 of this series.

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

February 4, 2010 at 10:33 PM

Posted in Deployment, How to..., Videos

Tagged with

Domain Controllers and Active Directory Domains Part 2

with 12 comments

After the “How to create the first domain controller in Active Directory Part1”, it’s time to consider an additional domain controller to your domain.

Why should you to consider that?

Redundancy: If you have more than one DC for a given domain you can provide better redundancy for users, computers and apps. Apart to active directory redundancy, you may also have additional roles in those DCs that you want to keep available in case of a DC failure or DC overload. Roles commonly used in DCs are DNS server role and the Global Catalog.

Workload distribution: With multiple DCs you can “load balance” requests from users, apps, computers, etc… This is particularly important when those services/servers are across sites over WAN links, when that happens you can place a DC or more on those sites and take advantage of local authentication/requests without having them across the WAN link.

Domain hierarchy: The first domain that is created is the Root Domain of the forest. If you lose that domain you lose the entire forest. In a scenario where you have multiple domains within a forest, if you have only one DC for that top Root Domain and you lose that DC forever, you may say goodbye to your entire forest. Hum… that’s not good is it?!! As you already guessed domain hierarchy is very important in Active Directory.

Recovery/Availability: Consider the following scenario. Your DC suffers a hardware failure, and to recover from that hardware failure you’ll have to wait some time. If you have only one DC, you may have a problem, the domain apps may need that DC and may stop working until that DC is back online again, the users that use those apps will also stop working and your company will lose money because of that down time. Anyway, you recover that DC from hardware failure, but then you discover that the DC cannot start (BSoD-More down time), no problem (you think), you start the Backup Recovery process, but you discover that the backup isn’t enough to recover that DC. Now you’ve a big problem, no one is working and the company isn’t making money because that. Everyone will have to wait until you replace the domain controller with a new one. With a second DC, you can reduce that problem, and the dead DC could be replaced easily without affecting users or apps that depend on it.

And if I lose both DCs?
It’s true, you can lose both DCs and you’ll be “dead” anyway, but that is another story with a different planning to a different blog post. The point that I’m trying to make clear is with 2 DCs per domain “at the minimum” you will get a good chance to recover from down times (with good percentage of success) plus better redundancy and distributed workload. I could give you a lot more reasons to have additional DCs, but keep those in mind and hopefully they should be enough to make you think twice before consider only one DC for your Domain.

Ok, back to the beginning, How to create the second domain controller in Active Directory. Actually is a very simple process, we just need to have healthy domain (run dcdiag tools to check if everything is ok), and if everything is working correctly you are ready to add the 2nd DC to your domain.

Before start:
Plan carefully your FQDN of the domain controller, make sure that follow the rules of your internal company documentation. Although it’s possible to rename DCs that are running Windows 2003 and latter, I would rather do it correctly at first time preventing latter changes. Check the Naming conventions at Microsoft KB909264.

Configure your NIC with a static IP address. Avoid the use of multiple NICs in DCs, this type of configuration may lead to errors and Active Directory communication might fail on multihomed domain controllers, check MS KB272294 and 191611 for more information.

Make sure that the Administrator account has a strong password. If possible, avoid using the Administrator account and use a dedicated account to perform your everyday work in AD. Think in Administrator account as the SOS account, and try to use it only for emergency situations.

You must have at least one drive formatted with NTFS.

Install the latest updates from Microsoft website.

Check your event log for errors and correct them before proceed.

Plan and test the Backup strategy for your Active directory Forest. After that take a full backup of the existing DC in case that you need to rollback.

At last check the date and time settings, make sure that are correct, and make sure that the existing DC is in sync with a trusted and valid authoritative time server. By Default the DC that holds the PDCe will be (by default) the authoritative time server for your forest and additional DCs will sync their time with this DC.

Don’t miss Part 3 – “How to add a Domain Controller in a Remote Site using the new Windows 2008 R2

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

January 20, 2010 at 10:08 PM

Posted in Deployment, How to..., Videos

Tagged with

Domain Controllers and Active Directory Domains Part 1

with 9 comments

In this blog post I’ll show you an example of How to introduce the First Domain Controller in Active Directory Domain. This will be the first of many other blog posts that will help you with domain controllers configuration and related services across your forest, I’ll also show you how to introduce new domains and different ways to perform identical tasks. Let’s start qith a quick review about Domain Controllers basics:

A Domain controller (DC) is a server role that has the Active Directory service installed. Domain controllers have a database called “NTDS.dit” that stores information about Active Directory objects. This database is divided in different partitions. Domain partition has all information about the domain where that DC is located and is replicated between all DCs within the same domain, each DC has read/write permission to the domain partition. Schema and Configuration directory partitions that are common to the entire forest and replicated between all Domain Controllers within the same forest, it doesn’t matter if they belong to the same Domain or not, as long as they are in the same Forest they’ll need to have a Schema and Configuration directory partitions (which are only writable by their FSMO masters) + Domain Partition for the domain where the DCs were configured. Depending of the version that you’re running, DCs can also store one or more application directory partitions (this applies to Windows 2003 and later OS).

In addition to Active Directory database, DCs can also hold specific roles needed by Active Directory:
Flexible Single Master OperationFSMO” (pronounced Fiz-mo). Domain controllers that hold operations master roles are designated to perform specific tasks to ensure consistency and to eliminate the potential for conflicting entries in the Active Directory database. Active Directory defines 5 operations master roles (2 are Forest wide and the other 3 exist in each domain):

Forest operation masters:
– Schema master
– Domain naming master

Domain operation masters:
-Primary domain controller emulator (PDCe)
-Infrastructure master (IM)
-Relative ID master (RID)

Global Catalog (GC). A global catalog server is a domain controller that, in addition to its full writable domain directory partition replica (does not apply to RODC), also stores a partial, read-only replica of all other domain directory partitions in the forest. The attributes that are replicated to the global catalog are identified in the schema as the partial attribute set (PAS).
GCs are needed when: doing forest wide searches, User logons (when more than one domain exists in that forest), when a user principal name (UPN) is used at logon and the forest has more than one domain, to cache the user membership when is member of a Universal Group (Universal groups are only available when the domain is native mode or later), Exchange Address Book lookups and exchange clients also use global catalog servers to access the global address list (GAL). These are the most common scenarios, but you can also have specific apps that need to contact the GC to function properly.

DNS: Although DNS is not a component of Active Directory, Active Directory uses DNS as its domain controller location mechanism and leverages the namespace design of DNS in the design of Active Directory domain names. Is possible to have a non-Microsoft DNS solution to support Active Directory, but the DNS server must support service resource records (RFC 2782) and dynamic update protocol (RFC 2136). Active Directory uses DNS as the location mechanism for domain controllers, enabling computers on the network to obtain IP addresses of domain controllers. During the installation of Active Directory, the service (SRV) and address (A) resource records are dynamically registered in DNS. Both types of records are necessary for the functionality of the domain controller locator (Locator) mechanism among other functions.

That being said, now it’s time to setup of the First Domain Controller.

Before start:
· Plan carefully your FQDN (fully qualify domain name), the NetBIOS name and the Domain controller name, this is very important to avoid changes that may crash your entire forest later. Check the Naming conventions at Microsoft KB909264.
· Configure your NIC with a static IP address. Avoid the use of multiple NICs in DCs, this type of configuration may lead to errors and Active Directory communication might fail on multihomed domain controllers, check MS KB 272294 and 191611 for more information.
· Configure the Administrator account with a strong password.
· Install the latest updates from Microsoft website.
· You need to have at least one hard drive formated with NTFS.
· Check your event log for errors and correct them before proceed.
· Consider the use of at least 2 DCs for each domain that you plan to have in your forest, this will give you better redundancy but also a fastest way to recover from server failures.
· Plan and test the Backup strategy for your Active directory Forest.
· At last check the date and time settings, make sure that are correct, and make sure that the server is in sync with a trusted and valid authoritative time server. By Default the first DC will be the authoritative time server for your forest and additional DCs will sync their time with this DC.

Now it’s time to install Active directory in your server, check the video and follow the steps bellow:

Check the next article : How to create the second domain controller in Active Directory

To review all video demonstrations, check video section of Active Directory Windows 2008 and 2008 R2 Documentation

🙂

Written by IT Core

January 19, 2010 at 11:34 PM

Posted in Deployment, How to..., Videos

Tagged with