i was setting up a z3 app with a pau utility, and noticed some strange behavior, which tracked down to, the PluggableAuthentication's getPrincipal method, source below. def getPrincipal(self, id): if not id.startswith(self.prefix): next = queryNextUtility(self, IAuthentication) if next is None: raise PrincipalLookupError(id) return next.getPrincipal(id) id = id[len(self.prefix):] for name, authplugin in self.getAuthenticatorPlugins(): info = authplugin.principalInfo(id) if info is None: continue info.credentialsPlugin = None info.authenticatorPlugin = authplugin principal = interfaces.IFoundPrincipalFactory(info)(self) principal.id = self.prefix + info.id return principal next = queryNextUtility(self, IAuthentication) if next is not None: return next.getPrincipal(self.prefix + id) raise PrincipalLookupError(id) i had setup a local site with a pau with a prefix and an ldap auth, lookups for common groups like zope.EveryBody, zope.Authenticated, would in turn call queryNextUtility. however instead of returning the global site manager's principal registry, it would fail in the utility lookup. digging deeper, the queryNextUtility call is passing in a context of the authentication utility itself, which looks like a throwback to the older IComponentLookup adaptation, instead of the current thread local site manager with bases, thats currently used. When the auth utility is passed to queryNextUtility, the default site manager whose bases are queried is the global site manager, resulting in no utility found. Where as passing context none, gives the expected behavior, of looking up the current local site's bases for the auth utility in the global site manager. it appears to me, that this is a throwback/missed refactoring from jim's merge of the component registry refactoring.. can anyone confirm the analysis and the bug? this pattern is present in multiple places in pluggable auth utility implementation, and also, zope.app.security/zope/app/security/vocabulary.py:219 cheers, kapil