Lab 07: installatie en configuratie Active Directory (dcpromo)

berserkdisagreeableSoftware and s/w Development

Oct 29, 2013 (3 years and 7 months ago)

71 views

Lab 07: installatie en configuratie Active Directory (dcpromo)


Doel labo:

Member server herconfigureren tot Domain Controller via de installatie van Active Directory.


Voorbereiding


1.

Log aan als locale administrator en werk in Workgroup.

2.

Controleer of DNS

geïnstalleerd is.

3.

Controleer de TCP/IP settings. De “preferred dns setting” moet naar je eigen ip adres
verwijzen. Je hebt ook een statisch IP adres nodig (je kunt het ip adres overnemen dat je
van de dhcp server kreeg).

4.

Verander je tcp ip settings : Beh
oud ip, sm en default gateway. Zet je eigen ip adres in
de plaats van de “preferred dns” server.


Voorbereiding dns server: maak een dynamically updateable zone file

1.

Maak een nieuwe “primary zone”. Deze moet “dynamic updates” ondersteunen en draagt
de dns
-
naam van het domain dat we zullen installeren.

Neem als naam “DOMX.KHK” , waarbij de X per memberserver een andere letter van het
alfabet is.


Controleer dynamic updates.

1.

Ga naar de command prompt en registreer je computer name en ip adres. Commando:
ipc
onfig .......................................................

2.

Controleer de inhoud van de zone file. Is het gelukt om de naam van de member server te
registreren? .................................................

3.

Neem de properties van “My Computer” en ve
rander de “primary domain suffix”. Deze
moet dezelfde naam hebben als de dns naam van de zone file. Hierna moet je rebooten.

4.

Controleer na de reboot of je in de zone file geregistreerd bent.

5.

Delete je A (host) record in de zone file en registreer je zond
er te rebooten. Hoe?


Merk op dat je “Local user en groups “ nu nog kunt raadplegen. Straks zal je merken dat deze
snap in niet meer beschikbaar is, eens de server een domain controller geworden is.


Je kunt nu overgaan tot de installatie van Active Dire
ctory.


Start DCPROMO.EXE

1.

Je installeert de eerste DC in een nieuw domain , in een nieuwe Forest. De naam stemt
overeen met de dns zone file. Kies GEEN paswoord voor het venster met het Recovery
Paswoord.

2.

Reboot.

3.

Controleer na de reboot hoe de inhoud van

de zone file veranderd is.

Je zou vier folders moeten zien die met een underscore beginnen.

Als je die niet ziet, herstart dan de Netlogon service.

4.

Ga op zoek naar SRV records.

5.

Delete de folder _tcp en _ udp in de zone file en herstart de netlogon service
. Controleer
of de oorspronkelijke inhoud terug beschikbaar is.

6.

Open Local users and computers.
Je zult merken dat dit niet langer beschikbaar is.


Installeer de support tools.

1.

via de share op de docentenpc kan je suptools.msi installeren.

2.

controleer de
installatie via de volgende tools:

dcdiag.exe

netdiag.exe

dnscmd.exe (de syntax hiervoor kan je via Start /help vinden)

een goed voorbeeld is het opzoeken van alle SRV records in een raport:

dnscmd .........................................................
..........................


Voorbereiding labo Group Policies en Organizational Units.

1.

Maak een nieuwe user in de users container van Active Directory Users & Computers.

2.

Probeer aan te loggen met deze user. Lukt dit? Lukte dit op de member server?

3.

In de
volgende labo en theorie les onderzoeken we waar het verschil zit.

(tip: ga op zoek naar informatie rond het user right “Log on Locally”)


Aanmaken van Home Directories voor users.

1.

we willen een aantal users een persoonlijke folder geven op de server (verg
elijkbaar met
de I: schijf op school)

2.

Maak in de root van je systeem de folder HOME.

3.

Share deze folder onder dezelfde naam.

4.

Ga naar Active Directory Users & Computers.

Maak een nieuwe user : naam: AdminX (X staat voor de letter van je domain).

Maak deze us
er lid van de groep Domain Admins

5.

Ga naar de properties van deze user. Neem de Profile


tab en geef daar het pad in naar
de home directory.

BVB.
\
\
yourserver
\
home
\
%username%

Ook al bestaat die folder nog niet. Als je op OK drukt zal er een subfolder ge
maakt
worden.

6.

Controleer of er een subfolder is en controleer wie owner is van deze folder. Controleer
ook de NTFS folder security.

7.

Welke security zou je op de Home


share plaatsen?

8.

Log aan met AdminX en controleer of er een network mapping in Explorer t
e zien is naar je
home folder.


Extra oefening: conditional forwarding.


Als je wil ping’en naar de pc naam van de DC naast je dan lukt dat niet. Jouw dns server is niet in
staat om de andere te raadplegen.

Los dit op door Conditional Forwarding te conf
igureren.


Onderstaand voorbeeld kan je hierbij op weg helpen:



Conditional forwarding is a new feature of DNS in Windows Server 2003 that can be used to speed up
name resolution in certain scenarios. They can also be used to help companies resolve each o
ther's
namespace in a situation where companies collaborate a merger is underway. This article will look in
detail at how conditional forwarding works, how to configure it, and when you might use it. But first,
let's briefly review the concepts of forwardi
ng and forwarders in traditional DNS, starting with different
types of name queries.

Forwarders and Forwarding

When a name server is queried in DNS, the way it responds depends on the type of query issued, which
can be either iterative or recursive. In an

iterative query
, the client asks the name server for the best
possible answer to its query. The name server checks its cache and the zones for which it is authoritative
and returns the best possible answer to the client, which could be either a full answe
r like "here is the IP
address of the host you are looking for" or a partial answer like "try this other name server instead, it
might know the answer." In a
recursive query
, things work a little different for here the client demands
either a full answer (
the IP address of the target host) or an error message like "sorry, name not found."
In Windows DNS, client machines always send iterative queries to name servers, and name servers
usually send recursive queries to other name servers.

Sometimes this proce
ss isn't enough however. A simple example is a company that has Active Directory
deployed on its internal network and uses a private top
-
level domain like .local for its forest. For
example, say a company has a single Active Directory domain named test2003
.local, a domain controller
(and DNS server) named SRV220 and has a dedicated connection to the Internet. A user named Bob
goes to his desktop computer named DESK231, opens Internet Explorer, and tries to access Google
(www.google.com). Here's what happens

DNS
-
wise as far as name resolution is concerned:

1.

DESK231 sends an iterative query to SRV220 asking to resolve www.google.com into its
associated IP address.

2.

SRV220 looks in its DNS database and finds zone information only for the test2003.local domain,
r
ealizes www.google.com is not part of that domain, decides it has no way of knowing how to
resolve www.google.com into an IP address, and what happens next depends:

a.

If, when you promoted your standalone server to the role of domain controller using
dcprom
o, your machine was disconnected from the Internet and there were no other
DNS servers on your network, then dcpromo creates a root zone (".") in its DNS
database that specifies itself as the
root name server

for all DNS name resolution (that
is, "the buck

stops here"). In this case, SRV220 realizes it can't answer the query and
returns a "name not found" error to the client and Bob can't open the Google home
page.

b.

If however, when you promoted your server to a domain controller, your machine was
connected

to the Internet, then Windows contacts the first available Internet root name
server and downloads a list of all Internet root name servers, which becomes its list of
root hints
. In that case name resolution now continues as follows:

3.

SRV220 sends a recur
sive query to the first available Internet root name server, which responds
with the IP address of a name server authoritative for the .com top
-
level domain.

4.

SRV220 sends a second recursive query to the name server authoritative for .com, and this
machine

responds with the IP address of a name server authoritative for the google.com
domain.

5.

SRV220 sends a third recursive query to the name server authoritative for google.com, and this
machine responds with the IP address of the host named www.google.com.

6.

SRV220 returns the IP address of www.google.com to DESK231 and Bob sees the Google home
page appear in his browser.

Now that's a lot of steps, and if the company has a slow WAN link to the Internet then you're using
valuable bandwidth. A better approach t
han "going up to root" to resolve www.google.com would be to
configure a forwarder. A
forwarder

is a name server that handles name queries that can't be resolved by
another name server. Let's see how the above scenario works when a forwarder is configured
on the
internal name server SRV210:

1.

DESK231 sends an iterative query to SRV220 asking to resolve www.google.com into its
associated IP address.

2.

SRV220 looks in its DNS database and finds zone information only for the test2003.local domain,
realizes www.go
ogle.com is not part of that domain, decides it has no way of knowing how to
resolve www.google.com into an IP address, and checks its list of forwarders to see if any
forwarders have been configured for it.

3.

On the forwarders list it finds the IP address
of the external name server hosted by the
company's Internet Service Provider, so it forwards the query to the ISP's name server to
handle.

4.

The ISP's name server goes up to root as needed (which can involve two or more additional
queries) to resolve www.g
oogle.com into its IP address and returns this address to SRV220.

5.

SRV220 returns the address to Bob and he sees Google appear in his browser.

Note that this procedure takes about the same number of steps as before, but most of these steps are
performed o
ffsite by the ISP's name server, so the amount of bandwidth used over the Internet
connection is considerably less and the processing load on the internal name server SRV220 is minimized
as well. And these are good things from an administrator's perspectiv
e. Of course, if the forwarder
doesn't respond within the timeout configured, the server can either try another forwarder (if
configured) or use root hints (if available) or give up and return an error.

On Windows 2000, forwarders are configured using the

General tab of the DNS server's properties sheet
in the DNS console:


What's different in Windows Server 2003 is the concept of
conditional

forward
ing, which I'll look at next.

What Conditional Forwarding Does

A conditional forwarder is one that handles name resolution only for a specific domain. For example, you
could configure your name server to forward any requests for hosts in the domain google
.com directly to
a specific name server that is authoritative for the google.com domain. What this does is speed up the
name resolution process by eliminating the need to go up to root to find this authoritative server. In this
case our previous example wo
uld now look like this:

1.

DESK231 sends an iterative query to SRV220 asking to resolve www.google.com into its
associated IP address.

2.

SRV220 looks in its DNS database and finds zone information only for the test2003.local domain,
realizes www.google.com is
not part of that domain, decides it has no way of knowing how to
resolve www.google.com into an IP address, and checks its list of forwarders to see if any
forwarders have been configured for it.

3.

On the forwarders list it finds a conditional forwarder con
figured, which specifies the IP address
of an authoritative name server for the google.com domain, so it forwards the query to this
name server to handle it.

4.

The google.com name server immediately resolves www.google.com into its IP address without
the ne
ed of going up to root and returns this address to SRV220.

5.

SRV220 returns the address to Bob and Google quickly shows up in his browser, prompting Bob
to say, "Hey, the network sure is fast today!"

Let's now see how to configure this in Windows Server 20
03 DNS.

How to Configure Conditional Forwarding

First let's find a name server authoritative for the google.com domain. To do this we'll use the WHOIS
lookup tool on the NetworkSolutions website at
http://www.networksolutions.com/en_US/whois/index.jhtml. G
o to this page, type google.com into the
WHOIS search box, enter the code displayed (a feature that prevents mass lookups by automated
programs), and the following results are displayed:

google.com



Whois Server Version 1.

Domain names in the .com and .ne
t domains can now be registered

with many different competing registrars. Go to
http://www.internic.net

for detailed information.

Domain Name: GOOGLE.COM

Registrar: ALLDOMAINS.COM INC.

Whois Server: whois.alldomains
.com

Referral URL:
http://www.alldomains.com

Name Server: NS2.GOOGLE.COM

Name Server: NS1.GOOGLE.COM

Name Server: NS3.GOOGLE.COM

Name Server: NS4.GOOGLE.COM

Status: REGISTRAR
-
LOCK

Updated Date: 03
-
oct
-
2002

Creatio
n Date: 15
-
sep
-
1997

Expiration Date: 14
-
sep
-
2011

Let's find out the IP address of name server NS1.GOOGLE.COM using ping:


Now that we have the IP ad
dress of one of the name servers authoritative for the google.com domain,
we can configure Windows Server 2003 DNS to conditionally forward all name queries for this domain to
this name server.

To configure conditional forwarding, open the DNS console und
er Administrative Tools, right
-
click on the
DNS server node, select properties to open the Properties sheet for the DNS server, and select the
Forwarding tab:


If you compare this to the previous figure for Windows 2000 DNS above, you'll see a few differences.
First, if you just want to configure a regular forwarder here, leave "All other DNS domains" selected in
the DNS domain listbox, enter the IP a
ddress of the forwarder (typically the address of your ISP's name
server) in the dotted box, and click Add. If you want to add a
conditional

forwarder however, do the
following. First, click the New button and type the name of the domain you want your name

server to
conditionally forward to:


Click OK and the new domain appears in the top listbox (make sure it is selected for the next step):


Now type the IP address of your conditional forwarder into the dotted box and click Add to add it to the
selected domain's forwarders list:


Click OK to apply the change and close the properties sheet and you're done. Now any name queries for
the google.com domain that are issued against the name serve
r are forwarded directly to the name
server for the google.com domain to resolve.



Using Conditional Forwarding

When might you want to use conditional forwarding in the real world? I can think of several situations
where it might be useful:



To improve nam
e resolution between two separate companies that need to provide their users
with access to resources in the other company's intranet. This sort of situation is common in a
merger situation or between supply
-
chain partners. Just set up DNS servers in each
company to
forward name requests for resources in the other company's network directly to the IP
addresses of name servers in the other company and you're done. Of course, this can also be
done using stub zones as I discussed in my previous article
DNS Stub Zones in Windows Server
2003

and I'll compare the two approaches in a moment.



To improve name resolution within an Active Directory implementation that has a disjoin
ted
namespace (separate forests or multiple domain trees) or a deep hierarchy of subdomains. In
this kind of situation you can set up conditional forwarding so users in one domain can avoid
having to go all the way to root to find resources in a separate f
orest, another domain tree, or
way down the domain hierarchy in a tree. Again, stub zones could also be used for this purpose
if desired.



And then there's using it simply to forward name queries for specific Internet sites like
google.com as in the exampl
e above, but that example was meant only to be illustrative of the
procedure for configuring conditional forwarding on your name server
--
my company has no
plans on merging with Google anytime soon.

Summary

Finally, is there anything you need to watch out
for regarding using conditional forwarding? Two things
come to mind First, conditional forwarding is suitable if you are dealing with a fixed DNS infrastructure.
That means in a merger or supply
-
chain scenario you must be sure the other company doesn't pla
n on
changing their DNS infrastructure by decommissioning old name servers, deploying new ones, or
changing the IP addresses of existing ones. If they do change their infrastructure and don't inform you
of this, then your name server may suddenly find itse
lf forwarding queries to non
-
existing name servers
resulting in failed name queries and frustrated users flooding help desk with calls. In that case, it might
be better to create stub zones on your name servers for zones for which the other company's name
servers are authoritative. That's because stub zones automatically update themselves with the current
list of name servers in the zone while configuring forwarders is a process that has to be done manually.
Same thing in a large enterprise that has a compl
ex Active Directory forest
--
if you aren't sure that
administrators in other divisions of your company are going to tell you in advance when they change
their DNS infrastructures, don't implement conditional forwarding
--
use stub zones instead.

The second c
aveat concerning conditional forwarding is not to get to carried away implementing it. You
might think you could improve name resolution for your users by adding dozens of forwarders for the
most popular Internet sites they use for work purposes, but this
might be a bad idea. The reason is,
when you have a long list of conditional forwarders configured, your name server has to go through the
entire list until it either finds the domain requested or fails to find it, in which case standard forwarding
is used

(if configured), after which root hints is tried and standard recursion employed. The result of this
is that your name server has to perform extra processing to go through the forwarders list each time a
query is received, and in addition to increasing th
e CPU load on your server this can also result in
slower

name resolution rather than faster due to the time it takes to process an especially long list. And if the
forwarder itself is also part of your
own

company's DNS infrastructure then be aware that th
e added load
of receiving forwarded queries from other name servers and performing recursive queries to resolve
them means your forwarders will experience especially heavy CPU utilization and may need to have their
hardware beefed up considerably to handle

it. So if you do plan on using conditional forwarding,
particularly within your own enterprise, be sure to use it only where it really makes a difference and use
it sparingly.