Hi,
I am trying to replicate Microsoft FTMG firewall functionality (found in other products working as forward proxy as well) to use AD group membership to allow or deny traffic.
In FTMG wh...
Well, problem is that it should be transparent, based on user credentials when logging to domain on given workstation.
Without this I guess task is not so complicated 😞
Your iRule seems to be based on LocalDB - so if I am not wrong if I need to use any group from AD it would be necessary to replicate AD structure to BIG-IP. Sure I can create Access Policy using AD Auth and AD Query but still not very easy to manage.
I was thinking about using table but rather in connection with ifmap VS. This VS is receiving IP-username updates each time user is logging in/logging out of domain (via for exaple F5 LogonAgent). So I could parse SOAP messages received by this VS and update table containing IP-username mapping. Problem is I am not to good with iRules and parsing SOAP messages seems to be a bit complicated.
Access Policy way seems to be easier, only drawback I can see is performance. I assume that table lookup would be much faster that evaluating policy - but maybe not so much?
I wonder what do you think about this kind of iRule - one I mentioned before
when FLOW_INIT {
set flow_sid [ACCESS::session create -timeout 600 -lifetime 3600]
ACCESS::policy evaluate -sid $flow_sid -profile /Common/irule_transparent_user_id session.user.clientip [IP::client_addr]
Check the outcome of the access policy evaluation. Throw a response based on what we learn.
switch [ACCESS::policy result -sid $flow_sid] {
"allow" {
log local0.notice "Allow"
}
"deny" {
log local0.notice "Deny"
ACL::action reset
}
default {
log local0.notice "Default"
}
}
}
Then Access Policy is build like that:
With such approach everything can be mananged via VPE. I guess that using FLOW_INIT should be better considering performance - 3WHS and TMM processing should be avoided?
Problem is that:
It's not easily managed - you can't see alowed/denied user groups in AFM Rule
AFM logging is messed up - when access is Allowed (not ACL::action reject set in iRule) log entry is OK, when ACL::action reject is used there is no entry in AFM log at all