In which @Captain is confused by Windows



  • I'm setting up DirectAccess for work, so that the people at the remote offices can get into the network. I can't quite get it to work. I don't know if there's a single cause for the problem or not, but I did track down a promising lead.

    The DirectAccess server is located at vpn.contoso.org. If I run nslookup.exe on that domain, I get the right IP address. But my web browser and Windows both tell me that they can't resolve that name. WTF?


  • Notification Spam Recipient

    Yeah, I tried for a few weeks to get it set up, and failed. Best I could figure is that IPv6 wasn't enabled/configured properly and that apparently breaks stuff.



  • @Captain

    DirectAccess is a huge mess, especially if your goal is "simple VPN so people can get shit done from off site". At this point, it effectively requires true IPv6 on the internal corporate network (regardless of your internet connectivity - dual stacked will work).

    If you don't have IPv6 running on the internal network, set up a traditional VPN solution and go to the pub early. It'll be a lot easier on your users and your liver.

    If you do have IPv6 working, I can probably help out if you can provide some more details about the symptoms / error messages.



  • Hm, I wonder how hard it would be to turn IPv6 on. I think I'd have to enable it in the router. Does Windows need any specific configuration for IPv6 or does it learn what it needs from DHCP?



  • @Captain

    In theory, IPv6 should be fairly easy to turn on. Assuming your internal LOB applications and such support it. And that your installed base is Server 2008 R2 & Windows 7 or newer (Windows 8+ clients will help a lot for performance of the DA link).

    Basic IPv6 spec calls for computer auto configuration (basically an ARP-like discovery of the router that gets the prefix 64-bits of the network, and then an algorithm that hashes computer information like MAC to create a uniqueish 64-bit "host" address that stays the same on every network, so the full address is network + host). Some network admins aren't exactly thrilled with that sort of setup, so DHCPv6 or Static v6 addressing is also a thing.

    Ultimately, though DA is something like this:

    • The question Microsoft tried to answer: How do we ensure the corporate computers can be managed by System Center no matter where they are
    • The solution Microsoft billed it as: Hey, your corporate computers will JustWork(tm) with your corporate network no matter where they are, no user credentials required!
    • The solution sysadmins think it is: Drop-in replacement for Routing & Remote Access. (which it very much IS NOT).


  • OK I got DirectAccess working!

    Mostly. Windows is confusing me again.

    Right now, I'm sitting at home, some 60 miles away from the office. Windows 8.1 says I'm connected to the office network. I can see my desktop (which is stored on the office fileserver). But there are problems;

    1. can't connect to the file server directly/easily. I put in a FQDN in Explorer and I was able to connect to it, but even still;
    2. shares are missing, even when I connect to the file server's root directory.
    3. I can't see the office printers.
    4. Remote desktop connection won't work (it does if I'm in the building, though).

    Any ideas? I kind of think starting with 4 would make things easiest (since I could conceivably fix the rest from home on Friday -- if I could connect to the domain controller)


  • 🚽 Regular

    @Captain My knee-jerk reaction is group policies aren't being applied. But I'm still too green to know how DirectAccess and stuff works.



  • @Captain There is no IPv4 connectivity via DA. So you need FQDNs, and DNS64 and NAT64 set up for your DA infrastructure.



  • @Erufael I went through a painful process of debugging Group policies. I see all the relevant policies applied, even the custom one I made to share the self-signed certs and stuff.

    @izzion said in In which @Captain is confused by Windows:

    @Captain There is no IPv4 connectivity via DA. So you need FQDNs, and DNS64 and NAT64 set up for your DA infrastructure.

    So I should probably reset the domain controller's network stack so it gets an IPv6 in the AD/DNS?



  • @Captain

    Sorry for dashing off a cryptic post while I was working on something else.

    Basically, you cannot access anything via \\192.168.1.5 or similar over DirectAccess. The DA client has IPv6 connectivity only. If you configure your DA infrastructure correctly, you can deploy a DNS64 server to provide IPv4 A records to IPv6 clients, and a NAT64 server to allow the IPv6 clients to reach the IPv4 servers (inbound requests) via NAT. This will only work with FQDN access, though -- the DA client cannot use NAT64 to access something by an IPv4 IP address (such as many network printer connections).

    For initiating outbound connections to the DirectAccess clients (referred to as Manage Out - often used for ensuring your System Center Config Manager infrastructure can poll clients to ensure compliance with corporate policy, allow help desk access, etc), the server initiating the outbound request MUST have IPv6 active, and routable to the DirectAccess network, meaning your network infrastructure/design will have to support IPv6 as well. But for most client-initiated "VPN access" type function, setting up the DNS64 and NAT64 roles and ensuring all access is via FQDN will generally work.

    The most commonly held up example of things that may never work on DA would be old legacy applications that rely on hardcoded IPv4 addresses. But even there, things like ODBC generally can be configured to support FQDNs (they just usually aren't, because after all static IPs don't change so what's the big deal?)



  • ... what is DirectAccess and what is wrong with good old-fashioned RRAS SSTP VPNs (outside of the Error'd-worthy writing in some of the error messages that sound like they've been written by a typical Indian and not gone through quality control)?

    (... oh, DirectAccess is just a lazy variant of the inherently broken 'site-side' VPN client in RRAS that actually sets up client-to-site connectivity rather than an attempt at site-to-site? cute.)



  • @NTAuthority
    @izzion said in In which @Captain is confused by Windows:

    Ultimately, though DA is something like this:

    • The question Microsoft tried to answer: How do we ensure the corporate computers can be managed by System Center no matter where they are
    • The solution Microsoft billed it as: Hey, your corporate computers will JustWork(tm) with your corporate network no matter where they are, no user credentials required!
    • The solution sysadmins think it is: Drop-in replacement for Routing & Remote Access. (which it very much IS NOT).

    @izzion said in In which @Captain is confused by Windows:

    DirectAccess is a huge mess

    Basically, it was intended as the VPN reimagined, but implemented such that it's probably so much more difficult to configure that it's not worth the hassle versus a standard VPN.


  • Notification Spam Recipient

    @izzion said in In which @Captain is confused by Windows:

    Basically, it was intended as the VPN reimagined, but implemented such that it's probably so much more difficult to configure that it's not worth the hassle versus a standard VPN.

    X1000! I gave up after I could never get it to detect that I was inside the domain network.

    How hard could it be to ping a fscking server?!?!?



  • @Tsaukpaetra

    Well, if you were having problems with it not realizing you were inside the domain network, then that's going to be due to a problem with the Network Location Server - the FQDN and IIS website that the DA client uses to determine its network location. If it can reach the NLS, it thinks it's on network. If it cannot, it thinks it's off network and attempts to connect to the DirectAccess edge as an offsite client.

    But reaching is more than just pinging it. The DA client needs to get a 200 OK with a valid certificate (and CRL) in response to its HTTPS request for the NLS server (but it can just be the IIS default website).

    Edited to reflect the HTTPS requirements, as expanded on in two posts below


  • Notification Spam Recipient

    @izzion said in In which @Captain is confused by Windows:

    @Tsaukpaetra

    Well, if you were having problems with it not realizing you were inside the domain network, then that's going to be due to a problem with the Network Location Server - the FQDN and IIS website that the DA client uses to determine its network location. If it can reach the NLS, it thinks it's on network. If it cannot, it thinks it's off network and attempts to connect to the DirectAccess edge as an offsite client.

    But reaching is more than just pinging it. The DA client needs to get a 200 OK from its HTTP request for the NLS server (but it can just be the IIS default website).

    Yeah, that's just it: I could do so and it was still convinced I was "outside". I tried so many things, like mucking around with DNS to having the website to ping being hosted by httpd on the primary router, and without fail as soon as the Group Policy got applied BAM I'm outside...



  • @Tsaukpaetra

    Did you have a valid certificate for https://nls.domain.com/ for the website (or whatever the FQDN of the NLS was)? DA won't validate the connection unless it's using a trusted certificate with a valid CRL.


  • :belt_onion:

    @izzion said in In which @Captain is confused by Windows:

    @NTAuthority
    @izzion said in In which @Captain is confused by Windows:

    Ultimately, though DA is something like this:

    • The question Microsoft tried to answer: How do we ensure the corporate computers can be managed by System Center no matter where they are
    • The solution Microsoft billed it as: Hey, your corporate computers will JustWork(tm) with your corporate network no matter where they are, no user credentials required!
    • The solution sysadmins think it is: Drop-in replacement for Routing & Remote Access. (which it very much IS NOT).

    @izzion said in In which @Captain is confused by Windows:

    DirectAccess is a huge mess

    Basically, it was intended as the VPN reimagined, but implemented such that it's probably so much more difficult to configure that it's not worth the hassle versus a standard VPN.

    The biggest advantage I see with DA is that it's standard TCP over HTTPS, meaning it bypasses a lot of stupid VPN blocking things on hotspots and stuff.



  • @izzion said in In which @Captain is confused by Windows:

    @Tsaukpaetra

    Did you have a valid certificate for https://nls.domain.com/ for the website (or whatever the FQDN of the NLS was)? DA won't validate the connection unless it's using a trusted certificate with a valid CRL.

    Yeah, that's a big deal. I had to write custom group policy to move a self-signed cert around.


  • Notification Spam Recipient

    @izzion said in In which @Captain is confused by Windows:

    @Tsaukpaetra

    Did you have a valid certificate for https://nls.domain.com/ for the website (or whatever the FQDN of the NLS was)? DA won't validate the connection unless it's using a trusted certificate with a valid CRL.

    Well that's something that was NEVER mentioned anywhere. The answer is yes, after I trusted a self signed certificate. But I was primarily using the point where it said I could just have it ping said server.

    The documentation said that essentially so long as it was dns resolvable and responded it would 👍 the network as inside.



  • @Tsaukpaetra

    Yeah. The more research I've done into DA, the more I'm convinced it's the :guacamole: VPN.


  • area_deu

    @izzion said in In which @Captain is confused by Windows:

    Yeah. The more research I've done into DA, the more I'm convinced it's the :guacamole: VPN.

    Good to know. I'll continue to ignore it.
    Because OpenVPN just works.


  • Dupa

    @ChrisH are you sure?

    0_1469709029552_openvpn.PNG


  • area_deu

    @kt_ Yes. Because the OpenVPN people are decidedly NOT FOSS asshats.
    Plus we bought the commercial package anyway.



  • How would a remote computer even use AD if we had a plain VPN?


  • Notification Spam Recipient

    @Captain said in In which @Captain is confused by Windows:

    How would a remote computer even use AD if we had a plain VPN?

    Typically they auth outside the AD with certificates and then they're in the network so then AD.



  • @Captain

    1. You set up a new computer on network, join it to the domain
    2. The intended user logs in while the computer is still connected to your network
    3. The user takes the laptop offsite - when (s)he had already logged in on net, Windows caches the user account credentials so the user can log in offsite
    4. After logging into the computer, the user fires up the VPN connection (either as separate software - e.g. OpenVPN or AnyConnect - or via the networking control panel if you're using Windows RRAS for a PPTP connection) and logs in with their network credentials
    5. ???
    6. Profit! (Congratulations, you're now connected to the corporate network via IPv4)

    The big headache you get into in the above scenario comes from password expiration rules. Unlike when the computer is on-premises, the off-network computer will happily maintain its cached credentials for logon until @accalia blows up the silo the end of time. However, the VPN connection will not accept the expired credentials, so the user won't be able to connect to corporate resources until they update their password. Which they can't do until they connect to the VPN, so that the computer can talk to AD.

    If you're using Azure Active Directory Connect, you can mitigate this via password writeback and Azure's method for AD password resets. Or, if you have an OWA or Remote Desktop Services Gateway server set up, those services can make it possible for users to self-change passwords (even when expired) from off-site.

    Otherwise, you'll be down to a helldesk ticket every time a user locks themselves out because they didn't change their password before it expired. Which will happen a bunch, because the "your password is about to expire" balloon happens a lot less frequently when the computer is working offline (and users ignore that balloon anyway). There are scripts out there to send notification e-mails to users whose passwords are about to expire; I've had moderate success with utilizing those scripts to significantly reduce the frequency with which remote users fail to update their password before it expires.



  • Is there any particular reason why Windows won't let me copy and paste a fucking IPv6 address? FUCK. Neither the Network control panel nor ipconfig/cmd.exe let me copy the thing.



  • @Captain

    Huuuh. Haven't run into that one myself. And it looks like I don't have IPv6 enabled on my work laptop, so I don't have the ability to reproduce the issue.

    Though most network guys will tell you that using [2001::1] format addresses is :doing_it_wrong: - IPv6 is a brave new world of FQDNs or bust, man!

    As an aside / for posterity: if you are trying to access a web portal or something via IPv6, the required format is http://[2001:1243:5678:9abc:def0:1243:5678:9abc]/index.example (or using whatever shortening rules may apply to the IPv6 address) -- the [] around the address is required. I believe the []s are also required for UNC path connection (\[address]\path), but I'm not 100% certain of that.


  • Notification Spam Recipient

    @izzion Ah, NodeBB, you're wonderful...
    0_1469728633817_upload-f91c836f-24ab-4706-9301-93b5536b665c



  • @izzion Well TIL that if I hit Ctrl-C in the Control Panel > Network > <Ethernet Adapter> Status > Details... > IPv6 Address, it copies ALL of the properties and values.

    I can work with that. But it's not discoverable at all. It was more of a desperation move.





  • So I guess one last thing about DA is still confusing me.

    IPv6 addresses are "just" IP addresses. There's so many of them that each device can have lots if it wants, and they're "supposed" to be publicly addressable (but they're not in my network because I don't want that and NAT and firewalls).

    So DA does some translation stuff, so that when I try to connect to an IPv6 address in the network, it does it by Teredo or IPHTTPS or whatever to proxy the connection.

    OK, I get that. But where does that leave DNS? In particular, I'm confused about why I need FQDN's everywhere instead of just setting the clients to have "search domains".

    In other words, if I have a subdomain foo.contoso.org, and I try to go to foo, won't the client do a DNS lookup on contoso.org's DNS server, which would find foo and then respond with an IPv6 address?



  • @izzion I'm sure that this concept applied to multiple things in the past.

    "Sir, everyone died but me on that battlefield. I only escaped because the captain knocked me out and threw me into the river."

    "Congrats, son. You're the new captain."


  • Notification Spam Recipient

    @Captain said in In which @Captain is confused by Windows:

    OK, I get that. But where does that leave DNS? In particular, I'm confused about why I need FQDN's everywhere instead of just setting the clients to have "search domains".
    In other words, if I have a subdomain foo.contoso.org, and I try to go to foo, won't the client do a DNS lookup on contoso.org's DNS server, which would find foo and then respond with an IPv6 address?

    That is definitely a two million dollar question.



  • Aha. Maybe I found it. A troubleshooting guide says

    • The NRPT controls what DNS names the DA client is able to resolve across DirectAccess.
    • For domain/hostnames that should be resolved across DA, make sure the correct IPv6 address of the DA server appears (usually constains a "3333" IPv6 address).

    I definitely don't have the DA server in the DNS server field... imagine that!

    Update: Oh, I guess it was automatically set to the DA server. Still sucks. Fuck this suck.


  • area_deu

    @Tsaukpaetra said in In which @Captain is confused by Windows:

    Typically they auth outside the AD with certificates and then they're in the network so then AD.

    This. OpenVPN runs as service in the background and connects the machine to the network. The user then authenticates to the domain controller as if he was on site.

    You could also set up a L2TP VPN that automatically establishes the connection with the entered credentials during logon, but this has so many moving parts (including Microsofts shitty implementation of RADIUS) that we gave up on it.



  • @Captain

    My understanding is that DirectAccess is basically forced to operate in Split Tunnel mode (it will only forward requests for a FQDN that matches the NRPT policy), and that by design it doesn't do any sort of DNS suffix search. Whether or not they technically could have made it work, I don't know - they chose not to, and using FQDNs is a requirement for using DA :/



  • OK I have decided that Microsoft brand VPNs all suck.

    1. I used the DirectAccess setup wizard and got DirectAccess to work. Except it doesn't quite work with all of the Windows features I want. So bugger that.

    2. Luckily, the DirectAccess setup wizard made a VPN for me! Whee! Except that:

    3. Windows 8.1 Enterprise clients can't connect "by default" -- I have to change the connection as a PTPP connection; and when I make a new VPN, the default security settings in the client make a connection impossible. I have to disable EAP-CHAPv2 or whatever and enable CHAP and CHAPv2. Which have been deprecated by Microsoft for being pretty trivially hack-able. (EAP-CHAPv2 is supposedly CHAP in an SSL tunnel.)

    4. OK, let's just try that for now. It connects! I don't even have the PTPP ports open in the firewall, so it "must" be using an SSL tunnel and then just doing the stupid CHAP handshake through that and then I don't know.

    5. OOPS, the same client configuration that worked in Windows 8.1 Enterprise and that I put in a group policy doesn't work for Windows 7 Pro!


  • Notification Spam Recipient

    @Captain said in In which @Captain is confused by Windows:

    OOPS, the same client configuration that worked in Windows 8.1 Enterprise and that I put in a group policy doesn't work for Windows 7 Pro!

    Indeed. It's funny, because what you described is the setup it configures for Windows 7 clients IIRC, except it uses certificate authentication or something like that.



  • Holy jesus, I haven't touched any configurations and now the Windows 8 machine won't VPN in. Either of them.


  • Notification Spam Recipient

    @Captain said in In which @Captain is confused by Windows:

    Holy jesus, I haven't touched any configurations and now the Windows 8 machine won't VPN in. Either of them.

    Group policy probably "fixed" your connections for you.



  • Fuck it, I'm switching to SoftEther. Bonus points if it uses text configuration files. But at least it has a tutorial that "just works" and lots of documentation.



  • Yup, I switched to SoftEther. Setting up the server and the first client took about two hours. And it worked right, the "first time" (except for the client, and as usual, that's because Microsoft sucks at VPNs).



  • 0_1470328621235_upload-a92b0bfc-e7e3-48e6-b89b-3fe4ab5d8f57

    0_1470328633052_upload-061a2d95-9f5a-410f-a927-73b28b682a0f



  • @Captain said in In which @Captain is confused by Windows:

    Microsoft sucks at VPNs

    For giving teachers remote access to a terminal server at school, I tunnel RDP through ssh port forwarding.

    It works just fine.


  • :belt_onion:

    @flabdablet isn't that the point of RD web gateway?

    It's pretty reliable too... None of the weird directaccess stuff



  • I guess, thinking about Windows versus Unix philosophies, I like that Windows tries to be good software. It tries to have cool features that I want. But it has a strange GUI-oriented philosophy in the IT infrastructure world that makes it kind of suck.

    To configure DirectAccess, I "had" to Remote Desktop into the vpn server and the domain controller. I had a couple of windows open in each (certificates, group policy, . I had to constantly click between windows I couldn't even see. Information that should have been immediately visible for performing the configuration was always hidden in the middle of some GUI workflow or wizard. On another machine. Which had a couple of other windows open.

    Maybe this sounds like a dumb complaint. I guess, when I want to work, I just want text files, so I can put as many small snippets as I need on my screen. I'd much rather ssh into each server, maybe using Byobu to maintain sessions. I'd much rather have six tiny xterms and a big xterm (most of which are probably running vim, and one for editing code or executing stuff), and a browser on my screen. And a tiling window manager. And vim-like keyboard shortcuts and multiple virtual screens and tagging and subtiles. Administering servers with text-based configurations and sensible documentation. And pretty good tutorials that run you through the basic work flow and that discusses important configuration options. That would be awesome. I'd be like pyouunnnnnnng.

    Also, Microsoft enterprise IT documentation is balls.

    This is much unlike C# and .Net, where the products and documentation are pretty straight-forward and usable.



  • @Captain said in In which @Captain is confused by Windows:

    I like that Windows tries to be good software. It tries to have cool features that I want. But it has a strange GUI-oriented philosophy in the IT infrastructure world that makes it kind of suck.

    I think getting hung up on the GUI aspect is missing the point a little.

    As a person who likes Unix, the thing I like the most about it is that so many of the tools are composable and interoperable with very little friction. This is often cited as some kind of "do one thing and do it well" philosophy, but I think that's actually an epiphenomenon. The main thing that keeps Unix tools interoperable is that historically Unix has provided so few mechanisms for interoperability, and that such mechanisms as it did provide had so few arbitrary limitations. When all you have is files and pipes, it really helps that they're all 8-bit-clean and that so few assumptions have been made about their purpose and their internal structure.

    People who like Windows will often curl an upper lip at Unix on the basis that no single tool does everything they want. Using Unix makes composing tools and working with glue pretty much mandatory for successful completion of every real-world task; it's the opposite of integration, and if understanding and analyzing your tools before being able to use them successfully is not something that appeals to you, that just looks shambolic and stupid.

    Working with these two systems is like playing the blues vs. orchestrating symphonies. On Unix, you've got a really limited framework that's not real hard to harmonize with; but if you don't like playing by ear, or the blues just doesn't do it for you, you're going to have a bad time. On Windows, every single instrument is some kind of Mighty Wurlitzer, each capable of every pitch and timbre its designers could conceive of; but they're all tuned to different scales, and most of what you end up spending time on is figuring out how to stop them making noises you don't want.

    Having fairly recently started messing about with RDP, I think it's a case in point. Windows RDP is a really good remote GUI protocol. Once you've got an RDP client talking successfully to an RDP server, it really does work better than just about anything else in that space.

    But instead of being content to provide a great server and a great client and then let you provide whatever plumbing you need in order to connect them however you want, RDP also comes with this dizzying tower of RDP-specific pipes and fittings: RDP load balancers, RDP brokers, RDP licence managers, RDP authentication, RDP encryption and whatever the hell DirectAccess does.

    As a Unix person, I can't see the point. What's so sacred about RDP TCP connections that they need all this food-grade plumbing?

    I'm sure it's all wonderful for people whose whole life revolves around RDP. I'm equally sure there's a perfectly cromulent RDP Way to achieve any routing and access control task with RDP that reasonably can be achieved. But here's the thing: I already have a whole pile of general-purpose plumbing that I've already configured to achieve the exact access controls I want. So when it comes time to adding an RDP capability to my network, my choices are (a) learn how to build an approximate special-purpose replica of all that infrastructure out of officially approved blue-grey Microsoft RDP ductwork or (b) just tunnel RDP from my end users' clients to their appropriate RDP servers over the existing general-purpose plumbing and provide my users with a tiny wrapper of launcher script.

    Frankly, there's a lot less effort in (b).

    In fact most of the effort so far has been in finding ways to make the terminal servers look familiar to users on first connection so as not to frighten them: giving them a desktop on connection instead of a Start Screen, turning off visual effects that don't work well over slow connections, removing all the crap that a default Server 2012R2 install loads into the taskbar, supplying a pretty desktop theme instead of the hideous Server 2012 default one and so forth.

    I've been kind of halfway between amused and annoyed to find out how fiddly it is to do all that stuff, and how amazingly poorly Windows supports scripting any of it after it's already been installed. You'd think there'd be workable Group Policy settings for all of it, but there's loads that GP just doesn't cover.

    As far as I can tell, the Official Method would be to tear down both my new terminal servers and reinstall them using an unattend.xml file, but fuck that noise. Nuke and pave every time some setting turns out not to work out how I want? Forget it. I'll just keep on making my logon scripts incrementally more obscure.



  • @flabdablet The reason RDP has all that "plumbing" is that a remote access solution without it is dangerous as fuck, and Microsoft doesn't want to expose their users to that risk. It's not some kind of philosophy, it's simply part of their software being more usable.

    VNC, X11, have zero encryption and zero authentication by default. If you install a VNC server and you don't know exactly what you're doing (and you don't, because setting up "SSH tunneling" for encryption and God-knows-what for authentication is difficult as fuck), you've basically just put your machine online for literally any asshole to come along and steal your credit card numbers from.

    RDP isn't complicated because Microsoft hates you and wants to see you fail, it's more complicated so it can guarantee (or at least get closer to a guarantee) that what it's doing is the right thing to do. It's complicated because Microsoft trying to protect their customers from snooping and unauthorized access.

    And, I don't know what you were trying to do with it, but for the normal user trying to do a normal typical remote-control like workflow, RDP is just as easy as VNC. They open the window, type in the host name, hit Go. The only difference is the RDP user gets authentication by default, encryption by default, disk/device sharing by default, etc. All fast, safe, and secure. It takes a techie who would rather tinker with shit than just sit back and enjoy the great experience to bitch about this kind of stuff.



  • @blakeyrat said in In which @Captain is confused by Windows:

    X11, have zero encryption and zero authentication by default

    I'm not sure why you think that's a problem. Does the Win32 graphics API encrypt your pixels on the way to your monitor?


Log in to reply