User authentication for web proxy not working from Terminal Server

Do only VIP users have logon access to the terminal server?

Everybody can access the Terminal Server

I have a client that will need to know this, too, so I'm glad you asked!  What happens if a user logged in to the domain as JimB logs into the TS with a different username like JimBob?

Cheers - Bob
PS Ölm says this should work just the way you have it set up now.

If I am logged onto a member server as Administrator, and I RDP to the TS as myself, the result is the same. The URL log shows user="" and the Default Filter Action is applied. I have opened a support ticket and hope to get a resolution. I modified the Group Policy for the TS as suggested here Advanced Proxy add-on for IPCop and SmoothWall but it did not seem to make any difference.

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.

Thanks, Mike. [:)]

I don't remember discussing proxy profiles in a how-to.  Could you remind me where to find that? [:S]

Cheers - Bob

Sure, Bob. This FAQ is signed Bob at the bottom, so I assumed it was you. Your comments have been most helpful over the past 3 years as I have learned how to use the ASG's. Thanks, again.
https://support.astaro.com/support/index.php/User_Contributed:HTTP/S_Proxy_Access_with_AD-SSO

Yep, that was written by the same Bob, not to be confused with the guy who spells his name backwards...boB. ;P

You guys! [:D]

Yes, I wrote that based on personal experience and a lot of input from others here.

I think the following from the HTTP Profiles Guide is good:

If an HTTP request comes in, the HTTP proxy first determines which proxy profile must be applied.  This exclusively depends on the source IP address of the request. The first profile that matches the source IP of the request will be used. All other proxy profiles that may exist will be ignored.

It is then checked which filter assignment is associated with this proxy profile. If no filter assignment matches, the fallback action will be applied to the request. The fallback action is a special filter action that should reflect the security policy of your company. If you must adhere to a strict security policy, you could, for instance, create a filter action that completely blocks all web traffic.

If the source IP address does not match any proxy profile, the default profile will be applied. The default profile is not a profile to be explicitly configured on the Web Security >> HTTP Profiles tabs. Instead, the default profile is automatically created when you globally configure the HTTP proxy on the Web Security >> HTTP tabs. For example, the Allowed Networks on the Web Security >> HTTP >> Global tab correspond to the Source Networks of a proxy profile. The settings in the Users/Groups box (located on Web Security >> HTTP >> Global tab when  peration mode Basic User Authentication is selected) become the default filter assignment. And lastly, the settings on the Web Security >> HTTP >> Content Filter tab correspond to a filter action, which are configured on the Web Security >> HTTP Profiles >> Filter Actions tab. Finally, if not even the default profile matches, then the HTTP request will be blocked.

To provide different levels of protection for various users within the same network segment, you only need to configure one single proxy profile with different filter assignments associated. What is allowed for specific users is dependent on the order of the selected filter assignments. For that reason it does not make sense to configure two profiles with exactly the same source networks, as the second profile will never be used.

Cheers - Bob
PS And kudos to Mike for coming back and giving the rest of us an outline of what needs to be done - I'll use that, maybe even today!