Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/09/postfix-secondary-mx-local-deliver.html

Suppose you have a domain name, example.org, that has a primary MX host
(mail.example.org) that does most of the delivery. However,
one of the users, who works at example.com, actually gets delivery of
<[email protected]> at work (from the primary MX for example.com,
mail.example.com). Of course, a simple .forward
or /etc/aliases entry would work, but this would pointlessly
push email back and forth between the two mail servers — in some
cases, up to three pointless passes before the final destination!
That’s particularly an issue in today’s SPAM-laden world. Here’s how to
solve this waste of bandwidth using Postfix.

This tutorial here assumes you have a some reasonable background
knowledge of Postfix MTA administration. If you don’t, this might go a
bit fast for you.

To begin, first note that this setup assumes that you have something
like this with regard to your MX setup:

        $ host -t mx example.org
        example.org mail is handled by 10 mail.example.org.
        example.org mail is handled by 20 mail.example.com.
        $ host -t mx example.com
        example.com mail is handled by 10 mail.example.com.
        

Our first task is to avoid
example.org SPAM
backscatter on mail.example.com. To do that, we make a file with
all the valid accounts for example.org and put it
in mail.example.com:/etc/postfix/relay_recipients. (For more
information, read
the Postfix
docs
or various
tutorials
about this.) After that, we
have something like this in mail.example.com:/etc/postfix/main.cf:

        relay_domains = example.org
        relay_recipient_maps = hash:/etc/postfix/relay_recipients
        

And this in /etc/postfix/transport:

        example.org     smtp:[mail.example.org]
        

This will give proper delivery for our friend <[email protected]>
(assuming mail.example.org is forwarding that address properly to
<[email protected]>), but mail will push mail back and forth
unnecessarily when mail.example.com gets a message for
<[email protected]>. What we actually want is to wise up
mail.example.com so it “knows” that mail for
<[email protected]> is ultimately going to be delivered locally on
that server.

To do this, we add <[email protected]> to
the virtual_alias_maps, with an entry like:

        [email protected]      user
        

so that the key [email protected] resolves to the local
username user. Fortunately, Postfix is smart enough to look at
the virtual table first before performing a relay.

Now, what about aliases like <[email protected]>, that
actually forwards to <[email protected]>? That will have the same
pointless forwarding from server-to-server unless we address it
specifically. To do so, we use the transport file. of course, we
should already have that catch-all entry there to do the relaying:

        example.org     smtp:[mail.example.org]
        

But, we can also add email address specific entries for certain
addresses in the example.org domain. Fortunately, email address matches
in the transport table take precedence over whole domain match entries
(see the transport man
page for details.). Therefore, we simply add entries to
that transport file like this for each of user‘s
aliases:

        [email protected]    local:user
        

(Note: that assumes you have a delivery method in master.cf
called local. Use whatever transport you typically use to
force local delivery.)

And there you have it! If you have (those albeit rare) friendly and
appreciative users, user will thank you for the slightly
quicker mail delivery, and you’ll be glad that you aren’t pointlessly
shipping SPAM back and forth between MX’s unnecessarily.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.

Post Syndicated from Bradley M. Kuhn original http://ebb.org/bkuhn/blog/2008/01/01/apache-2-2-ldap.html

I thought the following might be of use to those of you who are still
using Apache 2.0 with LDAP and wish to upgrade to 2.2. I found this
basic information around online, but I had to search pretty hard for it.
Perhaps presenting this in a more straightforward way might help the
next searcher to find an answer more quickly. It’s probably only of
interest if you are using LDAP as your authentication system with an
older Apache (e.g., 2.0) and have upgraded to 2.2 on an Ubuntu or Debian
system (such as upgrading from dapper to gutsy.)

When running dapper on my intranet web server with Apache
2.0.55-4ubuntu2.2, I had something like this:

             <Directory /var/www/intranet>
                   Order allow,deny
                   Allow from 192.168.1.0/24 
        
                   Satisfy All
                   AuthLDAPEnabled on
                   AuthType Basic
                   AuthName "Example.Org Intranet"
                   AuthLDAPAuthoritative on
                   AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                   AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                   AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org?cn
                   AuthLDAPGroupAttributeIsDN off
                   AuthLDAPGroupAttribute memberUid
        
                   require valid-user
            </Directory>
        

I upgraded that server to gutsy (via dapper → edgy → feisty
→ gutsy in succession, just because it’s safer), and it now has
Apache 2.2.4-3build1. The methods to do LDAP authentication is a bit
more straightforward now, but it does require this change:

            <Directory /var/www/intranet>
                Order allow,deny
                Allow from 192.168.1.0/24 
        
                AuthType Basic
                AuthName "Example.Org Intranet"
                AuthBasicProvider ldap
                AuthzLDAPAuthoritative on
                AuthLDAPBindDN uid=apache,ou=roles,dc=example,dc=org
                AuthLDAPBindPassword APACHE_BIND_ACCT_PW
                AuthLDAPURL ldap://127.0.0.1/ou=staff,ou=people,dc=example,dc=org
        
                require valid-user
                Satisfy all
            </Directory>
        

However, this wasn’t enough. When I set this up, I got rather strange
error messages such as:

        [error] [client MYIP] GROUP: USERNAME not in required group(s).
        

I found somewhere online (I’ve now lost the link!) that you couldn’t
have standard pam auth competing with the LDAP authentication. This
seemed strange to me, since I’ve told it I want the authentication
provided by LDAP, but anyway, doing the following on the system:

        a2dismod auth_pam
        a2dismod auth_sys_group
        

solved the problem. I decided to move on rather than dig deeper into the
true reasons. Sometimes, administration life is actually better with a
mystery about.