DNS Basics

DNS is used to translate the ipaddresses to names. To explain, how DNS works, please look at the diagram on left. There is a DNS client which is also known as resolver. If DNS Client needs to resolve admin.server2.com it will check its client cache for which it used HOSTS file. It is usually in

C:/>Windows/System32/Drivers/etc/

If the record is not found in that file, it looks for a dns server. You enter that under the IPv4 properties for the network adapter.

When it find the DNS server, the server looks for the record in the server cache. Cache.dns file is located in the server at the following location

C:/>Windows/System32/DNS/

If it does not find the entry on the root hint file, it goes on the internet and looks for the "." Once that is resolved, "." server will resolve for the ".com" server. In same way the ".com" server resolves for "server2.com" and in turn the "student.server2.com" address gets resolved. This all happens on UDP PORT 53. If there is another DNS server in and the zones have to be transferred, it used TCP PORT 53 to transfer.

There are two types of queries:

1. Recursive: When the server HAS to resolve the query

2. Iterative: When the server can look for other servers, if it cannot resolve the query



Active Directory Trusts

* Manual Trust
* External Trust
* Realm Trust
* Forest Trust
* Shortcut Trust

In a school environment, for eg. Student domain should trust admin domain (outgoing).

Replication

If a domain controller has to replicate the changes to other domain controllers in the topology, it replicates the data to other DC in 15 sec and if there is another DC on which it has to replicate the change, it will 15+3 sec to replicate the same change to the other DC. Intrasite replication can only go upto 3 hops or then optimising network connections has to be created. KCC (knowledge consistency checker) lets the replication to occur if there are more than 3 hops by optimising network connections (intrasite). KCC also uses ISTG (intersite topology generator) to choose a bridgehead server on each site (single entry and exit point), which is used to transfer the data across sites. If a server is selected manually as bridgehead server, then ISTG will not select other server as bridgehead in case if the that server goes down for some reason.
If the replication is happening inter-site, divide the servers in different SITES and join the sites by a link. The replication in that case will be a STORE AND FORWARD replication which will be by default after every 3 hours instead of every 15 secs. A site is usually an area of high speed connectivity.

Next thing that can be done is to create different subnets. When you create subnets, they can be associated with different sites. Then, when a computer logs on in one of the sites, and gets an ipaddress ranging in one of the subnets, it will only use one of the domain controller, to logon associated with that site.

The way one DC replicates to another DC in a different site is by POLLING. If a DC2 from Site B somehow feels that it does not have updated information, it will POLL DC1 in Site A and DC1 will replicate the changes only to DC2 in site B.

Lower cost of a site link takes precedence in replicating data across the site.

Now I will show some commands,

1. repadmin /bridgeheads /v : Used to identify the bridgehead server. /v is for verbose and gives information about what time was last replication done.

2. repadmin /syncall : This can be used to push al the replication changes to all the servers to across sites as well.

The way the data is replicated across the sites is by POLLING. After every 3 hours the bridgehead server will POLL the other bridgehead server and only the changes in directory are replicated.

If you use SMTP for site replication, remember that it can not replicate the domain naming information so basically it cannot replicate between same domain names.

What is a GLOBAL CATALOGUE?
* Server which has all forest objects
*  But it does not store all attributes
*  A server from which Universal groups can query
*  Exchange apps need a global catlogue server to function properly
* It queries on port 3268

Functional Levels

There are two types of functional levels:

1. Domain functional level
2. Forest functional level

DFL: Windows 2000 Native
-----------------------------------------------------------------------
* No mixed or native
* DC: W2k, W2k3, W2k8
* Basic AD services

DFL: Windows Server 2003
----------------------------------------------------------------------
* DC: W2k3, W2k8
* DC rename possible : To change the computer name using command line, use the netdom command as follows:

netdom computername %computername% /add:newcompname.domain.com

netdom computername %computername% /makeprimary:newcompname.domain.com

To restart the computer,

shutdown /r /t 0
/r- restart
/t- time after which to restart

To remove the old computer name,

netdom computername %computername% /remove:oldcompname.domain.com


* Attributes :
- Last logon time stamp- Check the saved queries folder in Active directory to find out last logon information.
- User password

* Rediruser, Redircmp
* Selective Authentication
* Constrained Delegation
* Authorization Manager

DFL: Windows Server 2008
-------------------------------------
- DFL W2K3 + .....
- DC : W2k8
- DFS R SysVol Replication
- Last Logon
- Fine Grained Passwords

To raise the functional level,
1. Go to dsa.msc and right click on the domain and click on raise domain functional level

FFL: Windows 2000
---------------------------
DFL: W2k Native, Win2k3, Win2k8

FFL: Windows 2003
---------------------------
Forest Trust
Domain rename
Linked Value Replication: Just replicates new objects instead of entire group
RODC
Improved KCC algorithms
and with FFL Windows 2008, you get the same features as in FFL windows 2003.

To raise FFL: Go to Active directory domains and trusts and right click on forest level and choose Raise forest functional level.

Transferring FSMO roles

I found a very nice step by step guide on how to transfer the FSMO roles. The link is:

http://www.elmajdal.net/win2k8/Transferring_FSMO_Roles_in_Windows_Server_2008.aspx

Before you transfer the roles, you can check the roles by using the following commands:

i) netdom query fsmo

ii) dsquery server -hasfsmo

for eg. dsquery server -hasfsmo pdc

iii) dcdiag /test:knowsofroleholders /v

/v- verbose

Correct Placement of Infrastructure Master Role

Correct placement of Infrastructure master in a domain is very important. On the diagram on the left, I have shown two domains in the same forest with a 2 way transitive trust. In domain2.com, infrastructure master is on a separate server than the GC server. Infrastructure master's job is to check the cross domain reference- so here it checks whether the user smith from the other domain is a member of operations group, it has to validate that against the GC server. In domain2.com it checks against GC server and if a change is made it also replicates to the other DC.

In case of domain1.com when the infrastructure master checks whether adam is member of marketing group, it has to check against GC server. Because GC is on the same server as Infrastructure master, when a change takes place, GC server will make that change in the NTDS.dit file. Because Infrastructure Master is on the same server, it does not see any change on the GC server as it validates against the same NTDS.dit file. Because it sees no change, it does not replicate the change to the other domain controller.

MS2008 Server Operations Masters

Operations Masters are also commonly known flexible single master operations or FSMO roles. There are commonly 5 FSMO roles which can be divided into Forest and Domain. These roles are as follows:


Forest:
1. Domain Naming
2. Schema


Domain:
1. Infrastructure
2. RID Master
3. PDC Emulator

I will explain these roles one by one now.

1. Domain Naming: This role is applied forest wide and it prevents someone accidently creating another domain with the same name.

2. Schema: All the options that can be filled in to a objects properties like their name, all the radio buttons, checkboxes, etc is because of the schema master.

Before you add this role, you have to register it by following command on command prompt:

regsvr32 schmmgmt.dll



5. PDC Emulator: This is one of the most important roles in Win Srv environment. PDC Emulator does the following tasks:

i) Acts as PDC for NT4 domain and NT4 based apps.
ii) Acts as a password authority and dictates all the password changes to the other DC's.
iii) GPO authority role and dictates the other DC's about any GPO changes in the domain and other DC's report to PDC Emulator about GPO changes.
iv) Domain Master Browser- Acts as a domain master browser and is responsible for the network browsable objects in the windows explorer windows.
v) Master Time source- all objects in the domain get the time from PDC emulator. It has to access the NTP (UDP port 123) which should be open on the firewall.

Follow this document to configure NTP on your PDC emulator.http://technet.microsoft.com/en-us/library/cc786897(WS.10).aspxLet's talk about dividing the roles among DC's. One way of doing this is shown below.You can also use ADSI Edit to check the SID of the object. Right click on the object and go to properties to find the SID.



4. RID Master : RID masters purpose is to keep a track of SID. To check your SID, type the following command.

whoami /user
To find the information about the RID pool, use the following command.

dcdiag /test:ridmanager /v
3. Infrastructure: Purpose of this role is to keep the cross domain referencing straight especially when it comes to locate the users in a different domain's security group.

This divides the roles according to the forest roles and domain roles classifications.

Another way of doing this in a busy environment like schools, where many accounts have to be created every year is shown below. By dividing roles this way we divide the RID master and PDC emulator roles, which would get very busy in such environments. We also have a standby master in case one of the DC fails.