locked
RDS Gateway server is not authenticating users from other domains RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

    We have 2 domains in my organisation, let's call them domain A and domain B.

    RDS is set up in domain B (Gateway, connection broker, 2 session hosts for remote apps, 1 session host for virtual desktop pools, hyper v farm  hosting the virtual desktop pools...etc).

    Users in domain B can successfully connect through the gateway and access all the remote apps and virtual desktop pools.

    Users in domain A can not. Whenever a user from domain A tries to connect they get an error:
    __________________________________________________________________________________________________________
    ---------------------------
    RemoteApp Disconnected
    ---------------------------
    Remote Desktop can’t connect to the remote computer "remote apps server" for one of these reasons:

    1) Your user account is not authorized to access the RD Gateway "gateway server"
    2) Your computer is not authorized to access the RD Gateway "gateway server"
    3) You are using an incompatible authentication method (for example, the RD Gateway might be expecting a smart card but you provided a password)

    Contact your network administrator for assistance.
    ---------------------------
    OK   Help  
    ---------------------------
    _____________________________________________________________________________________________________________

    In addition, if I look at the logs on the gateway server I can see event 4402:
    There is no domain controller available for domain A

    and event 6274: 
    Network Policy Server discarded the request for a user.
    Contact the Network Policy Server administrator for more information.

    There is a one way trust between domain A and domain B.
    Domain B trusts domain A, but domain A does not trust domain B.

    If a user from domain A is logging into any PC in domain B, they can authenticate and log in fine.
    If a user from domain A is remoting into one of the RDS session hosts directly (using  RDP), they can authenticate and log in fine.
    If a user from domain A is trying to connect through the gateway, authentication seems to be failing.

    What should I do? One thing that was suggested is to add the gateway server to the "RAS and IAS Servers" group in domain A.
    I have not yet tried this as I do not believe that the admins of domain A will be too happy with doing this for me.

    Another thing I was told was to make sure that the user group I am entering into the "CAP user group membership" on the gateway, is a universal group in domain A, as opposed to first adding the group from domain A into the local group in domain B, and then adding the local group into the CAP user group membership.

    I have asked the domain admins for domain A to create a universal group and only add my domain A account into this group, and they have done this for me. I have added this universal group from domain A, directly into the CAP user group membership on the gateway and I am still having this issue.

    Both domain A and B are server 2008 R2 domains, and all our servers I mentioned above are running server 2008 R2. 

    This is a problem connecting from any client, whether it be XPSP3, Vista, or WIN7.

    Any help will be much appreciated, this is driving me insane!!!!

    Friday, October 22, 2010 1:52 AM

Answers

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    For the one way trust model that you are using, you need to deploy central NPS server (and not local NPS server for CAP policies which is the default setting) where the NPS server is joined to the Corporate domain where the users are located. In case you want to use local NPS role on the Gateway server itself you need to establish two way trust. This is "by-design” for NPS server and is documented at http://technet.microsoft.com/en-us/library/dd197429(WS.10).aspx

    For RD Gateway, you can find this information on this blog: http://blogs.msdn.com/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx (Refer section 3.2).

    Thanks.

    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Joson Zhou Monday, November 1, 2010 8:00 AM
    Wednesday, October 27, 2010 9:23 AM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

    For the one way trust model that you are using, you need to deploy central NPS server (and not local NPS server for CAP policies which is the default setting) where the NPS server is joined to the Corporate domain where the users are located. In case you want to use local NPS role on the Gateway server itself you need to establish two way trust. This is "by-design” for NPS server and is documented at http://technet.microsoft.com/en-us/library/dd197429(WS.10).aspx

    For RD Gateway, you can find this information on this blog: http://blogs.msdn.com/rds/archive/2009/07/31/rd-gateway-deployment-in-a-perimeter-network-firewall-rules.aspx (Refer section 3.2).

    Thanks.

    This posting is provided "AS IS" with no warranties, and confers no rights. Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
    • Marked as answer by Joson Zhou Monday, November 1, 2010 8:00 AM
    Wednesday, October 27, 2010 9:23 AM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Thanks for your reply Jason,

    I though that may be the case. I am not sure how willing will the admins of the corporate domain be to do this for me.

    Thanks for you advice!!!

     

    Monday, November 1, 2010 2:14 AM
  • Question
    Sign in to vote
    0
    Sign in to vote
    We have since established a two way trust and everything is now working great.
    Thursday, March 3, 2011 4:38 AM