some windows server concepts

[ilyas001]

hello guys .

well i started to revise for my Microsoft mcsa . now i will write what i have in my head and i need you to tell me if i'm write or wrong and more clarification in case i'm you feel i'm confused 

i domain is multiple servers sharing the same scheme to provide services to the end user 

the domain itself is in a forest that is constituted of many other domains if there is any and each domain is contained in a tree 

where i get confused is do we consider each tree part a under domain of the root domain , or a domain under a domain , or just domain 1 and domain 2 ............  or is there only one domain in the tree ? 

also i know that each domain in a tree have it's own database they just share the same scheme i would like to know a little more about that thanks guys 

also does all servers must have the active directory to be part of a same domain ? can they have different type of services running and still be of a same domain ?  

[Anghammarad]

If you do a Domain Tree you get the Root/Master Domain, and it's stub/sub domains. 

 

Positive effects of this tree, The master Domain Admin has full priviliges in the stub/sub domains, but not the other way around.

 

This is a nice concept when you have for example a company headquarter and many branchoffices around the world. In this setup you get a good first security. Each brach gets it's own stub/subdomain in the forest beneath the Root/Master Domain. 

 

So you can push out GPOs and scripts as well as users and groups more easily. 

 

The servers are registered into the domain that their branch has.

 

For example master domain : company.local (Office Madrid main datacenter)

Stubs: 

- ny.company.local

- hh.company.local

- sp.company.local

 

you got the Master AD in Madrid, which also holds the information about the domain tree, your company mailserver (exchange) inside the company.local

 

In the three branches you have an AD, File/printserver, Terminal Server. Those are in the local domains, not the company.info.

 

 

 

[ilyas001]

33 minutes ago, Anghammarad said:

If you do a Domain Tree you get the Root/Master Domain, and it's stub/sub domains. 

 

Positive effects of this tree, The master Domain Admin has full priviliges in the stub/sub domains, but not the other way around.

 

This is a nice concept when you have for example a company headquarter and many branchoffices around the world. In this setup you get a good first security. Each brach gets it's own stub/subdomain in the forest beneath the Root/Master Domain. 

 

So you can push out GPOs and scripts as well as users and groups more easily. 

 

The servers are registered into the domain that their branch has.

 

For example master domain : company.local (Office Madrid main datacenter)

Stubs: 

- ny.company.local

- hh.company.local

- sp.company.local

 

you got the Master AD in Madrid, which also holds the information about the domain tree, your company mailserver (exchange) inside the company.local

 

In the three branches you have an AD, File/printserver, Terminal Server. Those are in the local domains, not the company.info.

 

 

 

thanks for the answer . i heard that we must try as hard as possible to limite the tree to only one domain rather then created sub domains and stuff how true is that ? 

also does the master domain must be the root domain ? because i also read that to add more security we can create a secure sub domain . but what's the purpose if the root domain would be the first to fall in case of a hacker attack ( well i suppose because it's the first domain so it's the gate of the website right ? )?

 

also i don't understand your answer here . does domains of the same tree must all be active domains ? and if yes must they all have the same services ?  what's similar between multiple same tree domains  and what's allowed to be different ? 

thanks for your time 

[Anghammarad]

phew this gets hard without a flipchart and a marker to explain =) 

 

If you have to do only one domain, you can do that, but it has some drawbacks. I'll nom really quick and then write something together.

 

Oh... I forgot, the things MS teaches to achieve the MCSA are good for getting the MCSA. In real IT enviroments you can pin the certificate you get onto the wall or in a frame on your desk and really start learning. 

 

The MCSA is nice if you start from scratch, but even then real life is different then the theoretical stuff they teach. Learning about the systems and what they do is ok, but their "best practices" often lack productive enviroment needs.

[ilyas001]

44 minutes ago, Anghammarad said:

phew this gets hard without a flipchart and a marker to explain =) 

 

If you have to do only one domain, you can do that, but it has some drawbacks. I'll nom really quick and then write something together.

 

Oh... I forgot, the things MS teaches to achieve the MCSA are good for getting the MCSA. In real IT enviroments you can pin the certificate you get onto the wall or in a frame on your desk and really start learning. 

 

The MCSA is nice if you start from scratch, but even then real life is different then the theoretical stuff they teach. Learning about the systems and what they do is ok, but their "best practices" often lack productive enviroment needs.

i know men i always relay on making maximum labs . what i like to do is not only the get theorie part but also get deeper in it . when i say understand theory i mean understand every single possibility with maximum details also when i run in to a problem i hate magic fixes i need to understand the hell happened but i don't don't think that you answered any of my questions . or maybe i wrote them badly for you to understadnd what i really want 

[Anghammarad]

Ok I try to write some little thing up here. Please forgive me if I forget to input things, because, I do this for over 20 years now and some things are just kind of flesh and blood now =) 

 

There are several models of domain setups in the wild. I'll talk only from the internal network point of view (LAN/WAN) of the "company"

I'll input network addresses when needed.

 

1. Single domain in only one location

 

You have one Active Directory Domain Controller for the domain company.local (you don't use an external domain like .com/net/org etc to ship around possible DNS problems). That in short AD Server is also running the DNS for the domain. If needed as well the DHCP. 

Onto the AD Server you may also put the file server and print server roles, if hardware is to be limited.

 

Inside this domain company.local you register all other servers and clients.

With this you have a single domain to control and care for. 

 

2. Single domain in more locations (eg. 2) with less security

 

you have like in 1. the local domain company.local. In the offsite there is also need for clients and servers. So if you have a permanent line to that location the AD Server in the main location may be enough. But then, if that line is cut, the offsite will be down and no user could log onto the domain.

 

So you see, you need an AD server in the offsite as well, with DNS and if needed DHCP as well. Of course in a new network. 

 

Main site 192.168.1.1/255.255.255.0

Offsite 192.168.2.1/255.255.255.0 

 

In this case you need to make sure that DHCP Requests are not running over the WAN connection between both sites but stay in their subnet.

 

Now you may lose the WAN connection between both sites and the offsite is still able to work and logon. Now you can get your line provider to get up to speed to fix the connection. There is a possible problem of a out of age tombstone in that case the two domain controllers may get out of sync after bringing the line back up working. But this only happens after 60+ days. Need to read the specific aging time.

 

Another problem for the security, it is in this case a full domain controller which is like a mirror of the one in the main office and can be edited on site.

 

3. Single domain in more locations with higher security.

 

Same scenario as in 2. but here in the offsite you create a read only DC instead of a fully editable one. This brings you the security of only one active AD DC which is editable. That one is in your local site. As long as both can communicate, the RO DC is always up to date with the changes you make on the PDC. If the wan line fails, the offsite can still log on and work, but it is like in a frozen state. You can't change any users/groups/security there without doing that from the PDC, which then can't push the changes to the RO DC because of the lost wan line between both offices.

 

4. Multi domain in more locations with using domain trusts

 

You have again your local office which has its own servers, own AD/DNS/DHCP called companymain.local. This domain is only for your main office. There will be no replication of its data but the DNS and possible LDAP.

 

In the offsite you have again the needed servers and clients as in the main site. But this AD hosts the domain companyoff.local. This again is a full stand alone domain.

 

To make both interact you need to create a domain trust between both AD Servers domains and mirror the DNS zones on both ADs DNS server.

 

Then you can give access to resources cross the domains. The benefit here is good security because of stand alone domains and only ressources being shared that are configured to be shared. Negativ point, two single domains to work with and administer.

 

5. Multi domain in more locations with using Domain Tree

 

in the main site you have company.local, in the offsites a subdomain branched off from the master like off.company.local.

Benefit here, the master domain can access and in part adminsiter the subdomains, the subdomains though, can't administer the master domain but automatically trust other subdomains of company.local. So a cross site logon is possible if the technical possibility is given. This is nice when you have roaming users, one week her, one there, next week another branch office.

 

After the subdomains are set up, they may even lose their connection to the master domain controller for a while and still the local domains would work. Cross site logon will be affected though.

 

6. multiple trees into a forest

 

You have an office in the US with branches. your master domain is called company-us.local. the branches like city.company-us.local. Here all of 5. is working.

 

Now you have a head office in the eu wich as well has own branch offices called company-eu.local and city.company-eu.local.

 

Those two are separate trees. To be able to access ressources from the us in the eu domain and vice versa both masters need to create a trust between each other. Then it is like in 4.

 

 

-----

 

Those are examples of planning a domain setup in a company. Now what always needs to be installed on the Domain Controllers are the AD roles as well as DNS server roles. If there are trusts or offsites, the dns zones must be transfered to each dns server, so you have a functioning dns resolve for your whole network. quick example:

 

Main site DNS sends it's zone to the Offsite DNS, and vice versa. This is done quite easy. Google and MS Websites help =) 

 

As for DHCP you may only have one DHCP per network. Else you'll have machines that have the same ip address due to both dhcp handing the same ip range. This can only be done in a Cluster Setup.

 

Another basic rule, never ever run your domain with only one Domain Controller (AD, DNS, DHCP and so on). Because if that dies, you will have to start from scratch. So always put a secondary domain controller in your network with active DNS as well and preconfigured deactivated DHCP, so if the PDC goes wahoonie shaped, you switch on the dhcp on the secondary and it will take the full load.

 

In regard of having multiple AD servers for the same domain, keep in mind changes on one AD server need time to get propagated to the others. You can manually kick the synchronization to speed things up. If you don't, changes may take a while to take affect, depending on which AD the user/ressource you changed is connecting to.

 

-----

 

those are a few short quick and dirty basics.

 

@ilyas001

 

Else you will run into errors that perhaps no one has ever seen before, or where MS says you need to start from scratch. But if you have a little google fu and now your way around in a windows system and AD innards to use what google may bring you as an answer securely, then you are good to go.

 

You can't know every defect that may happen. But you need to know the systems that well, that you can for example to reg fixes, use ADSI Edit and fix the AD in an open heart surgery  

 

 

[Anghammarad]

regarding Lab enviroments... 

 

We got a "sysadmin" that got freshly out of school. Theoretically all knowledge there, the ability to let lose of the theoretical stuff and suck up an existing heterogene IT structure was not possible for him. So even if he meant good, he destroyed lots of things, because of trying to go by the book, instead of adepting to the given systems.

 

You can do Lab to reality when you start with a whole fresh IT implementation. Else... you need to adapt or you will break more than you think by working by the book.

[ilyas001]

On 6/11/2017 at 10:20 PM, Anghammarad said:

regarding Lab enviroments... 

 

We got a "sysadmin" that got freshly out of school. Theoretically all knowledge there, the ability to let lose of the theoretical stuff and suck up an existing heterogene IT structure was not possible for him. So even if he meant good, he destroyed lots of things, because of trying to go by the book, instead of adepting to the given systems.

 

You can do Lab to reality when you start with a whole fresh IT implementation. Else... you need to adapt or you will break more than you think by working by the book.

sorry for late comment . i had things to do and also lost my internet connection

but i did some labs and mad 2 virtual machines created 2 virtual dc's made them work together created new users secured them used OU's in between  and made my own pc join the  domains . i'm quite limited to this with my main pc 8gb of ram and 2 virtual machines running ^^

i will try when possible all the scenarios that you taught me once i learn more about read only servers and trust relation 

i have little questions , i used to log in with administrator as user name and the password . but after i created the dc i need to spicily the domain name\administrator as user name and then tape the password   . i mean the pc doesn't  have other users and the pc's knows in what domain he is in , then why do i have to specify that  ? also why only the domain-name\admin but not the fully specified one ? it's a common problem that i have right now i don't know when to use the fully qualified domain name or just the domain name . also if a pc joins the domain is it part of the domain itself because  i was watching a video and the guy said that we want this server to become the domain so it can't be part of a domain so it have to stay a work group ? which takes us to my new question i knew now what's a domain . but what's a work group

THANKS

 

 

[Anghammarad]

As soon as a Server becomes a Domain Controller, its local accounts are gone. Only domain accounts are to use on those for logon.

Every other computer/server you add to the domain that don't get promoted to a DC keep their local accounts as well as domain accounts, as long as they are connected to the domains network.

 

It's quite funny but there are some products that you need to install with a local account and won't get installed with a domain account. But this is just a sidenote  

 

 

As for when to use the fqdn or the domain short form to logon. Usually the short form is enough for systems nowadays (win 2003 upwards) but some times I can't say why the short form won't work and you need to enter the fqdn. To create a trust you should use the FQDN when establishing it across the domains. I had several "issues" where it was said use the fqdn and the short form was working as well, and some cases where the short form needed to be used, but only the fqdn did work.

 

To just logon you can use the short form\username or just pick the ressource to logon from the dropdown if the logon screen is configured to have one. 

 

A workgroup is a bunch of local computers/servers that all only have their local accounts but see each other in the network. If you want to login to a machine, you will always need the local accounts then and can't logon with a user from machine A onto machine B. Now you might say but I can logon as admin on all systems. Yes but that is always the local admin from the machine you logon to. 

 

I have a workgroup here at home. called it cave. Now in the network enviroment I can open up the workgroup and see all online machines inside. But you won't have any domain features with it. It's from my point of view just an option to cluster network ressources in groups to easier find them.

[ilyas001]

On 6/15/2017 at 2:10 PM, Anghammarad said:

As soon as a Server becomes a Domain Controller, its local accounts are gone. Only domain accounts are to use on those for logon.

Every other computer/server you add to the domain that don't get promoted to a DC keep their local accounts as well as domain accounts, as long as they are connected to the domains network.

 

It's quite funny but there are some products that you need to install with a local account and won't get installed with a domain account. But this is just a sidenote  

 

 

As for when to use the fqdn or the domain short form to logon. Usually the short form is enough for systems nowadays (win 2003 upwards) but some times I can't say why the short form won't work and you need to enter the fqdn. To create a trust you should use the FQDN when establishing it across the domains. I had several "issues" where it was said use the fqdn and the short form was working as well, and some cases where the short form needed to be used, but only the fqdn did work.

 

To just logon you can use the short form\username or just pick the ressource to logon from the dropdown if the logon screen is configured to have one. 

 

A workgroup is a bunch of local computers/servers that all only have their local accounts but see each other in the network. If you want to login to a machine, you will always need the local accounts then and can't logon with a user from machine A onto machine B. Now you might say but I can logon as admin on all systems. Yes but that is always the local admin from the machine you logon to. 

 

I have a workgroup here at home. called it cave. Now in the network enviroment I can open up the workgroup and see all online machines inside. But you won't have any domain features with it. It's from my point of view just an option to cluster network ressources in groups to easier find them.

thanks for your time