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?
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.
-
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
-
@brrabill said in Handling DNS in a Single Active Directory Domain Controller Environment:
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
Just imagine if a free AD server existed out there!
Oh wait...
-
@kelly 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:
@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?
Completely different. One is "51% or more" and one is "essentially 100%". In no way are they similar.
For example... the "most common correct approach" to commuting is to drive by car. More than 51% of commuters should use cars (given current housing and work locations.) If it was a best practice, it would mean that no one should walk, bike, or take a train. So clearly, very different.
A "Best Practice" means you shouldn't even question it, you always do it. So BPs are insanely rare. We assume that exceptions can exist, so think 99.999% use case, not really 100%, but exceptions are so rare that you never consider that it might exist for you because it's unreasonable. Majority case you never, ever do blindly, because as much as 49% of all cases don't match.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
Perhaps my word choice was not in alignment with the direction you were going, but the distinction is fine if there is one.
The difference, though, is I think what led to the confusion. Here is why...
Your examples were showing that exceptions to the "majority case" existed. But they didn't make sense and we weren't sure how to respond, because the things that you said (without detail) were already implied by the statement of the single AD being the majority case (the minority case would have to be two or more domain controllers.) To be a majority case, you must have a minority case(s) as well.
But if I had said best practice (which is 100% roughly) then showing any reasonable example of there being an exception should disprove the best practice.
I think you were trying to disprove the best practice, but I had never stated such so the proof you provided was confusing to me, since I thought I had already implied that that must already be true by the nature of the single domain controller not being a best practice (there can be no best practice around anything like HA.)
The only actual best practice at play here is a business one that can be stated like this: "HA as the best solution can never be assumed and the need for HA must always be evaluated for the individual scenario."
Or you can flip it if you like, both BPs are true: "Lack of HA can never be assumed as the proper choice, and the need for HA must always be evaluated."
-
@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:
@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?
Completely different. One is "51% or more" and one is "essentially 100%". In no way are they similar.
For example... the "most common correct approach" to commuting is to drive by car. More than 51% of commuters should use cars (given current housing and work locations.) If it was a best practice, it would mean that no one should walk, bike, or take a train. So clearly, very different.
A "Best Practice" means you shouldn't even question it, you always do it. So BPs are insanely rare. We assume that exceptions can exist, so think 99.999% use case, not really 100%, but exceptions are so rare that you never consider that it might exist for you because it's unreasonable. Majority case you never, ever do blindly, because as much as 49% of all cases don't match.
That distinction might be clear in your mind, but it wasn't clear to me, nor do I think to more than a few others. I also think that your definition of a Best Practice is different from the common usage. To most that I talk to a Best Practice is something you do the majority of the time, the best option from your selection of options that is sufficiently better so as to make it your "rule of thumb". A common Best Practice recommendation for SMB is having your DNS service on your DC.
-
@kelly Best Practice is supposed to mean that it is the best thing to do. What you are describing is a common practice, something that is often the best thing to do. If something is best, then you should always do it, because it is best.
The difference in terminology is that the "most commonly best" vs "best" is that one is best "more than any other solution when evaluating the individual solutions", and the other is simply best, no evaluation needed.
A rule of thumb is different than either. Rules of thumb are only okay when they are a safe guide. You can't have a rule of thumb with HA, for example, because both having and not having HA are easily the right choice given a scenario, there isn't really a reliable fall back position to use as a rule of thumb. A rule of thumb might involve something that is rarely the best choice, but avoids a disastrous choice reliably.
Best Practice is a very important term because if you were to catch an employee intentionally not following a true best practice, you should be upset with them and demand an explanation. It means they did something wrong. It's a powerful term. If you said "he didn't follow best practices, and we lost data", it implies he was at fault.
A most commonly correct / best scenario is different. It means that yes, its' the "most likely" to be correct without doing any evaluation. But if you said "he didn't do the most common thing, and we lost data", that it no way implies he evaluated wrong.
Think about people stating a best practice, when people say it, they really mean 100% of the time and if you don't do it, you are in the wrong. And the words mean that. To not follow a best practice is to say that you did something sub-optimally. But to not follow the most commonly best practice means you might still have done the best thing for your specific needs.
-
@kelly said in Handling DNS in a Single Active Directory Domain Controller Environment:
A common Best Practice recommendation for SMB is having your DNS service on your DC.
If you meant commonly rather than common, then yes, I agree. It's most commonly the best solution for an SMB, but it is not a common best practice.
Commonly means here that as it comes up, it's the best choice when evaluated individually.
Common means that it is the best practice and one that is well known.
So the "ly" changes the meaning quite a bit. It's not a best practice, but most commonly it is the best choice.
-
If you think of a conversation with management...
"Well Microsoft says it is a best practice to do X, therefore we should do it."
That's someone believing best practices mean what it really means (although we we'd believe a vendor's opinion, I don't know.) If they believed that a best practice only meant the thing done commonly or the thing most commonly good, that statement would make no sense - because they would know that something being a best practice has no reasonable bearing on whether or not it was good for their scenario.
I've never heard anyone use best practice to mean something other than truly being the best option.
-
@scottalanmiller You have some linguistic gymnastics going on there.
This is what wikipedia says:
Best practice
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements."Generally accepted as superior" being the central point here. IMHO best practice means just that. It doesn't mean that it is actually the best way in every situation, only that it is accepted as generally the best way.
Put in another way - you better have a good reason to do things differently.
-
@pete-s said in Handling DNS in a Single Active Directory Domain Controller Environment:
@scottalanmiller You have some linguistic gymnastics going on there.
This is what wikipedia says:
Best practice
A best practice is a method or technique that has been generally accepted as superior to any alternatives because it produces results that are superior to those achieved by other means or because it has become a standard way of doing things, e.g., a standard way of complying with legal or ethical requirements."Generally accepted as superior" being the central point here. IMHO best practice means just that. It doesn't mean that it is actually the best way in every situation, only that it is accepted as generally the best way.
Put in another way - you better have a good reason to do things differently.
Actually read Wikipedia closely again... it's exactly what I said.
"A best practice is a method or technique that has been generally accepted as superior to any alternatives".
Notice "superior to ANY alternatives". If something is considered a best practice, it means that there considered to be no room for choosing anything else.
That's precisely what I said. No linguistic gymnastics whatsoever. Total agreement. @Kelly 's point was that he felt it meant that there were lots of times you wouldn't do best practices, because they were just common and commonly you'd do something else.
All I'm doing is following the language. The words are quite clear on their own. There's no massaging going on.
-
That's why Best Practices must be so few and far between, there are so rarely things that have no acceptable alternatives. Since a best practice must be accepted to be superior to all alternatives, then you never have to question it, as any alternative is inferior.
But in something like one DC or two, there can be no best practice, because both options are perfectly acceptable under different scenarios. Sometimes one DC is just fine, sometimes you need two (or more.) If one or the other was a best practice, then the other would be never the right option.
-
@scottalanmiller said in Handling DNS in a Single Active Directory Domain Controller Environment:
@brrabill said in Handling DNS in a Single Active Directory Domain Controller Environment:
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
Just imagine if a free AD server existed out there!
Oh wait...
I'm guessing you mean Samba? Or am I missing something?
-
@pmoncho 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:
@brrabill said in Handling DNS in a Single Active Directory Domain Controller Environment:
Just think of what a different discussion this would be if MS just allowed you to spin up a free AD server, that just had AD, like Hyper-V Server.
Just imagine if a free AD server existed out there!
Oh wait...
I'm guessing you mean Samba? Or am I missing something?
Yes, Samba will do AD for free. And is available on many platforms.
-
I believe the forest level with Samba can only be 2008R2 though.
