This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

User authentication for web proxy not working from Terminal Server

I have been running for a while with Transparent mode. Recently needed to separate VIP's from Mere Mortals for Web Surfing, so thanks to Bob's excellent guide, I got AD Authentication and HTTP/S Profiles setup and enforced use of the proxy with Group Policy on the Windows 2003 Server. Using an ASG 120 with 7.509

User's from their desktops seem to be authenticating correctly (although in the web log I see something like user="Mere Mortal" Filter Action=(VIP), when it should say "Default Filter Action") but it seems to be working, Mere Mortals cannot open social media sites and VIP's can.

EXCEPT, when logging into the Terminal Server. There a VIP still cannot open Facebook. The HTTP log shows User="" so it seems like the user id is not being passed from the Terminal Server. 

Is there any fix for this?


This thread was automatically locked due to age.
Parents
  • OK, things I learned:
    1: Thanks to Larry at Astaro, I now understand that since I only have 1 network accessing the proxy, I only need 1 profile. Bob, you may want to put that in BOLD in the FAQ, so noobs like me don't get confused. Here is Larry's explanation:
    "If both profiles use the same Networks in the Allowed networks, then which ever one is first in the list of proxy profiles will be applied. I'm guessing each separate profile has a different group tied to it via the Filter Assignment section. If you enable both filter assignments under the first profile, then the Astaro will apply the Assignment based on the user name, and any others not in one of the two groups will fall under the fallback action."
    2: In order for Terminal Server to pass the userid to the proxy, the Operational Mode on the Global tab of HTTP/S must be set to Active Directory SSO (or some authenticated mode). I had Transparent Mode set there. Local Users were authenticating to the proxy, but TS users were not.
    3: I enforced the use of the proxy using Windows Server Group Policy on the container with userid's (THis is not the standard Users container in my case). However, I found out that if a domain administrator logged onto the TS, the proxy was not enforced. If a regular user did, it was. I corrected this by setting the same Group Policy on the container for the Terminal Server (In my case the TS Server is in its own container for loop back policy reasons).
    4: Be careful not to lock yourself out of the webadmin interface, it must be exempted from the proxy.
Reply
  • OK, things I learned:
    1: Thanks to Larry at Astaro, I now understand that since I only have 1 network accessing the proxy, I only need 1 profile. Bob, you may want to put that in BOLD in the FAQ, so noobs like me don't get confused. Here is Larry's explanation:
    "If both profiles use the same Networks in the Allowed networks, then which ever one is first in the list of proxy profiles will be applied. I'm guessing each separate profile has a different group tied to it via the Filter Assignment section. If you enable both filter assignments under the first profile, then the Astaro will apply the Assignment based on the user name, and any others not in one of the two groups will fall under the fallback action."
    2: In order for Terminal Server to pass the userid to the proxy, the Operational Mode on the Global tab of HTTP/S must be set to Active Directory SSO (or some authenticated mode). I had Transparent Mode set there. Local Users were authenticating to the proxy, but TS users were not.
    3: I enforced the use of the proxy using Windows Server Group Policy on the container with userid's (THis is not the standard Users container in my case). However, I found out that if a domain administrator logged onto the TS, the proxy was not enforced. If a regular user did, it was. I corrected this by setting the same Group Policy on the container for the Terminal Server (In my case the TS Server is in its own container for loop back policy reasons).
    4: Be careful not to lock yourself out of the webadmin interface, it must be exempted from the proxy.
Children
No Data