locked
Portal Authentication fails if "Use Remote Desktop Single-Sign-On Services (SSO)" is selected. RRS feed

  • Question

  • Hi Folks,

    i'm having problems to publish some RemoteAPPs on UAG.

    When the "Use Remote Desktop Single-Sign-On Services (SSO)" option is checked in the RemoteAPP application policy, then the initial Portal authentication just fails.

    Webmon/EventLog MSG:

    User Contoso.de\\administrator with source IP address 20.20.20.102 failed to log into trunk accesstrunk (secure=1) using authentication server CONTOSO with session ID 2614740F-5F2F-4525-8435-EEBB79BC8AC8. Error code is Logon failure: unknown user name or bad password.

    User contoso\\administrator with source IP address 20.20.20.102 failed to log into trunk accesstrunk (secure=1) using authentication server CONTOSO with session ID 2614740F-5F2F-4525-8435-EEBB79BC8AC8. Error code is Logon failure: unknown user name or bad password.

    User Contoso.de\\administrator@contoso.de with source IP address 20.20.20.102 failed to log into trunk accesstrunk (secure=1) using authentication server CONTOSO with session ID 2614740F-5F2F-4525-8435-EEBB79BC8AC8. Error code is Logon failure: unknown user name or bad password.

    If i deselect the RemoteAPP SSO option, the initial Portal authentication went back to normal operation - but with manual RemoteAPP authentication (i'll get a promt when accessing RDApp's). When turned back on - the portal authentication fails again, etc...

    I crawled almost the entire internet for a solution, but i couldn't find any releated information how to avoid this problem.

    Any clues?

    -Kai

     

    Wednesday, August 31, 2011 3:44 PM

Answers

  • Hey Kai,

    Are there by any chance any "special characters" in the user's password? Not that I know of any issue with that which is relevant to your scenario, but just thinking out loud what could possibly cause the failure...

    Regards,


    -Ran
    • Marked as answer by Kai Wilke Thursday, September 1, 2011 10:55 AM
    Wednesday, August 31, 2011 7:18 PM
  • Hi Ran,

    I collected additional information using Fiddler2 in addition to a custom “repository.inc” debugging hook to see the Password values during LDAP authentication.

    SSO Disabled:

    POST String:

    user_name=Administrator&password=Password1%2B&repository=CONTOSO&language=de-DE&site_name=accesstrunk&secure=1&resource_id=2&login_type=2

    Repository.inc hook:

    User_Name = Administrator
    Password = Password1+

    SSO Enabled:

    POST String:

    user_name=Administrator&password=Password1+&repository=CONTOSO&language=de-DE&site_name=accesstrunk&secure=1&resource_id=2&login_type=2&rds_sso=on

    Repository.inc hook:

    User_Name = Administrator
    Password = Password1 (followed by SPACE)

    It seems to be an URL/HTML encoding problem, so you're absolutely right with your special character theory! But come on, the "+" sign is indeed not that special, or isn't it?

    I've digged a little in the code and found the part that causes this issues...

    "login.asp" HTML code:

    document.getElementById("rds_sso").value = "on";
    var post_data = "";
    for (i = 0 ; i < document.form1.length ; i++)
     {
      var tempobj = document.form1.elements[i];
      if (tempobj.name != '')
       {
        post_data += "&" + tempobj.name + "=" + escape(tempobj.value);
       }
     }
    
    

    I checked the "escape()" function using IE developer tools. The "+" sign doesn't get escape'd correctly using this function (its getting ignored).

    When I customize the login.asp page to use the "encodeURIComponents()" function instead of "escape()", then the portal login works nicely using "+" and even German "umlaute" (e.g. i tried "ÄäÖöÜü +?ß!"§$%&/" as password)". So far nothing seems to be broken after doing the customization...

    So please get in touch with the PSS/CSS guys. This issue should be fixed as soon as possible...

    -Kai

    Edit: "encodeURIComponents()" has a typo. It should be written without the last "s". So "encodeURIComponent(tempobj.value)" would be the right customization.

    • Marked as answer by Kai Wilke Thursday, September 1, 2011 10:54 AM
    • Edited by Kai Wilke Friday, September 2, 2011 8:04 AM Found a typo in the code provided.
    Thursday, September 1, 2011 10:53 AM

All replies

  • Hey Kai,

    Are there by any chance any "special characters" in the user's password? Not that I know of any issue with that which is relevant to your scenario, but just thinking out loud what could possibly cause the failure...

    Regards,


    -Ran
    • Marked as answer by Kai Wilke Thursday, September 1, 2011 10:55 AM
    Wednesday, August 31, 2011 7:18 PM
  • No, its the well known Administrator and Password1+ combination (aka. CONTOSO)

    -Kai

     

    Wednesday, August 31, 2011 7:27 PM
  • I've collected some additional trace information.

    This happens when RemoteAPP SSO is enabled...

    [0]cf8.17cc 08/31/2011-23:00:55.642 [usermgrcore whale::usermgr::CUserMgrCore::AuthenticateUser UserMgrCore.cpp@460] Info:got [CAuthenticateUserIn:
    m_repository                          = [CONTOSO]
    m_user                                = [Administrator]
    m_password                            = [**Confidential**]
    m_domain                              = []
    m_param_vec                           = <EmptyField>
    m_site_name                           = [accesstrunk]
    m_secure                              = [1]
    m_session_id                          = [9F0965CF-AAFB-4D18-A3F2-873B915FB680]
    m_login_type                          = [2]
    m_source_ip                           = [20.20.20.200]
    m_cert_client                         = [0]
    ]
    ...

    [0]cf8.17cc 08/31/2011-23:00:55.649 [usermgrcore whale::usermgr::CLdap::AuthenticateUser Ldap.cpp@411] Info:Authenticate user [Administrator], domain [<NULL>], in the LDAP server [192.168.1.10], port [3268], DN [DC=Contoso,DC=de], type [Active Directory]
    [0]cf8.17cc 08/31/2011-23:00:55.649 [usermgrcore whale::usermgr::CLdap::GetDomainDnsName Ldap.cpp@6622] Info:DomainName: [LoggedInDomain]. DomainDNSName: [Contoso.de].
    [0]cf8.17cc 08/31/2011-23:00:55.649 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6456] Info:UAG server domain name: [Contoso.de].
    [0]cf8.17cc 08/31/2011-23:00:55.650 [usermgrcore whale::usermgr::CLdap::GetDomainDnsName Ldap.cpp@6622] Info:DomainName: [Contoso.de]. DomainDNSName: [Contoso.de].
    [0]cf8.17cc 08/31/2011-23:00:55.650 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6466] Info:User domain name: [Contoso.de].
    [0]cf8.17cc 08/31/2011-23:00:55.650 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6470] Info:The user and the UAG machine belong to the same domain: [Contoso.de]
    [0]cf8.17cc 08/31/2011-23:00:55.650 [usermgrcore whale::usermgr::CLdap::LogonUserInternal Ldap.cpp@6551] Info:Trying to login the User: [Administrator] Domain: [Contoso.de]...
    [0]cf8.17cc 08/31/2011-23:00:55.702 [usermgrcore whale::usermgr::CLdap::LogonUserInternal Ldap.cpp@6562] ERROR:Login failed for User: [Administrator] Domain: [Contoso.de]. Code: [0x52E]. Description: [Logon failure: unknown user name or bad password].
    [0]cf8.17cc 08/31/2011-23:00:55.702 [usermgrcore whale::usermgr::CLdap::Disconnect Ldap.cpp@1153] Info:Destroy the connection to IP [192.168.1.10], port [3268].
    [0]cf8.17cc 08/31/2011-23:00:55.702 [usermgrcore whale::usermgr::CUserMgrCore::AuthenticateUser UserMgrCore.cpp@527] ERROR:Failed to authenticate [Logon failure: unknown user name or bad password]

    And this happens when RemoteAPP SSO is disabled...

    [0]cf8.1734 08/31/2011-23:51:52.011 [usermgrcore whale::usermgr::CUserMgrCore::AuthenticateUser UserMgrCore.cpp@460] Info:got [CAuthenticateUserIn:
    m_repository                          = [CONTOSO]
    m_user                                = [administrator]
    m_password                            = [**Confidential**]
    m_domain                              = []
    m_param_vec                           = <EmptyField>
    m_site_name                           = [accesstrunk]
    m_secure                              = [1]
    m_session_id                          = [20703B68-2EA4-4210-ABCF-9820BD6E64EE]
    m_login_type                          = [2]
    m_source_ip                           = [20.20.20.200]
    m_cert_client                         = [0]
    ]

    [0]cf8.1734 08/31/2011-23:51:52.020 [usermgrcore whale::usermgr::CLdap::AuthenticateUser Ldap.cpp@411] Info:Authenticate user [administrator], domain [<NULL>], in the LDAP server [192.168.1.10], port [3268], DN [DC=Contoso,DC=de], type [Active Directory]
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::GetDomainDnsName Ldap.cpp@6622] Info:DomainName: [LoggedInDomain]. DomainDNSName: [Contoso.de].
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6456] Info:UAG server domain name: [Contoso.de].
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::GetDomainDnsName Ldap.cpp@6622] Info:DomainName: [Contoso.de]. DomainDNSName: [Contoso.de].
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6466] Info:User domain name: [Contoso.de].
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::IsTrustedDomain Ldap.cpp@6470] Info:The user and the UAG machine belong to the same domain: [Contoso.de]
    [0]cf8.1734 08/31/2011-23:51:52.021 [usermgrcore whale::usermgr::CLdap::LogonUserInternal Ldap.cpp@6551] Info:Trying to login the User: [administrator] Domain: [Contoso.de]...
    [0]cf8.1734 08/31/2011-23:51:52.052 [usermgrcore whale::usermgr::CLdap::LogonUserInternal Ldap.cpp@6580] Info:Login succeeded for User: [administrator] Domain: [Contoso.de].

    I have no clue what is causing this wired behavior, its a fresh UAG installation without any customizations deployed. The LDAP authentication just fails when RemoteAPP SSO gets enabled.

    BTW: Does someone know a way to to see the values behind the "[**Confidential**]" blinds?

    BTW2: I even C/P´ed the username and password into the login form to get sure! :)

    -Kai

     

    Wednesday, August 31, 2011 10:15 PM
  • Strange indeed, Kai...

    same code gets executed in both scenarios, yet once it succeeds to logon the user, while the other time it fails.

    BTW: Does someone know a way to see the values behind the "[**Confidential**]" blinds?

    Have you tried using Fiddler on the client machine, to see the HTTP traffic sent to UAG?

     Regards,


    -Ran
    Thursday, September 1, 2011 6:23 AM
  • Hi Ran,

    I collected additional information using Fiddler2 in addition to a custom “repository.inc” debugging hook to see the Password values during LDAP authentication.

    SSO Disabled:

    POST String:

    user_name=Administrator&password=Password1%2B&repository=CONTOSO&language=de-DE&site_name=accesstrunk&secure=1&resource_id=2&login_type=2

    Repository.inc hook:

    User_Name = Administrator
    Password = Password1+

    SSO Enabled:

    POST String:

    user_name=Administrator&password=Password1+&repository=CONTOSO&language=de-DE&site_name=accesstrunk&secure=1&resource_id=2&login_type=2&rds_sso=on

    Repository.inc hook:

    User_Name = Administrator
    Password = Password1 (followed by SPACE)

    It seems to be an URL/HTML encoding problem, so you're absolutely right with your special character theory! But come on, the "+" sign is indeed not that special, or isn't it?

    I've digged a little in the code and found the part that causes this issues...

    "login.asp" HTML code:

    document.getElementById("rds_sso").value = "on";
    var post_data = "";
    for (i = 0 ; i < document.form1.length ; i++)
     {
      var tempobj = document.form1.elements[i];
      if (tempobj.name != '')
       {
        post_data += "&" + tempobj.name + "=" + escape(tempobj.value);
       }
     }
    
    

    I checked the "escape()" function using IE developer tools. The "+" sign doesn't get escape'd correctly using this function (its getting ignored).

    When I customize the login.asp page to use the "encodeURIComponents()" function instead of "escape()", then the portal login works nicely using "+" and even German "umlaute" (e.g. i tried "ÄäÖöÜü +?ß!"§$%&/" as password)". So far nothing seems to be broken after doing the customization...

    So please get in touch with the PSS/CSS guys. This issue should be fixed as soon as possible...

    -Kai

    Edit: "encodeURIComponents()" has a typo. It should be written without the last "s". So "encodeURIComponent(tempobj.value)" would be the right customization.

    • Marked as answer by Kai Wilke Thursday, September 1, 2011 10:54 AM
    • Edited by Kai Wilke Friday, September 2, 2011 8:04 AM Found a typo in the code provided.
    Thursday, September 1, 2011 10:53 AM
  • Congratulations guys

    What a nice troubleshooting!!


    // Raúl - I love this game
    Thursday, September 1, 2011 2:35 PM
  • Yep, Ran gave me a pretty good hint where to look at... :)

    Thanks!

    -Kai

    Thursday, September 1, 2011 7:19 PM
  • Yes, Ran is like my mother :)

    Always there and always gives you good advice...


    // Raúl - I love this game
    • Edited by RMoros Tuesday, September 6, 2011 4:08 PM
    Tuesday, September 6, 2011 4:08 PM
  • Hi Folks,

    i got a responce from CSS regading this issue, the proposed fix for this issue will be included in the next UAG update.

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Friday, September 30, 2011 9:41 AM
  • Hi Folks,

    the UAG SP1 Update 1 contains the official fix for this issue ...

    http://support.microsoft.com/kb/2585140/en-us#Fix11

    11. Users cannot log on if password includes the plus character (+)

    Symptoms
    Authentication fails when a user tries to log on to UAG if the password includes the plus character (+) and if Remote Desktop Service (RDS) SSO is turned on.

    -Kai


    This posting is provided "AS IS" whithout any warranties. Kai Wilke | ITaCS GmbH | GERMANY, Berlin | www.itacs.de
    Wednesday, October 19, 2011 9:15 AM