Forum Discussion
Nova_201357
Nimbostratus
NimbostratusAPM Dynamic ACL assignment from AD
Greetings!
I had a static ACL applied to a Network Access Resource. In testing static assignment, it worked fine. So I took the same logic and formatted as a F5 ACL, put it in AD, in the test account's "info" attribute.
Using my test client, and viewing the debug logs, it seems to load the ACL (as HEX encoded which seems a little weird) but clearly isn't working. The test client can access any resources it can route to.
I tried :
- to send the entire list as a "one liner" and it wouldn't load.
- to set the list, one ACL per line using widows default line termination (cr/lf) and that didn't work (it loaded as Hex encoded though).
- to set the list, one ACL per line using Unix line termination (lf) and that ostensibly worked the same as number 2 above.
Question: Has anyone done this?
The ACL looks like this:
{ allow tcp any 10.100.32.15:3389 }
{ allow tcp any 10.100.32.15:80 }
{ allow tcp any 10.100.32.15:443 }
{ allow udp any 10.100.1.84:53 }
{ allow udp any 10.100.1.85:53 }
{ deny ip any any }
The goal is to allow remote web developers access to a workstation over RDP and connect to web services they use for testing their work. What am I doing wrong?
Thanks for any pointers.
Mike
Brad_ParkerCirrus
In my experience it needs to be a single line entry, not multi-line to work. You also can't put spaces between the rules. When you format it like this, does it load? What kind of error do you get if it doesn't? What does the APM log look like for the session? Also, you can look at the built acl with sessiondump -list
{ allow tcp any 10.100.32.15:3389 }{ allow tcp any 10.100.32.15:80 }{ allow tcp any 10.100.32.15:443 }{ allow udp any 10.100.1.84:53 }{ allow udp any 10.100.1.85:53 }{ deny ip any any }
Nova_201357Hi Brad,
Thanks for chiming in. I tried a single line acl, but it still didn't work. The other thing I did see is that I had a mistake above; "deny" should be reject or discard. So I did change deny to reject, but that didn't do it either.
Should the acl be in straight ASCII? Because what I see in the log is HEX encoded and I'm not sure what that's about.
The ACL looks like this:
8e132485.session.ad.last.attr.info 394 0x7b20616c6c6f772074637020616e792031302e3130302e33322e31353a33333839207d0a7b20616c6c6f772074637020616e792031302e3130302e33322e31353a3830207d0a7b20616c6c6f772074637020616e792031302e3130302e33322e31353a343433207d0a7b20616c6c6f772075647020616e792031302e3130302e312e38343a3533207d0a7b20616c6c6f772075647020616e792031302e3130302e312e38353a3533207d0a7b2072656a65637420697020616e7920616e7920616e79207dIf you were to decode it, you'd get the acl. I thought it would be something you could easily read. I might just delete it and drop it in again with less ACEs for testing. Any other thoughts?
Thanks, Mike
- Nova_201357
Hey there,
So for anyone who tried this, Brad is right. The ACL must be a single string with all the ACEs concatenated together. In my case, I had to clear out the AD attribute and paste the properly formatted ACL for it to work.
Thanks for the tips Brad!
BTW, F5 should consider documenting things like that!
Cheers, Mike
- Where do you think the best place would be to document it? This question comes up sometimes when people put characters like CRLF, or other things that don't translate well to session variables which are plain one-line ascii. In that case, it's auto-transformed to hex encoding.
- Walter_Kacynsk1I would settle on the fact to document how Dynamic ACLs should be represented in AD/LDAP within the product documentation. Information on these are scarce to say the least. However their power is great in that group management is already externalized, so it would make sense to pair the ACLs with the group assignments.
- Nova_201357I'd update this: https://support.f5.com/kb/en-us/products/big-ip_apm/manuals/product/apm-implementations-11-5-0/2.htmlconceptid Just add a caveat or a link to a sol doc that goes into greater detail. Thanks, Mike
