locked
Update 1 has broken DA RRS feed

  • Question

  • I have installed Update 1 on my UAG server and since then no clients can connect using DA. It would appear that any intranet address cannot be resolved. I have been through many of the troubleshooting steps and can ping the IPv6 addresses of the UAG gateway.

    nltest /dsgetdc: /force works on the UAG server but not on the client. It just can't resolve names in my domain, (except for those excluded by the DA configuration like uag.mydomain.com).

    Can someone point me in the right direction now?

    Thursday, July 15, 2010 12:44 PM

Answers

  • I resolved this now by a total rebuild, OS and all.

    I applied UPDATE 1 BEFORE doing any configuration.

    All is working now and no gpupdate needed on the clients but sadly no indication as to what broke.

    Thanks all

    Tim

    • Marked as answer by Tim Chapman Friday, July 16, 2010 6:07 PM
    Friday, July 16, 2010 6:07 PM

All replies

  • In addition I am getting the following frequently on the UAG windows security log;

    Log Name:      Security
    Source:        Microsoft-Windows-Security-Auditing
    Date:          15/07/2010 13:42:54
    Event ID:      4653
    Task Category: IPsec Main Mode
    Level:         Information
    Keywords:      Audit Failure
    User:          N/A
    Computer:      TRITON.domain.co.uk
    Description:
    An IPsec main mode negotiation failed.

    Local Endpoint:
     Local Principal Name: -
     Network Address: 2002:57e0:21f8::57e0:21f8
     Keying Module Port: 500

    Remote Endpoint:
     Principal Name:  -
     Network Address: 2001:dc0:1:0:4777::131
     Keying Module Port: 500

    Additional Information:
     Keying Module Name: AuthIP
     Authentication Method: Unknown authentication
     Role:   Initiator
     Impersonation State: Not enabled
     Main Mode Filter ID: 115926

    Failure Information:
     Failure Point:  Local computer
     Failure Reason:  Negotiation timed out

     State:   Sent first (SA) payload
     Initiator Cookie:  2a029522296285eb
     Responder Cookie: 0000000000000000
    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>4653</EventID>
        <Version>0</Version>
        <Level>0</Level>
        <Task>12547</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8010000000000000</Keywords>
        <TimeCreated SystemTime="2010-07-15T12:42:54.931873500Z" />
        <EventRecordID>4130092</EventRecordID>
        <Correlation />
        <Execution ProcessID="500" ThreadID="6132" />
        <Channel>Security</Channel>
        <Computer>TRITON.domain.co.uk</Computer>
        <Security />
      </System>
      <EventData>
        <Data Name="LocalMMPrincipalName">-</Data>
        <Data Name="RemoteMMPrincipalName">-</Data>
        <Data Name="LocalAddress">2002:57e0:21f8::57e0:21f8</Data>
        <Data Name="LocalKeyModPort">500</Data>
        <Data Name="RemoteAddress">2001:dc0:1:0:4777::131</Data>
        <Data Name="RemoteKeyModPort">500</Data>
        <Data Name="KeyModName">%%8223</Data>
        <Data Name="FailurePoint">%%8199</Data>
        <Data Name="FailureReason">Negotiation timed out
    </Data>
        <Data Name="MMAuthMethod">%%8194</Data>
        <Data Name="State">%%8202</Data>
        <Data Name="Role">%%8205</Data>
        <Data Name="MMImpersonationState">%%8217</Data>
        <Data Name="MMFilterID">115926</Data>
        <Data Name="InitiatorCookie">2a029522296285eb</Data>
        <Data Name="ResponderCookie">0000000000000000</Data>
      </EventData>
    </Event>

    Thursday, July 15, 2010 12:49 PM
  • Looks like an IPsec 1st authentication error.

    Can you check that both the client and server have valid client authentication certificates issued by the root CA configured in UAG DirectAccess.

    Thanks,

    Yaniv

    Thursday, July 15, 2010 1:11 PM
  • Also - check the Connection Security Rules on the UAG server and see if they are there.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Thursday, July 15, 2010 3:17 PM
  • All machines have the correct certificates and the connection security rules are in place in the adv firewall, (in the monitoring section too). Yesterday I had almost 50 DA clients working fine until the install of Update 1

    The errors on the UAG server are 4653. An IPsec main mode negotiation failed. There are 2 flavours of this error and they both involve my internal DCs as the remote endpoints.

    first one has a keying module name IKEv1 and a failure reason 'No policy configured'

    second one has a keying module name AuthIP and a failure reason 'Negotiation timed out'

    Really don't know how to move forward at the moment.

    Thursday, July 15, 2010 5:04 PM
  • I believe that when applying Update 1, the certificates need to be fixed:

    As per the MS install instructionsL

    If you have previously configured HTTPS trunks, open the Advanced Trunk Configuration dialog box, in the Server certificate drop-down list select a different trunk certificate, and on the dialog box, click OK. Open the Advanced Trunk Configuration dialog box for a second time, in the Server certificate drop-down list select the correct certificate, and then click OK.

    Thursday, July 15, 2010 5:46 PM
  • That would apply to the SSL VPN component of the UAG server, but DirectAccess doesn't use trunks, and the IPsec connections aren't using web site certificates.

    However, it might be worthwhile to re-run the DirectAccess wizard on the UAG server and see if that helps.

    HTH,

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Friday, July 16, 2010 12:51 PM
  • I resolved this now by a total rebuild, OS and all.

    I applied UPDATE 1 BEFORE doing any configuration.

    All is working now and no gpupdate needed on the clients but sadly no indication as to what broke.

    Thanks all

    Tim

    • Marked as answer by Tim Chapman Friday, July 16, 2010 6:07 PM
    Friday, July 16, 2010 6:07 PM
  • By the way, a "no policy" error usually means that an corresponding IPsec rule cannot be found on both client and server.

    You said that you validated the IPsec rules exist. so maybe something changed on the server, like the external IPv4, certificate or anything, that made the IPsec rule "invalid"

    Sunday, July 18, 2010 7:24 AM
  • Hi Yaniv,

     

    Nice tip!

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Monday, July 19, 2010 12:41 PM
  • For sure something was not right but it was none of the obvious unfortunately. It was literally a sequence like this;

    1. Working perfectly, dozens of happy DA clients
    2. Install Update 1
    3. Not working

    I think the only other thing I did prior to step 2 above was install the .net framework v4 as offered by MS Update. This may be related.

    Thanks

    Tim

    Monday, July 19, 2010 1:32 PM
  • Hi Tim,

    I'll keep my eyes out for this. I'm rebulding a UAG DA lab today and I'll play with some timings for updating to UP1.

    Thanks!

    Tom


    MS ISDUA/UAG DA Anywhere Access Team
    Tuesday, July 20, 2010 12:59 PM