Introduction to Group Policy Group policies are used to restrict what a user can and cant do.

For example, they can be used to remove the run command from a users start menu, or to set a specific background image. Group policies are very similar to the local policies , but on a workstation computer the Domain group policy always overrides the Local one. This is the Effective Setting for a machine joined to a domain. Use the buttons below to navigate through the lesson

Group policies can be applied to either a particular computer, or a particular user. When applied to a computer, the settings are applied to all users who log onto that computer. When applied to a user, the settings apply to that particular user, no matter which computer he/she logs on to. Group policies are used for: Efficiency reducing network traffic, thus lowering running costs. Security - preventing users from tampering with things they shouldnt, thus increasing productivity and reducing administration costs.

Group Policy Inheritance Group policy inheritance affects the order in which different policies are processed. This may not sound impressive, but its important. Sadly, this is only true up to a point. There are other considerations. For example, a later GPO may not make any conflicting changes to an earlier policy so the earlier policy appears to survive. The picture is also complicated by the NO Override and Block Policy Inheritance settings that can be applied to a GPO.

Use the buttons below to navigate through the lesson

GPO Application Order This can be summarised thus:

GPO level
Local

Applies to:
All users on the local computer. All users and computers in the site. All users and computers in the domain.

Overridden by:
GPOs applied to the site, domain or Organisational Unit. Group Policy Objects applied to the domain or Organisational Unit.

Site

Domain Organisational Unit

GPOs applied to the Organisational Unit. Nothing OU GPOs have precedence over all other policies

All users and computers in the OU

To illustrate how GPOs are applied, consider this site which contains two domains, each with two OUs, each with several local machines

The Site GPO is applied next. The policy is that all screens shall be RED: GPOs are applied in this order: Local Site Domain Organisational Unit Local policies are in effect on the local workstations to give them red or blue wallpaper as they choose. The Site GPO is applied next. The policy is that all screens shall be RED: The Site-level GPO affects everything in it, whether its a domain, OU or local machine. The Domain GPO is applied next. As policy is that all screens shall be RED while Bs policy is to have Blue Screens. The Domain-Level GPO affects everything in it, too. The OU GPO is applied next. Bobs policy is that all screens shall be Blue while Alfs policy is to have red screens. Note that the last GPO applied can change what went before. Anns policy is to have Blue Screens, while Beas doesnt specify anything in this regardso nothing apparently changes. The default behaviour of group policy objects can be overridden using the Block Policy Inheritance and No Override options. If this latter option is selected for a GPO linked to the site or domain, policies further down the chain (such as in an OU) will not override them.

Anns GPO specifies a red screen. Normally, as the last applied GPO, it would be the one to count in this scheme of things, but the Purple GPO specifies blue screens, and has the No Override option set for this link. The OU GPO does not override it If the Block Policy Inheritance option is selected at the OU or domain level, the policies further up the chain (such as those applied to a site) will not take effect. The Purple GPO specifies Red screens, but Ann OUs Block Policy Inheritance prevents the Site GPO being applied in the first place. If an OU has the Block Policy Inheritance option set, but the domain has No Override on one of its GPOs, the domain has its GPO applied. This is because a domain administrator may want to prevent the person delegated control of an OU from overriding their settings. the Purple GPO specifies blue screens, and has the No Override option set for this link. The OUs Block Policy Inheritance cannot block this. Click Start. Click Administrative Tools. Click Active Directory Users and Computers. Right click any OU that has a GPO linked to it. Right click any OU that has a GPO linked to it. Click Properties. Click Group Policy. Click Block Policy Inheritance. The OU GPO will now take priority, and all GPOs applied at the domain or site level will no longer apply to the objects in this Organisational Unit. Click OK. Right-click the domain. Click Properties. Click Group Policy. Click Options. Click the No Override checkbox. Click OK. The tick means that No Override has now been selected for this GPO. It will propagate its policies to the OU GPO regardless of the Block Policy Inheritance setting. Click OK. Group Policy Permissions Using group policy permissions you can deny a user read permission to a GPO which will prevent the policy being applied to that user. This is useful when you dont want to apply a GPO to a user but you want them to be a member of the container. You could , for example block a single user from using a GPO which automatically installs Microsoft Office. Permissions can be configured by bringing up the properties for the GPO. A useful option in the GPO properties page is to disable the computer or user configuration. If you have no policies in one of the configurations then it can improve performance by disabling it. Select the Security tab to configure permissions. You can then add or remove permissions as needed

Creating a Group Policy Scenario: your company has just employed a temporary worker who is tasked with editing xml documents. He requires an xml editor to be installed on his workstation. This is a large project and may require further editors to be employed. To ease the administration of the software deployment, you decide to create a group policy to automatically install the software for all users in the Tempworkers group.

Use the buttons below to navigate through the lesson

Wait- not all the users in the Tempworkers group require this editor, far better to create a group for the xml editors. Create a group inside the Tempworkers OU called xml_users, the group policy can then be focused on this group only.

Select Start>Administrative Tools>Group Policy Management. Expand the domain. Right click the OU and select Create a GPO in this domain and link it here. Type in a name for the new GPO and click OK. Right click the new GPO and select Edit. Expand User Configurations>Policies. Right click Software Settings. Select New>Package. Select the software package MSI file. Ensure that the package is selected with a network accessible path. I.E. \\Server\share. Click Open. Select Assigned and then OK. Deployment options explained in next slide. Select Assigned and then OK. Publish (User only) Assign (User) The next time a user logs on. The Control Panel Add Or Remove Programs (Windows XP) or Programs And Features (Windows Server 2008 and Windows Vista) applications. The next time a user logs on. Assign (Computer) The next time the computer starts.

After deployment of the GPO, the software is available for installation:

Typically, the user installs the software from: If the software is not installed and the user opens a file associated with the software, does the software install?

Start menu or desktop shortcut. An application can also be configured to install automatically at logon.

The software is installed automatically when the computer starts up.

Yes (if auto-install is enabled).

YES Yes, and the software is available for installation again from the Start menu shortcuts or file associations.

Does not apply; the software is already installed.

Can the user remove the software by using Control Panel?

Yes, and the user can choose to install it again from Control Panel. Windows Installer packages (.msi files), .zap files.

No. Only a local administrator can remove the software; a user can run a repair on the software.

Supported installation files:

Windows Installer Windows Installer packages (.msi files) packages (.msi files)

Right click the new package. Select Properties. Select Deployment tab. Ensure Install the application at logon is checked. Ensure Uninstall this application when it falls out of the scope of management is checked. Click OK. Close the Editor. Select the policy. You need focus this group policy for the xml_users group only. In Security Filtering highlight the Authenticated Users and click Remove. Click OK to confirm the deletion.. Click Add. Locate xml_users and click OK. The focus of this group policy is set to xml_users group only. Upgrading a software package

After deploying the software the manufacturer advises you there has been an updated software release. You have evaluated the new release and decide to upgrade the existing software. Again to ease the administration you will implement the upgrade via a group policy. Right click the software package and select Edit. Expand User Configuration>Policies>Software Settings. Right click Software installation and select New>Package. Select the software package MSI file. Ensure that the package is selected with a network accessible path. I.E. \\Server\share. Select Advanced then click OK. Select Upgrades tab. Click Add. Select the package to be upgraded and click OK. Click OK. Close Editor. Xml Editor installed.

Post navigation

Auditing Authentication
Configuring Password and Lockout Policies In a Windows Server 2008 domain, users are required to change their password every 42 days, and a password must be at least seven characters long and meet complexity requirements including the use of three of four character types: uppercase, lowercase, numeric, and nonalphanumeric.

Use the buttons below to navigate through the lesson

Three password policiesmaximum password age, password length, and password complexityare among the first policies encountered by administrators and users alike in an Active Directory domain. Rarely do these default settings align precisely with the password security requirements of an organization. Your organization might require passwords to be changed more or less frequently or to be longer. There are exceptions to every rule, and you likely have exceptions to your password policies. To enhance the security of your domain, you can set more restrictive password requirements for accounts assigned to administrators, for accounts used by services such as Microsoft SQL Server, or for a backup utility. In earlier versions of Windows, this was not possible; a single password policy applied to all accounts in the domain.In this lesson, you will learn to configure fine-grained password policies, a new feature in Windows Server 2008 that enables you to assign different password policies to users and groups in your domain. If the new password meets requirements, Active Directory puts the password through a mathematical algorithm that produces a representation of the password called the hash code. The hash code is unique; no two passwords can create the same hash code. The algorithm used to create the hash code is called a one-way function. You cannot put the hash code through a reverse function to derive the password. The fact that a hash code, and not the password itself, is stored in Active Directory helps increase the security of the user account. The password settings configured in the Default Domain Policy affect all user accounts in the domain. The settings can be overridden, however, by the password-related properties of the individual user accounts. On the Account tab of a users Properties dialog box, you can specify settings such as Password Never Expires or Store Passwords Using Reversible Encryption. For example, if five users have an application that requires direct access to their passwords, you can configure the accounts for those users to store their passwords, using reversible encryption. In this lesson, you will learn how to implement your enterprises password and lockout policies by modifying the Default Domain Policy Group Policy object (GPO). Click Group Policy Management. Expand the domain. Right Click Default Domain policy and click Edit. Expand Computer Configuration>Policies>Windows Settings>Security Settings. Expand Account Policies. Select Password Policies. Right Click Maximum password age and select Properties. Change Password will expire in: to 30 days. Click OK. Maximum password age is now set to 30 days. Next select Account lockout policy and right click Account lockout threshold and select Properties. Set invalid logon attempts to 3. When you Click OK Windows will suggest values for

the remaining policies, Click OK to accept these. The suggested values can be changed later. Click OK. The Account lockout policy is now configured. All open dialogue boxes can now be closed. Fine-Grained Password and Lockout Policy You can also override the domain password and lockout policy by using a new feature of Windows Server 2008 called fine-grained password and lockout policy, often shortened to simply fine-grained password policy. Fine-grained password policy enables you to configure a policy that applies to one or more groups or users in your domain. To use fine-grained password policy, your domain must be at the Windows Server 2008 domain functional level. To raise the domain functional level open Active Directory Users and Computers. Right click the domain and select Raise domain functional level. Select Windows Server 2008 and click Raise. Warning Raising the domain functional level cannot be reversed. Click OK to continue. Click Close to complete. Fine-Grained Password and Lockout Policy The settings managed by fine-grained password policy are identical to those in the Password Policy and Accounts Policy nodes of a GPO. However, fine-grained password policies are not implemented as part of Group Policy, nor are they applied as part of a GPO. Instead, there is a separate class of object in Active Directory that maintains the settings for fine-grained password policy: the password settings object (PSO). Most Active Directory objects can be managed with user-friendly graphical user interface (GUI) tools such as the Active Directory Users and Computers snap-in. You manage PSOs, however, with low-level tools, including ADSI Edit. In this exercise, you will create a PSO that applies a restrictive, fine-grained password policy to users in the Domain Admins group. Before you proceed with this exercise, confirm that the Domain Admins group is in the Users container. If it is not, move it to the Users container. Click Administrative tools>ADSI Edit. Expand the domain. Expand CN=System. Select CN=Password Settings Container. Right click and select New>Object. Click Next to continue. Type a name for the new object and click Next. PSO Precedence and Resultant PSO A PSO (Password Settings Object) can be linked to more than one group or user, an individual group or user can have more than one PSO linked to it, and a user can belong to multiple groups. So which fine grained password and lockout policy settings apply to a user? One and only one PSO determines the password and lockout settings for a user; this PSO is called the resultant PSO. Each PSO has an attribute that determines the precedence of the PSO. The precedence value is any number greater than 0, where the number 1 indicates highest precedence. If multiple PSOs apply to a user, the PSO with the highest precedence (closest to 1) takes effect. Set the Precedence value to 1 and click Next. Type False The password is not stored using reversible encryption and click Next. Type 30 The user cannot reuse any of the last 30 passwords and click Next. Type True Password complexity rules are enforced and click Next. Type 10 Password must be at least 10 characters in length and click Next. Type 1:00:00:00. A user cannot change his or her password within one day of a previous change. The format is d:hh:mm:ss (days, hours, minutes, seconds) and click Next. Type 45:00:00:00. The password must be changed every 45 days and click Next. Type 5. Five invalid logons within the time frame specified by (the next attribute) will result in account lockout and click Next. Type 0:01:00:00. Five invalid logons (specified by the previous attribute) within one hour will result in account lockout and click Next. Type 0:01:00:00. An account, if locked out, will remain locked for one hour or until it is unlocked manually. A value of zero will result in the account remaining locked out until an administrator unlocks it and click Next. The attributes listed are required. After clicking Next on the msDSLockoutDuration attribute page, you will be able to configure the optional attribute. Click the More Attributes button. In the Edit Attributes box, type CN=DomainAdmins,CN=Users,DC=es-net,DC=co,DC=uk and click Set. Click OK. The new PSO is now active.

Resultant PSO To identify the PSO that controls the password and lockout policies for an individual user. Open the Active Directory Users And Computers snap-in. Click the View menu and make sure that Advanced Features is selected. Expand the domain and click the Users container in the console tree. Right-click the Administrator account and choose Properties. Click the Attribute Editor tab. Click the Filter button and make sure that Constructed is selected. The attribute you will locate in the next step is a constructed attribute, meaning that the resultant PSO is not a hard-coded attribute of a user; rather, it is calculated by examining the PSOs linked to a user in real time. In the Attributes list, locate msDS-ResultantPSO. Identify the PSO that affects the user. The Domain Admins PSO that you created is the resultant PSO for the Administrator accoun Auditing Authentication When a user logs on to any computer in the domain using his or her domain user account, a domain controller authenticates the attempt to log on to the domain account. This generates an account logon event on the domain controller. Use the buttons below to navigate through the lesson

The computer to which the user logs on for example, the users desktop generates a logon event. The computer did not authenticate the user against his or her account; it passed the account to a domain controller for validation. The computer did, however, allow the user to log on interactively to the computer. Therefore, the event is a logon event. When the user connects to a folder on a server in the domain, that server authorizes the user for a type of logon called a network logon. Again, the server does not authenticate the user; it relies on the ticket given to the user by the domain controller. But the connection by the user generates a logon event on the server. Open Group Policy Management. Expand Domain Controllers OU. Right Click the Default Domain Controllers Policy. Select Edit. Expand Computer Configuration>Windows Settings>Security Settings. Click Audit Policies. Right click Audit account logon events and select Properties. Select Define these policy settings and select Success and Failure. Click OK. Right click Audit logon events and select Properties. Select Define these policy settings and select Success and Failure. Click OK. Both audit policies are enabled. Close the dialogue box. In order to test the audit policy the Administrator will attempt to log on with an incorrect password. Close Group Policy Management and try it. After some failed logons check event viewer security log. Note the Audit Failures. Double click an event for more detail. These are the events details. You can also access Microsofts online database for more information about any event. Close all open dialogue boxes to return to the desktop. Configuring a Read-Only Domain Controller Consider an enterprise that is characterized by a main site and branch offices. The branch offices connect to the main site over WAN links that might be congested, expensive, slow, or unreliable. Users in the branch office must be authenticated by Active Directory to access resources in the domain. Should a DC be placed in the branch office?

Use the buttons below to navigate through the lesson

If a DC is not placed in the branch office, authentication and service ticket activities will be directed to the main site over the WAN link. Authentication occurs when a user first logs on to his or her computer in the morning. Service tickets are a component of the Kerberos authentication mechanism used by Windows Server 2008 domains. If a DC is placed in the branch office, authentication is much more efficient, but there are several potentially significant risks. A DC maintains a copy of all attributes of all objects in its domain, including secrets such as information related to user passwords. If a DC is accessed or stolen, it becomes possible for a determined expert to identify valid user names and passwords, at which point the entire domain is compromised. At a minimum, you must reset the passwords of every user account in the domain. Because the security of servers at branch offices is often less than ideal, a branch office DC poses a considerable security risk. A second concern is that the changes to the Active Directory database on a branch office DC replicate to the hub site and to all other DCs in the environment. Therefore, corruption to the branch office DC poses a risk to the integrity of the enterprise directory service. For example, if a branch office administrator performs a restore of the DC from an outdated backup, there can be significant repercussions for the entire domain. The third concern relates to administration. A branch office domain controller might require maintenance, for example, a new device driver. To perform maintenance on a standard domain controller, you must log on as a member of the Administrators group on the domain controller, which means you are effectively an administrator of the domain. It might not be appropriate to grant that level of capability to a support team at a branch office. Read-Only Domain Controllers The RODC is designed specifically to address the branch office scenario. An RODC is a domain controller, typically placed in the branch office, that maintains a copy of all objects in the domain and all attributes except secrets such as password-related properties. When a user in the branch office logs on, the RODC receives the request and forwards it to a domain controller in the main site for authentication. You are able to configure a password replication policy (PRP) for the RODC that specifies user accounts the RODC is allowed to cache. If the user logging on is included in the PRP, the RODC caches that users credentials, so the next time authentication is requested, the RODC can perform the task locally. As users who are included in the PRP log on, the RODC builds its cache of credentials so that it can perform authentication locally for those users. Because the RODC maintains only a subset of user credentials, if the RODC is compromised or stolen, the effect of the security exposure is limited; only the user accounts that had been cached on the RODC must have their passwords changed. Writable domain controllers maintain a list of all cached credentials on individual RODCs. When you delete the account of the stolen or compromised RODC from Active Directory, you are given the option to reset the passwords of all user accounts that were cached on the RODC. The RODC replicates changes to Active Directory from DCs in the main site. Replication is one way (from a writable domain controller to a RODC); no changes to the RODC are replicated to any other domain controller. This eliminates the exposure of the directory service to corruption resulting from changes made to a compromised branch office DC. Finally, RODCs, unlike writable DCs, have a local Administrators group. You can give one or more local support personnel the ability to maintain an RODC fully, without granting them the equivalence of domain administrators. Installing an RODC An RODC must replicate domain updates from a writable domain controller running Windows Server 2008. It is critical that an RODC is able to establish a replication connection with a writable Windows Server 2008 domain controller. Ideally, the writable Windows Server 2008 domain controller should be in the closest site to the main site. In the following lesson we will create an RODC called Branchrodc attached to the Es-net domain. We will create a branch office security group and users, then configure a Password Replication Policy (PRP)

Type dcpromo in the run box and click OK. Check if Active Directory binaries are installed. Active Directory installation wizard starts. Click Next to continue. Operating System compatibility page click Next. Ensure add a domain controller to an existing domain is checked and click Next. Enter domain you wish to join and specify credentials, then click Next. Select domain then click Next. Select site for new domain controller and click Next. Ensure Global Catalog and Read-only domain controller (RODC) are checked and click Next. Click Next. Type in and confirm restore mode password and click Next. Review selections and click Next. Installation of Active Directory begins. Installation completed. Click Finish. To complete the install click Restart Now. Password Replication Policy In the previous lesson we installed an RODC, to continue we will create a branchofficeusers security group and populate it with users. We will then create a password replication policy, monitor credential caching, and prepopulate credentials on the RODC.

Use the buttons below to navigate through the lesson

In this scenario we will create 3 users Jim Bean, Paul Gray and Mike Stand. Jim and Paul will become members of the branchofficeusers group, Mike Stand will not be added to the group;his credentials will be prepopulated later. All three users will be added to the print operators group in order to allow them to logon to the Domain controller locally. This action is not recommended in production environments and is only used for testing purposes. On DC1 open Active directory Users and computers. Right click Builtin and select New>Group. Group name branchofficeusers, click OK. On DC1 open Active directory Users and computers. Right click Users and select New>User. Fill in Users details and click Next. Type in password and confirm password and click Next. Repeat process for other users, Paul Gray and Mike Stand. Click finish to complete. Select users Jim Bean and Paul Gray Right click and select add to a group. Specify branchofficeusers and click OK. Add to group All three users will be added to the print operators group in order to allow them to logon to the Domain controller locally. This action is not recommended in production environments and is only used for testing purposes. Right click branchofficeusers group and select Add to a group. Specify the Print Operators group and click OK. Configure RODC-Specific Password Replication Policy To facilitate the management of PRP, Windows Server 2008 creates two domain local security groups in the Users container of Active Directory. The first, named Allowed RODC Password Replication Group, is added to the Allowed List of each new RODC. By default, the group has no members. Therefore, by default, a new RODC will not cache any users credentials. If there are users whose credentials you want to be cached by all domain RODCs, add those users to the Allowed RODC Password Replication Group. The second group is named Denied RODC Password Replication Group. It is added to the Denied List of each new RODC. If there are users whose credentials you want to ensure are never cached by domain RODCs, add those users to the Denied RODC Password Replication Group. By default, this group contains security-sensitive accounts that are members of groups including Domain Admins, Enterprise Admins, and Group Policy Creator Owners. The two groups described in the previous section provide a method to manage PRP on all RODCs. However, to support a branch office scenario most efficiently, you need to allow the RODC in each branch office to cache user and computer credentials in that specific location. Therefore, you need to configure the Allowed List and the Denied List of each RODC.

In the Domain Controllers OU, right click branchrodc, Select Properties. Select Password Replication Policy. Click Allowed RODC Password Replication Group. Select Members. By Default the group is empty. Click Denied RODC Password Replication Group. Select Members. By default, this group contains security sensitive accounts that are members of groups including Domain Admins, Enterprise Admins, and Group Policy Creator Owners. In the Allowed Password Replication Group Properties Members Tab click Add. Specify branchofficeusers and click OK. Branch office users credentials will be cached by the server. Monitor Credential Caching The 3 users we created previously will logon to the RODC so we can monitor the caching. Remember Mike Stand was not a member of the branchofficeusers group, his credentials should not be cached by the RODC. We will use his account to prepopulate his password to the RODC. After the users have logged on and off, on DC1 open the Domain controllers OU. Right click the RODC and select Properties. Select Password Replication Policy. Click Advanced. Note the two members of the branchofficeusers group, passwords are stored in Accounts whose passwords are stored on this read-only domain controller. Mike Stands password has not been stored. Mike Stands password is in the Accounts that have been authenticated to this read-only domain controller. Mike Stands password can be prepopulated to this RODC. Click Prepopulate Passwords. Specify Mike Stands account and click OK. Click Yes. Mike Stands password cannot be prepopulated because we did not add him to the allowed list. Return to the Password Replication Policy box and select Add. . Then select Allow passwords for the account to replicate to the RODC. Click OK. Specify Mike Stands account and click OK. Mike Stands password can be prepopulated to this RODC. Click Prepopulate Passwords. Specify Mike Stands account and click OK. Click Yes. Click OK. Mike Stands password is now stored on the RODC. Click Close. Click OK. Remember in order for a user to logon when no Writeable domain controller is available, both the Users and the Computers passwords must be stored on the RODC.

DNS Overview WINS worked well for internal networks as all machines are part of the same organisation. However, with the advent of the Internet where there are many networks connected, a method of structuring names became essential. A flat database, such as WINS, would be too cumbersome, as the resolver would have to search the entire database to resolve a name. Considering the size of the Internet this would be an extremely resource intensive, slow process.

Use the buttons below to navigate through the lesson

To solve this problem the Domain Naming System (DNS) was introduced. DNS names are arranged in a tree structure with the client names comprising of their own computer name followed by a string of domain names in order, separated by a . finishing with the top level domain. e.g. mail.es-net.co.uk. This system allows distinctive names to be used on all networks, For example a computer called mail. In WINS there could only be one machine called mail in the world. With DNS we can call any computer mail as long as its domainname was unique. DNS is a distributed service that is based on a logical, hierarchical structure of DNS domain names. Because of this it is more scalable than WINS. Internet searches are based on DNS name resolution. When a name resolution query is made to a DNS server and it doesnt know the answer the query can be passed onto another DNS server which in turn may pass the query on. In the end the client will either receive an answer or a name-resolution error. DNS is a hierarchically distributed database. This means that the DNS database is distributed all over the internet instead of in a central location. Queries are made in a specific order, as you are about to see. Suppose a user types this address into his browser. Effectively a query has been made which says: Find this address for me. I wont go away until you have!

The local DNS server begins its search The first server visited is the root, because this address is known. Each DNS Server only has records for the next tier in the hierarchy. The root servers know the locations of the top-level domains, e.g. com, edu, uk. Thanks to the speed of modern switches and repeaters, and the blistering speed of light, many servers can be queried in a short space of time. Each of these question and response pairs are Iterative queries. The questioner (resolver) is happy with a hint as to where to look next. As far as the user is concerned his demand for a definitive answer has been met. The DNS server has done its job. A Recursive query demands a definitive answer (even Havent a clue counts in this case.) An Iterative query accepts a hint to ask somewhere else. A Resolver is the machine making queries. A DNS resolver can make one of two different queries: Iterative queries can be described as do you know the answer? If you dont could you point me in the right direction and is used by DNS servers to query other DNS servers. Recursive queries are more like tell me an answer even if the answer is I cant find it or I dont know. This is how a client machine queries a DNS server. Servers can issue a recursive query but it is considered bad form as you put load on someone elses DNS server. The server takes the responsibility for resolving the query. DNS Servers and Zones Primary DNS Servers A DNS Server contains zone files. If a DNS Server is authoritative over a zone file, it has full control over it. A Primary DNS Server can update, make additions to, modify and delete records in the zone file. The Primary DNS Server is the only place modifications to the domain can be made. Primary DNS Servers are authoritative over the zones that they contain. Multiple Primary DNS Servers can be authoritative for the same zone, any changes to the zone file will be replicated to all other DNS Servers. Secondary DNS Servers A Secondary DNS Server contains backup copies of a zone file and can only read information from the zone file. A Secondary DNS Server cannot update or delete records from the zone file it contains. Any changes that need to be made to the zone file have to be made on the Primary DNS Server. These changes are then replicated to the secondary DNS server. Secondary DNS Servers are used for load-balancing and fault-tolerance.

Use the buttons below to navigate through the lesson

Forward Lookup Zones A Forward lookup is the most common form of DNS lookup. This type of lookup converts a hostname into an IP address. A Forward Lookup-Zone contains Name to IP Address mappings. Each zone file consists of a number of resource records (RRs). Resource records (RRs) contain information about certain resources on the network. Resource Records There are several types of resource records (RRs) that can be found in a zone file:

A (Host) Record: Is used to associate a hosts name to an IP address. CNAME (Alias): An IP Address can have more than one name. Some Web Sites, for example, have several Web
Servers for load balancing, each with different IP Addresses. A query to www.microsoft.com will give you several possible IP Addresses all pointing to the same web-site.

MX (Mail Exchanger): A Mail record used to indicate where mail for the domain should go.

The Name Server Record (NS): Shows which DNS Servers are authoritative for this zone. Start of Authority (SOA) Record: This is the first record in the database file and contains information about
the zone file.

Service (SRV) Records. These contain the IP addresses of different services on the domain, e.g. the services
used to logon and query Active Directory. Domains could not function without SRV records. Reverse Lookup Zones A Reverse Lookup-Zone contains IP Address to Name mappings. This allows the computer to do reverse queries, some applications need to be able to make reverse lookup queries. Reverse Lookup Zones contain the following Resource Records. Pointer Record: (Does the opposite of the A record it maps an IP address to a host name. By having the two types of records it is possible to do a reverse lookup.) CNAME (Alias) The Start of Authority (SOA) record The Name Server Record (NS) When doing reverse-lookups, DNS uses the same principle as a forward query. The IP address is reversed allowing queries to start from the least specific to the most specific. The special domain name in_addr.arpa is used for reverse lookups. e.g. A query about the hostname of 10.1.0.1 would result in a query to a zone-file called 0.1.10.in_addr.arpa. Active Directory Integrated Zones Active Directory Integrated Zones store the same information as standard Zone Files, however the information is stored and replicated with the Active Directory. There are no Primary or Secondary Zones. All zones are multimaster, which means that you can update any of the zones and the changes will be replicated. Active Directory zones as well as standard Windows Server 2003 zones use IXFR (Incremental Zone Transfers), which means that when a change is made to a zone file, only that change is replicated instead of the entire database. This can lower network traffic between DNS Servers. Active Directory Zones allow for secure, dynamic updates. Updates to the DNS zone are done automatically and only clients who are a member of the forest can register. Stub Zones A stub-zone contains a partial copy of another zone. The zone contains only the NS and SOA records for its master zone. Stub zones identify the servers that are authoritative for the master zone and the servers that are authoritative for its child zones below the master in the namespace. Stub zones are mainly used to keep track of name servers in delegated child zones when there are a great deal of children. Root Servers If your Windows Network isnt connected to the Internet or if you want to prevent users querying anything on the Internet, you can configure a DNS server to contain its own root zone. The Root Zone is treated as the master of all queries. Nothing is ever queried above a Root Zone. A Root Zone can never be demoted and then a new Root Server placed above it. It is therefore essential that you plan your DNS implementation correctly. Caching-Only DNS Servers All DNS Servers store the queries that they have resolved. However caching-only DNS Servers only cache the information and dont actually hold any sort of zone file. When a caching-only DNS Server is first started it contains

no information and the cache is gradually built up over time using iterative queries to other DNS Servers that contain the information. A caching-only server is not authoritative for any zone. Caching only servers can be used to speed up Internet access on networks. The DNS server will store any queries it makes to the Internet and speed up name resolution. A DNS Server can be configured to forward name resolution requests to other DNS Servers. These forwarding requests can either be all unresolvable queries or queries based on domain-names (conditional). Installing and Configuring DNS Before installing DNS it is imperative that the server has a static IP address. DNS is installed using the Server Manager Utility. N.B. DNS is not available on Windows Server 2008 Web Edition or machines running Windows XP or Vista. Although DNS can be remotely managed from these machines.

Use the buttons below to navigate through the lesson

To install DNS using the Server Manager click on Start. Select Server Manager. Or from the Quick Launch Taskbar. Select Roles. Then Add Roles. Before you continue verify that; You can skip this page by default Click Next to continue Select DNS Server Select DNS Server then Click Next to continue Although the server has a static IP address. The wizard has detected a dynamic IP V6 address, it is safe to continue the install. Select Install DNS Server anyway Click Next to continue. For Additional Information click the links. Click Next to continue. Click Install to complete installation. The DNS Server role is now installed. The DNS Server role installation succeeded. Click Close to complete the wizard. The DNS Server role has been added. Server roles can also be removed from here. Expand Roles Select DNS Server.

A feature of Server Manager is by highlighting any server role. You will be given an overview of that role, Events, System Services and Resources and Support. The DNS Server role is installed, you now need to add zones to the server. To do this you need to return to the start menu. N.B. If no zones are added this server will be a Caching only server. Creating a Zone

Forward Lookup
A Forward lookup is the most common form of DNS lookup. This type of lookup converts a hostname into an IP address. A Forward Lookup-Zone contains Name to IP Address mappings. Each zone file consists of a number of resource records (RRs). Resource records (RRs) contain information about certain resources on the network. To add zones to the server. Click Start> Administrative Tools> DNS Expand by clicking the + next to the DNS server To add a New Forward Lookup Zone Right click Forward Lookup Zones. Click New Zone. Select Primary Zone and Next to continue Fill in the Zone name. N.B. The zone name must be Fully Qualified ie end in .com, .local, .co.uk etc. and Next to continue. The wizard will ask you where you want to store the zone file. Click on Next to accept the default. The Wizard will ask you if you want to accept dynamic updates. As the wizard shows there are drawbacks for having it enabled but there are also drawbacks for having it disabled. Click on Next to continue. Click on Finish to create the zone. The zone file currently contains two resource records, the SOA and NS records.

Reverse Lookup
A Reverse Lookup-Zone contains IP Address to Name mappings. This allows the computer to do reverse queries, some applications need to be able to make reverse lookup queries. Reverse Lookup Zones contain the following Resource Records. Pointer Record: (Does the opposite of the A record it maps an IP address to a host name. By having the two types of records it is possible to do a reverse lookup.) CNAME (Alias) The Start of Authority (SOA) record The Name Server Record (NS) Right click Reverse Lookup Zones and Select New Zone. Select Next. Select Primary Zone Select IPv4 Reverse Lookup Zone. and Next to continue. Type in the Network ID and Next to continue Select Create a new file with this file name

and Next to continue The Wizard will ask you if you want to accept dynamic updates. As the wizard shows there are drawbacks to having it enabled, but there are also drawbacks for having it disabled. Click on Next to continue. The Wizard will display summary page. Click on Finish to continue. The zone file currently contains two resource records, the SOA and NS records.

Stub Zone
A stub-zone contains a partial copy of another zone. The zone contains only the NS and SOA records for its master zone. A stub zone is similar to a secondary zone, but it contains only those resource records necessary to identify the authoritative DNS servers for the master zone. Stub zones are often used to enable a parent zone like es-net.co.uk to keep an updated list of the name servers available in a delegated child zone, such as brighton.es-net.co.uk. They can also be used to improve name resolution and simplify DNS administration. To add a New Stub Zone Right click Forward Lookup Zones. Select New Zone Click Next. Select Stub Zone and Next to continue Select Active Directory Zone Replication options, click Next to continue Type in the name of the new zone and click Next. Type in the IP address of the server or the servers Fully Qualified Domain Name(FQDN). Press Enter When the IP address of the server or the servers Fully Qualified Domain Name(FQDN) has been verified, Click Next The wizard displays summary page, if all is OK click Finish. The resource records for the new Stub Zone. DNS Server Properties Right-click on the DNS to view its configuration options. Select Properties. From the Interfaces page you can configure which IP addresses you want the DNS server to serve requests for. The default is All IP addresses. From the Forwarders page, additional DNS servers can be specified. This DNS server will forward unknown queries to the specified DNS servers. The advanced page allows you to configure different advanced options by simply ticking a check box. The disable recursion checkbox allows recursion to be disabled on this server. It is then down to the client to query other DNS servers if this DNS server cannot answer the query. BIND Secondaries enables support when transferring a zone to DNS servers running BIND. (BIND is the implementation of DNS used by Unix and Unix-like systems.) Fail on load if bad zone data stops the server from loading if there are any errors in the zone file. Determines whether the DNS server uses round robin to rotate and reorder a list of multiple host (A) resource records if a queried host name is for a computer with multiple IP addresses. Enable Netmask Ordering is enabled by default. If the client has various IP addresses the server resolves the query with the nearest IP address. Secure cache against pollution specifies whether the server attempts to clean up responses to avoid cache pollution. There are three methods used for name checking: Multibyte (UTF8) Permits recognition of characters other than ASCII (a-z, A-Z and 1-0). Strict RFC (ANSI) Strict name checking according to RFC 1123 Internet host naming specifications. Non RFC (ANSI) Permits names that are non-standard and that do not follow RFC 1123 Internet host

naming specifications. The Load zone data on startup specifies the boot method to be used by this DNS server. Either boot file or registry boot options are supported. Boot files can be used if a Boot.dns file has been created. By enabling scavenging, the DNS server will remove any records that have expired from any zone files it is authoritative for. The period represents the time between repetitions of the scavenging process. DNS Servers contain root hints, which point to various top-level domains. This enables the DNS Server to recursively query other servers using the root server. Additional root hints can be specified by clicking the Add button. The Monitoring page allows you to automatically test the DNS server. Select A simple query against this DNS server. Click Test Now. The Server passed the simple query. A recursive query would require connection to the internet in order to query a Root Server. From the Event Logging tab the user is able to choose events that can be logged such as Error or Errors and Warnings. Logging is generally a good option because it allows you to troubleshoot any potential DNS problems. Debug logging allows you to enable verbose logging for the DNS service. Use this option with caution as it can generate a lot of information. Install and Configure DNS Active Directory To install Active Directory and DNS using the Server Manager.

Use the buttons below to navigate through the lesson

Select Server Manager. Or from the Quick Launch Taskbar. Select Roles. Then Add Roles. Before you continue verify that; You can skip this page by default. Click Next to continue Select Active Directory Domain Services. There is no need to select DNS Server; this role will be added with DCPROMO. Then Click Next. Ensure you read Things to Note. Then Click Next. Click Install. The Active Directory Binaries have been installed. Click Close this wizard and launch dcpromo.exe. You can also launch dcpromo from the Run box. Click Next. Operating System Compatibility warning about new Server 2008 security settings. Check there is no compatibility issue with existing network infrastructure. If none click Next. Select Create a new domain in a new forest and Click Next. Fill in Domain name and Click Next. Domain name checked and verified as not in use. There are 3 Forest functional levels Windows 2000, Windows 2003, Windows 2008. Select the level which suits the existing infrastructure, this can be changed at a later date. Click Next.

Domain functional level should be set to match Forest Functional level. This can be changed later. Click Next Select DNS server then Next to continue. Next to continue. The Wizard cannot contact the DNS server for this zone. Select yes to continue; DNS will then be installed. The Database folders are assigned. Click Next to accept the defaults. Restore mode password must be set, click Next to continue. Create Unattended Answer file Click Export settings if you wish to create an unattended answer file for installing Active Directory on server Core. Type in the file name. click Save. The file can be exported later. The wizard can be cancelled if you are just creating an answerfile. To continue Active Directory install click Next. The installation will now continue. The Active Directory components are installed. Click Finish to complete the installation. The Server needs to be restarted to finalise the installation. Click Restart Now. Server restarts. Select DNS from administrative tools. Expand DNS console. Note the folders for Active Directory DNS. Zone Properties Right click the zone, Select Properties. The General Tab displays the general options you setup when creating the zone. The zone can be stopped and started from here and the zone type and Replication can also be changed. The aging/scavenging button can be used to configure how long records stay valid in the zone. Dynamic DNS A big advantage of using Windows 2008 DNS is that it can be updated automatically. When a client is given a name and an IP address, the DNS server is automatically updated, saving the administrator the job of adding every single entry into the DNS database. A Windows 2000/XP/Vista Client with a static or dynamically assigned IP address will register its name and IP address with a DNS Server. Non-Windows 2000/XP/Vista clients cant use dynamic updates, therefore the DHCP server will automatically update the DNS Server. The server will then be known as a DNS Proxy. However, this method has security issues because a malicious DHCP client could ruin your DNS database. The SOA record contains information about the Primary Server, which is responsible for the zone as well as expiry and time to live (TTL) information used for replication. The Name Servers tab displays information on which servers hold a copy of the zone-file. Servers holding replicas of this zone would be displayed here. The Security tab can be used to configure who can manage, read and write object to the DNS database. The Zone Transfers Tab can be used to configure which machines are allowed to hold a copy of this zone. The default will replicate to all servers who have a copy of this zone. When using Active-Directory Integrated Zones, replication is managed via Active Directory. However if you are using Primary or Secondary zone replicas then you will still need to configure zone transfers. WINS lookup allows you to configure the DNS server to use WINS if a name resolution request fails. Install and Configure DNS Server Core To install DNS on 2008 Server Core. Type start /w ocsetup DNS-Server-Core-Role. Note the syntax of the command and the capitalisation as server roles must be in this format.Once the installation has completed, you need to attach to the server via an MMC in order to create and manage zones.

Use the buttons below to navigate through the lesson

After attaching to the Server Core Server, Right Click Forward Lookup Zones. Select New Zone. Click Next.

Select Primary zone, then Next to continue. Type in zone name, then click Next. Create a new Zone file, click Next to accept the default. The Wizard will ask you if you want to accept dynamic updates. As the wizard shows there are drawbacks for having it enabled but there are also drawbacks for having it disabled. Click on Next to continue. Click Finish to create the zone. The zone file currently contains two resource records, the SOA and NS records. Uninstalling Roles To uninstall DNS on 2008 Server Core. Type start /w ocsetup DNS-Server-Core-Role /uninstall. Note the syntax of the command and the capitalisation as server roles must be in this format. A restart is required to complete the uninstall. Click Yes to finish. Install and Configure Active Directory and DNS To perform an unattended installation of Active Directory and DNS,you can use the answer file you created in the earlier module. Type the command dcpromo.exe /unattend:a:\filename.txt. Note the file was saved to a floppy disc. System checks for Domain Services binaries and validates environment and parameters. DNS is installed. Domain configuration is completed. A restart may be required, after completion. To configure the domain and DNS zones you will need attach to the server via an MMC.

Configuring DNS Clients Before the DNS server will be of any use, the clients on the network will need to be configured to use the server. To do this bring up the TCP/IP properties of your network adapter. In the Preferred DNS server box, type in the IP address of the DNS server. The Alternate DNS server is used when the preferred DNS server isnt available. To configure advanced DNS options, click on Advanced.Select DNS.

Use the buttons below to navigate through the lesson

Every query to a DNS server is done using a fully qualified domain name (FQDN). This is in the format of (hostname.domainname). For example the FQDN of a computer called CDSERVER on the ES-NET.CO.UK domain would be CDSERVER.ESNET.CO.UK Every query to a DNS server is done using a FQDN, but instead of writing out the full name, just the hostname is used and the computer fills out the rest of the name based on its own FQDN. E.g. If pc01.es-net.co.uk was querying pc03 it would add its own domain name to the end of the query. This results in a query to pc03.es-net.co.uk. This domain name is known as a DNS suffix. Additional DNS suffixes can be specified, so that if one suffix fails then it will try another suffix. The Register this connections address in DNS will automatically register the computers name and IP address with the DNS server. Troubleshooting DNS NSLOOKUP is an important utility that performs query testing and troubleshooting of DNS servers at the command prompt window. NSLOOKUP can be accessed by going to the command prompt window and typing in NSLOOKUP and pressing Enter. Use the buttons below to navigate through the lesson

As shown, the NSLOOKUP tool is now active. To do a forward or reverse lookup, type the name in the command prompt window. A list of command lines can be found by typing in help or ? From the NSLOOKUP command window. When a query is made to a DNS server, the server can either return an authoritative answer or a non-authoritative answer. If it returns an authoritative answer then the record exists in its own zone file. If it returns a nonauthoritative answer then the record exists in the zone file of another DNS server. There are many ways that DNS can fail to work. There is no one sure way to solve every problem which might occur. The following list is a reasonable starting point for troubleshooting. Test to see if the client is on the network by using the ping utility. Use ipconfig to view the clients DNS settings. Use NSLOOKUP to perform DNS queries and check the contents of the zone files. Use the Event Viewer to see any DNS client or server error messages. From the server Properties choose the Logging tab to log and monitor certain events. From the server Properties choose the Monitoring tab to perform simple test queries. From the DNS console select Action and choose Set Aging/Scavenging to clear the DNS database of stale resource records. While Ping, Ipconfig and Nslookup can all be run in a command window with the ? Switch to reveal the full range of available configurations, there are two switches in particular which are used more often than others in troubleshooting DNS: Ipconfig /flushdns empties the local resolver cache. (This cache is the file of all the names and addresses resolved for the client so far.) Ipconfig /registerdns forces a dynamic update of the clients registration in the local DNS server..

How to Edit Group Policy in Windows XP

Run at user logon policyEditing Other User
Edited by Blizzerand, Maluniu, Lael Rapier, Teresa and 1 other

Discussed herein are ways through which a PC user can be able to utilize the Group Policy snap-in to develop or edit the lists of applications that load automatically when you log into a PC running on Windows XP.

Edit

Method 1 of 2: Run at user logon policy

1.1

This option is utilized when you would like to develop or edit the list of applications that load automatically when you log into your PC. To do so, follow the instructions listed below:

2.

2
Click the Start button from the taskbar.

3.

3
From the popup menu choose Run and in the dialog box that appears, type mmc and press the enter key or click OK.

4.

4
Click File from the menu bar and in the drop down list choose Add or Remove Snap-in and choose Add.

5.

5
Look for the tab labeled Available Stand-alone Snap-ins and click on Group Policy Object Editor. Thereafter click Add and then choose Finish.
Edit

Method 2 of 2: Editing Other User

1.

1
If you do not wish to edit the Local Computer Policy, click on the button labeled Browse to search the Group Policy object which you want. Provide your user name plus password when prompted for it.

2.

2
Click finish when you are taken back to the Select Group Policy Object dialog box.

3.

3
Select the Close button and then click OK in the Add or Remove Snap-in.

4.

4
Extend the Local Computer Policy located in the left pane of the Group Policy Snap-in. In addition, extend the Computer Configuration as well as the Administrative Templates. Extend the System object and then click on the Logon object.

5.

5
Double click on the "Run these programs at user logon" from the right pane of the window.

6.

6
Look for the button labeled Enabled and click on the option labeled Show. In the dialogue box that appears choose Add and type the name of the executable application (.exe) file or any other document which you may want and then click on OK. You have to outline the path to the files. But, if the files are stored in the %Systemroot% directory, you do not have to outline the path.