Forum Discussion
NimbostratusAPM LDAP Query Failure - not using fallback
I running an LDAP query in a policy that is performing
return [mcget {session.ldap.last.attr.userPrincipalName}]
I know this is working for known UPNs, but I'm not catching the exceptions and taking the fallback path.
I've noticed that even upon query failure the policy is not using the fallback path even when the last.errmsg is "No such object" and the query result is "0" - the policy continues to the variable assign, which it should only perform when a UPN is matched.
Any suggestions?
youssef1Cumulonimbus
Hello.
In your ldap query validate the following point:
-
in your ldap query object you add the following attribute "
", in "userPrincipalName
".Required Attributes (optional) -
second point, in branch rules, be sure that you modified expression from:
Expression: User is a member of CN=MY_GROUP, CN=USERS, CN=MY_DOMAINto
Expression: LDAP Query has PassedKeep me in touch.
regards
-
eric_haupt1Ok - I shifted the logic. The input for the query is taken care of in the filter.
So for my success branch I use
expr { [mcget {session.ldap.last.queryresult}] == 1 } and getting the expected results: LDAP query is good based on valid filter input = success LDAP query fails based on input not found (no such object) = session.ldap.last.queryresult = 0 and fallback path is taken.- youssef1
normally you see error message generated for LDAP in session.ldap.last.errmsg (ex: aad2a221.ldap.last.errmsg) it is useful for troubleshooting.
You can also activate "Show Extended Error" in your ldap query.
you will see the error generated by ldap...
keep me in touch
- eric_haupt1
Yeah - I got so used to advanced query I forgot all about the built in basics.