Windows Server Interview Questions
Windows Server Interview Questions
Properties of FAT16
• Restricted to 512 entries in the root directory of the hard drive and 128
entries in the root partition of a floppy disk
• No built-in support for long file names - Windows® 95/98 VFAT writes
additional entries to a modified file allocation table containing the long file
name (up to 255 characters); this reduces the maximum number of entries
into the root directory
Advantages
• Compatible with operating systems other than DOS (including Windows® 95,
Windows® 98, and Windows® NT)
• No size overhead
Disadvantages
• Large cluster size results in poor use of drive space for large partitions
• No compression available under Windows® NT
• Minimal security - may only set the read only and hidden attributes of files
• Updating the FAT table is slow - performance decreases as partition sizes
become greater than a few hundred MB
Properties of FAT32
• Long file names supported through Windows® 95/98 VFAT - VFAT writes
additional entries to a modified file allocation table containing the long file
name (up to 255 characters)
Advantages
• Small cluster size (as small as 4K)
• Relocatable root directory allows for greater number of entries
• The file allocation table (FAT) and master boot record (MBR) may be relocated
• Backup copies of the FAT and MBR may be created with the proper tool
• May disable writing to the secondary FAT; can run directly from the secondary
FAT if the primary FAT lies on a bad cluster
Disadvantages
Properties of NTFS
Advantages
Disadvantages
The table below shows the partition and cluster size differences of each of the file
system types.
NOTE: FAT 16 partition sizes greater than 2.1 GB are only supported under
Windows® NT 4.0.
Cluster Size FAT Cluster Size FAT
Partition Size Cluster Size NTFS
16 32
16 MB - 127 MB 2K *** 512 bytes
128 MB - 255 MB 4K *** 512 bytes
256 MB - 511 MB 8K *** 512 bytes
512 MB - 1023 MB 16K 4 KB 1K
1024 MB - 2048 MB 32K 4 KB 2K
2048 MB - 4096 MB 64K 4 KB 4K
4096 MB - 8192 MB *** 4 KB 8K
8192 MB - 16384 MB *** 8 KB 16K
16384 MB - 32768 MB *** 16 KB 32K
greater than 32768
*** 32 KB 64K
MB
Disadvantages Disadvantages
1. Requires a windows server 1. Need to setup account and password
2. Complex to set up on each and every machine.
2. Passwords can become out of sync, if
changed on one computer and not others
6) What are PDC and BDC? Highlight the difference between PDC and BDC---
A PDC is a Primary Domain Controller, and a BDC is a Backup Domain Controller. You
must install a PDC before any other domain servers. The Primary Domain Controller
maintains the master copy of the directory database and validates users. A Backup
Domain Controller contains a copy of the directory database and can validate users.
If the PDC fails then a BDC can be promoted to a PDC. Possible data loss is user
changes that have not yet been replicated from the PDC to the BDC. A PDC can be
demoted to a BDC if one of the BDC's is promoted to the PDC.
7) Can we reset password or make changes to domain in NT4.0 when PDC is down
and BDC is up.
NO, since it is read only, you have to first promote the BDC to PDC then make the
changes.
Ntldr H; R ; S o Loads OS
There are five different FSMO roles and they each play a different function in making
Active Directory work:
• PDC Emulator - This role is the most heavily used of all FSMO roles and has
the widest range of functions. The domain controller that holds the PDC
Emulator role is crucial in a mixed environment where Windows NT 4.0 BDCs
are still present. This is because the PDC Emulator role emulates the functions
of a Windows NT 4.0 PDC. But even if you've migrated all your Windows NT
4.0 domain controllers to Windows 2000 or Windows Server 2003, the domain
controller that holds the PDC Emulator role still has a lot to do. For example,
the PDC Emulator is the root time server for synchronizing the clocks of all
Windows computers in your forest. It's critically important that computer
clocks are synchronized across your forest because if they're out by too much
then Kerberos authentication can fail and users won't be able to log on to the
network. Another function of the PDC Emulator is that it is the domain
controller to which all changes to Group Policy are initially made. For
example, if you create a new Group Policy Object (GPO) then this is first
created in the directory database and within the SYSVOL share on the PDC
Emulator, and from there the GPO is replicated to all other domain controllers
in the domain. Finally, all password changes and account lockout issues are
handled by the PDC Emulator to ensure that password changes are replicated
properly and account lockout policy is effective. So even though the PDC
Emulator emulates an NT PDC (which is why this role is called PDC Emulator),
it also does a whole lot of other stuff. In fact, the PDC Emulator role is the
most heavily utilized FSMO role so you should make sure that the domain
controller that holds this role has sufficiently beefy hardware to handle the
load. Similarly, if the PDC Emulator role fails then it can potentially cause the
most problems, so the hardware it runs on should be fault tolerant and
reliable. Finally, every domain has its own PDC Emulator role, so if you have
N domains in your forest then you will have N domain controllers with the
PDC Emulator role as well.
• RID Master - This is another domain-specific FSMO role, that is, every
domain in your forest has exactly one domain controller holding the RID
Master role. The purpose of this role is to replenish the pool of unused relative
IDs (RIDs) for the domain and prevent this pool from becoming exhausted.
RIDs are used up whenever you create a new security principle (user or
computer account) because the SID for the new security principle is
constructed by combining the domain SID with a unique RID taken from the
pool. So if you run out of RIDS, you won't be able to create any new user or
computer accounts, and to prevent this from happening the RID Master
monitors the RID pool and generates new RIDs to replenish it when it falls
beneath a certain level.
• Infrastructure Master - This is another domain-specific role and its purpose
is to ensure that cross-domain object references are correctly handled. For
example, if you add a user from one domain to a security group from a
different domain, the Infrastructure Master makes sure this is done properly.
As you can guess however, if your Active Directory deployment has only a
single domain, then the Infrastructure Master role does no work at all, and
even in a multi-domain environment it is rarely used except when complex
user administration tasks are performed, so the machine holding this role
doesn't need to have much horsepower at all.
• Schema Master - While the first three FSMO roles described above are
domain-specific, the Schema Master role and the one following are forest-
specific and are found only in the forest root domain (the first domain you
create when you create a new forest). This means there is one and only one
Schema Master in a forest, and the purpose of this role is to replicate schema
changes to all other domain controllers in the forest. Since the schema of
Active Directory is rarely changed however, the Schema Master role will rarely
do any work. Typical scenarios where this role is used would be when you
deploy Exchange Server onto your network, or when you upgrade domain
controllers from Windows 2000 to Windows Server 2003, as these situations
both involve making changes to the Active Directory schema.
• Domain Naming Master - The other forest-specific FSMO role is the Domain
Naming Master, and this role resides too in the forest root domain. The
Domain Naming Master role processes all changes to the namespace, for
example adding the child domain vancouver.mycompany.com to the forest
root domain mycompany.com requires that this role be available, so you can't
add a new child domain or new domain tree, check to make sure this role is
running properly.
To summarize then, the Schema Master and Domain Naming Master roles are found
only in the forest root domain, while the remaining roles are found in each domain of
your forest. Now let's look at best practices for assigning these roles to different
domain controllers in your forest or domain.
15) What is the use of PDC emulator in both Native and Mixed mode
PDC emulator
By default, Windows 2000 (Win2K) networks operate in a mixed mode, which lets
both Win2K and Windows NT domain controllers coexist. During migration to Win2K,
the mixed mode provides the functionality that lets NT domain controllers offer
domain services. After you upgrade all NT domain controllers to Win2K, switch from
mixed mode to native mode, which doesn’t support NT domain controllers. However,
before you switch to native mode, you need to understand the differences between
the two modes. Depending on your organization, when you convert to native mode
can be a critical decision with major implications. It’s a one-way conversion—there’s
no going back.
Mixed Mode: In mixed mode, a Win2K domain assigns a domain controller to act as a
PDC for NT BDCs. By default, the first domain controller in a Win2K domain acts as a
PDC emulator. There can be only one PDC emulator in a domain, and you can assign
the role to any domain controller in a domain. The PDC emulator performs several
important tasks in mixed mode, including:
If a Win2K site in mixed mode contains Win2K clients, make sure there’s at least one
Win2K domain controller in that site because the Win2K clients first attempt to locate
Win2K domain controllers using DNS. If a client doesn’t find a Win2K domain
controller, it’ll try to use NTLM to log on to an NT domain controller. Obviously, NT
doesn’t support group policies so your Win2K client users won’t be able to take
advantage of either the group policies or the logon scripts. . . .
17) What are the 3 naming context in which ADS is divided.
18) What will be the effect on root and child domain if Schema master is down
20) What is GC? Why is it recommended to have GC for each AD site and sub domain
Using a Global Catalog allows for circumventing this obstacle, when querying for
objects outside of requester's domain. Global Catalog contains index of all objects in
the forest and a small, most commonly used, subset (about 60 out of 1500) of their
attributes . This eliminates most of the time the need for requester's searches
through other domains in a forest (unless one of non-typical attributes is searched
for). The number of attributes stored on each Global Catalog server can be modifed
by using Schema Management snap-in (by selecting "Replicate this attribute to the
Global Catalog" option for selected attributes of an object)..
In addition, GCs are used by default in a native mode environment when looking up
universal group information during login. If any one of the GCs can not be contacted,
users are not allowed to logon to the domain (if cost of placing a high performance
server in a site is prohibitive, this requirement can be eliminated by modifying
HKLM\SYSTEM\CurrentControlSet\Control\Lsa\IgnoreGCFailures registry entry - in
such case, though, the use of universal groups is discouraged). Therefore, at least
one Global Catalog per site should be available.
Global Catalog is installed automatically on the first domain controller in the forest.
Subsequent installations (or relocation of original GC) are up to forest and domain
administrators.
OR
Windows 2000 Global Catalog Servers store all of the Active Directory object
attributes for all of the Active Directory objects from their own domain. This is
referred to as a full replica. They also contain some of the Active Directory object
attributes from all of the remaining Active Directory objects from all of the other
domains in the forest. This is referred to as a partial replica. This subset of data from
throughout the forest, allows for user and service queries for finding directory
information and directory objects from any domain in the forest regardless of which
domain that data and / or object exists. In a nutshell this means, for example, a user
from one domain can search for a printer that is published in the Active Directory
and locate it in any domain, even an external one, by using only the printer's name
or some other known (to the Active Directory database) attribute. This could be a
building number or floor or some other naming convention used within the given
organization.
24) What are local, global and Universal groups in ADS domain
The Windows Server 2003 System Volume (SYSVOL) is a collection of folders and
reparse points in the file systems that exist on each domain controller in a domain.
SYSVOL provides a standard location to store important elements of Group Policy
objects (GPOs) and scripts so that the File Replication service (FRS) can distribute them
to other domain controllers within that domain.
Note:
Only the Group Policy template (GPT) is replicated by SYSVOL. The Group Policy
container (GPC) is replicated through Active Directory replication. To be effective,
both parts must be available on a domain controller.
FRS monitors SYSVOL and, if a change occurs to any file stored on SYSVOL, then
FRS automatically replicates the changed file to the SYSVOL folders on the other
domain controllers in the domain.
The day-to-day operation of SYSVOL is an automated process that does not require
any human intervention other than watching for alerts from the monitoring system.
Occasionally, you might perform some system maintenance as you change your
network.
This objective describes the basic tasks required for managing SYSVOL in order to
maintain capacity and performance of SYSVOL, for hardware maintenance, or for
data organization.
http://technet2.microsoft.com/WindowsServer/en/Library/551f0123-26a7-4ce5-
be71-173e7aa79bd31033.mspx
27) What is Dcdiag, netdiag, replmon, repstat and dsadiag? & How to use ?
DCDiag consists of a framework for executing tests and a series of tests to verify
different functional areas of the system. This framework selects which domain
controllers are tested according to scope directives from the user, such as enterprise,
site, or single server.
Netdiag
Netdiag is a command-line diagnostic tool that you can use to test network
connectivity and the key network status. These tests and information will give
network administrators and support personnel a more direct means of identifying
and isolating network problems.
Replication Monitor
Use REPLMON to query and control replication and to view the location of the FSMO
roles
You can use the DSADiag utility to display the current list of cached servers that
DSAccess is using (and thus supplying to DSProxy) and also to force DSAccess to
refresh the server list. DSADiag, which is available from http://www.exinternals.com,
is a single executable file. To use the utility, you must place the file in the
\exchsrvr\bin directory. Executing DSADiag from a command window
29) Explain by means of a scenario where would I require a tree, Child domain,
Additional Domain Controller?
Organizational Units
NOTE
The default Users and Computers folders in Active Directory are not technically
organizational units. Rather, they are technically defined as Container class objects.
It is important to understand this point because these Container class objects do not
behave in the same way as organizational units. To be able to properly utilize
services such as Group Policies that depend on the functionality of OUs, it is
recommended that you move your user and computer objects into an OU structure.
Each object in the Active Directory structure can be referenced via LDAP queries that
point to its specific location in the OU structure. You will often see objects referenced
in this format when you're writing scripts to modify or create users in Active
Directory or simply running LDAP queries against Active Directory. For example, in
Figure 6.2, a user named Andrew Abbate in the San Jose Users OU would be
represented by the following LDAP string:
NOTE
While there is a tendancy to use organizational units to structure the design of Active
Directory, OUs should not be created to just document the organizational chart of
the company. The fact that the organization has a Sales department, a
Manufacturing department, and a Marketing department doesn't suggest that there
should be these three Active Directory OUs. An administrator should create
organizational units if the departments will be administered separately and/or
policies will be applied differently to the various departments. However if the
departments will all be administered by the same IT team, and the policies being
applied will also be the same, having multiple OUs is not necessary.
Additionally, organizational units are not exposed to the directory, meaning that if a
user wants to send an e-mail to the members of an OU, he would not see the OU
structure nor the members in the OU grouping.
Groups
The idea of groups has been around in the Microsoft world for much longer than OUs
have been. As with the OU concept, groups serve to logically organize users into an
easily identifiable structure. However, there are some major differences in the way
that groups function as opposed to OUs. Among these differences are the following:
• Group Membership Viewable by Users—Whereas OU visibility is restricted
to administrators using special administrative tools, groups can be viewed by
all users engaged in domain activities. For example, users who are setting
security on a local share can apply permissions to security groups that have
been set up on the domain level.
• Membership in Multiple Groups—OUs are similar to a file system's folder
structure. In other words, a file can reside in only one folder or OU at a time.
Group membership, however, is not exclusive. A user can become a member
of any one of a number of groups, and her membership in that group can be
changed at any time.
• Groups as Security Principals—Each security group in Active Directory has
a unique Security ID (SID) associated with it upon creation. OUs do not have
associated Access Control Entries (ACEs) and consequently cannot be applied
to object-level security. This is one of the most significant differences because
security groups allow users to grant or deny security access to resources
based on group membership. Note, however, that the exception to this is
distribution groups, which are not used for security.
• Mail-Enabled Group Functionality—Through distribution groups and (with
the latest version of Microsoft Exchange) mail-enabled security groups, users
can send a single e-mail to a group and have that e-mail distributed to all the
members of that group. The groups themselves become distribution lists,
while at the same time being available for security-based applications. This
concept is elaborated further in the "Distribution Group Design" section later
in this chapter.
Groups in a Windows .NET Server 2003 come in two flavors: security and
distribution. In addition, groups can be organized into different scopes: machine
local, domain local, global, and universal.
Security Groups
The type of group that administrators are most familiar with is the security group.
This type of group is used to apply permissions to resources en masse so that large
groups of users can be administered more easily. Security groups can be established
for each department in an organization. For example, users in the Marketing
department can be given membership in a Marketing security group, as shown in
Figure 6.3. This group is then allowed to have permissions on specific directories in
the environment.
Distribution Groups
The concept of distribution groups in Windows .NET Server 2003 was introduced in
Windows 2000 along with its implementation of Active Directory. Essentially, a
distribution group is a group whose members are able to receive Simple Mail
Transfer Protocol (SMTP) mail messages that are sent to the group. Any application
that can use Active Directory for address book lookups can utilize this functionality in
Windows .NET Server 2003.
NOTE
Mail-Enabled Groups
With the introduction of Exchange 2000 into an Active Directory environment comes
a new concept: mail-enabled groups. These groups are essentially security groups
that are referenced by an e-mail address, and can be used to send SMTP messages
to the members of the group. This type of functionality becomes possible only with
the inclusion of Exchange 2000 or higher. Exchange 2000 actually extends the forest
schema to allow for Exchange-related information, such as SMTP addresses, to be
associated with each group.
Most organizations will find that mail-enabled security groups satisfy most of their
needs, both security-wise and e-mail–wise. For example, a single group called
Marketing that contains all users in that department could also be mail-enabled to
allow Exchange users to send e-mails to everyone in the department.
Group Scope
There are four primary scopes of groups in Active Directory. Each scope is used for
different purposes, but all simply serve to ease administration and provide a way to
view or perform functions on large groups of users at a time. The group scopes are
as follows:
Machine local groups are essentially groups that are built into the operating system
and can be applied only to objects local to the machine in which they exist. In other
words, they are the default local groups such as Power Users, Administrators, and
the like created on a standalone system. Before networking simplified administration,
local groups were used to control access to the resources on a server. The downside
to this approach was that users needed to have a separate user account on each
machine that they wanted to access. In a domain environment, utilizing these groups
for permissions is not recommended because the administrative overhead would be
overwhelming.
NOTE
Domain controllers in an Active Directory forest do not contain local groups. When
the dcpromo command is run on a server to promote it to a domain controller, all
local groups and accounts are deleted in favor of domain accounts. Essentially, the
local groups and users are replaced with a copy of the domain groups and users. Any
special permissions using local users must be reapplied using domain accounts.
Domain local groups, a term that may seem contradictory at first, are domain-level
groups that can be used to establish permissions on resources in the domain in
which they reside. Essentially, domain local groups are the evolution of the old
Windows NT local groups.
Domain local groups can contain members from anywhere in an Active Directory
forest or any trusted domain outside the forest. A domain local group can contain
members from any of the following:
• Global groups
• User accounts
• Universal groups (in AD Native mode only)
• Other domain local groups (nested, in Native mode only)
Domain local groups are primarily used for access to resources because different
domain local groups are created for each resource and then other accounts and/or
groups are added to them. This helps to readily determine which users and groups
have access to a resource.
Global Groups
Global groups are the reincarnation of the NT global group, but with slightly different
characteristics. These groups can contain the following types of objects:
• User accounts
• Global groups from their own domain (Native mode only)
Global groups are primarily useful in sorting users into easily identifiable groupings
and using them to apply permissions to resources. What separates global groups
from universal groups, however, is that global groups stop their membership
replication at the domain boundary, limiting replication outside the domain.
Universal Groups
The concept of universal groups was new with the release of Windows 2000 and has
become even more useful in Windows .NET Server 2003. Universal groups are just
that—universal. They can contain objects from any trusted domain and can be used
to apply permissions to any resource in the domain.
Universal groups are available only in Native Windows .NET Server 2003 or Windows
2000 modes and cannot be used in Interim or Windows NT Mixed mode. This is
because Windows NT4 backup domain controllers (BDCs) cannot replicate the
functionality present in universal groups.
Although simply making all groups within a domain into universal groups may seem
practical, the limiting factor has always been that membership in universal groups is
replicated across the entire forest. To make matters worse, Windows 2000 Active
Directory universal group objects contained a single multi-entry attribute that
defined membership. This meant that any time membership was changed in a
universal group, the entire group membership was re-replicated across the forest.
Consequently, universal groups were limited in functionality.
Windows .NET Server 2003 introduces the concept of incremental universal group
membership replication, which accomplishes replication of membership in universal
groups on a member-by-member basis. This drastically reduces the replication
effects that universal groups have on an environment and makes the concept of
universal groups more feasible for distributed environments.
36) What is the Difference between Basic Disk & Dynamic disk?
Lmhost
A local hosts file used by Microsoft Wins Clients such as Microsoft Windows 98 or
Windows NT to provide mappings of IP addresses to NT computer names (NetBIOS
name). The lmhost file is generally located in either root Windows directory or the
Windows\System32\drivers\etc directory and is called "lmhost.sam". The lmhost file
will likely already contain data in the file, such as commented instructions and
examples similar to the below example.
In the above two examples, you can see that we have specified the IP address, the
name, and the # remark for that line. In the above example, "localhost" or
"example" would be the NetBIOS name; therefore, when typing "localhost" or
"example" in Internet Explorer, for example, the computer would attempt to resolve
that name by accessing the IP address corresponding with that name. This is also
commonly used when unable to access or having difficulties with the DNS server.
NTFS permissions are an attribute of the folder or file for which they are configured.
The NTFS permissions include both standard and special levels of settings. The
standard settings are combinations of the special permissions, making the
configuration more efficient and easier to establish. These permissions include the
following, as shown in Figure 2:
Full Control
Modify
Read & Execute
List Folder Contents
Read
Write
There are 14 special permissions for folders, which include detailed control over
creating, modifying, reading, and deleting subfolders and files contained within the
folder where the permissions are established.
NTFS permissions are associated with the object, so the permissions are always
connected with the object during a rename, move, or archive of the object.
Share permissions are only associated with the folder that is being shared. For
example, if there are 5 subfolders below the folder that is shared, only the initial
shared folder can have share permissions configured on it. NTFS permissions can be
established on every file and folder within the data storage structure, even if a folder
is not shared.
Share permissions are configured on the Sharing tab of the shared folder. On this
tab, you will have a Permissions button, which exposes the share permissions when
selected, as shown in Figure 3.
Figure 3: Share permissions on a shared folder
As you can see, the share permissions standard list of options is not as robust as the
NTFS permissions. The share permissions only provide Full Control, Change, and
Read. There are no special permissions available for share permissions, so the
standard permissions are as granular as you can go for this set of access control.
The share permissions are not part of the folder or file, so when the share name is
changed, the folder is moved, or the folder is backed up, the share permissions are
not included. This makes for a fragile control of the share permissions if the folder is
modified.
• Aysmmetric: one CPU does the work of the system, the other CPUs service
user requests.
• Symmetric: All processors can be used by the system and users alike. No
CPU is special.
The asymmetric variant is potentially more wasteful, since it is rare that the system
requires a whole CPU just to itself. This approach is more common on very large
machines with many processors, where the jobs the system has to do is quite
difficult and warrants a CPU to itself.
The Internet is a collection of networks whose users communicate with each other.
Each communication carries the address of the source and destination networks and
the particular machine within the network associated with the user or host computer
at each end. This address is called the IP address (Internet Protocol address). This
32-bit IP address has two parts: one part identifies the network (with the network
number) and the other part identifies the specific machine or host within the network
(with the host number). An organization can use some of the bits in the machine or
host part of the address to identify a specific subnet. Effectively, the IP address then
contains three parts: the network number, the subnet number, and the machine
number.
The standard procedure for creating and identifying subnets is provided in Internet
The IP Address
The 32-bit IP address (we have a separate definition of it with IP address) is often
depicted as a dot address (also called dotted quad notation) - that is, four groups (or
quads) of decimal numbers separated by periods. Here's an example:
130.5.5.25
Each of the decimal numbers represents a string of eight binary digits. Thus, the
above IP address really is this string of 0s and 1s:
10000010.00000101.00000101.00011001
As you can see, we inserted periods between each eight-digit sequence just as we
did for the decimal version of the IP address. Obviously, the decimal version of the IP
address is easier to read and that's the form most commonly used.
Some portion of the IP address represents the network number or address and some
portion represents the local machine address (also known as the host number or
address). IP addresses can be one of several classes, each determining how many
bits represent the network number and how many represent the host number. The
most common class used by large organizations (Class B) allows 16 bits for the
network number and 16 for the host number. Using the above example, here's how
the IP address is divided:
To simplify this explanation, we've divided the subnet into a neat eight bits but an
organization could choose some other scheme using only part of the third quad or
even part of the fourth quad.
Using the previous example (which is a very typical case), the combined network
number and subnet number occupy 24 bits or three of the quads. The appropriate
subnet mask carried along with the packet would be:
255.255.255.0
Or a string of all 1's for the first three quads (telling the router to look at these) and
0's for the host number (which the router doesn't need to look at). Subnet masking
allows routers to move the packets on more quickly.
If you have the job of creating subnets for an organization (an activity called
subnetting) and specifying subnet masks, your job may be simple or complicated
depending on the size and complexity of your organization and other factors.
44) Explain the procedure for migrating from Windows NT4.0 to Windows 2000?
1. Upgrade the PDC in the master domain that will be the root domain. Upgrade
the PDC to Windows 2000.
2. Use mixed mode for active directory.
3. Upgrade BDCs and servers to Windows 2000.
4. Update client computers in the domain to Windows 2000 or install Directory
Service Client onm.
5. Follow the same procedure for each succeeding domain down through the
domain tree.
6. Once all updates are complete, the multiple domains may be merged into one
or reconfigured using Windows 2000 tools.
When the NT Domain controller is upgraded to Windows 2000, the following changes
are made:
Microsoft has done quite a bit of tuning on Active Directory in Windows Server 2003
to improve scalability and speed and to correct a couple of key deficiencies. Some of
these updates might not make much sense until you read further, but here is a
synopsis to use for reference. The first three features require having Windows Server
2003 on every domain controller:
Terms:
• Domain tree - A hierarchial group of one or more domains with one root
domain. Only one domain is required to make a tree.
• Parent domain - One domain above another in a domain tree.
• Child domain - One domain below another in a domain tree. The child
inherits the domain name of its parent in a DNS hierarchial naming
convention. Example: "child.parent.root.com".
• Forest root domain The first domain created in a forest.
• Tree root - The first domain created in a tree.
Trust relationship is a description of the user access between two domains consisting
of a one way and a two way trust. Terms:
• One way trust - When one domain allows access to users on another
domain, but the other domain does not allow access to users on the first
domain.
• Two way trust - When two domains allow access to users on the other
domain.
• Trusting domain - The domain that allows access to users on another
domain.
• Trusted domain - The domain that is trusted, whose users have access to
the trusting domain.
• Transitive trust - A trust which can extend beyond two domains to other
trusted domains in the tree.
• Intransitive trust - A one way trust that does not extend beyond two
domains.
• Explicit trust - A trust that an administrator creates. It is not transitive and
is one way only.
• Cross-link trust - An explicit trust between domains in different trees or in
the same tree when a descendent/ancestor (child/parent) relationship does
not exist between the two domains.
This means the two way non transitive trust supported by Windows NT is no longer
supported. The way to deal with this is to create two one way trusts in Windows
2000.
Controllers
Terms:
• Forest root controller - The first domain controller created when Active
Directory is first installed on any computer if there are no previously installed
controllers available on the network.
Windows NT 4.0 does not support transitive trusts. All windows 2000 Active
Directory trusts are transitive by default with trusts existing between parents and
children. Transitive trusts do not exist between children even if they are of the same
parent. Transitive trusts extend up and down through parents to children to
grandchildren and so on. Administrators may create explicit trusts between any
two domains.
It is good policy for the administrator to set up a root domain with the administrator
account. This will allow all child domains to be controlled from that domain.
• Schema
• Configuration data - Forest, tree, and domain information.
• Domain data - Information about all domain objects sent to domain
controllers in the domain.
Domain Controllers
Windows NT uses a Primary Domain Controller (PDC) and Backup Domain Controllers
(PDC) to control the operations of its domains. The BDC or BDCs back up the
operations of the PDC in the event that it fails. Data is constantly replicated between
these controllers. Windows 2000 has changed this method of controlling the domain.
• Native mode - In this mode Active Directory interfaces only with Windows
2000 domain controllers and directory service client software. Windows 2000
is more efficient in native mode. In this case, the PDC emulator will get
password changes faster.
• Mixed mode - Used to support domains where there are still Windows NT
domain controllers. Mixed mode occurs when Active Directory interfaces with
NT 4.0 BDCs or ones without Windows 2000 Directory Service client software.
In mixed mode, computers without Windows 2000 client software must
contact the PDC emulator to change user account information
1. local group
2. domain local group
3. domain global group
4. domain univesal group
Remember that "local", "global", "universal" refers to where these groups may be
assigned permissions and are not related to the group membership itself. But let's
define each of them now:
1. Local group: The members of this group type can be assigned permissions only
localy on the computer where the group exist. It cannot be used to assign
permissions on the domain and this group is not known by other computers.
However, it can contain local security accounts (created on the same computer - in
the local security database SAM) or other domains members accounts (when the
machine/computer is part of a domain) from any domain.
Example: when you join the computer to a domain, the domain administrator
account is automaticaly added to the local Administrators group. That's why a
domain administrator can handle administrative tasks on any domain client
computer. But you cannot use this local "Administrators" group to assign permissions
on any other computer/resource on the domain. You will use this group only locally
on the computer it exists. "Administrators" membership could be domain1\user1,
domain2\user2, localuser3, etc.
2. Domain Local group: can have as their members, accounts, global groups, and
universal groups FROM ANY DOMAIN, as well as domain local groups from the same
domain. This groups can belong to another domain local groups and assigned
permissions only in the same domain. Can be converted to universal scope, as long
as it does not have as its member another group having domain local scope.
Example: Suppose you were the network administrator for a three domains network.
Now you have to give permissions to some users from domain2 and domain3 to
resources located in domain1. What you do? Well ... You can create a domain local
group in the domain1 and then assign the respective users from domain2 and
domain3 to the group you have just created in domain1. Then use this group to
assign permissions to resources inside domain1 only. You will not be able to assign
permissions for this group in other domains resources!! However, you did add users
from other domains.
3. Domain Global group: can have as their members accounts and global groups
FROM THE SAME DOMAIN. Can be converted to universal scope, as long as it is not a
member of any other group having global scope.
Example: You create a "group1" in the "domain1" domain. Then you add accounts,
other global groups from the same domain to it. You can use this group to assign
permissions to resources located on other domains or for other domain
administrators to assign permissions to your domain users in their own domains
resources.
4. Domain Unversal group: can have as their members accounts FROM ANY DOMAIN,
global groups from any domain and universal groups FROM ANY DOMAIN. This group
cannot be converted to any other group scope.
Example/Some more detail: This is the less restrictive group. For some
administrators it might be a better solution for easy administration. However the use
of Universal Group have a big impact on active directory performance because the
universal group memebership is stored on the global catalog. There might algo occur
problems with the login. When a user login, if the user belongs to a Universal group,
a global catalog most be found otherwise the user would not be able to login. If the
user doesn't belong to a universal group, cached credentials are used if a global
catalog cannot be found. In that case, if the user had never before loged in, cached
credentials doesn't exist, therefore the user will not be able to login also.
Note1: If you have multiple forests, users defined in only one forest cannot be placed
into groups defined in another forest, and groups defined in only one forest cannot
be assigned permissions in another forest.
Note2: Group nesting is available only when in Native mode. In mixed mode,
universal groups cannot be used. There are also some differences about the way the
PDC emulator works. But you will learn about it ... It's related with AD authentication
and with the mster operation roles.
Now, why add a global group to domain local group? This is because it's a best
practice to always assign permissions to groups and not to users individualy. I will
try to give you a practical approach.
Let's assume again that you are a network administrator for a company with 50
users. If you were to assign permissions for a network resource it's better (from the
administrator's point of view) to define permissions only once (for a group) than
assigning permissions for every time a user have to be given access. So, that's the
reason why even having a single user, you put it inside a group and then assign
permissions to the group itself. In the future when you need to assign permissions to
other users, you just add them to the group and usualy, they will have to log-off and
log-in again. Don't you agree ? :)
Now the A G DL P concept goes all arround this. It's just a bit more generic and does
make a lot sense when in an environement with multiple domains !! So you put
ACCOUNT inside a GLOBAL GROUP. Then the GLOBAL GROUP you put it inside the
DOMAIN LOCAL GROUP and finaly, you assign PERMISSIONS.
One practical example: There are 2 domains (dom1 and dom2). You are
administering dom1. If the dom2 administrator tells you that some of his users need
access to some resources located in your domain (in dom1). You say to the dom2
administrator to create a global group in domain dom2 and put the users inside it.
Then you take that global group in put it inside a domain local group and assign
permissions for this domain local group to the specified resources in your domain.
Now, for everytime the dom2 administrator wants to add/remove a user he just need
to remove the user/users from the global group in his domain (because he doesn't
have permission on dom1 domain).
If you were assigning users to a domain local group, every time the dom2
administrator wanted to add a user, he will have to contact you and only you would
be the person allowed to make the change because only you have permissions in
your domain (it might be the case).
some advantages:
1. You, as dom1 domain administrator assign permissions only once.
2. you will not have to worry in the future if the dom2 domain administrator wants to
add/remove users from the users list witch might have access to specified resources.
Requirements:
o Server name
o Targer containers
o Objects to be synchronized
o Synchronization schedule
ADC Installation:
o Replication
o Account Management - Events while writing to or deleting an objects.
o Attribute Mapping - Events while attributes are mapped between AD
and Exchange.
o Service Controller - Events when the ADC service is stopped or
started.
o LDAP Operations - Events when LDAP accesses the directory.