This relates to a migration from 3.8 to 4G. The 3.8 implementation has a simple sequence of 2 LDAP policies in succession that need to be duplicated in 4G, using the 4G Ldap Policy. The Ldap being used is Active Directory, and the users being challenged are from the Runtime stream (*not* administrators).
The first Ldap policy executes an authentication, both 3.8 and 4G policies operate similarly. The second Ldap policy executes an authorization, searching a specified cn name (a group id) for membership by the user. In the 3.8 case, searching for a member in a bogus group will generate a failure in the policy and set a variable that is queried for logging. Any users not in the specified group are permitted to complete the request, but they are logged as being *not in the group*. I.e., the Search is successful, but returns a null result set that can be queried in the flow.
In 4G, the search also succeeds, however, but there is no indication of a null result set. Nothing shows up in any variables, which could then be used to trigger the appropriate logging.
Thank you for your help
@Terry David Can you copy your ldap policy that does the search in 4G ?
Is the ldap.$policyname.execution.success = true even in case of null result set ?
If you know what attributes you get when your result set is !null and check for that attribute in case of null result set ?
1. Yes, that is correct.
2. The attributes fields return empty.
@Maruti Chand check out SECENG-330. Yes, "ldap.$policyname.execution.success = true" is the actual case. I will post final resolution here. TFTH.
Hello @Terry David,
Is this still a problem for you? Have you been able to look into Maruti's suggestions? Please let us know if this has been resolved or if you need more help.
My current understanding is that is a bug that is being worked.
User | Count |
---|---|
7 | |
2 | |
2 | |
1 | |
1 |