ZeroTier + Active Directory Authentication
-
I am initially only getting ZT installed and will be seriously working my way through this tomorrow.
I already know I can do it, because I did the same thing with Pertino before they released their AD Connect add on.
I opened a thread on the ZeroTier forums (it is NodeBB!) a couple days ago and they have not worked up a process yet. So it is up to us
Since ZT uses IPv4 and not IPv6, the hard part here is getting the DNS only resolving when desired. The original Pertino client was easy to get only AD auth working because it was IPv6 only.
@scottalanmiller on a related note, I had to go to the wayback machine to get your old post about Pertino and AD.
The problem with using IPv4 like this instruction says to do is that all DNS ends up going through and interal IP addresses get returned (as they should).
I do not want full mesh. I want AD Auth, nothing else. When you have full mesh it is easy.
-
Test network built with 2 devices and IPv6 and IPv4 addresses. Too tired to try and understand their very very bad instructions on how to build the controller myself. also not critical for this test.
More tomorrow.
-
@JaredBusch said:
@scottalanmiller on a related note, I had to go to the [wayback machine ....
Oh, yeah I shut that down, no time to maintain it. There wasn't that much content. But that's a great idea, I'll move that stuff here for archival purposes.
-
@JaredBusch said:
I do not want full mesh. I want AD Auth, nothing else. When you have full mesh it is easy.
Well I'm assuming you want things like network shares and GPOs to work as well?
I'm definitely interested in seeing what you come up with.
-
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
-
Relevant to my interests
-
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
-
@Dashrender said:
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
A VPN client is not automagically connected when the machine is booted and active prior to log in. Thus a VPN client will not cause AD creds to be refreshed and you will eventually run into the cached credential expiration.
-
@JaredBusch said:
@Dashrender said:
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
A VPN client is not automagically connected when the machine is booted and active prior to log in. Thus a VPN client will not cause AD creds to be refreshed and you will eventually run into the cached credential expiration.
We always used OpenVPN in that way, worked really well.
-
@Dashrender said:
@JaredBusch said:
I do not want full mesh. I want AD Auth, nothing else. When you have full mesh it is easy.
Well I'm assuming you want things like network shares and GPOs to work as well?
I'm definitely interested in seeing what you come up with.
I care less for shares. I use ownCloud for that.
I specifically want valid AD authentication when needed and nothing else. Most especially I do not want full DNS redirect.
Full DNS redirect requires that you have full connectivity on the ZT network for all devices and also causes all traffic for onsite resources to subsequently route over ZT because they are getting the ZT IP from DNS. I do not want that.
For example, remote.domain.com is the Exchange server and resolves internally to 10.X.X.14 and externally to 12.X.X.42. When I am on the network it runs on the LAN and when I am off the network it runs out the WAN. This is normal. But if I have a full ZT network with DNS, then I end up with email clients using the ZT IP for connectivity and all traffic now routing through ZT.
While this is not really a bad thing, it is completely not required. The pre ZT setup is already fully secure and encrypted end to end via standard SSL. I have no need to route this traffic.
-
@scottalanmiller said:
@JaredBusch said:
@Dashrender said:
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
A VPN client is not automagically connected when the machine is booted and active prior to log in. Thus a VPN client will not cause AD creds to be refreshed and you will eventually run into the cached credential expiration.
We always used OpenVPN in that way, worked really well.
OpenVPN automatically connecting with no user interaction prior to desktop log in? I have never had that work reliably on end user machines.
-
@JaredBusch said:
@scottalanmiller said:
@JaredBusch said:
@Dashrender said:
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
A VPN client is not automagically connected when the machine is booted and active prior to log in. Thus a VPN client will not cause AD creds to be refreshed and you will eventually run into the cached credential expiration.
We always used OpenVPN in that way, worked really well.
OpenVPN automatically connecting with no user interaction prior to desktop log in? I have never had that work reliably on end user machines.
Yeah, it worked great for us (read: worked great after the pain of setting it up for each user) and we used it until we moved to Pertino. It was very reliable and we specifically used it for AD functionality.
-
My co-worker left the spare domain joined client laptop in the office
Hopefully I will have access to that a bit later and can continue with the AD auth configuration.
-
@scottalanmiller said:
@JaredBusch said:
@scottalanmiller said:
@JaredBusch said:
@Dashrender said:
@dafyre said:
If all you are wanting is AD Auth, why not just use a VPN?
A VPN, in this case would likely be less complicated than trying to pigeon hole ZT into place like this...
Does the open VPN client handle this seamlessly for users? How do you handle proper DNS issues with that?
I'm using a Split horizon DNS, so I can't just assume everything going to my DNS name is internal.
A VPN client is not automagically connected when the machine is booted and active prior to log in. Thus a VPN client will not cause AD creds to be refreshed and you will eventually run into the cached credential expiration.
We always used OpenVPN in that way, worked really well.
OpenVPN automatically connecting with no user interaction prior to desktop log in? I have never had that work reliably on end user machines.
Yeah, it worked great for us (read: worked great after the pain of setting it up for each user) and we used it until we moved to Pertino. It was very reliable and we specifically used it for AD functionality.
I'm going to test a similar setup in my test environment.
-
@JaredBusch said:
While this is not really a bad thing, it is completely not required. The pre ZT setup is already fully secure and encrypted end to end via standard SSL. I have no need to route this traffic.
Why does it matter? I also recall ZT coming here and saying that if ZT detected that a client device was trying to talk to a local service, even though it was using the ZT IPs, it would be done over the local network, at or near full network speeds. So the full mesh shouldn't be a problem.
What I don't understand is when you're offsite, your device is at Starbucks... your computer has to use the DNS provided by the DHCP of Starbucks so it can find your ZT controller - only after that happens would it be possible to switch to using your internal DNS servers.
What facilitates this switch?
-
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.
-
@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.
-
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?
