Ole Bobakke wrote:

Both of them use the Cisco ACS to authenticate users, so at this point the same username can login to both SSL portals, this is no good :-(

Yup.

Then I tried to add a fortigate VSA to the Cisco ACS server, so when user pet@ompa.corp.com <mailto:pet@ompa.corp.com> login to https://tampa.corp.com , ACS server retun "Fortinet-Vdom-Name = ompa" to the fortigate, and I was looking forward to see the ompa portal but i got tampa. So Fortigate just ignore the VSA from the ACS .

Yes. The NAS usually ignores attributes it doesn't understand.

I did some sniffing, and it seems that *fortigate* return Fortinet-Vdom-Name= ompa when you use https://ompa.corp.com, and Fortinet-Vdom-Name= tampa when you use https://tampa.corp.com.

So we need to have some checking on the radiusserver, to verify user realm vs what fortigate retuns. Cisco ACS server doesn't support this type of checking.

All the more reason to use a real RADIUS server. :)

Now I have installed a freeradius and it does proxy towards the ACS from Fortigate FW, but I need some help to configure this checking, could rlm do this stuff?

if user pet@ompa.corp.com <mailto:pet@ompa.corp.com> login to tampa, and Fortigate return Fortinet-Vdom-Name= tampa it should *not* get access, but if it retun Fortinet-Vdom-Name= ompa it should get access.

Simple. Put this in the "authorize" section, after "suffix" if (Fortinet-Vdom-Name && (User-Name !~ /@%{Fortinet-Vdom-Name/)) { reject } Make sure the "if ... {" is all on one line. That should be simple to understand. If the Fortinet-Vdom-Name attribute exists, AND the User-Name entered by the user doesn't have "@", followed by the Fortinet-Vdom-Name, then reject the user. Alan DeKok.