Hide Forgot
Created attachment 424505 [details] upstream patch adjusted for 2.2.3-43 Customer is trying Working on centralising the authentication systems using kerberos and LDAP against Windows AD 2003 to provide SSO. They are using mod_authnz_ldap module shipped with RHEL5 to configure apache server to authenticate against LDAP server. There's an Issue with mod_authnz_ldap shipped whereby it incorrectly follows referrals without using the supplied bind credentials. The request is denied by the AD and causes authorization to fail. There's an fix in the upstream for the above issue. The relevant BZ is as follows. https://issues.apache.org/bugzilla/show_bug.cgi?id=26538 httpd-2.2.3-43.el5.x86_64 Observed behavior: CU is using mod_authnz_ldap module to authenticate httpd against Windows AD 2003. The authentication fails because the results returned gives referrals to follow which httpd follows without using the supplied bind credentials. Since windows 2k3 doesn't allow anonymous bind the authentication fails. Desired behavior: httpd and mod_authnz_ldap should follow referrals with appropriate bind credentials. The patch associated with upstream BZ 26538 (https://issues.apache.org/bugzilla/show_bug.cgi?id=26538) is for 2.0.63 codebase below patchset addresses the same issue. But has the patch for 2.2.4 https://issues.apache.org/bugzilla/show_bug.cgi?id=40268 https://issues.apache.org/bugzilla/show_bug.cgi?id=42557 (patch is attached in this BZ) 1. Configure httpd to authenticate using kerberos with authorization with ldap backend. 2. configure etc/httpd/conf.d/auth_kerb.conf as below <Location /auth> AuthType Kerberos AuthName "Kerberos Login" Krb5KeyTab /etc/httpd/conf/keytab AuthLDAPBindDN 'cn=my_svc_account,ou=Service Accounts,ou=London,ou=UK,dc=mydomain,dc=local' AuthLDAPBindPassword <<BIND PASSWORD>> AuthLDAPUrl "ldap://my.AD.server:389/dc=mydomain,dc=lcoal?userPrincipalName?sub?(objectClass=user)" NONE require ldap-group CN=LinuxRoot,OU=Mail,OU=Groups,OU=London,OU=UK,DC=mydomain,DC=local </Location> 3. user accounts are under different OUs to the normal ou=People., Here we have (as you can see above) users segmented by region then city so my user account would be CN=john.doe,ou=Users,ou=London,ou=UK,DC=mydomain,dc=local. The problem is related to how the authnz_ldap module interprets the referral entries sent back by Active Directory.
Thanks for the backport!
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unfortunately unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate and relevant, in the next release of Red Hat Enterprise Linux.
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHBA-2011-1067.html
FYI, it seems that upstream went with the LDAPReferrals configuration directive rather than LDAPChaseReferrals[1]. Reference Comment #2. Also reference the Apache 2.2 documentation here[2] and this[3] commit. Should RHEL's Apache be updated to stick with upstream? [1] https://issues.apache.org/bugzilla/show_bug.cgi?id=42557 [2] http://httpd.apache.org/docs/2.3/mod/mod_ldap.html#ldapreferrals [3] http://svn.apache.org/viewvc?view=revision&revision=614605
In support of the above, there is no documentation for LDAPChaseReferrals short of a mention here[1]. LDAPReferrals is close (from the Apache documentation itself), but is usable within a Directory context whereas LDAPChaseReferrals does not appear to be. [1] http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/5/html/5.7_Technical_Notes/httpd.html
For those interested, opened: https://bugzilla.redhat.com/show_bug.cgi?id=727342