CUC (6) CUCM (28) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (3)

Tuesday, 7 August 2018

F5 webtop access policy and resource assignment configuration

F5 webtops can be used to provide 3rd party portal access into your network. A webtop is essentially nothing more that a very fancy VIP hosted on the F5 appliance itself. You can do 2FA authentication (see my previous post), you can customise the look and feel of the portal for instance by sticking your company's logo in it. but that is all cosmetic.  The real smarts of a webtop, lie within the access profile, or better the access profiles' access policy.

So lets get started, go to the access profile associated with your webtop ACCESS POLICY > ACCESS PROFILES > ACCESS PROFILES LIST,  then go to the visual policy editor (see below).

Fig. 1 - Access Profile on F5

As you can see in the screenshot of the visual policy editor below,  there are two main threads, one for staff access and one for vendor access (discrimination done on the basis of AD group).

Fig.2.- Visual Policy editor

I would like to focus on the vendor access, so after 2FA has taken place and it has been established, based on the user's AD group member ship, that the user is a vendor, how can we assign certain resources/access methods to this user and can we differentiate between vendors.  To answer this. let me drill into the "Vendor Resource Assign" element in Fig 2. visual policy editor.

Fig, 3 shows the resource assignment screen in detail

Fig. 3 resource assignment detail visual policy editor
in this example there are 3 vendor groups, each with their own resources, they have access to once successfully authenticated through 2FA. these 3 groups all have their own AD group. (see Expression user is a member of CN=blahblah). These 3 vendors/AD groups each have their own resources assigned to them (app tunnels and Remote Desktops). These are all individual resources, i,e, they only connect to a single IP address.  For instance the RDP resource called "EXEC", that gets assigned to the first AD group "networks" is defined as follows:

Fig.4.-Remote Desk top details
so this remote desktop only allows access to 10.x.y.17.  This is all good and well if your vendor only requires access to a limited amount of IP addresses, but it quickly gets out of hand if access to dozens if not hundreds of IP addresses is required.

Figure 5 shows a wildcard destination IP address, using % as the host name (pre populating last IP address logged into).

Fig. 5- multiple IP RDP access

Of course this would gives no control over what gets access and what not. So you would need to put an ACL in places.  Fig. 3 shows you can add a static ACL to the AD group's resource assignment. Fig. 6 show the "vendor_access" ACL that gets assigned to all vendors. which restricts access to only 2 subnets, in this case. 

Fig. 6 User defined ACLs

No comments:

Post a Comment