APM Access Policy - Pass LDAP or AD Query variable
Is it possible to query whether a user has a value for one or another variable then use that to pass or fail passage down the rest of the swimlane for access? (e.g.-expr {[mcget {session.ad.session.ad.last.attr.variable1}] != 0 || [mcget {session.ad.session.ad.last.attr.variable2}] != 0} where the two variables are numbers or a non-constant string, but do have a value...and are not "<not set>". Is it also possible to have another path where the lack of a value for theexpr {[mcget {session.ad.session.ad.last.attr.variable1}] == 0, can be sent to a uri or url? Any assistance would be greatly appreciated!
AD password expired check in Active Directory Query
Hello i'm facing this issue and I could only find this solution. Solved: AD password expired - DevCentral (f5.com) For our flow is impossible to apply the same solution as we need to do that check almost at the end of the flow after dozen of other checks. In the post is a link related with another possibility if "pwdLastSet" + "Max-Pwd-Age" >= "now" "password is expired" How can we translate this into the expr ? expr {[mcget {session.logon.last.pwdLastSet +session.logon.last.maxPwdAge}] equals session.logon.last.LastLogonTimeStamp } Is this expr correct ? Kind regardsAD query for a user from a trusted domain (forest trust)
Hi! Been trying to solve this for a while, but can´t find how to do this... I have seen similar questions on the forum without response, maybe this time is the one! I have two domains, domain A and domain B. Domain A is configured to trust Domain B. Also, users from domain B belongs to some AD groups on domain A. I have setup an access policy, where users from domain A authenticate against domain A, and users from domain B authenticates agains domain B (two different AAA servers). This is working fine. My question is: How can I check the group membership of domain A groups for a user from domain B? I need to make a query to domain A asking the "memberOf" attr for a trusted user which is originally from domain B. If I try to do this, que AD Query does not found the user, as the CN, sAMAccountName, SID, and GUID for the domaing B user are not the same in domain A. Any ideas on how to achieve this? Regards, Gerar
get AD password using AD query
hi, im currently working on a apm setup, where the customer has different 2FA's depending on group membership. Im struggling to get SSO to work on one of them, as they only validate using username+token. Is there a way to use AD query to get the password, populate a variable assign, and use this for SSO?
F5 APM AD Query is failing for users having long username
Hi I have a running setup of LTM+APM+ASM in order load balance and secure the various application including Microsoft Exchange 2013. I have configured Two factor authentication for all the application access with Active Directory followed by OTP (SMS Gateway is using to deliver OTP) Now I found a strange issue on F5 that users having a long username (let say more than 20 Character) failing to do AD Query. in APM Logs it shows AD Auth is successful where as AD Query is failing as shown in below. Feb 2 18:19:47 bigip notice apd[6329]: 01490010:5: 6f817c66: Username 'abc12345678901234567890' Feb 2 18:19:47 bigip info apd[6329]: 01490004:6: 6f817c66: Executed agent '/Common/AMM_AD_1_act_logon_page_ag', return value 0 Feb 2 18:19:47 bigip info apd[6329]: 01490006:6: 6f817c66: Following rule 'fallback' from item 'Logon Page' to item 'AD Auth' Feb 2 18:19:47 bigip info apd[6329]: 01490017:6: 6f817c66: AD agent: Auth (logon attempt:0): authenticate with 'abc12345678901234567890' successful Feb 2 18:19:47 bigip info apd[6329]: 01490004:6: 6f817c66: Executed agent '/Common/AMM_AD_1_act_active_directory_auth_ag', return value 0 Feb 2 18:19:47 bigip info apd[6329]: 01490006:6: 6f817c66: Following rule 'Successful' from item 'AD Auth' to item 'AD Query' Feb 2 18:19:48 bigip err apd[6329]: 01490107:3: 6f817c66: AD module: query with 'sAMAccountName=abc12345678901234567890' failed: no matching user found with filter sAMAccountName=abc12345678901234567890 (-1) Feb 2 18:19:48 bigip info apd[6329]: 01490019:6: 6f817c66: AD agent: Query: query with 'sAMAccountName=abc12345678901234567890' failed Feb 2 18:19:48 bigip info apd[6329]: 01490004:6: 6f817c66: Executed agent '/Common/AMM_AD_1_act_active_directory_query_ag', return value 0 Feb 2 18:19:48 bigip notice apd[6329]: 01490005:5: 6f817c66: Following rule 'fallback' from item 'AD Query' to ending 'Deny' What I noticed that Users having a username with with up-to 20 charterer is able to login and access the application without any problem and if the username is more than 20 Character its failing. We have a multiple users having a long username, if any one can help to resolve/Advice on this that would be highly appreciated.
APM Posture Assessment Slow - Checking Client hangs
Hi, We utilize APM to secure one of our Apps based on AD lookups. Here's how the policy works: Windows Info, to capture the computer name. Then an iRule event that takes the computer name and sets it static to our domain. Finally an AD lookup based on defined list of allowed OUs. The problem is often times computers hang at the "checking for client" screen for up to 20 seconds. Then the posture itself takes another 10. Is there any way to speed this up or what to look for? We do not use the full blown edge client but, the "BIG-IP Edge Client Components" almost like a soft client. Our DCs used to query are not over utilized by any means. This is affecting users with all resources local to them. I understand there are many outside variables that could impact this. Questions: How exactly how the F5 interact with the clients and initiate connectivity? Would switching to the full client have any impact? Should we add a dedicate DC to use for lookups? Any other help would be appreciated.APM AD Query Branch Rules
Hi, We're attempting to setup APM AD query branch rules using OU. Our details looks like this (sanitized a little): CN=username,OU=IT,OU=Departments,OU=Office,DC=domain,DC=com The default string provided is: CN=MY_GROUP, CN=Users, DC=MY_DOMAIN Is there an issue with using OUs? As we can't seem to get it to work. Also we've created the AAA AD server object and supplied it with credentials. However, is there anyway to actually verify this piece is working standalone?