Hello All: Been running Apache since 1996, so I know my way around. However this has me stumped. Our LDAP team recently brought to my attention that my primary webserver has been making NUMEROUS searches to our LDAP farm, and wanted me to investigate. Not to flood this post with every 'lsof -Pi' entry, but ALL 270 httpd children have established a connection to the LDAP farm, similar to httpd 5812 daemon 211u IPv4 739383096 TCP WEBfarm:44900->LDAPfarm:11389 (ESTABLISHED) Normally, I wouldnt think it odd that Apache calls LDAP since I have mod_authnz_ldap.c compiled in, but the LDAP farm logs show that the lookup against 'daemon' which is the account running Apache: (Sensitive data NULLed out) [01/Oct/2014:10:52:38 -0400] conn=989732 op=-1 msgId=-1 - fd=321 slot=321 LDAP connection from 155.xxx.xxx.xxx:39925 to 155.yyy.yyy.yyy [01/Oct/2014:10:52:38 -0400] conn=989732 op=0 msgId=1 - BIND dn="cn=NULL,ou=NULL,dc=NULL,dc=NULL" method=128 version=3 [01/Oct/2014:10:52:38 -0400] conn=989732 op=0 msgId=1 - RESULT err=0 tag=97 nentries=0 etime=0 dn="cn=NULL,ou=NULL,dc=NULL,dc=NULL" [01/Oct/2014:10:52:38 -0400] conn=989732 op=1 msgId=2 - SRCH base="dc=NULL,dc=NULL" scope=2 filter="(&(objectClass=posixAccount)(uid=daemon))" attrs=ALL [01/Oct/2014:10:52:38 -0400] conn=989732 op=1 msgId=2 - RESULT err=0 tag=101 nentries=0 etime=0 [01/Oct/2014:10:52:38 -0400] conn=989732 op=2 msgId=3 - SRCH base="dc=NULL,dc=NULL" scope=2 filter="(&(objectClass=posixGroup)(memberUid=daemon))" attrs="gidNumber" [01/Oct/2014:10:52:38 -0400] conn=989732 op=2 msgId=3 - RESULT err=0 tag=101 nentries=0 etime=0 It's as if the 'daemon' user is trying to verify its own existence. The Apache logs do not show any outgoing requests to the LDAP farm. I even enabled logging for LDAP on my side, but there's no HTTP information in those local LDAP logs. Nothing in Apache is dynamically loaded and there's nothing in (VERY LARGE) httpd.conf that explictly calls the LDAP farm. Compiled in modules: core.c http_core.c mod_actions.c mod_alias.c mod_asis.c mod_auth_basic.c mod_auth_digest.c mod_authn_alias.c mod_authn_anon.c mod_authn_dbd.c mod_authn_dbm.c mod_authn_default.c mod_authn_file.c mod_authnz_ldap.c mod_authz_dbm.c mod_authz_default.c mod_authz_groupfile.c mod_authz_host.c mod_authz_owner.c mod_authz_user.c mod_autoindex.c mod_cache.c mod_cgi.c mod_charset_lite.c mod_dav.c mod_dav_fs.c mod_dav_lock.c mod_dbd.c mod_dir.c mod_disk_cache.c mod_env.c mod_expires.c mod_file_cache.c mod_filter.c mod_headers.c mod_include.c mod_info.c mod_log_config.c mod_log_forensic.c mod_logio.c mod_mem_cache.c mod_mime.c mod_mime_magic.c mod_negotiation.c mod_proxy_ajp.c mod_proxy_balancer.c mod_proxy.c mod_proxy_ftp.c mod_proxy_http.c mod_proxy_scgi.c mod_rewrite.c mod_setenvif.c mod_so.c mod_speling.c mod_ssl.c mod_status.c mod_unique_id.c mod_usertrack.c mod_version.c mod_vhost_alias.c prefork.c util_ldap.c I think the problem might be more related to /etc/ldap.conf, but I want to rule out Apache outright. Any insight would be greatly appriciated! Thanks! Mr. S.A. Birl --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscribe@xxxxxxxxxxxxxxxx For additional commands, e-mail: users-help@xxxxxxxxxxxxxxxx
|