On 7/12/2011 9:44 p.m., Eugene M. Zheganin wrote:
Hi.
I'm using the squid_ldap_group external ACL to control AD users access
to the Internet.
Recently I got a problem: on some machines squid_ldap_group gives
false negative result.
Consider using emz is a member of 'Internet Users - Crystal' (and ofc
he's never removed).
It looks like:
===Cut===
2011/12/06 13:49:30.255| ACLChecklist::preCheck: 0x802797a18 checking
'http_access allow ad-internet-users'
2011/12/06 13:49:30.255| ACLList::matches: checking ad-internet-users
2011/12/06 13:49:30.255| ACL::checklistMatches: checking
'ad-internet-users'
2011/12/06 13:49:30.255| aclMatchExternal: ldap_group("emz
Internet%20Users%20-%20Crystal") = lookup needed
2011/12/06 13:49:30.255| aclMatchExternal: "emz
Internet%20Users%20-%20Crystal": entry=@0, age=0
2011/12/06 13:49:30.255| aclMatchExternal: "emz
Internet%20Users%20-%20Crystal": queueing a call.
2011/12/06 13:49:30.255| aclMatchExternal: "emz
Internet%20Users%20-%20Crystal": return -1.
2011/12/06 13:49:30.255| ACL::ChecklistMatches: result for
'ad-internet-users' is -1
Expected result if the helper does not have an immediate answer in its
cache from an earlier lookup.
2011/12/06 13:49:30.255| ACLList::matches: result is false
Fine. false here only means non-success.
2011/12/06 13:49:30.255| aclmatchAclList: 0x802797a18 returning false
(AND list entry failed to match)
Minor bug, the bracketed () message is wrong about the state. It is
actually still waiting for the lookup to complete.
What you should find is that some unknown time later (helper response
delay, maybe up to 50-100 milliseconds?) you get another mention of
testing checklist 0x802797a18. That will have a second allow/skip action
response to this test followed by any continuing steps the ACL lookups
may have done.
Amos
