We are currently evaluating how to setup a bigIP running LTM and APM for the following environment:
a lot of customer server networks (1000+) "behind" the bigIP. Each one of those contains:
one or more (up to about ten) client IP-ranges (remote sites) per customer. Those IP-ranges are unique and being connected via VPN (terminated externally, not on the BigIP itself)
one single public facing virtual for all customers to connect to their ICA server(s)
customers must login to a central landing page (provided by APM) using a user name 'user@customer-domain' and password
that user/pw must be authenticated against the right customer-specific AD forest. Hence, the proper AAA server must be selected in accordance to the entered domain
additionally, authentication against the customer-specific AD must only be allowed from the customer-specific client IP-ranges (sort of second factor). Clients of one customer must not be allowed to perform AD auth against another customer's servers, even if they type in the other customer's domain correctly.
In a testing scenario, we already managed to exctract the domain from the entered user@domain field, derive the right AAA server from that and perform AD auth against the right AD. We tested this with four "customers" and it works so far. This policy was built using the VPE.
However, when thinking about deploying this in production for 1000+ customers, some doubtful thoughts arise:
Because of those doubts, we have thought about some other ways to address that:
deploy one public facing virtual per client net (with specific source IP) and have each group of virtuals (several source nets per client = several virtuals per customer) use a customer-specific policy. Although that is supposed to be better in terms of performance and statistics (stats per customer site), it will leave us with thousands of virtuals and thousands of APM policies, which is even more confusing (although each policy by itself will be much easier in terms of number of branches).
insert an iRule (or two) into the policy that will lookup two data groups:
Thus, it might be possible to present a customer-specific landing page (because the customer was already identified by the client subnet) with the proper domain being pre-populated in the login mask. Also, adding new customers will be easy as it means adding lines to the data groups only. And I suppose, in terms of confusion and performance, this is probably the best way to do it.
BUT... because my knowledge in terms of APM is quite limited (read: nearly zero), I need some advise here. Is setup #2 possible? How would the according iRule(s) and access policy look like? What do you think about performance?
Any hints are welcome. Many thanks in advance.
Any ideas? Anybody?
That a quite complex subject.
on the performance side, the only big configuration will be your datagroups and they are made for that so no big deal.
now you need to try and test in an irule if you can set the AAA ip address with a ACCESS::session mcset command somehow, a good example is assigning dynamically microsoft rdp server destination address, in this example you can replace the destination address by a session variable.
i'll try it.
Arnaud, thanks for your reply. You are referring to an example of "assigning dynamically microsoft rdp server destination address". I couldn't succeed in finding that anywhere around here, though... Can you provide a link?
something like this i believe