Back to Active Directory, Route 53 DNS
-
And your AD server is more reliable than a simple DNS service on the same server?
You could point you AD DNS server to route53, and also configure DHCP to assign your route53 DNS as the second DNS server. That way you get the ease and convenience of not having to screw with external DNS with AD.
Lots of options, but it will be more of a pain in the ass to not use MS DNS with AD. It'll work though.
-
Anyways, I'd still set up MS DNS with your first DC so you can just more simply export your zones over. Then after testing you can uninstall you MS DNS.
-
@tim_g said in Back to Active Directory, Route 53 DNS:
And your AD server is more reliable than a simple DNS service on the same server?
You could point you AD DNS server to route53, and also configure DHCP to assign your route53 DNS as the second DNS server. That way you get the ease and convenience of not having to screw with external DNS with AD.
Lots of options, but it will be more of a pain in the ass to not use MS DNS with AD. It'll work though.
AD is not nearly as critical as DNS. I can be without AD server for a week without noticing it.
-
@tim_g said in Back to Active Directory, Route 53 DNS:
And your AD server is more reliable than a simple DNS service on the same server?
You could point you AD DNS server to route53, and also configure DHCP to assign your route53 DNS as the second DNS server. That way you get the ease and convenience of not having to screw with external DNS with AD.
Lots of options, but it will be more of a pain in the ass to not use MS DNS with AD. It'll work though.
The master-slave idea is great, I already consider it and it sounds good to me also.
-
@francesco-provino said in Back to Active Directory, Route 53 DNS:
@tim_g said in Back to Active Directory, Route 53 DNS:
And your AD server is more reliable than a simple DNS service on the same server?
You could point you AD DNS server to route53, and also configure DHCP to assign your route53 DNS as the second DNS server. That way you get the ease and convenience of not having to screw with external DNS with AD.
Lots of options, but it will be more of a pain in the ass to not use MS DNS with AD. It'll work though.
AD is not nearly as critical as DNS. I can be without AD server for a week without noticing it.
Right, but that's why almost everything asks for at least two DNS servers in IP configurations. Many allow you to configure more.
If you can be without it for that long and not notice, it doesn't seem you have any services really relying on it... which makes me further lean towards Salt. Salt is extremely easy to use. Did you give it a fair chance and learn it?
-
@tim_g said in Back to Active Directory, Route 53 DNS:
@francesco-provino said in Back to Active Directory, Route 53 DNS:
@tim_g said in Back to Active Directory, Route 53 DNS:
And your AD server is more reliable than a simple DNS service on the same server?
You could point you AD DNS server to route53, and also configure DHCP to assign your route53 DNS as the second DNS server. That way you get the ease and convenience of not having to screw with external DNS with AD.
Lots of options, but it will be more of a pain in the ass to not use MS DNS with AD. It'll work though.
AD is not nearly as critical as DNS. I can be without AD server for a week without noticing it.
Right, but that's why almost everything asks for at least two DNS servers in IP configurations. Many allow you to configure more.
If you can be without it for that long and not notice, it doesn't seem you have any services really relying on it... which makes me further lean towards Salt. Salt is extremely easy to use. Did you give it a fair chance and learn it?
One thing is to have AD infrastructure in place (that can cache credential and policy for a long time), another one is to have one or more DC always available.
I like salt and I use it for my Linux environments (now learning ansible), but I just prefer the AD integration with many services like our ERP.
-
If your ERP didn't integrate with AD, what authentication would it use?
what was the issue with DropBox and Azure AD? is your issue the lack of a centralized authentication? (I'm assuming DropBox can't use your user's from Azure AD, or vice versa?)
-
Is your plan to not have a LAN? Not sure how you use a public DNS for internal records (NAT'ed, non routable IPs) - I mean, of course you can put non routeable IPs in a public DNS server, that that really seems weird.
-
Are you referring to Route 53 Private DNS hosting to store the zone and reverse DNS zones? Or are you just referring to DNS resolution to resolve public internet services outside of your domain?
If the latter, and in reference to no AD clients I am assuming one issue is the slowness with which DNS can resolve on insecure clients (non AD) for internet services?
Just trying to understand the resiliency issue you are targeting by not using AD DNS...
-
@dashrender said in Back to Active Directory, Route 53 DNS:
If your ERP didn't integrate with AD, what authentication would it use?
Depending on how many people use the ERP I can see that being an issue. If it's manufacturing and every office employee uses it for documents, billing, etc and every shop employee uses it for time tracking and job tracking it could be a nuisance. Plus I doubt there's a way that automation tools can set usernames and passwords because I'm willing to bet this software doesn't have a RESTful API to work with.
-
I agree with the idea of still using local DNS on the AD server(s) and then just having that copy up to Route 53. The only downside is that it would be really cumbersome to make DNS changes if the local AD was down. But would you want to make changes during that period anyway?
-
@scottalanmiller said in Back to Active Directory, Route 53 DNS:
I agree with the idea of still using local DNS on the AD server(s) and then just having that copy up to Route 53. The only downside is that it would be really cumbersome to make DNS changes if the local AD was down. But would you want to make changes during that period anyway?
You could have your orchestration tool do that for you as well. That way they are always in sync, but it's in sync from the orchestration tool instead of some other method.
I'm assuming Salt uses dictionaries the same way Ansible does. For the one role I have I just add a DNS record like this:
records: router: { type: A, last: 1, mac: } server-a: { type: A, last: 5, mac: "de:ad:be:ef:ca:fe" }The MAC doesn't have to be used but I can use the same dictionary for both reservations and DNS entries that way. Then just have your orchestration tool push the changes to both DNS on the AD server and Route 53.
-
@dashrender said in Back to Active Directory, Route 53 DNS:
If your ERP didn't integrate with AD, what authentication would it use?
what was the issue with DropBox and Azure AD? is your issue the lack of a centralized authentication? (I'm assuming DropBox can't use your user's from Azure AD, or vice versa?)
We are using local ERP user, another set of credential to manage. That is one of the issues.
DropBox becomes very pricey if you have a lot of data and a lot of users… spin up another Windows fileserver is essentially free for us (we have datacenter license). And… yes, of course DropBox cannot use AzureAD auth.
-
@dashrender said in Back to Active Directory, Route 53 DNS:
Is your plan to not have a LAN? Not sure how you use a public DNS for internal records (NAT'ed, non routable IPs) - I mean, of course you can put non routeable IPs in a public DNS server, that that really seems weird.
I try to be almost LANless (AzureAD, Dropbox, public DNS), but it does not work so well for our workflow. I see no issue with private IP on public DNS, there is zero valuable information in our IP/server names.
-
@bigbear said in Back to Active Directory, Route 53 DNS:
Are you referring to Route 53 Private DNS hosting to store the zone and reverse DNS zones? Or are you just referring to DNS resolution to resolve public internet services outside of your domain?
If the latter, and in reference to no AD clients I am assuming one issue is the slowness with which DNS can resolve on insecure clients (non AD) for internet services?
Just trying to understand the resiliency issue you are targeting by not using AD DNS...
I’m already using Route 53 to resolve internal address.
-
@stacksofplates said in Back to Active Directory, Route 53 DNS:
@dashrender said in Back to Active Directory, Route 53 DNS:
If your ERP didn't integrate with AD, what authentication would it use?Depending on how many people use the ERP I can see that being an issue. If it's manufacturing and every office employee uses it for documents, billing, etc and every shop employee uses it for time tracking and job tracking it could be a nuisance. Plus I doubt there's a way that automation tools can set usernames and passwords because I'm willing to bet this software doesn't have a RESTful API to work with.
Exactly, we have many application that we can integrate with AD making our life easier.
-
@francesco-provino said in Back to Active Directory, Route 53 DNS:
I see no issue with private IP on public DNS, there is zero valuable information in our IP/server names.
Yeah typically you need to be on someone's local network. And if you are, you can get server names and IPs so easily just by scanning. There's really no need to block IPs and server names in screenshots and such. All you're doing is adding 30 seconds to an attackers work.
-
@scottalanmiller said in Back to Active Directory, Route 53 DNS:
I agree with the idea of still using local DNS on the AD server(s) and then just having that copy up to Route 53. The only downside is that it would be really cumbersome to make DNS changes if the local AD was down. But would you want to make changes during that period anyway?
This is a no-issue, our DNS config is almost static.
-
@francesco-provino said in Back to Active Directory, Route 53 DNS:
@dashrender said in Back to Active Directory, Route 53 DNS:
Is your plan to not have a LAN? Not sure how you use a public DNS for internal records (NAT'ed, non routable IPs) - I mean, of course you can put non routeable IPs in a public DNS server, that that really seems weird.
I see no issue with private IP on public DNS, there is zero valuable information in our IP/server names.
Ya I don’t see an issue either. The only thing that may ever happen is if someone is on a LAN with the same subnet as you and you also have the same record name as a public server. But that seems so out of the way that it’s not even worth considering.
-
I did think of one other issue that would need to be explicitly used in an attack. One of your workers takes a laptop somewhere and connects to public WiFi. They actually connect to a rogue network with the same subnet as your work subnet. Then they could create a few honeypot servers to try to grab any credentials that are sent automatically.
But again this is such a crazy specific case where you have to be targeted with a huge effort behind it. And if they are specifically targeting you they will likely do something much much easier.
