locked
Microsoft UAG 2010 - DirectAccess - User and Computer Different Domains - Event ID 4984 RRS feed

  • Question

  • I have installed Microsoft UAG 2010 into a domain, let's call it x.biz.  I am trying to utilize DirectAccess technology, which is working when both the user and computer accounts are in the domain x.biz (infrastructure and intranet tunnels work).  The problem I am running into is when the user account is in another domain, y.com, and the computer is still in x.biz.  The infrastructure tunnel is up (able to Ping internal servers), but the intranet tunnel appears to be down and I am unable to access anything on the corporate network.  The security event log on the Microsoft UAG 2010 server is showing events IDs 4984.  I have added both x.biz and y.com to the management servers and DCs under the DirectAccess configuration.

     

    Is it possible to have the user account in a different domain than the Microsoft UAG 2010 server and computer utilizing DirectAccess?  Is there something I am missing or misunderstanding?

    Tuesday, December 7, 2010 4:15 PM

All replies

  • It is possible, but it is handled much better with UAG SP1. I would save yourself some pain and install SP1 and try again ;)

    http://technet.microsoft.com/en-us/library/gg315305.aspx

    http://www.microsoft.com/downloads/en/details.aspx?FamilyID=980ff09f-2d5e-4299-9218-8b3cab8ef77a

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Wednesday, December 8, 2010 12:17 AM
  • I installed UAG SP1 today, but have not seen any improvement.  I am still receiving event IDs of 4984 and now 4654 when I attempt to connect to internal resources from a user in a different domain.  I validated the user domain was still added to the management servers and DCs, reapplied the GPOs, and activated the configuration again.
    Wednesday, December 8, 2010 4:32 PM
  • Are these domains in the same forest, or domains in two separate forests?

    Can you provide a bit more detail on your chosen config options defined as part of the DA wizard?

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 9, 2010 11:23 AM
  • The domains are in separate forests, but there are full trusts between them.  I even tried a different account in another domain/forest, same issue.

     

    Step 1:

    Deployment Model: Allow DirectAccess clients to connect to internal networks, and enable remote management of DirectAccess clients.

    Client Domains: x.biz y.com z.net

    Policy Management: Automatically generate the following GPOs for DirectAccess policies.

    Client Groups: Security groups (x.biz computer added to group).

     

    Step 2:

    Configured, but if you need these they're fairly straight-forward.

     

    Step 3:

    Network Location Server: abc.x.biz

    DNS Suffixes: ...

    Authentication Domains: x.biz y.com z.net

    Management Servers: ...

     

    Step 4:

    Not configured.

    Thursday, December 9, 2010 1:15 PM
  • Ah ok, as you didn't mention forests, most people would assume that the domains were both in a single forest.

    I don't know the details as I have not used DA across forests in this manner, but I believe you need to disable or enable a 'kerberos AES encryption' option when setting up the forest trusts.

    Let me ping Tom, as I think he mentioned the issue a while back...

    Cheers

    JJ


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 9, 2010 1:36 PM
  • Thursday, December 9, 2010 1:39 PM
  • Hey guys,

    Let me see if I understand the scenario correctly:

    • UAG DirectAccess server and computer accounts are in forest y.com
    • Users and network resources are in forest x.com

    If that's the case, you can see the details of how to configure this scenario in the Proof of Concept Guide:

    http://blogs.technet.com/b/tomshinder/archive/2010/08/13/uag-directaccess-proof-of-concept-guide.aspx

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, December 9, 2010 4:55 PM
  • Tom, that is correct.  I checked your POC guide, but we have a two-way forest trust between x.biz and y.com...   Yet it seems like the intranet tunnel is failing to establish from a y.com user.
    Thursday, December 9, 2010 9:20 PM
  • Tom, that is correct.  I checked your POC guide, but we have a two-way forest trust between x.biz and y.com...   Yet it seems like the intranet tunnel is failing to establish from a y.com user.


    So it sounds like your environment is the same as the one set up in the POC guide. You might want to go through all the steps in your lab and see what in the POC guide differs from your setup.

    Also, could there be any firewalls that are blocking any required protocols?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Friday, December 10, 2010 5:17 PM
  • Not sure if the below helps, but:

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          12/16/2010 9:56:07 AM
    Event ID:      4654
    Task Category: IPsec Quick Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      uagsrv.x.biz
    Description:
    An IPsec quick mode negotiation failed.

    Local Endpoint:
        Network Address:    2002:d0ff:9503:8001::a40:20c9
        Network Address mask:    0
        Port:            0
        Tunnel Endpoint:        2002:d0ff:9504::d0ff:9504

    Remote Endpoint:
        Network Address:    ::
        Address Mask:        0
        Port:            0
        Tunnel Endpoint:        2002:d0ff:9503:8100:d03d:6d8a:80a3:de2f
        Private Address:        0.0.0.0

    Additional Information:
        Protocol:        0
        Keying Module Name:    AuthIP
        Virtual Interface Tunnel ID:    0
        Traffic Selector ID:    0
        Mode:            Tunnel
        Role:            Initiator
        Quick Mode Filter ID:    288586
        Main Mode SA ID:    1848

    Failure Information:
        State:            Sent first (SA) payload
        Message ID:        2147483648
        Failure Point:        Local computer
        Failure Reason:        Main mode SA assumed to be invalid because peer stopped responding.

    Event Xml:
    <Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
      <System>
        <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
        <EventID>4654</EventID>
        <Version>1</Version>
        <Level>0</Level>
        <Task>12549</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2010-12-16T14:56:07.309730100Z" />
        <EventRecordID>483935</EventRecordID>
        <Correlation />
        <Execution ProcessID="524" ThreadID="1352" />
        <Channel>Security</Channel>
        <Computer>uagsrv.x.biz</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalAddress">2002:d0ff:9503:8001::a40:20c9</Data>
        <Data Name="LocalAddressMask">0</Data>
        <Data Name="LocalPort">0</Data>
        <Data Name="LocalTunnelEndpoint">2002:d0ff:9504::d0ff:9504</Data>
        <Data Name="RemoteAddress">::</Data>
        <Data Name="RemoteAddressMask">0</Data>
        <Data Name="RemotePort">0</Data>
        <Data Name="RemoteTunnelEndpoint">2002:d0ff:9503:8100:d03d:6d8a:80a3:de2f</Data>
        <Data Name="Protocol">0</Data>
        <Data Name="RemotePrivateAddress">0.0.0.0</Data>
        <Data Name="KeyModName">%%8223</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">Main mode SA assumed to be invalid because peer stopped responding.
    </Data>
        <Data Name="Mode">%%8213</Data>
        <Data Name="State">%%8208</Data>
        <Data Name="Role">%%8205</Data>
        <Data Name="MessageID">2147483648</Data>
        <Data Name="QMFilterID">288586</Data>
        <Data Name="MMSAID">1848</Data>
        <Data Name="TunnelId">0</Data>
        <Data Name="TrafficSelectorId">0</Data>
      </EventData>
    </Event>

     

    There is no internal filtering done within the network.

    Thursday, December 16, 2010 3:08 PM
  • Did you add the DCs for both domains to the management servers collection?

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Thursday, December 16, 2010 4:09 PM
  • Tom, thanks for you help and I did.

    I was able to get functionality working for users that were in some of the different domains.  I noticed that I had created the ISATAP host records that pointed to the UAG server, but DNS querying for ISATAP records were blocked.  So after removing the block from the DNS servers, the intranet tunnels for these users started working!  I need to read up more on ISATAP and IPv6...

    Now for some of the other domains the issue still persists...  These domains have a child domain that the users exist in (i.e. internal.y.com and a parent of y.com).  The trusts with the UAG server/client computers domain (x.biz) are configured as followed:

     

    x.biz Properties

    Domains trusted by this domain (outgoing trusts):

    Name                   Trust Type       Transitive

    y.com                  Forest             Yes

    internal.y.com       External          No

     

    Domains that trust this domain (incoming trusts):

    Name                   Trust Type       Transitive

    y.com                  Forest             Yes

    internal.y.com       External          No

     

    Is there a possible issue with this trust configuration?  Do I need to create an isatap.y.com and isatap.internal.y.com DNS entry that both point back to the UAG server?

     

    Thursday, December 16, 2010 7:16 PM
  • Anyone familiar with this trust configuration and ISATAP DNS entries?
    Tuesday, December 28, 2010 1:08 PM
  • Anyone familiar with this trust configuration and ISATAP DNS entries?


    For all domains and clients in those domains, you need to make sure that they are able to resolve the host name ISATAP to the internal interface of the UAG DA server.

    RE: the trust configuration, as long as it's bidirectional between the UAG DA server domain and the resource domain, then you're in good shape.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team Get yourself some Test Lab Guides! http://blogs.technet.com/b/tomshinder/archive/2010/07/30/test-lab-guides-lead-the-way-to-solution-mastery.aspx
    Tuesday, January 4, 2011 2:33 PM
  • We had a similar problems.

    I see this is an old thread, but I want to share our solution:

    The source of our problem was that the domain trust type was external, and Kerberos authentication cannot be done with external trusts. (ref: http://blogs.technet.com/b/tkarch/archive/2007/03/19/kerberos-demystified.aspx)

    Our solution was to delete the external trust and add a forest trust instead. (If you use SID-history: Remember to enable it and remove filtering after changing the trust)

    Thanks a lot for the link to the POC guide, Thomas. Is was of great help while troubleshooting.

    Gisle

    Friday, February 3, 2012 1:55 PM