You are viewing a plain text version of this content. The canonical link for it is here.

Posted to bugs@httpd.apache.org by bu...@apache.org on 2010/07/21 21:03:58 UTC

DO NOT REPLY [Bug 49632] New: mod_authnz_ldap denies users when search is performed at AD root.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49632

           Summary: mod_authnz_ldap denies users when search is performed
                    at AD root.
           Product: Apache httpd-2
           Version: 2.2.3
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: mod_authz_ldap
        AssignedTo: bugs@httpd.apache.org
        ReportedBy: tmclaugh@sdf.lonestar.org


When mod_authnz_ldap is setup to search for a user at the root of an AD domain
it will fail the user because of the referrals returned in the search.

--- config ---
<Location /private>
#  SSLRequireSSL
  AuthType              Kerberos
  AuthName              "EXAMPLE Domain Login"
  KrbMethodNegotiate    On
  KrbMethodK5Passwd     On
  KrbAuthRealms         EXAMPLE.COM
  Krb5KeyTab            /etc/httpd/conf/keytab
  require valid-user

  # Strip the realm from the kerberos principle.
  MapUsernameRule (.*)@(.*) "$1"

  AuthLDAPURL           "ldap://dc1.example.com
dc2.example.com/dc=example,dc=com?sAMAccountName"
  AuthLDAPBindDN        cn=nss_ldap,ou=services,dc=example,dc=com
  AuthLDAPBindPassword  ********
  Require ldap-group    cn=Domain Admins,ou=Groups,dc=example,dc=com
</Location>
---

--- error_log ---
[Wed Jul 21 14:40:34 2010] [debug] src/mod_auth_kerb.c(1432): [client
172.30.235.107] kerb_authenticate_user entered with user (NULL) and auth_type
Kerberos
[Wed Jul 21 14:40:34 2010] [debug] src/mod_auth_kerb.c(915): [client
172.30.235.107] Using HTTP/corptech.meditech.com@MEDITECH.COM as server
principal for password verification
[Wed Jul 21 14:40:34 2010] [debug] src/mod_auth_kerb.c(655): [client
172.30.235.107] Trying to get TGT for user tmclaughlin@MEDITECH.COM
[Wed Jul 21 14:40:34 2010] [debug] src/mod_auth_kerb.c(569): [client
172.30.235.107] Trying to verify authenticity of KDC using principal
HTTP/corptech.meditech.com@MEDITECH.COM
[Wed Jul 21 14:40:34 2010] [debug] src/mod_auth_kerb.c(994): [client
172.30.235.107] kerb_authenticate_user_krb5pwd ret=0
user=tmclaughlin@MEDITECH.COM authtype=Basic
[Wed Jul 21 14:40:34 2010] [info] [client 172.30.235.107] Applying pattern
'^(.*)@(.*)$' to user 'tmclaughlin@MEDITECH.COM', mech:'Any'
[Wed Jul 21 14:40:34 2010] [info] [client 172.30.235.107] Pattern matched
[Wed Jul 21 14:40:34 2010] [notice] [client 172.30.235.107] User name
'tmclaughlin@MEDITECH.COM' rewritten to 'tmclaughlin'
[Wed Jul 21 14:40:34 2010] [debug] mod_authnz_ldap.c(683): [client
172.30.235.107] ldap authorize: Creating LDAP req structure
[Wed Jul 21 14:40:37 2010] [debug] mod_authnz_ldap.c(695): [client
172.30.235.107] auth_ldap authorise: User DN not found, ldap_search_ext_s() for
user failed
---

The resulting request made by mod_authnz_ldap is for
(&(objectclass=*)(sAMAccountName=tmclaughlin)).  The search result is the
account entry in AD plus three referrals:

ldap://DomainDnsZones.example.com/DC=DomainDnsZones,DC=example,DC=com
ldap://ForestDnsZones.example.com/DC=ForestDnsZones,DC=example,DC=com
ldap://example.com/CN=Configuration,DC=example,DC=com

The attempts to search these three referrals all fail with the same LDAP error:

00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a
successful bind must be completed on the connection., data 0, vece

I've found two workarounds for this issue.  One is to change the path in
AuthLDAPURL to where all our users are stored.  This may not work for all
organizations.  The second is to set in /etc/openldap/ldap.conf "REFERRALS
off".  That unfortunately affects the behavior of everything using the openldap
libs.  The best fix would probably be to implement what looks to have been done
in mod_auth_ldap in bugzilla 26538 and add AuthLDAPFollowReferrals which would
allow toggling referral chasing in mod_authnz_ldap.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

DO NOT REPLY [Bug 49632] mod_authnz_ldap denies users when search is performed at AD root.

Posted by bu...@apache.org.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49632

--- Comment #1 from Eric Covener <co...@gmail.com> 2010-07-21 15:57:15 EDT ---
other options: point at the global catalog port, or to the "ADAM" frontend.

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

[Bug 49632] mod_authnz_ldap denies users when search is performed at AD root.

Posted by bu...@apache.org.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49632

Eric Covener <co...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |NEEDINFO

--- Comment #3 from Eric Covener <co...@gmail.com> ---
referral stuff in 2.4 helpful for this?

(sorry this PR has been stagnant)

-- 
You are receiving this mail because:
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org

DO NOT REPLY [Bug 49632] mod_authnz_ldap denies users when search is performed at AD root.

Posted by bu...@apache.org.

https://issues.apache.org/bugzilla/show_bug.cgi?id=49632

--- Comment #2 from Tom McLaughlin <tm...@sdf.lonestar.org> 2010-07-21 17:42:03 EDT ---
Only problem I could see with searching a global catalog is often times the GC
servers are a subset of your DCs.  You may have multiple DCs per site with only
one GC in that site.  From my recollection of AD topology recommendations that
is an advisable setup according to MS.  (It's to balance availability with
replication load.)  For redundancy with mod_authnz_ldap you would end up
pointing to the local site GC and a foreign site's GC instead of just utilizing
the local site DCs.

ref:
http://technet.microsoft.com/en-us/library/cc978012.aspx
http://technet.microsoft.com/en-us/library/cc728188%28WS.10%29.aspx

-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

---------------------------------------------------------------------
To unsubscribe, e-mail: bugs-unsubscribe@httpd.apache.org
For additional commands, e-mail: bugs-help@httpd.apache.org