DirectAccess 2012 Setup issues

Good afternoon,

I've recently been attempting to configure DirectAccess for my domain.  I have gotten to the point where I thought I had everything configured properly but I am receiving errors on the DA server as well as on my test clients.  I am attempting to resolve issues on the DA server first before worrying about the clients.

Right now I have three issues in my Ops Status page in the Remote Access Mgnt Console:  IP-HTTPS listener is inactive; IPsec says no valid cert which chains to root/intermediate certificate configured; and DNS says enterprise DNS servers are not responding.

My DA server has 2 NICs; one in my domain LAN, one in my DMZ.  There is a Cisco ASA(firewall) between the DMZ nic and the public internet.  

On the DNS issue - I am seeing evidence (in ASA logs) that the DA server is trying to resolve local domain DNS queries through the DMZ nic and it's failing to do so. Also, the DNS item in Ops Status jumps between OK, Warning and Critical periodically; which supports my theory that sometimes it's trying to communicate over the DMZ nic.

For the IP-HTTPS listener inactive part - I'm confused here because "netsh interface httpstunnel show interface" shows IPHTTPS interface is active:

PS C:\Windows\system32> netsh interface httpstunnel show interface

Interface IPHTTPSInterface Parameters
------------------------------------------------------------
Role                       : server
URL                        : https://access.mydomain.com:443/IPHTTPS
Client authentication mode : none
Last Error Code            : 0x0
Interface Status           : IPHTTPS interface active


From searching the web, it seems that the IPsec error is all about certificates, which makes sense...  Firstly, I issued a cert from my domain CA for access.mydomain.com and selected it on the "Network Adapters" page of 'Step 2' in the DA setup/config page. On the 'Authentication' page of the same 'Step 2' wizard, I selected the root CA cert for my domain, as we have no intermediate CA present.  We already had an existing machine cert autoenrollment policy for the entire domain present & working.

Here's output of certutil -store my

PS C:\Windows\system32> certutil -store my
my "Personal"
================ Certificate 0 ================
Serial Number: (removed)
Issuer: CN=dc1, DC=mydomain, DC=com
 NotBefore: 4/14/2015 9:01 AM
 NotAfter: 4/13/2017 9:01 AM
Subject: CN=access.mydomain.com, O=---, S=VA, C=US
Non-root Certificate
Template: WebServer2008, Web Server 2008
Cert Hash(sha1): (hash removed)
  Key Container = (removed)
  Unique container name: (removed)
  Provider = Microsoft Software Key Storage Provider
Encryption test passed

================ Certificate 1 ================
Serial Number: (removed)
Issuer: CN=DirectAccess-RADIUS-Encrypt-DAHost.mydomain.com
 NotBefore: 4/14/2015 10:52 AM
 NotAfter: 4/14/2020 7:02 AM
Subject: CN=DirectAccess-RADIUS-Encrypt-DAHost.mydomain.com
Signature matches Public Key
Root Certificate: Subject matches Issuer
Cert Hash(sha1): (removed)
  Key Container = (removed)
  Simple container name: (removed)
  Provider = Microsoft Strong Cryptographic Provider
Private key is NOT exportable
Encryption test passed

================ Certificate 2 ================
Serial Number: (removed)
Issuer: CN=dc1, DC=mydomain, DC=com
 NotBefore: 4/9/2015 2:42 PM
 NotAfter: 4/8/2016 2:42 PM
Subject: CN=DAHost.mydomain.com
Certificate Template Name (Certificate Type): Machine
Non-root Certificate
Template: Machine, Computer
Cert Hash(sha1): (removed)
  Key Container = (removed)
  Simple container name: (removed)
  Provider = Microsoft RSA SChannel Cryptographic Provider
Private key is NOT exportable
Encryption test passed
CertUtil: -store command completed successfully.
PS C:\Windows\system32>


Output of get-daserver:

PS C:\Windows\system32> get-daserver


DAInstallType               : FullInstall
InternetInterface           : DMZ
InternalInterface           : LAN
ConnectToAddress            : access.mydomain.com
SslCertificate              : [Subject]
                                CN=access.mydomain.com, O=OCC, S=VA, C=US

                              [Issuer]
                                CN=dc1, DC=mydomain, DC=com

                              [Serial Number]
                                (removed)

                              [Not Before]
                                4/14/2015 9:01:37 AM

                              [Not After]
                                4/13/2017 9:01:37 AM

                              [Thumbprint]
                                (removed)
GpoName                     : mydomain.com\DirectAccess Server Settings
InternalIPv6Prefix          : {fdeb:f1d5:df35:1::/64}
ClientIPv6Prefix            : fdeb:f1d5:df35:1000::/64
UserAuthentication          : UserPasswd
ComputerCertAuthentication  : Enabled
IPsecRootCertificate        : [Subject]
                                CN=dc1, DC=mydomain, DC=com

                              [Issuer]
                                CN=dc1, DC=mydomain, DC=com

                              [Serial Number]
                                (removed)
                              [Not Before]
                                9/20/2013 3:39:12 PM

                              [Not After]
                                9/21/2018 3:48:55 PM

                              [Thumbprint]
                                (removed)
IntermediateRootCertificate : False
TeredoState                 : Disabled
IsSingleNic                 : False
IsNatDeployed               : True
HealthCheck                 : Disabled

For what it's worth, I have no idea if any of these issues are actually preventing my test client from connecting; but it makes the most sense to me to try to start fixing the issues on the DA server before the client.  

If there is any additional information I can provide from somewhere, to help figure out what I need to do to fix this, I will gladly do so.  I have yet to find any relevant event log entries on the host, nor have I located any actual log files yet.

April 15th, 2015 3:17pm

Hi,

If you have two network cards on your DirectAccess server, you should not have a DNS configuration on the external network card, only internat network card.

For the IPHTTPS listener, can you check that your external network interface have a public firewall profile.

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 7:58am

Hi,

If you have two network cards on your DirectAccess server, you should not have a DNS configuration on the external network card, only internat network card.

For the IPHTTPS listener, can you check that your external network interface have a public firewall pr

April 16th, 2015 8:30am

Hi,

There is no need to creaate your own incoming firewall rules for HTTPS, HTTP, teredo on the DirectAcces Gateway. GPO targeting your DirectAccess Server include required firewall configuration. Just keep ICMPV4/V6. Can you publish logs of the DirectAccess client?

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 8:36am

I just noticed in the screenshot the DMZ network shows "no network access" - and I was unable to Ping the gateway IP of the ASA; but im still able to hit things on the DA server from outside, such as the CRL site.  not sure what I've changed and done wrong to make it not ping the ASA ip now..
April 16th, 2015 8:36am

Where do I locate the log files?
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 8:37am

CRL site, you are using the DirectAccess Gateway to publish your internal CA CRL? I hope your clients can download it otherwise, IPHTTPS negociation will fail.
April 16th, 2015 8:39am

I'm having trouble locating the information I followed to help me get it all setup, but the process I followed for certificates & CRL publish was to create an IIS site that responds to crl.mydomain.com on the web; share the local folder and give the domain CA machine account full control to the share. Then from the CA I gave it a new location to publish the CRL to as the share location.

here is the website with the steps I followed at first: https://technet.microsoft.com/en-us/magazine/hh922970.aspx; I used this site down through step 5; from there I used a combination of other references to familiarize myself with the rest of the setup.

  • Edited by Dan Ceola 18 hours 38 minutes ago
April 16th, 2015 8:46am

Client logs generated by DCA located here: http://pastebin.com/euXAupCF
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 9:16am

Hello,

Your client is reporting 0x274c for IP-HTTPS Tunnel.

Something may be wrong in your ASA configuration.
Normally, you just need to forward TCP 443 from the Internet IP to the External IP of your DA Server. 

Also, are you able to resolve access.mydomain.com from your client when it is connected to Internet?

And as Benoit said before, because your HTTPS Certificate comes from your Internal CA, your internal CRL should be accessible from the internet.

Gerald

April 16th, 2015 9:32am

Hello,

Your client is reporting 0x274c for IP-HTTPS Tunnel.

Something may be wrong in your ASA configuration.
Normally, you just need to forward TCP 443 from the Internet IP to the External IP of your DA Server. 

Also, are you able to resolve access.mydomain.com from your client when it is connected to Internet?

And as Benoit said before, because your HTTPS Certificate comes from your Internal CA, your internal CRL should be accessible from the internet.

Gerald

Internal CRL is accessible from internet as it should be. 

On ASA I have an 'Access Rule' for traffic hitting my public IP to allow ports tcp80 & 443, udp port 3544 and, ip protocol 41 which is what this website shows needed to be allowed. https://technet.microsoft.com/en-us/library/jj134204.aspx#ConfigRouting; then I also have a NAT rule to translate the public IP to my DMZ IP.  It's completely likely I've done something wrong there but I'm not sure what it would be at this point. 

From outside the network, I am able to resolve access.mydomain.com to the public ipv4 address that I've configured everything on.  However for what it's worth, there is no ping response

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 9:45am

Right now it seems as though I have some sort of issue on my DMZ network as the DA server isn't able to talk to the DMZ gateway IP anymore..
April 16th, 2015 9:59am

You have a "Behind a edge" configuration so you can only connect using IP-HTTPS
The only thing you need to open is TCP 443 because you can't use Teredo or 6to4 ;-)

If you want to ping access.mydomain.com, you need to allow ICMP on your ASA appliance for your internet IP.

Why have you excluded access.mydomain.com and crl.my.domain.com in the NRPT Tables?

Gerald

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 10:02am

Didn't know that about the ports; I must have misread something. The ASA has a rule for any source to any destination allow icmp/echo-reply, I'm not too worried about it not pinging though, if its not a issue.

I have those two URLs excluded in the NRPT table as when it wasn't there, the client was trying to resolve those across the corporate connection, which it hadn't established yet. After I discovered that, I found a resource somewhere (can't find it again easily now) that said I needed to add exclusions for anything that was ___.mydomain.com that I wanted a client outside the corporate network to resolve across the internet. So for that, I excluded crl, access and this morning realized I'd have to add www as well.


edit:  stupid network interface on my DA server for the DMZ zone lost it's dang static IP settings, hence no comms to the gateway that I was seeing for a bit..
  • Edited by Dan Ceola 17 hours 17 minutes ago
April 16th, 2015 10:09am

Hi

A few things I noticed. First your Wifi card have IPv6 native and IPv4 address. This may disrupt DirectAccess clients. You also have a Teredo interface configured but by default. According to your configuration, you do not have Teredo enabled on DirectAccess Gateway side. So you can disable the Teredo interface on the DirectAccess client by GPO of NETSH INTERFACE TEREDO SET STATE DISABLE.

0x274c is a common certificate problem with CRL location. Is the new CDP included in the IPHTTPS certificate? If not, it won't work.

In your NRPT, you have an exclusion for CRL. I hope it's not the CRL you try to use. 

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 10:15am

Ok, so I should modify one of my GPOs to disable the Teredo interface; I can do that..

On the CRL exclusion in the NRPT - maybe I'm not understanding something properly..  my url crl.mydomain.com is meant to be accessible to the public internet (over port 80); before I added that NRPT exclusion, the client was only attempting to resolve that URL across my internal domain dns servers rather than across the web, and therefore would never resolve the public IP of the site.

Is this not the correct configuration for it?

Next:  sorry to say, but I'm not familiar with what CDP (crl distribution point, maybe?) stands for? All certificates that I've issued & used this far were generated after I created the CRL website distribution point. 

More Importantly:  after fixing my messed up DMZ NIC on the DA server, I rebooted it; now the operations status page shows all green check marks.  So I would think at this point my problems are going to be incorrect ASA settings.

April 16th, 2015 10:26am

For CRL.MYDOMAIN.COM, including it in the NRPT with no IP address mean that this FQDN cannot be resolved by DirectAccess clients. If it's the CRL to be used by to check your IPHTTPS certificats, it will cause a lot of problem.

If you created the CRL after you sign certificate requests, CDP information is not present in your certificate.

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 10:31am

For CRL.MYDOMAIN.COM, including it in the NRPT with no IP address mean that this FQDN cannot be resolved by DirectAccess clients. If it's the CRL to be used by to check your IPHTTPS certificats, it will cause a lot of problem.

I don't understand this though.. Right now with it excluded, I am able to do a nslookup and resolve that IP; or do a ping and it resolves the IP (no reply though, as mentioned previously due to no firewall rule to allow it).. Before I had it excluded and could not access it. It was my understanding that because my internal domain name and my public domain name were the same that I had to add NRPT exclusions for anything that I wanted the client to resolve with their local/internet DNS rather than corporate DNS.

Is this not correct? If that is not correct, I will remove the exclusion. 

April 16th, 2015 10:41am

Using the same domain name for internal and external resources doesn't help :-)

Have you checked if your server's certificate have a "CRL Distribution Points" field? (you should have something like http://crl.mydomain.com/<your-ca>.crl)
If no, you need to create a new certificate because if the client doesn't validate that your certificate is not revoked, the connection will fail.

If yes, try to download the CRL file from a client connected to the Internet using Internet Explorer.
If you can't download the CRL file, DirectAccess can't check if the certificate is revoked then will not connect the HTTPS Tunnel.


Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 11:04am

Here's what the cert in use for access.mydomain.com shows:

The root CA cert that I have in use doesn't show that distro point, and neither does the machine cert that's on the DA server.  Which one(s) do I need to try to update?

April 16th, 2015 11:10am

You must have a CDP pointing to your External CRL server (http)

something like URL=http://crl.????.com/???-dc1(3).crl

If yes, your client needs to be able to download the CRL file when connected to the Internet using this address.

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 11:23am

Updated DCA log file: pastebin.com/JgMTzgPb
April 16th, 2015 11:26am

You must have a CDP pointing to your External CRL server (http)

something like URL=http://crl.????.com/???-dc1(3).crl

If yes, your client needs to be able to download the CRL file when connected to the Internet using this address.


Yes, I did this.  That CRL file is downloadable over the internet at my crl.mydomain.com/crld/ address.  I followed this website: https://technet.microsoft.com/en-us/magazine/hh922970.aspx step 4, for configuring this.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 11:28am

I don't see /crld/ in your certificate. It must be published using the exact name internet address configured in the certificate
April 16th, 2015 11:35am

Seems that your https tunnel is up. But I don't see DTE checks. You should configured DTE adresses and at least a PING check in the Directaccess Connectivity Assistant in your GPO
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 11:50am

I'm having trouble locating the information I followed to help me get it all setup, but the process I followed for certificates & CRL publish was to create an IIS site that responds to crl.mydomain.com on the web; share the local folder and give the domain CA machine account full control to the share. Then from the CA I gave it a new location to publish the CRL to as the share location.

here is the website with the steps I followed at first: https://technet.microsoft.com/en-us/magazine/hh922970.aspx; I used this site down through step 5; from there I used a combination of other references to familiarize myself with the rest of the setup.

  • Edited by Dan Ceola Thursday, April 16, 2015 12:47 PM
April 16th, 2015 12:45pm

I'm having trouble locating the information I followed to help me get it all setup, but the process I followed for certificates & CRL publish was to create an IIS site that responds to crl.mydomain.com on the web; share the local folder and give the domain CA machine account full control to the share. Then from the CA I gave it a new location to publish the CRL to as the share location.

here is the website with the steps I followed at first: https://technet.microsoft.com/en-us/magazine/hh922970.aspx; I used this site down through step 5; from there I used a combination of other references to familiarize myself with the rest of the setup.

  • Edited by Dan Ceola Thursday, April 16, 2015 12:47 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 12:45pm

I don't see /crld/ in your certificate. It must be published using the exact name internet address configured in the certificate

That makes sense!  I'll change the IIS site so it doesn't want the /crld/ at the end of the URL..

April 16th, 2015 12:51pm

Seems that your https tunnel is up. But I don't see DTE checks. You should configured DTE adresses and at least a PING check in the Directaccess Connectivity Assistant in your GPO
In 'Step 1' of the configuration wizard stuff, where you config Remote Client info, I do have two internal FQDN's as hosts to ping to check corporate connectivity...
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 12:53pm

After changing the IIS site to not want /crld at the end of the CRL url, my test client is showing connectivity - sort of.  In the "DirectAccess Client Troubleshooting Tool" (as opposed to the MS DirectAccess Connectivity Assistant) it's showing under IP Connectivity Tests - successfully connected to endpoint access.mydomain.com:443; but then says 'no response received from mydomain.com' 'User tunnel tests' passed but 'Infrasatructure tunnel tests' failed; it was trying to hit the sysvol share for the infrastructure tunnel test. Also - the DA console on the server does show the client as being connected.  It shows the host name, protocol as IPHttps, duration; shows no username or ISP address.  However from the client, I can't seem to access any network shares or internal websites; pings to things doesn't seem to work either.

Here's a new log from DCA: http://pastebin/uw1SFiB0



  • Edited by Dan Ceola 14 hours 10 minutes ago
April 16th, 2015 1:13pm

I realized Windows Firewall for Private/Public were set to off for some reason, so I just modified GPO's to enable them; same result on the client after doing this.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 1:42pm

This time it's a Windows 7 client no? I see that the DAC application is not correctly configured. It's normal, GPO configured was designed for DAC 2.0, not 1.5.

Teredo is still enabled. It's not required in your scenario and will cause many problems.
We still see 0x274c for IPHTTPS. Using a certificate delivered by an Internal CA is not a good practice and will lead to multiple problems.

Considering your latest log, IPHTTPS now seems to be operational. Just disable Teredo.

Enable CAPI2, will be usefull to check IPHTTPS/IPSEC certificate problems : http://blogs.msdn.com/b/benjaminperkins/archive/2013/10/01/enable-capi2-event-logging-to-troubleshoot-pki-and-ssl-certificate-issues.aspx

Using the same domain name on internal as external is very complicated (SPlit -Brain DNS). By default, DirectAccess clients will use internal DNS to resolve DNS names. You need to create entries in the NRPT to resolve IP from the public internet DNS domain zone.

I still ne a native IPV6 address on the Wireless interface. Maybe your ISP is providing dual connectivity (IPV6/IPV4). We will ned to work on it. If I remember well we just need to uncheck the IPV6 checkbox on the wireless interface. It does not disrupt protocols such as IPHTTPS.

April 16th, 2015 1:48pm

According to latest we are on Windows 7. DTE configutation generated by Windows Server 2012/2012 R2 was designed for NAC (Windows 8), not Windows 7 (DAC), it's a common bug. We just need to create an additional GPO that overide the DirectAccess configuration.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 1:51pm

Yes - test client is win 7; we don't have any Win 8 systems in the field at this time (aside from one or two IT employees), so I'm using W7 for test client.

What is the proper way to disable Teredo?  I used command line to disable it, but it came back on after reboot.  Then I went in changed a GPO to set Teredo State to disabled, and I have verified the GPO is properly applied to the client; but it's still staying enabled somehow?

Based on that info, how am I supposed to disable Teredo?

While I understand that using a cert from an Internal CA may not be good practice, it is what is mentioned in the MS guides; and until I can prove that the system works properly, the company will not allow for purchasing a third party cert.

For same internal & external domain name - I believe I have appropriate NRPT entries to resolve the public dns vs local; NRPT should show crl, access, vpn and www as exceptions that are looked up on public internet, with all else being local.

In your last point, I hate to say but I'm having trouble understanding what you are saying; but it appears as though you are suggesting to disable ipv6 on the client's wireless nic?

April 16th, 2015 1:56pm

According to latest we are on Windows 7. DTE configutation generated by Windows Server 2012/2012 R2 was designed for NAC (Windows 8), not Windows 7 (DAC), it's a common bug. We just need to create an additional GPO that overide the DirectAccess configuration.

BenoitS - Simple by Design http://danstoncloud.com/blogs/simplebydesign/default.aspx


Would you be able to elaborate on what you mean here? Or what sort of GPO I would need to fix whatever it is you're saying is wrong?
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 1:57pm

NETSH INTERFACE TEREDO SET STATE DISABLE (you can also do it with GPO).

DirectAccess was not designed to woth on native IPv6 environment. I suppose DirectAccess client will try to use your Wireless interface but the IPv6 prefix you use is not routable, unless you deploy DirectAccess on a native IPv6 LAN.

April 16th, 2015 2:01pm

Didn't know that about the ports; I must have misread something. The ASA has a rule for any source to any destination allow icmp/echo-reply, I'm not too worried about it not pinging though, if its not a issue.

I have those two URLs excluded in the NRPT table as when it wasn't there, the client was trying to resolve those across the corporate connection, which it hadn't established yet. After I discovered that, I found a resource somewhere (can't find it again easily now) that said I needed to add exclusions for anything that was ___.mydomain.com that I wanted a client outside the corporate network to resolve across the internet. So for that, I excluded crl, access and this morning realized I'd have to add www as well.


edit:  stupid network interface on my DA server for the DMZ zone lost it's dang static IP settings, hence no comms to the gateway that I was seeing for a bit..
  • Edited by Dan Ceola Thursday, April 16, 2015 2:08 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 2:07pm

Didn't know that about the ports; I must have misread something. The ASA has a rule for any source to any destination allow icmp/echo-reply, I'm not too worried about it not pinging though, if its not a issue.

I have those two URLs excluded in the NRPT table as when it wasn't there, the client was trying to resolve those across the corporate connection, which it hadn't established yet. After I discovered that, I found a resource somewhere (can't find it again easily now) that said I needed to add exclusions for anything that was ___.mydomain.com that I wanted a client outside the corporate network to resolve across the internet. So for that, I excluded crl, access and this morning realized I'd have to add www as well.


edit:  stupid network interface on my DA server for the DMZ zone lost it's dang static IP settings, hence no comms to the gateway that I was seeing for a bit..
  • Edited by Dan Ceola Thursday, April 16, 2015 2:08 PM
April 16th, 2015 2:07pm

Ok, I've verified that Teredo state shows disabled, and I disabled ipv6 on the wireless adapter.  Still not seeing any change on the client after this though; and I hope that disabling ipv6 on the device doesn't end up making this work because I don't want to have to disable that on each client...

New DCA log:  http://pastebin.com/9HsCDYHS

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 2:24pm

Using the same domain name for internal and external resources doesn't help :-)

Have you checked if your server's certificate have a "CRL Distribution Points" field? (you should have something like http://crl.mydomain.com/<your-ca>.crl)
If no, you need to create a new certificate because if the client doesn't validate that your certificate is not revoked, the connection will fail.

If yes, try to download the CRL file from a client connected to the Internet using Internet Explorer.
If you can't download the CRL file, DirectAccess can't check if the certificate is revoked then will not connect the HTTPS Tunnel.


April 16th, 2015 3:03pm

Using the same domain name for internal and external resources doesn't help :-)

Have you checked if your server's certificate have a "CRL Distribution Points" field? (you should have something like http://crl.mydomain.com/<your-ca>.crl)
If no, you need to create a new certificate because if the client doesn't validate that your certificate is not revoked, the connection will fail.

If yes, try to download the CRL file from a client connected to the Internet using Internet Explorer.
If you can't download the CRL file, DirectAccess can't check if the certificate is revoked then will not connect the HTTPS Tunnel.


Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 3:03pm

I don't see /crld/ in your certificate. It must be published using the exact name internet address configured in the certificate
  • Marked as answer by Dan Ceola 19 hours 9 minutes ago
April 16th, 2015 3:34pm

I don't see /crld/ in your certificate. It must be published using the exact name internet address configured in the certificate
  • Marked as answer by Dan Ceola Wednesday, April 22, 2015 12:14 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 3:34pm

You still don't have configured your DCA 2.0 with a gpo. The client settings you have in Step1 are for windows 8.x clients. You need to implement the DCA 2.0 admx on your central store or at least on the server where you create your gpo, create an additional gpo for your clients and configure DCA. DirectAccess 2012 provides support for Windows 7 but is focussed on Windows 8 by default which use NCA.
April 16th, 2015 3:47pm

Latest log shows that the DA server is now providing an IPv6 to your https tunnel. Please configure DCA with an additional gpo. Tha DCA icon will stay in a red state until some checks are validated, even if your tunnel is up. Check also your client firewall... Seems it's disabled, according to your log
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 3:54pm

You still don't have configured your DCA 2.0 with a gpo. The client settings you have in Step1 are for windows 8.x clients. You need to implement the DCA 2.0 admx on your central store or at least on the server where you create your gpo, create an additional gpo for your clients and configure DCA. DirectAccess 2012 provides support for Windows 7 but is focussed on Windows 8 by default which use NCA.

Is the DCA program not just a troubleshooting tool for the DirectAccess connection?  If I'm understanding you correctly, there is additional configuration I need to do on the server (and gpos?) to make DirectAccess work in Windows 7? 

Also, I got my hands on a windows 8 system; verified it has DA gpo's applied, connected it to external network (been using hotspot from my phone for testing access from external networks) and it is not connecting either.  The "DirectAccess Client Troubleshooting Tool" only shows failure to connect to domain sysvol share; all of it's other checks pass.  Client Status page on DA server does not show the win 8 system as connected. I'm still trying to locate additional logs on W8.


  • Edited by Dan Ceola 11 hours 25 minutes ago
April 16th, 2015 4:00pm

Latest log shows that the DA server is now providing an IPv6 to your https tunnel. Please configure DCA with an additional gpo. Tha DCA icon will stay in a red state until some checks are validated, even if your tunnel is up. Check also your client firewall... Seems it's disabled, according to your log

I saw the firewall message as well; but Firewall is only disabled on Domain connection and is enabled for Public & Private connections.  I'm not sure why DCA log is showing otherwise.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:02pm

Gold evening,

Now IPv6 is disabled on Wireless card and Teredo also Disabled, your're IPHTTPS interface is now active. You have an IPSEC main mode association for the infrasstructure tunnel. You should be able to ping IPv6 addresses that are registred for your DNS64/NAT64 (see in the NRPT section, some addresses with 3333). Next move it to have an IPSEC main mode association for your user.

Just execute the following command on the DirectAccess Gateway to enable advanced IPSEC logging : auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable

In the security event log, we should have some valuable informations why it's not working.

April 16th, 2015 4:03pm

Gold evening,

Now IPv6 is disabled on Wireless card and Teredo also Disabled, your're IPHTTPS interface is now active. You have an IPSEC main mode association for the infrasstructure tunnel. You should be able to ping IPv6 addresses that are registred for your DNS64/NAT64 (see in the NRPT section, some addresses with 3333). Next move it to have an IPSEC main mode association for your user.

Just execute the following command on the DirectAccess Gateway to enable advanced IPSEC logging : auditpol.exe /set /SubCategory:"IPsec Main Mode","IPsec Extended Mode" /success:enable /failure:enable

In the security event log, we should have some valuable informations why it's not working.

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:05pm

DAC is a troubleshooting tool but also an indicator for end user. It's also requises to informe user of sole situation (no internet connectivity, smartcard requises, ...). DAC it's not mandatory for DirectAccess but improve user exprience. With W8, it's incluses in the OS.
April 16th, 2015 4:06pm

Command is working. Otherwise, just open a GPEDIT.MSC, these are Advanced leggings available since Windows 7.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:07pm

For DCA 2.0, you need to implement the ADMX and ADML files provided by Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=29039)

Then configure an additional GPO applied to your Windows 7 clients like this:

You can duplicate the Step1 settings, they are in the DirectAccess Clients Settings GPO :

Corporate Resources are identical in DCA and NCA
DTEs in DCA are IPsec Tunnels Endpoints in NCA


April 16th, 2015 4:43pm

For IPsec logging, you can configure it there:

Do this on both clients and server to have a full IPsec logging for troubleshooting ;-)
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:43pm

Added GPO for DCA with rules and settings based on info from this website: http://www.ivonetworks.com/news/2013/08/windows-7-dca-with-server-2012-directaccess/

No change on w7 client with regards to it working.. Here's new log set from DCA: http://pastebin.com/4EecQpZM 

April 16th, 2015 4:45pm

Thank you all for your assistance with this today.  With your help, I have at least made some progress in getting clients to sort of, partially connect.
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:52pm

Hi's an IPHTTPS problem now

Have a look at this : https://support.microsoft.com/en-us/kb/2980635?wa=wsignin1.0

 

April 16th, 2015 4:55pm

I was just seeing that same thing; it shows IPHTTPS with error 0x2afc.

I just ran netsh int iphttps show int and it shows no error now; so maybe that was just a random thing.. new dca logs: pastebin.com/9xF21EYy

Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 4:59pm

Almost good :-)

HTTPS Tunnel is up with IPv6 address and IPsec Main mode tunnel seems OK.
Maybe you have a problem between the server and your internal infrastructure.

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


April 16th, 2015 5:09pm

After changing the IIS site to not want /crld at the end of the CRL url, my test client is showing connectivity - sort of.  In the "DirectAccess Client Troubleshooting Tool" (as opposed to the MS DirectAccess Connectivity Assistant) it's showing under IP Connectivity Tests - successfully connected to endpoint access.mydomain.com:443; but then says 'no response received from mydomain.com' 'User tunnel tests' passed but 'Infrasatructure tunnel tests' failed; it was trying to hit the sysvol share for the infrastructure tunnel test. Also - the DA console on the server does show the client as being connected.  It shows the host name, protocol as IPHttps, duration; shows no username or ISP address.  However from the client, I can't seem to access any network shares or internal websites; pings to things doesn't seem to work either.

Here's a new log from DCA: http://pastebin/uw1SFiB0



  • Edited by Dan Ceola Thursday, April 16, 2015 5:15 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 5:12pm

After changing the IIS site to not want /crld at the end of the CRL url, my test client is showing connectivity - sort of.  In the "DirectAccess Client Troubleshooting Tool" (as opposed to the MS DirectAccess Connectivity Assistant) it's showing under IP Connectivity Tests - successfully connected to endpoint access.mydomain.com:443; but then says 'no response received from mydomain.com' 'User tunnel tests' passed but 'Infrasatructure tunnel tests' failed; it was trying to hit the sysvol share for the infrastructure tunnel test. Also - the DA console on the server does show the client as being connected.  It shows the host name, protocol as IPHttps, duration; shows no username or ISP address.  However from the client, I can't seem to access any network shares or internal websites; pings to things doesn't seem to work either.

Here's a new log from DCA: http://pastebin/uw1SFiB0



  • Edited by Dan Ceola Thursday, April 16, 2015 5:15 PM
April 16th, 2015 5:12pm

You still don't have configured your DCA 2.0 with a gpo. The client settings you have in Step1 are for windows 8.x clients. You need to implement the DCA 2.0 admx on your central store or at least on the server where you create your gpo, create an additional gpo for your clients and configure DCA. DirectAccess 2012 provides support for Windows 7 but is focussed on Windows 8 by default which use NCA.

Is the DCA program not just a troubleshooting tool for the DirectAccess connection?  If I'm understanding you correctly, there is additional configuration I need to do on the server (and gpos?) to make DirectAccess work in Windows 7? 

Also, I got my hands on a windows 8 system; verified it has DA gpo's applied, connected it to external network (been using hotspot from my phone for testing access from external networks) and it is not connecting either.  The "DirectAccess Client Troubleshooting Tool" only shows failure to connect to domain sysvol share; all of it's other checks pass.  Client Status page on DA server does not show the win 8 system as connected. I'm still trying to locate additional logs on W8.


  • Edited by Dan Ceola Thursday, April 16, 2015 8:00 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 7:59pm

You still don't have configured your DCA 2.0 with a gpo. The client settings you have in Step1 are for windows 8.x clients. You need to implement the DCA 2.0 admx on your central store or at least on the server where you create your gpo, create an additional gpo for your clients and configure DCA. DirectAccess 2012 provides support for Windows 7 but is focussed on Windows 8 by default which use NCA.

Is the DCA program not just a troubleshooting tool for the DirectAccess connection?  If I'm understanding you correctly, there is additional configuration I need to do on the server (and gpos?) to make DirectAccess work in Windows 7? 

Also, I got my hands on a windows 8 system; verified it has DA gpo's applied, connected it to external network (been using hotspot from my phone for testing access from external networks) and it is not connecting either.  The "DirectAccess Client Troubleshooting Tool" only shows failure to connect to domain sysvol share; all of it's other checks pass.  Client Status page on DA server does not show the win 8 system as connected. I'm still trying to locate additional logs on W8.


  • Edited by Dan Ceola Thursday, April 16, 2015 8:00 PM
April 16th, 2015 7:59pm

For DCA 2.0, you need to implement the ADMX and ADML files provided by Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=29039)

Then configure an additional GPO applied to your Windows 7 clients like this:

You can duplicate the Step1 settings, they are in the DirectAccess Clients Settings GPO :

Corporate Resources are identical in DCA and NCA
DTEs in DCA are IPsec Tunnels Endpoints in NCA


Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 8:42pm

For IPsec logging, you can configure it there:

Do this on both clients and server to have a full IPsec logging for troubleshooting ;-)
April 16th, 2015 8:42pm

For DCA 2.0, you need to implement the ADMX and ADML files provided by Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=29039)

Then configure an additional GPO applied to your Windows 7 clients like this:

You can duplicate the Step1 settings, they are in the DirectAccess Clients Settings GPO :

Corporate Resources are identical in DCA and NCA
DTEs in DCA are IPsec Tunnels Endpoints in NCA


Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 8:42pm

For IPsec logging, you can configure it there:

Do this on both clients and server to have a full IPsec logging for troubleshooting ;-)
April 16th, 2015 8:42pm

For DCA 2.0, you need to implement the ADMX and ADML files provided by Microsoft (http://www.microsoft.com/en-us/download/details.aspx?id=29039)

Then configure an additional GPO applied to your Windows 7 clients like this:

You can duplicate the Step1 settings, they are in the DirectAccess Clients Settings GPO :

Corporate Resources are identical in DCA and NCA
DTEs in DCA are IPsec Tunnels Endpoints in NCA


  • Edited by Gerald Mathieu Thursday, April 16, 2015 8:47 PM
  • Marked as answer by Dan Ceola Wednesday, April 22, 2015 12:15 PM
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 8:42pm

Almost good :-)

HTTPS Tunnel is up with IPv6 address and IPsec Main mode tunnel seems OK.
Maybe you have a problem between the server and your internal infrastructure.

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


April 16th, 2015 9:07pm

Almost good :-)

HTTPS Tunnel is up with IPv6 address and IPsec Main mode tunnel seems OK.
Maybe you have a problem between the server and your internal infrastructure.

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


  • Edited by Gerald Mathieu Thursday, April 16, 2015 9:13 PM
  • Marked as answer by Dan Ceola 19 hours 8 minutes ago
  • Unmarked as answer by Dan Ceola 19 hours 8 minutes ago
Free Windows Admin Tool Kit Click here and download it now
April 16th, 2015 9:07pm

Almost good :-)

HTTPS Tunnel is up with IPv6 address and IPsec Main mode tunnel seems OK.
Maybe you have a problem between the server and your internal infrastructure.

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


  • Edited by Gerald Mathieu Thursday, April 16, 2015 9:13 PM
  • Marked as answer by Dan Ceola Wednesday, April 22, 2015 12:15 PM
  • Unmarked as answer by Dan Ceola Wednesday, April 22, 2015 12:15 PM
April 16th, 2015 9:07pm

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


Ahh - interesting. The GUI doesn't suggest that at all. In fact, it literally asks for "DNS server IPv4 address"; and the example it shows is an ipv4 address (though it doesn't appear to be a private IP in the example), and I'm honestly not sure where it got the IPv6 DNS addresses it's trying to use.

So, in the configuration wizards on the DA server, Step 3 - DNS page is where it asks for the NRPT host and DNS info - you're suggesting I need to enter the IPv6 address of the DA server rather than the IPv4 address of my internal DNS as the wizard suggests?

Looking at the GPO that the config wizards created, at Computer Config, Policies, Windows Settings, Name Resolution Settings, Rule Settings for ".mydomain.com" it shows an entry "DirectAccess (DNS Servers)" and shows two IPv6 addresses - fdeb:f1d5:df35:7777::c0a8:107;fdeb:f1d5:df35:7777::c0a8:108 - I don't know what these addresses came from, or what they are - they aren't from the DA server, nor are they from my internal DNS servers.

Heres current settings from that page of config wizards:


  • Edited by Dan Ceola 18 hours 53 minutes ago
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 8:23am

This is a common mistake when you configure NRPT.

People think that they must use the real DNS servers in their Active Directory.
DirectAccess include a Built-In DNS64 configuration and this is what you need to use.

If you enter mydomain.com as the DNS suffix, leave DNS Server empty then click on validate, you'll see that the IP address the wizard will configure will be the IP Address configured on your Internal Adapter.

fdeb:f1d5:df35:7777::c0a8:107 and fdeb:f1d5:df35:7777::c0a8:108 are the translated addresses for 192.168.1.7 and 192.168.1.8 ;-)

Gerald



April 17th, 2015 9:41am

Makes sense that its a common mistake; especially since the wizard specifically asks you for the ipv4 of your DNS servers; and I don't think I've seen any official documentation that states it wants something else.. But yes, just entering the domain name and hitting Detect did fill in an ipv6 address. 

I am updating policy on test client now and will report back with any changes.

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 10:05am

Success on Win 7!

Win 7 client is connected and can access internal resources!  Now I need to get my hands on a second system that I haven't done any work to and make sure that I haven't done anything crazy to this client to make it work; and test the Win 8 client as well.  Does the DCA client HAVE to be installed on each W7 client?

My current question is how does someone on the internal/corporate network (ie IT helpdesk) access a system that's connected via DA?  Does the client connected via DA get registered in internal DNS so we can access it?  I assume that it does; as in fact - looking at my internal DNS server it's showing an IPv6 address for my test client; but at the same time, nslookup is showing an invalid ipv4 address for it (even after verifying the ipv4 address isn't showing for it on DNS server and after doing a dns flush on my workstation).

I guess a better way to ask it is with a client connected via DirectAccess, are we supposed to be able to access that client from a system inside the corporate network?

April 17th, 2015 10:34am

For DCA, i recommend to install it on all your Windows 7 clients.
It helps to create the diagnotics logs and shows to the user that he's connected to the DirectAccess infrastructure.

Sometimes it reports errrors even if everything is good because one of the tests failed but the error will go away after a while.
There's no way to force DCA to recheck the connection.

When the client is connected through DA, it will register his IPv6 address in the internal DNS by updating his own record.
If it not the case, delete both records in the DNS then launch IPCONFIG /REGISTERDNS on the client.
Benoit recommended you to disable IPv6 on your client and i recommend it too.
I've seen some clients registering their official IPv6 address and their DA IPv6 address in internal DNS. Not fun :-D

If you want to access a client connected through DA from an internal resource, you need to implement DIrectAccess Manage-Out on your infrastructure.

Gerald


Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 10:44am

Thanks for the info.

Should IPv6 be disabled on both Windows 7 and 8 clients? 

April 17th, 2015 10:47am

Hi,

DAC must be installed on Windows 7 based DirectAccess clients. It allos to collect logs and inform users abour DirectAccess connectivity status

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 10:48am

If you don't need it for something else, I think it's better for the moment.
The real problem I had with native IPv6 on my clients was that they registered it in our internal DNS and when I wanted to perform a Remote Assistance, my Manage-Out station was trying to connect to his official IPv6 address :-D

Maybe this will change with the next DirectAccess release but actually, I don't have found changes in Windows Server 10 Preview.
April 17th, 2015 10:56am

Wonderful, thank you!

I'm looking at a GPO setting (via a custom ADMX) to allow controlling IPv6 on clients (we have a number of clients in the field, and deploying via GPO would make this much easier); it shows certain options for controlling IPv6 on the client, but I'm afraid that it wont give enough control here...

Here are my GPO options for controlling ipv6; I almost wish there was just one that said something like "disable all but..."  Maybe with using IPHTTPS I can just do "Disable all ipv6 components" and be ok?

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 11:05am

Yes.
April 17th, 2015 11:24am

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


Ahh - interesting. The GUI doesn't suggest that at all. In fact, it literally asks for "DNS server IPv4 address"; and the example it shows is an ipv4 address (though it doesn't appear to be a private IP in the example), and I'm honestly not sure where it got the IPv6 DNS addresses it's trying to use.

So, in the configuration wizards on the DA server, Step 3 - DNS page is where it asks for the NRPT host and DNS info - you're suggesting I need to enter the IPv6 address of the DA server rather than the IPv4 address of my internal DNS as the wizard suggests?

Looking at the GPO that the config wizards created, at Computer Config, Policies, Windows Settings, Name Resolution Settings, Rule Settings for ".mydomain.com" it shows an entry "DirectAccess (DNS Servers)" and shows two IPv6 addresses - fdeb:f1d5:df35:7777::c0a8:107;fdeb:f1d5:df35:7777::c0a8:108 - I don't know what these addresses came from, or what they are - they aren't from the DA server, nor are they from my internal DNS servers.

Heres current settings from that page of config wizards:


  • Edited by Dan Ceola Friday, April 17, 2015 12:29 PM
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 12:22pm

I think you made a mistake when configuring your DNS in the NRPT.

the DNS server that must be used in NRPT is the IPv6 address of the DirectAccess server, not the real DNS of your Active Directory.


Ahh - interesting. The GUI doesn't suggest that at all. In fact, it literally asks for "DNS server IPv4 address"; and the example it shows is an ipv4 address (though it doesn't appear to be a private IP in the example), and I'm honestly not sure where it got the IPv6 DNS addresses it's trying to use.

So, in the configuration wizards on the DA server, Step 3 - DNS page is where it asks for the NRPT host and DNS info - you're suggesting I need to enter the IPv6 address of the DA server rather than the IPv4 address of my internal DNS as the wizard suggests?

Looking at the GPO that the config wizards created, at Computer Config, Policies, Windows Settings, Name Resolution Settings, Rule Settings for ".mydomain.com" it shows an entry "DirectAccess (DNS Servers)" and shows two IPv6 addresses - fdeb:f1d5:df35:7777::c0a8:107;fdeb:f1d5:df35:7777::c0a8:108 - I don't know what these addresses came from, or what they are - they aren't from the DA server, nor are they from my internal DNS servers.

Heres current settings from that page of config wizards:


  • Edited by Dan Ceola Friday, April 17, 2015 12:29 PM
April 17th, 2015 12:22pm

I tried using that GPO to "disable all ipv6" and it most definitely made DA stop working completely.  Test stuff showed 'no ipv6 transition interfaces available' or something to that effect.  Looks like I'd  have to touch each computer individually to disable ipv6 on the nics.
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 1:08pm

Hi,

I agree disabling native IPv6 can be a jedi mind tricks but Powershell was done for that (For Windows 8) : Disable-NetAdapterBinding -InterfaceAlias Ethernet -ComponentID ms_tcpip6.

I will look for Windows  but i think there is a tool that was used on Hyper-V core installation to do that.

April 17th, 2015 1:24pm

This is a common mistake when you configure NRPT.

People think that they must use the real DNS servers in their Active Directory.
DirectAccess include a Built-In DNS64 configuration and this is what you need to use.

If you enter mydomain.com as the DNS suffix, leave DNS Server empty then click on validate, you'll see that the IP address the wizard will configure will be the IP Address configured on your Internal Adapter.

fdeb:f1d5:df35:7777::c0a8:107 and fdeb:f1d5:df35:7777::c0a8:108 are the translated addresses for 192.168.1.7 and 192.168.1.8 ;-)

Gerald



Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 1:40pm

This is a common mistake when you configure NRPT.

People think that they must use the real DNS servers in their Active Directory.
DirectAccess include a Built-In DNS64 configuration and this is what you need to use.

If you enter mydomain.com as the DNS suffix, leave DNS Server empty then click on validate, you'll see that the IP address the wizard will configure will be the IP Address configured on your Internal Adapter.

fdeb:f1d5:df35:7777::c0a8:107 and fdeb:f1d5:df35:7777::c0a8:108 are the translated addresses for 192.168.1.7 and 192.168.1.8 ;-)

Gerald



April 17th, 2015 1:40pm

This is a common mistake when you configure NRPT.

People think that they must use the real DNS servers in their Active Directory.
DirectAccess include a Built-In DNS64 configuration and this is what you need to use.

If you enter mydomain.com as the DNS suffix, leave DNS Server empty then click on validate, you'll see that the IP address the wizard will configure will be the IP Address configured on your Internal Adapter.

fdeb:f1d5:df35:7777::c0a8:107 and fdeb:f1d5:df35:7777::c0a8:108 are the translated addresses for 192.168.1.7 and 192.168.1.8 ;-)

Gerald



  • Edited by Gerald Mathieu Friday, April 17, 2015 1:44 PM
  • Marked as answer by Dan Ceola Wednesday, April 22, 2015 12:15 PM
Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 1:40pm

So I am now troubleshooting my Windows 8.1 client. The client has the appropriate GPO's (verified via gpresult /r) but I cant find some settings via rsop.msc (though I could be looking in the wrong places.

netsh int https sh int shows the proper url to access DA, and says the interface iphttps is active.

netsh na sh po (not sure what the long version of that cmd is) which should show the NRPT table, shows no results.  The client doesn't appear to be connecting; it's not showing in the remote client status screen in the console. I had found some info via Google that suggested Win 8 had a built-in location to generate connection log info (like the DCA tool for Win 7) and that I would find it from PC settings -> Network -> Connections; but there is nothing there for me.

Since I don't have that, the best I can do is the "DirectAccess CLient Troubleshooting Tool" http://pastebin.com/TwABiSHA

One thing I'm seeing that looks like the problem is no config for NRPT; netsh dnsclient show state simply shows "not configured" for DA settings.  I'm not sure what I need to do to correct this...

April 17th, 2015 1:54pm

For DCA, i recommend to install it on all your Windows 7 clients.
It helps to create the diagnotics logs and shows to the user that he's connected to the DirectAccess infrastructure.

Sometimes it reports errrors even if everything is good because one of the tests failed but the error will go away after a while.
There's no way to force DCA to recheck the connection.

When the client is connected through DA, it will register his IPv6 address in the internal DNS by updating his own record.
If it not the case, delete both records in the DNS then launch IPCONFIG /REGISTERDNS on the client.
Benoit recommended you to disable IPv6 on your client and i recommend it too.
I've seen some clients registering their official IPv6 address and their DA IPv6 address in internal DNS. Not fun :-D

If you want to access a client connected through DA from an internal resource, you need to implement DIrectAccess Manage-Out on your infrastructure.

Gerald


Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 2:43pm

For DCA, i recommend to install it on all your Windows 7 clients.
It helps to create the diagnotics logs and shows to the user that he's connected to the DirectAccess infrastructure.

Sometimes it reports errrors even if everything is good because one of the tests failed but the error will go away after a while.
There's no way to force DCA to recheck the connection.

When the client is connected through DA, it will register his IPv6 address in the internal DNS by updating his own record.
If it not the case, delete both records in the DNS then launch IPCONFIG /REGISTERDNS on the client.
Benoit recommended you to disable IPv6 on your client and i recommend it too.
I've seen some clients registering their official IPv6 address and their DA IPv6 address in internal DNS. Not fun :-D

If you want to access a client connected through DA from an internal resource, you need to implement DIrectAccess Manage-Out on your infrastructure.

Gerald


April 17th, 2015 2:43pm

Hi,

If you have both Windows 7 and Windows 8 clients, it's two different DirectAccess GPO. One reason is that some feature are only available with Windows 8 (Multisite, KerbProxy for example). SO You should have a separate AD group for each OS.

In your Log, we see :

-IPv6 is enabled on the Wireless Interface card

-You have an IPHTTPS interface operational

-You have DNS response from Google IPv6 DNS (2001:4860:4860::8888)

-DNS64/DNS64 IPv6 address is reachable (fdeb:f1d5:df35:3333::1)

-6to4 interface is enabled

-Teredo interface is disabled

-Probles used to test DirectAccess are not formated correctly

Free Windows Admin Tool Kit Click here and download it now
April 17th, 2015 3:00pm

I disabled ipv6 on the wifi card just after capturing the logs.

For the GPOs - the one for Win 8 clients would just be the one that the DA wizards creates automatically, wouldn't it? We created one Security group for all of our DA clients, which that GPO is applied to; it also is applied to the W7 clients, even though we also created another GPO for Win 7 DCA; so we have two separate GPO's for Win 7 and Win 8 clients but are using a WMI filter on the Win 7 GPO so it doesn't apply to the Win 8 systems. 

Is there somewhere else that I should be able to generate any troubleshooting logs? 

Also at this point the user who my W8 test system belongs to had to leave for the day, so I won't have access to a Win 8 system again until Monday.

April 17th, 2015 3:17pm

Hi

As long as you checked the enable Windows 7 DirectAccess clients checkbox, it will work. I prefer to have two separate secrity groups to avoir having Windows 7 and Windows 8 in the same group. That's because it has to be live that when you enable multisite.

Free Windows Admin Tool Kit Click here and download it now
April 18th, 2015 10:59am

Hello,

Just to be sure, did you enter an email address in Step1 for the helpdesk?
I think that Windows 8.x can't create logs if the email is not configured.

Also, if you are using the DirectAccess WMI filter for laptops, have you add detection for the 6.3 Kernel?
By default, the WMI filter only detect Windows 7 (Kernel 6.1)  and Windows 8.0 (Kernel 6.2).

That may explains why you don't see your GPOs on Windows 8.1.

Grald

April 20th, 2015 3:49am

There is an email address entered in Step 1.

On the WMI filtering - we only applied a filter to the DCA policies to make them only work on W7 clients; we didn't filter out the GPO that the DirectAccess wizard created, so it's applied to both W7 and W8/8.1 systems.  The only policy I'm not seeing take affect on my w8.1 client as of last Friday was the NRPT table; everything else appeared to have applied correctly.

This morning I am going to re-create my DirectAccess security groups so there is a separate one for W7 and W8/8.1 and see what sort of changes occur.

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 8:15am

If you search for NRPT settings using RSOP, you can find them in "Computer Configuration -> Administrative Templates -> Extra Registry Settings"
April 20th, 2015 9:37am

If you search for NRPT settings using RSOP, you can find them in "Computer Configuration -> Administrative Templates -> Extra Registry Settings"
THANK YOU for that; I had been trying to locate them under the same path that that you follow to configure them in GP
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 10:04am

Got my hands on another W8 laptop that I can use for a while, instead of having to turn it back over to the user daily... NRPT tables show up properly now. It's still not fully connecting though. IT says it connects, but it can't contact the internal resources.

trace log file from directaccess client troubleshooter tool: http://pastebin.com/1bRajgk2

April 20th, 2015 12:37pm

Here's logs from the built In troubleshooting thing; I looked through it but can't seem to locate anything that I recognize as being wrong...

http://pastebin.com/L0YcDwgt


  • Edited by Dan Ceola 14 hours 28 minutes ago
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 12:53pm

Hi,

In this log, I see :

-Native IPv6 on the Wireless interface (chekcbox du incheck)

-6to4 is OK : Disabled

-Teredo is OK : Disabled

-IPHTTPS : Up and Running

-You still use Google 8.8.8.8 for public DNS resolution (will work but Google respond in both IPv4 and IPv6), I had some bad experience with DirectAccess and Google DNS.

-NLS is unreachable : OK

-DNS64 reachable : OK (fdeb:f1d5:df35:3333::1)

-You have DTE probles not correctly configured, NAC should say that DirectAccess is not configured correctly (or a message like this). Can you ping fdeb:f1d5:df35:1000::1 and fdeb:f1d5:df35:1000::2 from a DirectAccess client?

-Firewall rules seems to be OK

-Certificate EKU tests : OK

-Seems to bug on SYSVOL CHECK (By Default, the configuration Wizard add all you domain controllers as infrastructure resources that can use the infrastructure tunnel from your DirectAccess clients, not sure you really opened network flows from the DirectAccess Gateway to all domain controllers in your environments. Just limit number of domain controllers to be used by DirectAccess Gateway.

April 20th, 2015 12:54pm

I'll disable ipv6 on the interface and see if that makes a difference.  The wireless network I'm using is pushing Google DNS as the connection's dns host; I would consider changing it, but I will have no control over a client using that in the field once this is functional & live, so hopefully it will work.

The two DTE addresses match what I entered into the GPO for Win 7 clients; but I'm honestly not sure where those addresses are generated from.  It doesn't seem to be anything that I input myself somewhere. Does it just pull the two DTE addresses from the DA server's iphttps tunnel adapter interface, as that's the only place I can locate those addresses.

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 1:00pm

I am able to ping the two DTE ipv6 addresses from the client. Still unable to ping any corporate resources.
April 20th, 2015 1:07pm

Hi,

I did not review the thread but did you enable IPV6 ICMP messages on the computer you try to reach. By default, it's a rule in the "File and Printer Sharing" group. It must be enabled :

-In the outbound on the DirectAccess client

-Inbound & outbound on the DirectAccess gateway

-inbound & outbound on ressources you want to ping

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 1:12pm

I don't think I have specifically set ICMP to be allowed; but my Win 7 clients are functioning so far; while Win 8 are not yet. I will look into the firewall settings further.
April 20th, 2015 1:15pm

I definitely overlooked something dumb.  When I re-did my security groups this morning to split W7 and W8 clients, I forgot to adjust how my GPO to apply firewall settings was being applied; so my W8 client wasn't getting firewall settings.

Fixed that, and now the W8 client connects.  I'm going to double-check everything on another W7 client and make double-sure that it's all working...

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 1:26pm

It was long but you're on good way now.  

April 20th, 2015 1:28pm

I'm looking at a second W7 test client, it's getting the GPO's applied but it seems as though any of the settings are working. netsh int httpstunnel sh int shows nothing at all. gpresult /r shows the GPO for DCA being applied. theres also no nrpt table being applied as well. I'll look at GPO settings a bit more before worrying about it tooo much
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 2:35pm

You probably made something wrong while splitting your configuration for Windows 7 and Windows 8.x.

If the httpstunnel is empty and you don"t have NRPT settings, it's because your client doesn't receive the default DirectAccess GPO.
If you didn't change the name, it should be DirectAccess Client Settings.
It must be applied on all your clients ;-)

For your question about the DTE applied on Windows 8.x without your intervention, it's because DirectAccess create it's default client GPO to configure NCA for Windows 8.
You need to create an additional GPO for Windows 7' DCA 2.0 because NCA doesn't exist in this OS.



April 20th, 2015 3:29pm

Thank you for all of the help! I found that not all of my W7 GPO settings were being applied properly; I forced a gp update on the client and rebooted the system and then it started working.


At this time I now have W7 and W8 clients working fully.  I will review all of the answers here and see if I can locate one that seems as though it should be marked as an answer; though that will be difficult since it was a combination of a lot of different questions/issues/answers to get my system functioning properly.

Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 3:31pm

Welcome to the DirectAccess world. Now some next points to consider :

-Poddle and DirectAccess by a valuable MVP colleague of mine : http://directaccess.richardhicks.com/2014/10/21/poodle-and-directaccess/

-DirectAccess IP-HTTPS SSL and TLS Insecure Cipher Suites : http://directaccess.richardhicks.com/2014/09/23/directaccess-ip-https-ssl-and-tls-insecure-cipher-suites/

-How to Install and Configure KB2862152 for a DirectAccess Scenario : http://blogs.technet.com/b/jasonjones/archive/2013/11/29/how-to-install-and-configure-kb2862152-for-a-directaccess-scenario.aspx

-And most important : KB2883952 : https://support.microsoft.com/en-us/kb/2883952?wa=wsignin1.0

April 20th, 2015 3:38pm

Here's logs from the built In troubleshooting thing; I looked through it but can't seem to locate anything that I recognize as being wrong...

http://pastebin.com/L0YcDwgt


  • Edited by Dan Ceola Monday, April 20, 2015 4:52 PM
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 4:51pm

Here's logs from the built In troubleshooting thing; I looked through it but can't seem to locate anything that I recognize as being wrong...

http://pastebin.com/L0YcDwgt


  • Edited by Dan Ceola Monday, April 20, 2015 4:52 PM
April 20th, 2015 4:51pm

You probably made something wrong while splitting your configuration for Windows 7 and Windows 8.x.

If the httpstunnel is empty and you don"t have NRPT settings, it's because your client doesn't receive the default DirectAccess GPO.
If you didn't change the name, it should be DirectAccess Client Settings.
It must be applied on all your clients ;-)

For your question about the DTE applied on Windows 8.x without your intervention, it's because DirectAccess create it's default client GPO to configure NCA for Windows 8.
You need to create an additional GPO for Windows 7' DCA 2.0 because NCA doesn't exist in this OS.



Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 7:28pm

You probably made something wrong while splitting your configuration for Windows 7 and Windows 8.x.

If the httpstunnel is empty and you don"t have NRPT settings, it's because your client doesn't receive the default DirectAccess GPO.
If you didn't change the name, it should be DirectAccess Client Settings.
It must be applied on all your clients ;-)

For your question about the DTE applied on Windows 8.x without your intervention, it's because DirectAccess create it's default client GPO to configure NCA for Windows 8.
You need to create an additional GPO for Windows 7' DCA 2.0 because NCA doesn't exist in this OS.



April 20th, 2015 7:28pm

You probably made something wrong while splitting your configuration for Windows 7 and Windows 8.x.

If the httpstunnel is empty and you don"t have NRPT settings, it's because your client doesn't receive the default DirectAccess GPO.
If you didn't change the name, it should be DirectAccess Client Settings.
It must be applied on all your clients ;-)

For your question about the DTE applied on Windows 8.x without your intervention, it's because DirectAccess create it's default client GPO to configure NCA for Windows 8.
You need to create an additional GPO for Windows 7' DCA 2.0 because NCA doesn't exist in this OS.



  • Edited by Gerald Mathieu Monday, April 20, 2015 7:29 PM
  • Marked as answer by Dan Ceola Wednesday, April 22, 2015 12:19 PM
Free Windows Admin Tool Kit Click here and download it now
April 20th, 2015 7:28pm

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics