locked
UAG DirectAccess NLA not working as expected RRS feed

  • Question

  • I’m writing because I’m working on NLA server config for our UAG DA pilot and there is a mystery that I haven’t yet been able to solve. 

     

    We initially used the UAG DA wizard to set up a GPO that points the DA clients to a server called uagpocnla.[domain].org.  This server works great but it's not highly available - it was only set up for use with our proof of concept testing.  Now we're working on setting up pilot servers that will eventually become production servers.  We're trying to test a new secure website, [domain].[domain].org, as our NLA server.  It's highly available and is used for many purposes throughout the company so it's an excellent choice for an NLA server.  I’ve manually modified the DA client GPO to change the NLA server information.  I changed the NCSI setting, the NRPT, and the WFAS rule to point to the new server, and everything seems to work but client computers are still considering themselves outside of the corpnet. 

     

    In general, NLA detection works when the clients get an HTTP 200 message from a successful connection to the NLA server, and then successfully contact the domain.  In my case, I've run packet captures and the client computers are making successful HTTPS connections to the new NLA server, but they're not trying to talk to the domain at all.  They don't initiate any packets to any domain controllers.  Packet captures on clients that were configured with the old NLA server show that after a successful HTTPS connection the clients immediately shot some LDAP packets to domain controllers.  So why aren't the clients which are pointed to the new NLA server doing this?

     

    I suppose my question is really whether the DA wizard sets anything that I've missed in my manual reconfiguration of the GPO.  I could run the DA wizard again with the new NLA server specified there to test this, but as I don't have permissions to create GPOs in the domain it will be a lengthy process of RFCs, approvals, and then having someone else actually do the work for me.  I'd like to just test this and get it over with, if possible.

     

    Thank you in advance for any assistance!

     

    Justin

    Friday, July 2, 2010 7:26 PM

Answers

  • Mystery solved! Whatever server is selected as the DA NLS must allow anonymous access. The uagpocnla.corp.[domain].org server did allow that, but the [domain].[domain].org server did not. So even though packet captures showed that the client was chatting a lot with the HTTPS server, it was not actually receiving HTTP 200 messages, only HTTP 401 (unauthorized). Thank you to everyone who responded!
    Wednesday, July 7, 2010 5:50 PM

All replies

  • I would run the DA wizard and change the NLA, this will also test the NLA validity to confirm all is ok...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Sunday, July 4, 2010 11:14 PM
  • Dude, what were you doing working on July 4th?  :-)

    I'll give the wizard a go - I agree that it seems like the only way to be sure.  I'll report my results here.

    Thanks!

    Tuesday, July 6, 2010 4:30 PM
  • The date it not so significant in the UK ;)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Tuesday, July 6, 2010 10:53 PM
  • Well, there you go.  :-)
    Tuesday, July 6, 2010 11:10 PM
  • If the server is used for many other purposes, you should make sure to use a different DNS name for the NLA purpose, otherwise DirectAccess clients will never be able to reach this server for the other purposes while they're outside.

    Anyway, can you try to check the NCSI event log on your client computers? It should give you an idea whether the clients think they're outside or not.

    Also, I'd run this trace: netsh trace DirectAccess,nid_wpp start and send the results to Microsoft Support.

    Wednesday, July 7, 2010 8:27 AM
  • Just to be clear, we're talking about the Network Location Server or NLS, right? NLA (Network Location Awareness) is a different issue, though related.

    It sounds like there's a problem with your Name Resolution Policy Table (NRPT). Are you using UAG RTM or Update 1?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Wednesday, July 7, 2010 11:57 AM
  • Yes, that's correct Tom - the Network Location Server for DirectAccess inside/outside detection.  We're using Update 1. 

    I guess that's the part I'm not getting - if the NRPT has the correct entry for the NLS (which it does) and if the client can create HTTPS sessions with the NLS (which it can - packet captures prove it), then why would it not initiate contact with the domain and therefore still consider itself outside? 

    I'm going to re-run the DA wizard today and see if I can wade through the change process to get the GPOs created in AD.  Thank you all for your responses!

    Wednesday, July 7, 2010 4:40 PM
  • Well well... the DA wizard says that the selected HTTPS URL is not currently accessible, or its HTTP response is not valid. I've successfully browsed to the site using IE on the DA server, so that would seem to eliminate the first possibility. In that case, process of elimination would suggest that the HTTP response is not valid. Weird - I thought all it needed was HTTP 200, and that all successful HTTPS sessions had that code. Maybe not.
    Wednesday, July 7, 2010 5:14 PM
  • Mystery solved! Whatever server is selected as the DA NLS must allow anonymous access. The uagpocnla.corp.[domain].org server did allow that, but the [domain].[domain].org server did not. So even though packet captures showed that the client was chatting a lot with the HTTPS server, it was not actually receiving HTTP 200 messages, only HTTP 401 (unauthorized). Thank you to everyone who responded!
    Wednesday, July 7, 2010 5:50 PM
  • Mystery solved! Whatever server is selected as the DA NLS must allow anonymous access. The uagpocnla.corp.[domain].org server did allow that, but the [domain].[domain].org server did not. So even though packet captures showed that the client was chatting a lot with the HTTPS server, it was not actually receiving HTTP 200 messages, only HTTP 401 (unauthorized). Thank you to everyone who responded!

    That would make sense! :)
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, July 7, 2010 7:28 PM
  • Yes, that's right!

    I'll check our docs again to see if we make it clear that anonymous access needs to be enabled to the NLS. There no reason for us to assume that you should know this if we haven't pointed it out explicitly.

    Good to hear you got it working and thanks for the follow up!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 9, 2010 1:31 PM
  • JustinMartin.

    I have just hit this issue. my laptop does not know it is on the network. i have allowed anonymous access to the default website and the crld folder but still does not work. When you say the [domain].[domain].org sever did not what do you mean?

    i can browse to https://nls.domain but shows 403 - Forbidden: Access is denied.

    any ideas?

    Monday, June 27, 2011 2:49 PM
  • Don't worry ive solved it. i had to enable directory browsing on the default web site. once that was complete the laptop knew it was on the domain and not just labled as "network"
    Monday, June 27, 2011 3:08 PM
  • Cool, I'm glad you got it figured out!

    Tuesday, June 28, 2011 12:34 AM