Information on technology

Active Directory Management

Active Directory allows administrators to manage large numbers of users, computers, printers,  and network resources from a central location by using the administrative tools that Windows server 2003 provides. Active Directory also supports decentralized administration by allowing an administrator with the proper authority to delegate a selected set of administrative privileges to appropriate users or groups within an organization. Active Directory provides a number of features that allow administrators to manage resources centrally. The following  describes

How Active Directory enable Centralized Administration.

1.    Active Directory contains information about all objects and their attributes. The attributes hold data that describes the resource that the directory object identifies. Because information about all network resources is stored in Active Directory, a single administrator can centrally manage and administer network resources.

2.    Active Directory can be queried by using protocols such as LDAP. Administrators can easily locate information about objects by searching for selected attributes of the object, using tools that support LDAP.

3.    Active Directory allows you to group objects with similar administrative and security requirements into organizational units. Organizational units provide multiple levels of administrative authority for both applying Group Policy settings and delegating administrative control. This delegation of administrative authority simplifies the task of managing these objects and allows administrators to structure Active Directory to fit their needs.

4.    Active Directory uses Group Policy to provide administrators with the ability to specify Group Policy settings for a site, domain, or organizational unit. Active Directory then enforces these Group Policy settings for all of the users and computers within the container.

 How Active Directory Supports Decentralized Management:

Active Directory enables you to delegate administrative privileges for certain objects to appropriate groups within an organization. This is possible because the structure of Active Directory allows you to assign permissions and grant user rights in very specific ways. We can delegate the following types of administrative control:

1.    Assigning permissions, such as Full Control, for specific organizational units to different domain local groups.

2.    Assigning the permissions to modify specific attributes of an object in a single organizational unit. For example, assigning the permission to change name, address, and telephone number, and to reset passwords on a user account object.

3.     Assigning the permissions to perform the same task, such as resetting passwords, in all organizational units of a domain.

Some common GUI tools for administering Active Directory.

1.    Active Directory Users and Computers  A Microsoft Management Console (MMC) hat you can use to administer and publish information in the directory. Using Active Directory Users and Computers, you can manage user accounts, groups, and computer accounts, add computers to a domain, manage account policy, user rights, and audit policy.

2.    Active Directory Domains and Trusts An MMC that you can use to administer domain trusts and forest trusts, add user principal name suffixes, and change the domain and forest functional levels.

3.    Active Directory Sites and Services An MMC that you can use to administer the replication of directory data.

4.    Active Directory Schema The Active Directory Schema MMC is an Active Directory administrative tool for managing the schema. It is not available by default on the Administrative Tools menu, and must be added manually.

5.    CSVDE  Imports and exports Active Directory data by using comma-separated format.

6.    LDIFDE  Can be used to create, modify, and delete Active Directory objects. This tool can also be used to extend the Active Directory schema, export user and group information to other applications or services, and populate Active Directory with data from other directory services.

7.    ADSI Editor  The ADSI editor is an MMC snap-in that can be used to view, create, modify and delete objects in Active Directory.ADSI provides a simple, powerful, scriptable interface to Active Directory to enable administrators to create reusable scripts for managing Active Directory. ADSI uses the LDAP protocol to communicate with Active Directory.

You can create scripts by using ADSI to perform the following tasks:

1.    Retrieve information about Active Directory objects

2.    Add objects to Active Directory

3.    Modify Active Directory object attribute values 

4.    Delete objects form Active Directory

5.    Extend the Active Directory schema

ADS and DNS Integration

DNS domains and Active Directory domains use identical domain names for different Namespaces. Using identical domain names enables computers in a Windows Server 2003 network to use DNS to locate domain controllers and other computers that provide Active Directory.related services.The integration of DNS and Active Directory is essential because a client computer in a Windows Server 2003 network must be able to locate a domain controller to allow users to log on to a domain or to use the services provided by Active Directory. To locate a domain controller, a computer uses DNS to locate the IP address for a computer that provides the required service within Active Directory.

Active Directory Integrated Zones

One of the benefits of integrating DNS and Active Directory is the capability to integrate DNS zones into the Active Directory database. A zone is a portion of the domain namespace that has a logical grouping of resource records allowing zone transfers of these records as a single unit.

Microsoft DNS servers store information that is used to resolve host names to IP addresses and IP addresses to host names, in a database file with the extension .dns, for each zone. Active Directory integrated zones are primary and stub DNS zones that are stored as objects in the Active Directory database. Zone objects can be stored in an Active Directory application partition or in an Active Directory domain partition. If zone objects are stored in an Active Directory application partition, only domain controllers that subscribe to the application partition will participate in the replication of this partition. However, if zone objects are stored in an Active Directory domain partition, they will be replicated to all Domain Controllers in the Domain

 
SRV RESOURCE RECORDS

For Active Directory to function properly, client computers must be able to locate servers that provide specific services such as authenticating logon requests and searching for information in Active Directory. To achieve this, Active Directory stores information about the location of the computers that provide these services in DNS records known as SRV resource records.

SRV resource records link the name of a service to the DNS computer name for the computer that offers that service. For example, an SRV record can contain information to help clients locate a domain controller in a specific domain or forest.

When a domain controller starts, it registers SRV records, which contain information about the services it provides, and an A resource record that contains its DNS computer name and its IP address. A DNS client later uses this combined information to locate the requested service on the appropriate domain controller.

All SRV records use a standard format, which consists of fields that contain the information used to map a specific service to the computer that provides the service.

SRV records use the following format:

The following is an example of an SRV record of a computer:

_ldap._tcp.contoso.msft 600 IN SRV 0 100 389 london.contoso.msft

The SRV record indicates that the computer provides the following services:

1.    Provides the LDAP service

2.     Provides the LDAP service by using the TCP transport protocol

3.    Registers the SRV record in the contoso.msft DNS domain

4.    Has a time to live (TTL) of 600 seconds or 10 minutes.

5.    Has an FQDN of london.contoso.msft

Procedure for viewing SRV records by using the DNS Snap-in

You can use either the DNS console or the NSLookup utility to view the SRV records registered by domain controllers. To view the SRV resource records registered domain controllers by using the DNS snap-in, perform the following steps:

1.    Open DNS from the Administrative Tools menu.

2.    Double-click Server (where Server is the name of your DNS server),double-click  forward Lookup Zones, and then double-click domain

3.    Open the following folders in the domain folder to view the SRV resource records that are registered:

•  _msdcs

•  _sites

•  _tcp

•  _udp

How clients locate resources ?

To log on to a Windows Server 2003 domain or to search Active Directory, a client computer must contact a domain controller. All domain controllers register both A resource records and SRV records. The A resource record contains the FQDN and IP address for the domain controller. The SRV record contains the FQDN of the domain controller and the name of the service that the domain controller provides. Therefore, the client computer can query DNS

to locate a domain controller.

The following describes the process of how a computer locates a domain controller:

1.    A user logs on to the domain, initiates an Active Directory search, or performs other tasks that require a domain controller. The Net Logon service on the client (the computer that is locating the domain controller) starts the DsGetDcName application programming interface (API).

2.    Net Logon collects information about the client and the specific service required; this information will be included in the DNS query. This information is specified by the following DsGetDcName parameters:

•  ComputerName. The name of the client computer.

•  DomainName. The name of the DNS domain that will be queried.

•  SiteName. The name of the site in which the domain controller should be located. I

if the  site is not specified, the domain controller that will be located is in the site that is

closest to the site in which the client computer is located. The client also specifies that

the domain controller should be an LDAP server in the domain named by DomainName,

or a global catalog server or KDC server for the forest in which DomainName is located.

3.    The Net Logon service sends a DNS query to a DNS server. This DNS query contains the information it collected from the client and specifies the service that is required.

4.    The DNS server queries the DNS zone database for SRV records that match the service required by the client in the domain named by DomainName. T

5.    he DNS server returns a list of IP addresses of domain controllers that provide the service requested in the domain specified by the client.

6.    The Net Logon service sends a datagram (an LDAP UDP message) to one or more of the located domain controllers to determine whether it is running and whether it supports the specified domain.

7.    Each available domain controller responds to the datagram to indicate that it is currently operational, and then returns the information to DsGetDcName. The Net Logon service returns the information to the client from the domain controller that responds first.

8.    The client computer chooses the first domain controller that responds and meets the criteria, and then sends the request to that domain controller. The Net Logon service  caches the domain controller information so that it is not necessary that the client computer repeat the discovery process for subsequent  requests. Caching this information also encourages the consistent use of the same domain controller.

The purpose of SID

Windows uses a data structure known as a Security ID (SID) to identify users, computers and groups. SIDs have two components. The first part uniquely identifies a domain; the second part uniquely identifies a user account, computer account, or group managed by that domain. Windows uses SIDs to identify users and groups in access control lists (ACLs) and group

memberships. When a user account is migrated to a different domain, it is assigned a new SID, which results in the loss of group memberships based on the old account SID. SID history is an attribute on user and group objects in Active Directory and is used to hold the previous SID of a migrated user account. If a user account is migrated multiple times, SID history stores a list of all the SIDs the user was assigned. SID history provides a migrated user with continuity of access to resources, until all the necessary groups or ACLs can be updated using the new account SID.

When a Windows Server 2003 domain controller authenticates a user, it computes group memberships using both the current user account SID, and any SIDs in SID history. If the user account has been migrated, access to resources based on the previous account is maintained.