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 [email protected] <mailto:[email protected]> 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 [email protected] <mailto:[email protected]> 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. - List info/subscribe/unsubscribe? See http://www.freeradius.org/list/users.html
