Adding 2nd Domain to SSO / Web Proxy

If it's not even working at all now, with the original configuration (did you restore a backup, or just try setting things back from memory?) ... you may want to revisit Astaro Support... they can have you turn on debug options that will shed some light on why users aren't authenticating at all now.

If you are on version 8.201, you may want to try the patch that Astaro has issued that corrects a number of issues with tht HTTP proxy (fair warning, I have not tested this patch myself, as my customers remain on Version 8.103 for now, just applied it to a test system today -- see https://support.astaro.com/support/index.php/HTTP_Proxy_Issues_after_8201 ).  I don't know that the patch would affect your particular issue, but it's something to try if you are on 8.201.

If you have not updated to the 8.2xx branch yet, I don't recommend that you do, but make sure you are running at least 8.103.

Oh... .looked at your OP ... I guess you're still on 7.509 ... you may want to try updating to 7.511, though I don't remember there being any SSO issues resolved by anything in 7.510 and 7.511 -- all of my managed customers are on the 8.103 platform currently.  I do recall wierd issues on domains running W2K8 or W2K8R2 with the 7.5xx (and earlier) versions, so updating to 8.103 may be something worth trying as well.

Just an FYI; the difference between using FQDN or an IP in your IE browser Proxy settings, when used with AD SSO, is that the browser will try Kerberos if you use a FQDN, and NTLM if you set an IP.

I'm still running 7.509. The proxy has been running fine for a couple of months, even after I added the second domain the local domain users were authenticating properly. When I bounced the http/s service it suddenly stopped. If I update to v 8 do I have to update all 4 asg units at the same time? Any problems with site2site vpn when they are on different major releases? I read some early reports about v 8 being a memory hog, these units are all running 70 80 % RAM most of the time anyway.

Immediate plan is to restart unit this evening, then turn on sso/https profiles. If that doesn't work, I will restore a backup.

You may just need to reboot the box, or restart the AUA daemon...  I have had that work on occasion -- iirc, stopping the httpproxy and the aua daemon, then restarting one or the other first, was the way to get it going again -- this was back when I was dealing with a wierd Kerberos issue at a customer site, and couldn't wait on a reboot -- a reboot would certainly work.

As for your questions regarding V8 and V7:

1) I take one thing back concerning what I said in an earlier post; I do have one managed customer that still has 7.511 at their main site, with the remote 110 units running 8.103 (about 6) all connected with IPSEC tunnels, interoperability is fine between 7 and 8 regarding VPN tunnels -- I have other customers that during the big upgrade phase worked fine with differing versions existing at different sites, etc.

2)  Version 8 does have a bigger RAM footprint than 7;  1GB is a minimum for the 220 and 110/120 appliances (I know one of our other friends will post and say Version 8 is worthless on a 1GB appliance -- not true, I have many customers that we upgraded with success; yes, swap is higher, but the infrequently used processes are what are swapped out).  If you are at 80 or 90 percent utilization with an appliance that has 1GB in it now, it's probably undersized, time for an upgrade.  If you are running older 110/120/220 appliances that have only 512MB in them, you need to upgrade them (replacement) before going to Version 8.

As far as my recommendations for updating to the Version 8 platform:

1) Know that all logs and reporting (other than the anti-spam DB and queued / quarantined items) will be deleted during the V7 to V8 upgrade phase
2) I'd update all devices to Version 7.511 before attempting an up2date to the Version 8 Firmware.
3) After the devices update to the Major V8 Version, I'd get the devices up2dated to Version 8.103, and hold there until the 8.2xx branch stabilizes
4) I do not recommend installing V8 on any device with less than 1GB of RAM (and neither does Astaro, for that matter).

I upgraded the boxes less than 2 years ago and they came maxed at 1 GB (Why didn't Astaro make more RAM available then?). The branches are pretty small, only about 14 people over 3 branches connected to the ASG220 site via vpn. Everyone is mostly doing remote desktop to the winserv2003 terminal server. but of course there is email, printing, internet, and some file transfers. But it doen't seem like they should be undersized.
It's easy to restart the http/s daemon, but where to you restart the authentication daemon?

Could you please post the logs?? 
one thing to notice when you change the user group try to flush the authentication cache and wait for three or four minutes.

I upgraded the boxes less than 2 years ago and they came maxed at 1 GB (Why didn't Astaro make more RAM available then?). The branches are pretty small, only about 14 people over 3 branches connected to the ASG220 site via vpn. Everyone is mostly doing remote desktop to the winserv2003 terminal server. but of course there is email, printing, internet, and some file transfers. But it doen't seem like they should be undersized.
It's easy to restart the http/s daemon, but where to you restart the authentication daemon?

Going to /var/aua and running ./aua.bin stop and ./aua.bin start seem to work, but I can't guarantee it won't throw your system for a loop ... I think there used to be a script in /var/mdw/scripts/ that would do the job, but I don't see it on our 8.201 testbed.

Ok, here is the log for the http content filter. The user "vicki" is logged onto the remote CHG domain and her pc is a member of the CHG domain (calcohotard.com). But she appears to be authenticating on the ASG as "vicki" from the local domain (calcotravel.com) because the filter action applied is "webusers" and the filter action that would be applied to her as a member of the "CHG AD DefaultWeb" user group is "CHG Default Web"

There is no real difference in the filter actions, I am using vicki as the test case before some of the vip's get special access.

FYI: Upgraded to 7.511 last night and restarted the ASG and the proxy resumed authentication.

just for test can you remove "vicki" from the group of the first domain and see if it will recognize her as member of the remote domain?

OK. I deleted the user vicki from the ASG120 and I removed her from the Webusers group on the local domain. I rebooted her PC just to refresh the credentials. The live log still shows user="vicki" but now she is getting the Default Filter Action, so she is not authenticating to the remote domain.

Just for fun I thought I would try pre-fetch authentication against the local ad group for the remote user the way techuser suggested. The live log shows that it finds the ad group I created, recognizes that the user id is a foreignsecurityprinciple and conducts an ldap search against the foreignsecurityprinciple folder with vicki's correct 40 digit sid. I can see the sid in the folder with advanced view. But pre-fetch then says no user found. Also for fun, I created a server for the CHG domain controller under Users/Authentication and tested the bind and the base and both passed, so authentication to the second domain is possible, but for some reason not happening.