Eric Covener replied: >That doesn't seem possible, as mod_authnz_ldap doesn't hook access_checker (and access_checker is before e.g. mod_auth_basic can even perform authn -- how can you do authz if you don't know who the user is?) And yet it moves...see log excerpt below... The only other possibility is that first ONLY the mod_authnz_ldap authorization mechanism is running--and failing, and only THEN my two mod_perl handlers [Access & Authen] run, followed by another invocation of the mod_authnz_ldap authorization routine--which would work, except for the first failure [ldap server bug, see below]. Is it possible that what I'm seeing is actually two passes through the AAA stack for one request? If so, why would this happen? I am looking at the debug logs, and [once the mod_ssl debug spew is done], I have... [time...] [info] Initial (No.1) HTTPS request received for child 0 (server servername:443) okay, we're in... [time...] [warn] [client address...] ldap authorize: Userid is blank, AuthType=(null) But--right away--we're already trying to run mod_authnz_ldap's authorization handler! [time...] [debug] mod_authnz_ldap.c(582) [client address...] ldap authorize: Creating LDAP req structure [time...] [debug] mod_authnz_ldap.c(582) [client address...] auth_ldap authorise: User DN not found, ldap_seach_ext_s() for user failed Unsurprisingly, it fails, as I haven't set the request->user(...), request->ap_auth_type(...), etc... [time...] [info] [client address...] AccessHandler: SSL_CLIENT_S_DN_CN = MyCN... Ah-ha! Now my access handler is running, great! [time...] [info] [client address...] AuthenHandler: SSL_CLIENT_S_DN_CN = MyCN... Followed by my authentication handler...no worries... [time...] [debug] mod_authnz_ldap.c(582) [client address...] ldap authorize: Creating LDAP req structure [time...] [debug] mod_authnz_ldap.c(582) [client address...] auth_ldap authorise: User DN not found, ldap_seach_ext_s() for user failed This pass through SHOULD work, right? Sadly, my directory administrator tells me that due to a bug in our LDAP server at this point my connection has been "scrogged" [his word] by the earlier invalid--and undesired--call from mod_authnz_ldap. If it helps, my config stanza looks like this: <Location "/ldap-status"> SSLOptions +StdEnvVars +OptRenegotiate SSLUserName HTTPS_CLIENT_S_DN SetHandler ldap-status AuthType Basic AuthName "Certificate Authentication" AuthzLDAP Authoritative off AuthLDAPURL "https://server/c=us?dn"; # Hack to force authorization hook to run; it short circuits if there is no Require ldap-* clause Require ldap-filter "cn=*" # May be redundant, as the filter expression will always work, assuming we find any user at all Require valid-user # both handlers set user name, set auth type, and spit out logging so we know where we are...theoretically I should only need one PerlAccessHandler ORG::AccessSSL PerlAuthenHandler ORG::AuthnSSL </Location> Warmly, --Pete --------------------------------------------------------------------- The official User-To-User support forum of the Apache HTTP Server Project. See <URL:http://httpd.apache.org/userslist.html> for more info. To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx " from the digest: users-digest-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|