Handling DNS in a Single Active Directory Domain Controller Environment
-
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
Unless you want to provide very specific examples, there won't be "the answer", unless you want a good old 42.
Let's take a greenfield example. I'd use Nethserver and be done with it, if AD services are required. That's a large if tho.
Walking into a place that already has 2016 AD services in place? Then stick with that.
It's all about knowing the different options and the requirements that need to be met.
Sure, which is fine on a recommended basis and that's how you would find out but making generalizations makes it harder to really get to the matter of things. Saying that using Microsoft Windows Server or a Microsoft Environment l or using Linux Server on a Linux or Windows Environment makes a SMB unsuccessful, muddies things.
Most companies are bad. Most companies use Windows. Using Windows isn't suggested to be bad or that using it makes companies bad. Only that both are common and you can't justify the majority use of Windows as being good because most companies are bad so that makes no sense.
What the heck, most companies are bad? I mean I hope this is my last interaction on this thread as I will be just looking from the outside at the moment.
Yes? Most companies are bad and have poor business practices. The vast majority fail under two years. This is pretty common knowledge.
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
No, because it doesn't take 2 hours to restore a 40GB VM. It takes 5 minutes. If it happens over the weekend, and business takes place during the weekend, that's a different story. For many, it won't even matter and can be handled on Monday morning or VERY QUICKLY Sunday night. You don't need to be on-prem to restore a VM.
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host? What does the disks on the host looks like, do we have bad sectors? Or is it a NIC problem on the VM host or a port on the switch? You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
Also, if you're not on-prem and don't have a working AD, are you even able to remote in and access anything?
Yes, but that you can find a way to not be able to restore is not a reason to use it as a decision factor.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
It might very well take two hours if you have cloud backup. Actually, you should probably be very glad if you can restore a tiny little 40GB VM from the cloud in two hours
Why would your only backups exist in the cloud over a slow connection? Mistake number 1.
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
But even if the backup is local you still have to determine what the problem is first. Why would the VM crash if there is not a hardware problem on the VM host?
Because Windows? I don't know. I didn't come up with the scenario. They don't in my experience crash. Windows Updates maybe? Who knows. Lots of reasons a Windows VM could crash, lots of reasons a physical host or host OS could crash too.
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
You can't determine what the problem is and also fix it in 5 minutes, that's completely unrealistic.
This is true regardless of whatever way you do things. Assuming it's the VM, and it's crashed. Restore it in 5 minutes from on-prem backups, or take the time to fix it in hours, cease fsmo roles, and rebuild a new DC from scratch in hours.
If it is ONLY the VM that failed. You might "restore" from a snapshot, too. Don't even need to go to a real backup in many cases.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
just challenging the "most commonly correct approach" statement
It seems you are mistaking the "most common approach" with the "most common correct approach". I haven't been around the SMB as much as JB, but I'm assuming the most common approach to SMB DC implementations are incorrect. Meaning, 2+ DCs are being used when 1 should be used. Perhaps two DCs are used because so many other things are done incorrectly, it's thought 1 should't be used due to so many other things not properly in place, but that's besides the point in my reply here.
IMHO, SMB's use 2 DC's (me included) because it is drilled over and over in our heads by outside forces, including the application developers and the OS companies themselves. On top of that, we are completely stupid if we don't have a second DC if the hardware is available. So to follow "Best Practices," SMB's just do it. It doesn't necessarily mean that things are done incorrectly though. It mostly means, we (aka I) have an extra DC there sitting, waiting, getting monthly updates and then gather more dust for years on end all in the name of protection and risk reduction.
That is why coming here and having extensive discussions about general topics has helped me changed my own thoughts about system/network design in SMB's.
Then I assume you have an extra everything if it costs less than $5k, correct? Especially if other things depend on it... such as redundant ISP, all redundant switches, definitely redundant LoB services, etc... if not, why choose only a DC over things that would be way more beneficial to have HA? If you have extra hardware, extra software, etc... that would go unused and be wasted otherwise, then sure, it could make more sense, but could still cause the same amount of benefits and negatives.
Just because a company has an extra DC doesn't mean every process/product/connection needs to be duplicated. If there are two hosts an extra DC is peanuts. No $5K is needed, $800 tops and there is value (reduced risk) in that $800. Plus, as been mentioned, ceasing roles is less time and MUCH less panic than restoring a VM.
Theres so much more though - now you have to make sure there are no replication issues, and you should likely be backing up that VM (it is a VM, right?) also. You could do it free, but assuming you're using a backup product, that might require another license because it's another box, so more costs. It's also additional time doing updates, 2 boxes vs 1.
Well, yo uonly ever back up one of them, not both. That's moot. But yes, there is real expertise and effort needed to support multiple ADs. I get called in regularly to fix broken AD for customers who thought they would do two and got in over their heads.
-
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Ok - now the question is - how likely is that?
I thought we already covered that the AD DNS should be first - though I can see arguments on both sides - so, whatever. I'm guessing the AD DNS being first would actually be best from a performance POV because one less hope when looking for things when all things are working correctly.
I'm still all for LANless.
At home, I log in to my home Windows computer with my Outlook.com account. That's basically the same as if you used AADDS for your SMB. Then you'd use your AAD login for everything else, and only use software that supports that.
Right, but in this thread, assuming LAN based as AD is a given need.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
But I must add you don't have to go MS to be LANless, above was just an example.
LOL - A stand along Mac or CentOS box is LANLess.
NOt necessarily or commonly.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@pmoncho said in Handling DNS in a Single Active Directory Domain Controller Environment:
In the scenario of 2 DC's, the VM would be backed up but is it worth it? Restoring a DC VM with multiple DC's has a higher probability of creating replication issues.
I thought this was resolved in Windows Server 2016? I.e. a restored DC would check with the other DCs and see that it was behind, and assuming authentication was still valid, it would update itself from the other DCs?
It is typically resolved, yes. Not a major issue IF you have an SMB that is current.
-
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
-
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
Unless you want to provide very specific examples, there won't be "the answer", unless you want a good old 42.
Let's take a greenfield example. I'd use Nethserver and be done with it, if AD services are required. That's a large if tho.
Walking into a place that already has 2016 AD services in place? Then stick with that.
It's all about knowing the different options and the requirements that need to be met.
Sure, which is fine on a recommended basis and that's how you would find out but making generalizations makes it harder to really get to the matter of things. Saying that using Microsoft Windows Server or a Microsoft Environment l or using Linux Server on a Linux or Windows Environment makes a SMB unsuccessful, muddies things.
Most companies are bad. Most companies use Windows. Using Windows isn't suggested to be bad or that using it makes companies bad. Only that both are common and you can't justify the majority use of Windows as being good because most companies are bad so that makes no sense.
What the heck, most companies are bad? I mean I hope this is my last interaction on this thread as I will be just looking from the outside at the moment.
85% of new companies fail. Yes, the average company is HORRIBLE. THe average company loses money, makes ridiculous decisions. This is the most fundamental truth of business in general. This is taught in all business classes. The average person is terrible at making decisions, business averages reflect this.
This isn't some weird statement, this is standard business knowledge that is supposed to be something everyone knows. Businesses fail with reckless abandon because... all the reasons we see every day. No clue what they are doing, risky, wasting money, bad business planning, etc.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Because it is a huge amount of risk mitigation so that breaking into one thing doesn't cascade to the whole environment. And it allows for all kinds of flexible use cases that AD doesn't well support.
-
@coliver said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dbeato said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
I do also understand that all SMBs are not equal, some may be running software that absolutely requires 99.999 uptime of AD... I get it. Then on the other side I coudl question why something like that was chosen in the first place. There are great alternatives to Windows for SMBs.
When you say they are great alternative to Windows for SMBs, what do you have in mind? Because if you see the SMB landscape you will find the opposite of what you are stating.
Just because many places deploy something, doesn't mean it was the right tool to use. There are reasons why so many SMB fail.
So what is the answer, that is all I am looking for.
Unless you want to provide very specific examples, there won't be "the answer", unless you want a good old 42.
Let's take a greenfield example. I'd use Nethserver and be done with it, if AD services are required. That's a large if tho.
Walking into a place that already has 2016 AD services in place? Then stick with that.
It's all about knowing the different options and the requirements that need to be met.
Sure, which is fine on a recommended basis and that's how you would find out but making generalizations makes it harder to really get to the matter of things. Saying that using Microsoft Windows Server or a Microsoft Environment l or using Linux Server on a Linux or Windows Environment makes a SMB unsuccessful, muddies things.
Most companies are bad. Most companies use Windows. Using Windows isn't suggested to be bad or that using it makes companies bad. Only that both are common and you can't justify the majority use of Windows as being good because most companies are bad so that makes no sense.
What the heck, most companies are bad? I mean I hope this is my last interaction on this thread as I will be just looking from the outside at the moment.
Yes? Most companies are bad and have poor business practices. The vast majority fail under two years. This is pretty common knowledge.
It's like 55% fail in 2 years, 85% before 8 years. This is why getting bank loans is nearly impossible before the 8 year mark. Being in the black after eight years is the mark of "initial success" in starting a working business generally.
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@Obsolesce later stated a BP, long after you had introduced it. But from what I've seen you two alone are discussing BPs. Everyone else is discussing "possible options".
I made a point on
that a "MS Best Practice" is not to be confused with an "IT Best Practice".Technically, having more than one DC is a MS Best Practice. In fact, it's even in the Server BPA (Best Practice Analyzer) as such.
So I know it's not an IT best practice, I was using it in the context of the current understanding of what's going on if that makes sense.
Someone should repeat what you said about best practices in that
thread. -
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
Risk mitigation is one reason - OK fine. But come on - how often does someone's AD really fail?
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
that's very bad logic. That's sunk cost thinking. You should be evaluating AD for each case, not "use it because we have it." That's how most AD gets deployed in the first place (we have Windows, so AD is included, why not use it.)
THere are loads of times that using it for those things is good. But loads that it is not, too. Never should you say "we have it, so we should use it."
-
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
Risk mitigation is one reason - OK fine. But come on - how often does someone's AD really fail?
Define fail. Fail when integrating with things, decently often. Fail because it turned out to be a security breach because we extended it to third party apps? More often than people say, or know.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dashrender said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@travisdh1 said in Handling DNS in a Single Active Directory Domain Controller Environment:
@dafyre said in Handling DNS in a Single Active Directory Domain Controller Environment:
@jaredbusch said in Handling DNS in a Single Active Directory Domain Controller Environment:
What really needs to be laid out here is a list of what needs done on both sides, both proactively and reactively after a failure. At that point relative costs can be estimated.
I certainly what @JaredBusch mentions would be a good grounding point for this point of discussion... Let's first describe the business scenario.
Company Details for Scenario 1
Acme, Inc.
24 Employees
1 x Virtualization Host
1 x AD Server (AD, DNS, DHCP) VM
Y x other VMs
Email is hosted on O365.
(we don't care about other VMs for sake of this discussion, do we?)
1 x Network RouterAssumptions:
- All devices use the router for DNS1, and AD Server for DNS2.
- Router points to AD Server for DNS1, and CloudFlare for DNS2.
- Company already owns a working backup product
Scenario 1:
Problem: AD Server VM Blows up, Blue Screens, Gets Deleted or just won't boot.
Impact: Services Requiring AD for authentication will not work. Devices that were working when the AD Server died continue working until DHCP lease time runs out. Internet is up since the router can use CloudFlare for DNS.
Solution: Restore VM from most recent backup into new VM on the Virtualization host.
Cost Formula: Hours Downtime * Lost Productivity (if Any) = Total Cost
**Cost: 2 hrs * $5000/hr = $10,000Does that oversimplify the discussion or provide enough details?
Getting there. What service broke because AD was down? Most of the time, AD could be down and nobody would know the difference. To have cost associated with AD being down, a service that doesn't cache credentials has to be authenticating with it.
Seriously, try it in your home lab sometime. Just shut down any AD servers you have running and see how long it takes for something to break.
First thing that comes to mind: NextCloud with AD integration, RocketChat with AD integration.
For the case of my scenario, we don't worry about WHAT broke. If you look closely at my Cost Formula... It was Lost Productivity (if Any)... because you're right, just because AD is down, doesn't necessarily mean the entire business just stops.
Right, but that's contrived. Why are they putting in those breaking points if they are risky, and why in such a small environment?
We have a similar setup, and just avoid AD integration, problem solved. And solved solidly. I know shops with hundreds of people doing the same.
Why make things harder for people by having multiple logons when you can skip that and have some form of SSO? or at least shared credentials?
Are you assuming AD provides SSO? So many other things can provide that piece of AD if needed.
SSO is likely the wrong term in this case. What I mean is a single centralized authentication. the user only needs ONE username and password, not many.
If you use have AD username/password and a separate one for NC, that's just more work on the user - why? Sure this thread gives one possible reason why to not do it.
If SSO is a thing you want to enable, lots of LDAP servers are available that can provide it securely, in addition to AD.
Sure - but that wasn't the point. We're talking about a single AD environment. You already have AD. Why not use it?
that's very bad logic. That's sunk cost thinking. You should be evaluating AD for each case, not "use it because we have it." That's how most AD gets deployed in the first place (we have Windows, so AD is included, why not use it.)
THere are loads of times that using it for those things is good. But loads that it is not, too. Never should you say "we have it, so we should use it."
Fine - I should have said - why not evaluate using it.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
What about an SMB who already has the mitigations in place (everything is set up correctly) for a single-DC environment?
@obsolesce said in Handling DNS in a Single Active Directory Domain Controller Environment:
What about automation? What if AD cannot be reached, so a bunch of other automatic checks take place, and if determined, automatically restores the DC? This would be rather simple to set up.
Not sure how this is even germane to the discussion. We are talking about best practices and recommendations for AD implementation.
No, no one was discussing that. That's not the topic of this thread, and you introduced both the discussion about AD practices and then later about best practices. At no point was I discussing best practices and I saw no one else discussing it either.
@Obsolesce later stated a BP, long after you had introduced it. But from what I've seen you two alone are discussing BPs. Everyone else is discussing "possible options".
How is "most commonly correct approach" different from a best practice? Perhaps my word choice was not in alignment with the direction you were going, but the distinction is fine if there is one.
-
I can give this answer from an SMB perspective. I feel like I am probably really close to the majority of SMB that try and deploy AD, specifically "because we already have it". In my implementation, we had two locations and two hosts initially, so it seemed a no brainer to use to DC's. However, I would guess that a lot of people that are setting up AD don't really know what AD even actually does. I have confused other things built into windows or NTFS with being AD simply because I manage the from my DC. I am talking about things like group policy, security groups, file permissions, etc. I would bet that the majority of SMB that deploy AD do so because they want to leverage these things and because owning windows servers gives them access to AD which is included.
With all that said, I know that AD's simplicity can be deceiving and there is a high chance that just because you have two DC, it doesn't mean that you have them configured correctly, I know that I don't.
How often does the real SMB actually have people that already know AD and what it actually does, and know that there are any other options in a windows ecosystem? I didn't even know I had a choice until recently.
