ZeroTier + Active Directory Authentication
-
I did read your links, what I want to know is how you manged to avoid DNS issues with non Pertino clients when they quired DNS (on the IPv6 side) and received the Pertino IPv6 address instead of the local network one?
This is the same problem I've seen with ZT on IPv4.
Did you disable IPv6 on all workstations and other servers except those using Pertino?
-
@JaredBusch said:
@dafyre said:
One possible solution, if you are going to use ZT... Is you will need to install ZT on at least one domain controller...
On this domain controller, you should:
- Set the ZT Adapter to use DHCP for the IPv4 Address and DNS settings, and the OK back out.
- Set the ZT Adapter to not register in DNS
- Check DNS and remove the ZT Adapter IP address.
On the Client Machines, you should:
- Set the ZT Adapter to use DHCP for the IPv4 Address and DNS settings, and the OK back out.
- Set the ZT Adapter to not register in DNS
- Check DNS and remove the ZT Adapter IP address.
4) Modify the C:\Windows\system32\drivers\etc\hosts file to add an entry for the DC and its ZT IP address.
Depending on the number of clients you have, that seems to be a feasible set of instructions.
No no no. Did you read the prior links at all? This was easily done with Pertino and IPv6 previously with nothing but a DNS entry on the IPv6 of the client. I know that works. I used it for quite a bit. I assume I can replicate it with ZT, but I am now stuck waiting for the test device to get online.
Change my instructions to do IPv6, and it should still net you the same result.
If you set your ZT Network to accept All protocols, and set your ZT ipv6 to "ZeroTier Managed"But as in @scottalanmiller's web page, add the ZT IPv6 address of your AD server.
-
We've got hardware to build a test lab, and are going to work on this pretty soon as well.
@JaredBusch Curious about the comment on "we don't want full mesh." Why? Is it just something you don't need or do you actively not want it?
-
@adam.ierymenko said:
We've got hardware to build a test lab, and are going to work on this pretty soon as well.
@JaredBusch Curious about the comment on "we don't want full mesh." Why? Is it just something you don't need or do you actively not want it?
I don't know about JB - but I'm concerned with just deploying this to all 115 of my devices and the possible problems I might run into. Deployment would take me at least 2 days (I suppose if I could build a script I could get it done faster) and during the transition, what's going to break?
-
@Dashrender said:
I don't know about JB - but I'm concerned with just deploying this to all 115 of my devices and the possible problems I might run into. Deployment would take me at least 2 days (I suppose if I could build a script I could get it done faster) and during the transition, what's going to break?
I don't feel like that is a good way to look at it. I mean the concern is real and valid, but half deploying something in a way that it is not intended isn't exactly wrong, per se, but you are using a product without attempting to leverage its value. If anything is going to make it complicated and cause problems, that's when I would expect that to happen. If it works, you always worry that you are just getting lucky and if it doesn't work you can always assume that it was because you never really tried it.
I meant it's just a tool, use as appropriate for you. But if you are not trying to use it as intended, why are you choosing this particular tool?
-
@Dashrender Yeah, if we go full product on this we will want some kind of "migration assistant" and/or detailed HOWTO that doesn't suck.
-
@scottalanmiller said:
@Dashrender said:
I don't know about JB - but I'm concerned with just deploying this to all 115 of my devices and the possible problems I might run into. Deployment would take me at least 2 days (I suppose if I could build a script I could get it done faster) and during the transition, what's going to break?
I don't feel like that is a good way to look at it. I mean the concern is real and valid, but half deploying something in a way that it is not intended isn't exactly wrong, per se, but you are using a product without attempting to leverage its value. If anything is going to make it complicated and cause problems, that's when I would expect that to happen. If it works, you always worry that you are just getting lucky and if it doesn't work you can always assume that it was because you never really tried it.
I meant it's just a tool, use as appropriate for you. But if you are not trying to use it as intended, why are you choosing this particular tool?
Well shortly after ZT came on the scene here on ML you, Scott, told me I was looking at ZT and Pertino all wrong. It's an all or nothing type of solution - that's how it was designed. Which is fine - But I have so few travelers that it's a lot of work (deploying it everywhere and then keeping in mind it's there for troubleshooting purposes).
I really like the idea of ZT over traditional VPN, because both JB and I are accustomed to VPN clients that won't load before a user logs on, and therefore can't get GPOs, or passwords that were changed on a different device, etc, etc, etc.
At this point, due to my very small mobile workforce compared to non mobile - I know I need to consider if this solution, as good as it maybe, might not be what I need.
-
@adam.ierymenko said:
@Dashrender Yeah, if we go full product on this we will want some kind of "migration assistant" and/or detailed HOWTO that doesn't suck.
Absolutely
I'm wondering if someone we know might be willing to assist?
-
@Dashrender said:
Well shortly after ZT came on the scene here on ML you, Scott, told me I was looking at ZT and Pertino all wrong. It's an all or nothing type of solution - that's how it was designed. Which is fine - But.....
Read your lead up and then.... but...
Are you sure you want a but there? I mean, you understand that you are looking at it wrong and not embracing it, but you are going to come up with a reason why you are an exception. Which maybe you are, but are you really both an exception to the deployment design and right for this tool?
-
@Dashrender said:
I really like the idea of ZT over traditional VPN, because both JB and I are accustomed to VPN clients that won't load before a user logs on, and therefore can't get GPOs, or passwords that were changed on a different device, etc, etc, etc.
But that's not traditional VPN. You are having an issue with having either had a problem with configuring a VPN or choosing a really poor one (Cisco is garbage in my experience.) I've been working with VPNs since 1999 extensively and the issues you face are ones that I've never had until one job that used a Cisco client just recently and that's when I found out for the first time that anyone was having this as an issue!
I think you are associated something with non-mesh VPNs that simply isn't true and associating something with mesh VPNs that is also not true (ZT can be designed to start later or only with user intervention just like Cisco) and confusing that you want a VPN that connects automatically with the concept of full mesh software defined networking. Leading you to feel like you need one tool but refusing to embrace it and use it as intended. You are really looking for a traditional VPN in every way.
-
@Dashrender said:
I really like the idea of ZT over traditional VPN....
I don't understand this statement. The thing that makes this unique is the full mesh aspect, the one part you don't like. What about ZT do you like if not the part that sets it apart?
-
@Dashrender said:
At this point, due to my very small mobile workforce compared to non mobile - I know I need to consider if this solution, as good as it maybe, might not be what I need.
Or just accept that the minor problem of deploying everywhere isn't really a problem worth actually considering. What does a full environment roll out take? Some effort, sure. But a lot? I doubt that it takes enough to really be worried about it. I have been rolling it out with servers recently and the big effort is just logging into the console.
-
@scottalanmiller said:
@Dashrender said:
Well shortly after ZT came on the scene here on ML you, Scott, told me I was looking at ZT and Pertino all wrong. It's an all or nothing type of solution - that's how it was designed. Which is fine - But.....
Read your lead up and then.... but...
Are you sure you want a but there? I mean, you understand that you are looking at it wrong and not embracing it, but you are going to come up with a reason why you are an exception. Which maybe you are, but are you really both an exception to the deployment design and right for this tool?
No I'm sure I'm not both - I'm sure I should be on something else. I guess that was what I was meaning to say.
-
@Dashrender said:
No I'm sure I'm not both - I'm sure I should be on something else. I guess that was what I was meaning to say.
While I think that ZT on everything is likely the best choice, if all you want is a hub and spoke... you really want to have a hub and spoke. OpenVPN and IPSec work great for this, it's really what they are architected to do.
-
@scottalanmiller You could also bridge it to a physical network if you have old boxes, printers, fax machines, etc. A Raspberry Pi makes a great bridge for $30.
-
@scottalanmiller said:
@Dashrender said:
At this point, due to my very small mobile workforce compared to non mobile - I know I need to consider if this solution, as good as it maybe, might not be what I need.
Or just accept that the minor problem of deploying everywhere isn't really a problem worth actually considering. What does a full environment roll out take? Some effort, sure. But a lot? I doubt that it takes enough to really be worried about it. I have been rolling it out with servers recently and the big effort is just logging into the console.
It's not the effort itself, as I said, I could walk around and get it done in two days. At this point, considering you're telling me that if I use a different VPN solution I'll probably get what I want ( pre logon VPN connections).
A concern is if the complexity is worth it considering my end goal.
-
Something to consider is that the effort to learn and deploy a solution like OpenVPN will likely be several times more time consuming and difficult than rolling ZT out to nodes that don't absolutely require a VPN connection. It's a trade off... do you care about your time, effort and flexibility or do you care about deploying the software to more nodes? Depends on your total network, of course, it's not that simple. But we moved to this model because deploying to every node was a fraction of the effort of OpenVPN to some nodes.
-
@Dashrender said:
A concern is if the complexity is worth it considering my end goal.
In this case, it's hard to know which is more complex. Setting up a VPN solution that does what you need might be more complex to you than ZT. We have ZT running and it is super simple.
-
@adam.ierymenko said:
@scottalanmiller You could also bridge it to a physical network if you have old boxes, printers, fax machines, etc. A Raspberry Pi makes a great bridge for $30.
I know this is a huge topic - one that I've even participated in. But how realistic is it that you'll want printer access while not onsite? At that point won't the local IP scheme solve the issue?
I suppose if the goal is to never worry about a local network, live purely in the ZT LAN, then this is worthwhile.
-
@Dashrender said:
I know this is a huge topic - one that I've even participated in. But how realistic is it that you'll want printer access while not onsite? At that point won't the local IP scheme solve the issue?
Right, in most cases, the ZT model does not get complex. Things that can't talk on ZT generally don't need ZT.
