Freigeben über

SSO (Single Sign On) not working for a published Web Application with UAG

  • Artikel

Toolbox3Introduction:

We had an application published on Microsoft Forefront Unified Access Gateway 2010 (UAG). Single Sign On (SSO) for that particular application on UAG was not working. We were using 401 to delegate credentials on the Applications Publishing Rule on UAG.

Scenario:

The issue was specific to one particular application published through UAG. SSO for the other published applications was working fine, so there was definitely something different on that particular server.

The users were getting the following error when trying to access the application externally:

You do not have permissions to view this folder or page

Troubleshooting:

We gathered a UAG trace and its analysis showed the following errors:

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CSSPINegStep::ProcessNegStep HTTP401Authentication.cpp@1340] ERROR:HTTPAuth::CSSPINegStep::ProcessNegStep - ERROR: InitializeSecurityContext failed with error code 0x80090302 (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10)

[0]5a0.1bfc 02/02/2012-22:07:34.406 [whlfilter HTTPAuthentication::CNTLMHandler::Negotiate HTTP401Authentication.cpp@1515] ERROR:HTTPAuth::CNTLMHandler::Negotiate - conversation failed, resetting state (PFC=000000000D61D718) (ExtPFC=00000000034F08C0) (ExtECB=0000000005239F10

Error Code 0x80090302 resolves to SEC_E_UNSUPPORTED_FUNCTION.

Researching the message led us to an article on TechNet that stated:

According to InitializeSecurityContext (NTLM) documentation, a call to this method will return a SEC_E_UNSUPPORTED_FUNCTION when : A context attribute flag that is not valid (ISC_REQ_DELEGATE or ISC_REQ_PROMPT_FOR_CREDS) was specified in the fContextReq parameter.

Network traces confirmed that it was exactly the behavior mentioned above, as the backend web server was not setting the "128-Bit Encryption" flag on its reply in the NTLM negotiate header. In a Network Monitor capture, this is what that looks like:

Request sent from UAG to the web server:

clip_image002

Response from the web server:

clip_image004

As it turns out, the backend server does not support 128-bit NTLM encryption, but UAG was set to require it.

The ideal way to solve this is by configuring the backend server. If, however, the backend server cannot support 128-bit, we can work around this by disabling 128-bit in UAG. Disabling 128-bit on the UAG server should only be done as a last resort. This is the procedure:

1. Open the local group policy editor on the UAG server

2. Navigate to Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options

3. Double-click the option “Network security: Minimum session security for NTLM SSP based (including secure RPC) servers":

clip_image006

4. Uncheck both options and click OK. The setting will change to read “no minimum”:

clip_image008

5. Exit the group policy editor.

 

Author :

Nitin Singh
Security Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Technical Reviewers:

Ophir Polotsky
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Ben Ari
Security Sr. Support Escalation Engineer
Microsoft CSS Forefront Security Edge Team

Comments

  • Anonymous
    February 21, 2014
    We’ve gathered the top Microsoft Support solutions to the most common issues experienced using
  • Anonymous
    May 16, 2014
    We’ve gathered the top Microsoft Support solutions for the most common issues experienced when
  • Anonymous
    May 16, 2014
    We’ve gathered the top Microsoft Support solutions for the most common issues experienced when
  • Anonymous
    July 21, 2014
    We’ve gathered the top Microsoft Support solutions for the most common issues experienced when
  • Anonymous
    July 21, 2014
    We’ve gathered the top Microsoft Support solutions for the most common issues experienced when