ZeroTier + Active Directory Authentication
-
@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?
-
@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.
