locked
Single Sign-on - always misses the AD Domain and fails RRS feed

  • Question

  • When accessing published Remoteapps, UAG attempts to use SSO to signon to the RemoteApp server, but always fails, generating a logon dialogue box. It appears to attempt to logon using just 'username' and 'password' whereas I have to enter 'domain\username' and 'password' for the RemoteApp to launch.

    I can't help thinking there must be someplace in UAG to say 'always use the following Active Directory domain for SSO attempts'

    Anyone know where this might be?

     

    Friday, May 14, 2010 10:18 AM

Answers

  • Sounds like customizing the login process. :-)   I mean, you can add the domain by customizing (copy into CustomUpdate folder) the appropriate files.

    • Marked as answer by Erez Benari Wednesday, May 19, 2010 11:45 PM
    Friday, May 14, 2010 10:01 PM

All replies

  • How is your Active Directory repository defined?


    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, May 14, 2010 11:57 AM
  • I have an Authentication server named "Windows".

    In Connection settings, I name two AD controllers, and use port 389

    In Search Settings, I have: CN=Users,DC=fabrikam,DC=org,DC=uk  and Include subfolders is checked, and level of nested groups is 0.

    In Server Access I have  fabrikam\Services and a suitable password

    In Default domain name I have tried both fabrikam.org.uk and fabrikam without success

    Friday, May 14, 2010 12:30 PM
  • Here is how to publish a remoteApp

     

    1. In the Forefront UAG Management console, select the portal in which you want to publish RemoteApp applications. In the Applications area of the main portal properties page, click Add. The Add Application Wizard opens.

    2. On the Select Application page of the wizard, select Terminal Services (TS)/Remote Desktop Services (RDS). In the list, select RemoteApp.

    3. On the Configure Application page of the wizard, enter a name for the RemoteApp application.

    4. On the Select Endpoint Policies page of the wizard, do the following:
    5. In Access policy, select a Forefront UAG policy with which endpoints must comply in order to access the published RemoteApps in the portal. In Printers, Clipboard, and Drives, select access policies with which endpoints must comply in order to access these local resources during remote desktop sessions.
    6. To enable single sign-on for the session, select the Use RDS Single Sign-On (SSO) Services check box.
    7. If the trunk through which you are publishing the RemoteApp applications uses Network Access Protection (NAP) policies, and you have a Network Policy Server (NPS) configured, do the following:

      • Select Require Network Access Protection (NAP) compliance, to specify that only endpoints that comply with NAP policy can access published RemoteApps.
      • Select Require NAP compliance for RDS device redirection only, to specify that only endpoints that comply with NAP policy can access devices and resources on RDS servers, such as drives, printers, and the clipboard. Access to other resources and applications on RDS servers does not require NAP compliance.
      • Select Do not require NAP compliance, if you do not require clients to use NAP to access the published RemoteApps.
    8. On the Import RemoteApp Programs page of the wizard, do the following:
    9. In File to import, specify the location of the exported .tspub file, or click Browse to locate the file.
    10. In RD Session Host or RD Connection Broker, specify the name of an RD Session Host (if different from that specified in the imported settings file), or the name of the RD Connection Broker server.
    11. If you are using an RD Connection Broker server, in IP addresses, IP address ranges, FQDNs, or subnets, add the names of all RD Session Hosts that might be used by the RD Connection Broker. To specify multiple servers, use an IP address range or subnet.
    12. On the Select Publishing Type page of the wizard, in the Available RemoteApps list, double-click each RemoteApp that you want to publish via Forefront UAG, to add it to the Published RemoteApps list. The list of available RemoteApps is retrieved from the imported .tspub file.

    13. On the Configure Client Settings page of the wizard, specify how RemoteApps should be displayed. You can set a display resolution and color, or select to use display settings retrieved from the imported .tspub file.

    14. Complete the Add Application Wizard.

    and here comes the silly question

    Have you done step 6

    I have to ask.

     

    Friday, May 14, 2010 12:51 PM
  • No it's not a silly question, but yes, I have done step 6....

    When the Remote app fails to launch, Remotea app helpfully says "Please enter new credentials for iportal.fabrikam.org.uk. The credentials that were used to connect to the remote computer did not work"

    hmmm...

     

    Friday, May 14, 2010 1:28 PM
  • VCheck this link out. It may not be UAG at fgault here but the Terminal server you are connecting to...

     

    http://www.virtualizationadmin.com/articles-tutorials/terminal-services/security/enable-single-sign-on-sso-windows-server-2008-terminal-services.html

    Friday, May 14, 2010 1:36 PM
  • I just read some release notes at:

    http://technet.microsoft.com/en-us/library/dd772157.aspx#BKMK_DA

    and found:

    "To use single sign-on for RDS applications, users must specify their login name in domain\user format"

    It's true. if I logon to the portal with username & password, RemoteApp SSO fails, and I get a logon prompt. If I logon to the portal as domain\username & password, RemoteApp SSO works fine.

    Is this a bug?

    Can I define somewhere in UAG that logons are always to a particular domain? so that users just enter there username, and UAG adds the domain prefix? (I only have 1 domain!)

    thanks.

     

    Friday, May 14, 2010 1:56 PM
  • Sounds like customizing the login process. :-)   I mean, you can add the domain by customizing (copy into CustomUpdate folder) the appropriate files.

    • Marked as answer by Erez Benari Wednesday, May 19, 2010 11:45 PM
    Friday, May 14, 2010 10:01 PM
  • Hi, this is exactly the problem I have too.  However, I have tried to create an inc file to acheive this but with no luck - I'm not sure what I am missing....

    I have looked at Login.asp with the hope of a quick javascript fix, which might yet be the way to acheive this (modify the DOM element to prepend the domain name\ to it) but my javascript is rusty and I don't really have a way to test it on IE6, 7 & 8.  I have tried to modify validate.asp (to change the username as it is 'saved' at the end of the script) and validate.inc (to append the domain to the username white it is being checked) but to no avail. 

    In the web monitor I can see that the username is in fact stored in the full format correctly with the domain; what I cannot find out is how the endpoint client ActiveX obtains the username and how to influence that, so the correct username is passed to Remote Desktop Client.

    Am I missing something really silly here?

    Thanks, --Chris

    Thursday, July 15, 2010 2:41 PM
  • We have the same problem, it says your credentials did not work, the logon attempt failed. I have to click "use another account", type domain\user and password it works....

    Wednesday, July 28, 2010 1:05 PM
  • I raised this as a new question http://social.technet.microsoft.com/Forums/en-US/forefrontedgeiag/thread/2ce4a71f-8613-4d3f-b2fc-90ddfe0d9a60 as this is marked complete but have not had a reply yet
    Thursday, July 29, 2010 12:19 PM
  • This has just worked for me http://technet.microsoft.com/en-us/library/ff607330.aspx I was trying to fix remote desktop but this fixed remote apps !!!

     

    Thursday, July 29, 2010 12:23 PM
  • If I sign into the portal with domain\username then I can access my remoteapps with sso.

    If I sign into the portal with just username it dont work, I guess the domain is not being appended.

    Also just removed the custom Portal1rdpdata.inc file and because im signing in as domain\username its still working !

    Thursday, July 29, 2010 12:33 PM
  • The problem is that this is the only application that uses domain\user so my users will get confused - so it will generate a lot of support calls.  There must be a way of appending the domain to the username that is stored internally (and is passed to the client component, since it is the component that passes the login to the RDP client).  The annoying thing is that if you look at the web monitor it shows the username with the domain attached!

    Dominic seemed to know how to do this but his response didnt actually say how to do it.  Ben was a bit keen in marking it as answered

    Thursday, July 29, 2010 2:21 PM
  • It is not as simple as appending the domain name to the form from what I have heard...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Friday, July 30, 2010 11:56 PM
  • So it would seem...though Dominik runs a significant Forefront blog so I do wonder if he knows the trick...
    Sunday, August 1, 2010 6:04 PM
  • What you should do is change a registry value on the RDS Server:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName

    Change that from 'computername' to 'domain.local'.

    After you change that, SSO for remoteapps should work even if you login with only your username.

    • Proposed as answer by JorenD Thursday, February 17, 2011 1:49 PM
    Thursday, December 2, 2010 12:12 PM
  • What you should do is change a registry value on the RDS Server:

    HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\DefaultDomainName

    Change that from 'computername' to 'domain.local'.

    After you change that, SSO for remoteapps should work even if you login with only your username.


    Cool...I believe it is fixed in UAG SP1 too, judging by the RC release...
    Jason Jones | Forefront MVP | Silversands Ltd | My Blogs: http://blog.msedge.org.uk and http://blog.msfirewall.org.uk
    Thursday, December 2, 2010 10:17 PM