Remo Paul. Salsa Sa. Dhanush Vicky. Srinivas Kommu. Show More. Views Total views. Actions Shares. No notes for slide. First make sure you read and understand Active Directory Installation Requirements. If you don't comply with all the requirements of that article you will not be able to set up your AD for example: you don't have a NIC or you're using a computer that's not connected to a LAN.
Meaning - don't do it for any other scenario, such as a new replica DC in an existing domain. Step 1: Configure the computer's suffix Not mandatory, can be done via the Dcpromo process. Right click My Computer and choose Properties. Click the Computer Name tab, then Change. In the Primary DNS suffix of this computer box enter the would-be domain name.
Make sure you got it right. No spelling mistakes, no "oh, I thought I did it right Although the domain name CAN be changed after the computer has been promoted to Domain Controller, this is not a procedure that one should consider lightly, especially because on the possible consequences. Read more about it on Windows Domain Rename Tool page. Click Ok. You'll get a warning window. Check your settings. See if they're correct 9. Click Ok to restart. Click Start, point to Settings and then click Control Panel.
Double-click Network and Dial-up Connections. Right-click Local Area Connection and then click Properties. Assign this server a static IP address, subnet mask, and gateway address. Note: This is true if the server itself will also be its own DNS server.
Click Advanced. Click the DNS Tab. Select "Append primary and connection specific DNS suffixes" 4. Check "Append parent suffixes of the primary DNS suffix" 5.
Check "Register this connection's addresses in DNS". If this server needs to resolve names on the Internet, it should have a forwarder configured. This article assumes that you already have the DNS service installed. Right click Forward Lookup Zones and choose to add a new zone.
Click Next. The new forward lookup zone must be a primary zone so that it can accept dynamic updates. Click Primary, and then click Next. The name of the zone must be the same as the name of the Active Directory domain, or be a logical DNS container for that name.
For example, if the Active Directory domain is named "lab. Type the name of the zone, and then click Next. Accept the default name for the new zone file. To be able to accept dynamic updates to this new zone, click "Allow both nonsecure and secure dynamic updates". Click Finish. You should now make sure your computer can register itself in the new zone. Go back to the DNS console, open the new zone and refresh it F5.
Notice that the computer should by now be listed as an A Record in the right pane. If it's not there try to reboot although if it's not there a reboot won't do much good. Check the spelling on your zone and compare it to the suffix you created in step 1. Check your IP settings. Right click the DNS Server object for your server in the left pane of the console, and click Properties. Click the Forwarders tab. You can also move them up or down. The one that is highest in the list gets the first try, and if it does not respond within a given time limit - the query will be forwarded to the next server in the list.
Click OK. For example, if your IP address is You should also configure the new zone to accept dynamic updates. I guess you can do it on your own by now, can't you? Click Start, point to Run and type "dcpromo". The wizard windows will appear. In the Operating System Compatibility windows read the requirements for the domain's clients and if you like what you see - press Next. Choose Domain Controller for a new domain and click Next. Choose Create a new Domain in a new forest and click Next.
Enter the full DNS name of the new domain, for example - kuku. This step might take some time because the computer is searching for the DNS server and checking to see if any naming conflicts exist. Click Next 8. Accept the Database and Log file location dialog box unless you want to change them of course. Accept the Sysvol folder location dialog box unless you want to change it of course. This folder must be on an NTFS v5.
This folder will hold all the GPO and scripts you'll create, and will be replicated to all other Domain Controllers. You should check your settings. Go back to steps 1, 2 and 3. You have an option to let Dcpromo do the configuration for you. Otherwise, you can accept the default choice and then quit Dcpromo and check steps 1 - 3. If your DNS settings were right, you'll get a confirmation window.
Just click next. Accept the Permissions compatible only with Windows or Windows Server settings, unless you have legacy apps running on Pre-W2K servers. Enter the Restore Mode administrator's password. Review your settings and if you like what you see - Click Next. See the wizard going through the various stages of installing AD. You'll wreck your computer if you do.
If you see you made a mistake and want to undo it, you'd better let the wizard finish and then run it again to undo the AD. If all went well you'll see the final confirmation window. You must reboot in order for the AD to function properly. Click Restart now. First, see that the Administrative Tools folder has all the AD management tools installed.
Run Active Directory Users and Computers or type "dsa. With Windows and Windows Server domains, the trusts are created and implemented by default. If the administrator does nothing but install the domain controllers, trusts are already in place. This automatic creation of trust relationships is tied to the fact that Windows and Windows Server domains unlike Windows NT 4 domains are hierarchically created; that is, there is a root domain and child domains within a given domain tree, and nothing else.
That enables Windows and Windows Server to automatically know which domains are included in a given domain tree, and when trust relationships are established between root domains, to automatically know which domain trees are included in the forest. In contrast, administrators had to create and subsequently manage trust relationships between Windows NT domains, and they had to remember which way the trust relationships flowed and how that affected user rights in either domain.
The difference is significant, the management overhead is sliced to a fraction, and the implementation of such trusts is more intuitive--all due to the new trust model and the hierarchical approach to domains and domain trees. In Windows and Windows Server , there are three types of trust relationships, each of which fills a certain need within the domain structure.
The trust relationships available to Windows and Windows Server domains are the following:. Transitive trusts establish a trust relationship between two domains that is able to flow through to other domains, such that if domain A trusts domain B, and domain B trusts domain C, domain A inherently trusts domain C and vice versa, as Figure illustrates. Transitive trust among three domains Transitive trusts greatly reduce the administrative overhead associated with the maintenance of trust relationships between domains because there is no longer a mesh of one-way nontransitive trusts to manage.
In Windows and Windows Server , transitive trust relationships between parent and child domains are automatically established whenever new domains are created in the domain tree. Transitive trusts are limited to Windows or Windows Server domains and to domains within the same domain tree or forest; you cannot create a transitive trust relationship with down-level Windows NT 4 and earlier domains, and you cannot create a transitive trust between two Windows or two Windows Server domains that reside in different forests.
One-way trusts are not transitive, so they define a trust relationship between only the involved domains, and they are not bidirectional. You can, however, create two separate one-way trust relationships one in either direction to create a two-way trust relationship, just as you would in a purely Windows NT 4 environment. Note, however, that even such reciprocating one-way trusts do not equate to a transitive trust; the trust relationship in one-way trusts is valid between only the two domains involved.
One-way trusts in Windows and Windows Server are just the same as one-way trusts in Windows NT and are used in Windows or Windows Server in a handful of situations. A couple of the most common situations are described below. First, one-way trusts are often used when new trust relationships must be established with down-level domains, such as Windows NT 4 domains. Since down-level domains cannot participate in Windows and Windows Server transitive trust environments such as trees or forests , one-way trusts must be established to enable trust relationships to occur between a Windows or a Windows Server domain and a down-level Windows NT domain.
Throughout the course of a migration from Windows NT 4 to Windows or Windows Server , trust relationships that you have established are honored as the migration process moves toward completion, until the time when all domains are Windows or Windows Server and the transitive trust environment is established.
There's a whole lot more detail devoted to the migration process in Chapter 11, "Migrating to Active Directory Services. You can use one-way trust relationships between domains in different Windows or Windows Server forests to isolate the trust relationship to the domain with which the relationship is created and maintained, rather than creating a trust relationship that affects the entire forest. Let me clarify with an example. Imagine your organization has a manufacturing division and a sales division.
The manufacturing division wants to share some of its process information stored on servers that reside in its Windows or Windows Server domain with a standards body. The sales division, however, wants to keep the sensitive sales and marketing information that it stores on servers in its domain private from the standards body. Perhaps its sales are so good that the standards body wants to thwart them by crying, "Monopoly!
To provide the necessary access to the standards body, you establish a one-way trust between the manufacturing domain and the standards body's domain, and since one-way trusts aren't transitive, the trust relationship is established only between the two participating domains. Also, since the trusting domain is the manufacturing domain, none of the resources in the standards body's domain would be available to users in the manufacturing domain.
Of course, in either of the one-way trust scenarios outlined here, you could create a two-way trust out of two separate one-way trust relationships. Cross-link trusts are used to increase performance. With cross-link trusts, a virtual trust-verification bridge is created within the tree or forest hierarchy, enabling faster trust relationship confirmations or denials to be achieved.
That's good for a short version of the explanation, but to really understand how and why cross-link trusts are used, you first need to understand how interdomain authentications are handled in Windows and Windows Server When a Windows or Windows Server domain needs to authenticate a user or otherwise verify an authentication request to a resource that does not reside in its own domain, it does so in a similar fashion to DNS queries. Windows and Windows Server first determine whether the resource is located in the domain in which the request is being made.
If the resource is not located in the local domain, the domain controller specifically, the Key Distribution Service [KDC] on the domain controller passes the client a referral to a domain controller in the next domain in the hierarchy up or down, as appropriate.
The next domain controller continues with this "local resource" check until the domain in which the resource resides is reached. This referral process is explained in detail in Chapter 8.
While this "walking of the domain tree" functions just fine, that virtual walking up through the domain hierarchy takes time, and taking time impacts query response performance. To put this into terms that are perhaps more readily understandable, consider the following crisis: You're at an airport whose two terminal wings form a V.
Terminal A inhabits the left side of the V, and Terminal B inhabits the right. The gates are numbered sequentially, such that both Terminal A's and Terminal B's Gate 1s are near the base of the V where the two terminals are connected and both Gate 15s are at the far end of the V. All gates connect to the inside of the V. You've hurried to catch your flight, and arrive at Terminal A Gate 15 at the far end of the V only to realize that your flight is actually leaving from Terminal B.
You look out the window and can see your airplane at Terminal B Gate 15, but in order for you to get to that gate you must walk OK, run all the way back up Terminal A to the base of the V and then jog by now, you're tired all the way down Terminal B to get to its Gate just in time to watch your flight leave without you.
As you sit in the waiting area, biding your time for the two hours until the next flight becomes available and staring across the V to Terminal A, from which you thought your flight was departing, you come up with a great idea: build a sky bridge between the ends of the terminals so that passengers such as yourself can quickly get from Terminal A Gate 15 to Terminal B Gate Does this make sense? It makes sense only if there's lots of traffic going between the terminals' Gate 15s.
Similarly, cross-link trusts can serve as an authentication bridge between domains that are logically distant from each other in a forest or tree hierarchy and have a significant amount of authentication traffic.
What amounts to lots of authentication traffic? This article describes how to install and configure a new Active Directory installation in a laboratory environment that includes Windows Server and Active Directory.
You will need two networked servers that are running Windows Server for this purpose in a laboratory environment. After you have installed Windows Server on a stand-alone server, run the Active Directory Wizard to create the new Active Directory forest or domain, and then convert the Windows Server computer into the first domain controller in the forest.
To convert a Windows Server computer into the first domain controller in the forest, follow these steps:. Specify the full DNS name for the new domain. Note that because this procedure is for a laboratory environment and you are not integrating this environment into your existing DNS infrastructure, you can use something generic, such as mycompany. Click Next. Click Permissions compatible only with Windows or Windows Server servers or operating systems , and then click Next.
Because this is a laboratory environment, leave the password for the Directory Services Restore Mode Administrator blank. Note that in a full production environment, this password is set by using a secure password format. The installation of Active Directory proceeds. Note that this operation may take several minutes. When you are prompted, restart the computer. After the computer restarts, confirm that the Domain Name System DNS service location records for the new domain controller have been created.
0コメント