Understanding Active Directory Schema

Friday, February 27, 2009

Understanding Active Directory Schema

 

Windows 2000 and Windows Server 2003 Active Directory uses a database set of rules called "Schema". The Schema is defines as the formal definition of all object classes, and the attributes that make up those object classes, that can be stored in the directory. As mentioned earlier, the Active Directory database includes a default Schema, which defines many object classes, such as users, groups, computers, domains, organizational units, and so on. These objects are also known as "Classes". The Active Directory Schema can be dynamically extensible, meaning that you can modify the schema by defining new object types and their attributes and by defining new attributes for existing objects. You can do this either with the Schema Manager snap-in tool included with Windows 2000/2003 Server, or programmatically.


READ MORE - Understanding Active Directory Schema

Windows 2003 ADPrep

Windows 2003 ADPrep
 

Before you can introduce Windows Server 2003 domain controllers, you must prepare the forest and domains with the ADPrep utility.

  • ADPrep /forestprep on the schema master in your Windows 2000 forest.
  • ADPrep /domainprep on the Infrastructure Master in each AD domain.

ADPrep is located in the i386 directory of the Windows Server 2003 install media.

Note: In Windows Server 2003 R2, ADPrep is not located in the same folder as in the older Windows Server 2003 media, and instead you need to look for it in the second CD. You see, Windows Server 2003 R2 comes on two installation disks. Installation disk 1 contains a slip-streamed version of Windows Server 2003 with Service Pack 2 (SP2). Installation disk 2 contains the Windows Server 2003 R2 files.

The correct version of the ADPrep.exe tool for Windows Server 2003 R2 is 5.2.3790.2075.

You can find the R2 ADPrep tool in the following folder on the second CD:

drive:\CMPNENTS\R2\ADPREP\

(where drive is the drive letter of your CD-Rom drive)

Read more about ADPrep and Windows Server 2003 R2 in KB 917385

Exchange 2000 note: Please make sure you read Windows 2003 ADPrep Fix for Exchange 2000 before installing the first Windows Server 2003 DC in your existing organization.

Microsoft recommends that you have at least Service Pack (SP) 2 installed on your domain controllers before running ADPrep. SP2 fixed a critical internal AD bug, which can manifest itself when extending the schema. There were also some fixes to improve the replication delay that can be seen when indexing attributes.

Similar to the Exchange setup.exe /forestprep and /domainprep switches.

  • The Exchange /forestprep command extends the schema and adds some objects in the Configuration Naming Context.

  • The Exchange / domainprep command adds objects within the Domain Naming Context of the domain it is being run on and sets some ACLs.

The ADPrep command follows the same logic and performs similar tasks to prepare for the upgrade to Windows Server 2003.

The ADPrep /forestprep command extends the schema with quite a few new classes and attributes. These new schema objects are necessary for the new features supported by Windows Server 2003.

You can view the schema extensions by looking at the .ldf files in the \i386 directory on the Windows Server 2003 CD. These files contain LDIF entries for adding and modifying new and existing classes and attributes.

Since the schema is extended and objects are added in several places in the Configuration NC, the user running /forestprep must be a member of both the Schema Admins and Enterprise Admins groups.

The ADPrep /domainprep creates new containers and objects, modifies ACLs on some objects, and changes the meaning of the Everyone security principal.

Before you can run ADPrep /domainprep, you must be sure that the updates from /forestprep have replicated to all domain controllers in the forest.

/domainprep must be run on the Infrastructure Master of a domain and under the credentials of someone in the Domain Admins group.

You can view detailed output of the ADPrep command by looking at the log files in the %Systemroot%\system32\debug\adprep\logs directory.

Each time ADPrep is executed, a new log file is generated that contains the actions taken during that particular invocation. The log files are named based on the time and date ADPrep was run.

Once you've run both /forestprep and /domainprep and allowed time for the changes to replicate to all domain controllers, you can then start upgrading your domain controllers to Windows Server 2003 or installing new Windows Server 2003 domain controllers.


READ MORE - Windows 2003 ADPrep

Understanding FSMO Roles in Active Directory

 Understanding FSMO Roles in Active Directory
 

Windows 2000/2003 Multi-Master Model

A multi-master enabled database, such as the Active Directory, provides the flexibility of allowing changes to occur at any DC in the enterprise, but it also introduces the possibility of conflicts that can potentially lead to problems once the data is replicated to the rest of the enterprise. One way Windows 2000/2003 deals with conflicting updates is by having a conflict resolution algorithm handle discrepancies in values by resolving to the DC to which changes were written last (that is, "the last writer wins"), while discarding the changes in all other DCs. Although this resolution method may be acceptable in some cases, there are times when conflicts are just too difficult to resolve using the "last writer wins" approach. In such cases, it is best to prevent the conflict from occurring rather than to try to resolve it after the fact.

For certain types of changes, Windows 2000/2003 incorporates methods to prevent conflicting Active Directory updates from occurring.

Windows 2000/2003 Single-Master Model

To prevent conflicting updates in Windows 2000/2003, the Active Directory performs updates to certain objects in a single-master fashion.

In a single-master model, only one DC in the entire directory is allowed to process updates. This is similar to the role given to a primary domain controller (PDC) in earlier versions of Windows (such as Microsoft Windows NT 4.0), in which the PDC is responsible for processing all updates in a given domain.

In a forest, there are five FSMO roles that are assigned to one or more domain controllers. The five FSMO roles are:

Schema Master:

The schema master domain controller controls all updates and modifications to the schema. Once the Schema update is complete, it is replicated from the schema master to all other DCs in the directory. To update the schema of a forest, you must have access to the schema master. There can be only one schema master in the whole forest.

Domain naming master:

The domain naming master domain controller controls the addition or removal of domains in the forest. This DC is the only one that can add or remove a domain from the directory. It can also add or remove cross references to domains in external directories. There can be only one domain naming master in the whole forest.

Infrastructure Master:

When an object in one domain is referenced by another object in another domain, it represents the reference by the GUID, the SID (for references to security principals), and the DN of the object being referenced. The infrastructure FSMO role holder is the DC responsible for updating an object's SID and distinguished name in a cross-domain object reference. At any one time, there can be only one domain controller acting as the infrastructure master in each domain.

Note: The Infrastructure Master (IM) role should be held by a domain controller that is not a Global Catalog server (GC). If the Infrastructure Master runs on a Global Catalog server it will stop updating object information because it does not contain any references to objects that it does not hold. This is because a Global Catalog server holds a partial replica of every object in the forest. As a result, cross-domain object references in that domain will not be updated and a warning to that effect will be logged on that DC's event log. If all the domain controllers in a domain also host the global catalog, all the domain controllers have the current data, and it is not important which domain controller holds the infrastructure master role.

Relative ID (RID) Master:

The RID master is responsible for processing RID pool requests from all domain controllers in a particular domain. When a DC creates a security principal object such as a user or group, it attaches a unique Security ID (SID) to the object. This SID consists of a domain SID (the same for all SIDs created in a domain), and a relative ID (RID) that is unique for each security principal SID created in a domain.  Each DC in a domain is allocated a pool of RIDs that it is allowed to assign to the security principals it creates. When a DC's allocated RID pool falls below a threshold, that DC issues a request for additional RIDs to the domain's RID master. The domain RID master responds to the request by retrieving RIDs from the domain's unallocated RID pool and assigns them to the pool of the requesting DC. At any one time, there can be only one domain controller acting as the RID master in the domain.

PDC Emulator:

The PDC emulator is necessary to synchronize time in an enterprise. Windows 2000/2003 includes the W32Time (Windows Time) time service that is required by the Kerberos authentication protocol. All Windows 2000/2003-based computers within an enterprise use a common time. The purpose of the time service is to ensure that the Windows Time service uses a hierarchical relationship that controls authority and does not permit loops to ensure appropriate common time usage.

The PDC emulator of a domain is authoritative for the domain. The PDC emulator at the root of the forest becomes authoritative for the enterprise, and should be configured to gather the time from an external source. All PDC FSMO role holders follow the hierarchy of domains in the selection of their in-bound time partner.

In a Windows 2000/2003 domain, the PDC emulator role holder retains the following functions:

  • Password changes performed by other DCs in the domain are replicated preferentially to the PDC emulator.
  • Authentication failures that occur at a given DC in a domain because of an incorrect password are forwarded to the PDC emulator before a bad password failure message is reported to the user.
  • Account lockout is processed on the PDC emulator.
  • Editing or creation of Group Policy Objects (GPO) is always done from the GPO copy found in the PDC Emulator's SYSVOL share, unless configured not to do so by the administrator.
  • The PDC emulator performs all of the functionality that a Microsoft Windows NT 4.0 Server-based PDC or earlier PDC performs for Windows NT 4.0-based or earlier clients.

This part of the PDC emulator role becomes unnecessary when all workstations, member servers, and domain controllers that are running Windows NT 4.0 or earlier are all upgraded to Windows 2000/2003. The PDC emulator still performs the other functions as described in a Windows 2000/2003 environment.

At any one time, there can be only one domain controller acting as the PDC emulator master in each domain in the forest.

READ MORE - Understanding FSMO Roles in Active Directory

Why are the options to configure Root Hints or Forwarders unavailable?

Why are the options to configure Root Hints or Forwarders unavailable?

 If no DNS servers were detected during the initial configuration of Windows 2000 DNS, the system will typically designate the new DNS server as a "root server", which is the ultimate authority for all naming resolution activities. As a result, the new DNS server will not be able to forward any name resolution queries that it is unable to resolve to another server or to the root servers on the Internet. Consequently, a Windows 2000 DNS server that has been configured as a root server disables the options to add forwarders automatically.

Also, the Root Hints tab will be empty.

If, at a later date, you decide that this DNS server should be integrated into a larger DNS environment such as the Internet, you will need to remove the "root" forward lookup zone.

To remove the root forward lookup zone:

  1. Click Start, point to Programs, point to Administrative Tools, and then click DNS to start the DNS Management Console.
  2. Click the DNS Server object for your server in the left pane of the console, and click the (+) PLUS sign next to the server object to expand the tree.
  3. Click the (+) PLUS sign next to Forward Lookup Zones to expand it.
  4. Click the zone that is marked with a (.) period, and then press DELETE.

  1. Click OK to confirm that you want to delete the zone.
  2. Close the DNS Management Console and re-open it. Now the options to configure Root Hints or Forwarders are available.

After deleting the root zone you can now read Configure DNS Forwarding.

READ MORE - Why are the options to configure Root Hints or Forwarders unavailable?

Why do I get lots of 407 and 408 Event IDs in my DNS event log?

Why do I get lots of 407 and 408 Event IDs in my DNS event log?

 If you also have NAT installed on the same server that hosts the DNS server, you will get these errors. NAT has a DNS Proxy setting that enables DHCP clients to direct DNS queries to the NAT server. The client DNS queries are then forwarded to the NAT server's configured DNS server. The DNS Proxy and the DNS Server service cannot coexist on the same host, if the host is using the same interface and IP address with the default settings.

To workaround this issue, use one of the following three methods:

  1. Install NAT and DNS on different servers.
  2. Use the DHCP server Service in NAT, NOT the DHCP Allocator and DNS Proxy.
  3. Set the DNS Server so it doesn't listen on the IP address of the NAT private interface:
    1. In the DNS MMC snap-in, right click the DNS server and press Properties.
    2. In the Listen on section of the Interfaces tab, select the Only the following IP addresses check box.
    3. Select the IP address that you do NOT want the DNS server to listen on, and press Remove. DNS will NOT respond to queries that are directed to this removed address.
    4. Press OK and close the snap-in.
READ MORE - Why do I get lots of 407 and 408 Event IDs in my DNS event log?

Why do I get lots of 407 and 408 Event IDs in my DNS event log?

Why do I get lots of 407 and 408 Event IDs in my DNS event log?

 If you also have NAT installed on the same server that hosts the DNS server, you will get these errors. NAT has a DNS Proxy setting that enables DHCP clients to direct DNS queries to the NAT server. The client DNS queries are then forwarded to the NAT server's configured DNS server. The DNS Proxy and the DNS Server service cannot coexist on the same host, if the host is using the same interface and IP address with the default settings.

To workaround this issue, use one of the following three methods:

  1. Install NAT and DNS on different servers.
  2. Use the DHCP server Service in NAT, NOT the DHCP Allocator and DNS Proxy.
  3. Set the DNS Server so it doesn't listen on the IP address of the NAT private interface:
    1. In the DNS MMC snap-in, right click the DNS server and press Properties.
    2. In the Listen on section of the Interfaces tab, select the Only the following IP addresses check box.
    3. Select the IP address that you do NOT want the DNS server to listen on, and press Remove. DNS will NOT respond to queries that are directed to this removed address.
    4. Press OK and close the snap-in.
READ MORE - Why do I get lots of 407 and 408 Event IDs in my DNS event log?

Sometimes when I use DCPROMO to install AD and the DNS service on my Windows 2000 Server, it does not create the correct entries in the zone database. Why?

Sometimes when I use DCPROMO to install AD and the DNS service on my Windows 2000 Server, it does not create the correct entries in the zone database. Why?

 After you run Dcpromo.exe and Windows 2000 automatically installs and configures the Domain Name System (DNS), the primary DNS server is left as the current DNS server. This causes Netlogon error messages that are related to DNS registration not working. For example:

Event Source: NETLOGON Event Category: None Event ID: 5781 Date: Time: User: Computer: Description: Dynamic registration or deregistration of one or more DNS records failed because no DNS servers are available. Data: 0000: 0000232a

When an administrator chooses to automatically configure the DNS server to be authoritative for the new zone, the DNS service is installed and the DNS zone for the domain is created. The DNS client configuration for the computer's primary or secondary DNS server is not changed.

To resolve this issue, use any of the following methods:

  • Create a delegation to the new DNS server on the primary DNS server.
  • Configure the DNS server's primary DNS server address with its IP address, or remove the value for the Primary DNS Server setting so that the computer uses its IP address.
READ MORE - Sometimes when I use DCPROMO to install AD and the DNS service on my Windows 2000 Server, it does not create the correct entries in the zone database. Why?

 
 
 

Popular Posts