blaine, all,

On Sat, 7 Dec 2002, blaine wrote:

> > to be fair, there are at two good reasons for not using PAM as far as i
> > can tell:
> >
> > 1) you are using OpenBSD for its security properties.  in spite of the
> > 2) you are using a PAM-capable OS but you trust the qmail-ldap patch's
> > implementation of LDAP authentication/authorization more than you trust
> 
> Or, perhaps the more obvious reason that you don't want to give all of 
> your users PAM access. This is the case on the systems that I've 
> configured, where some shell access (authenticated via PAM-LDAP) is 
> necessary, but most users are simply pop/imap/webdav users, and as such 
> don't even need system uid/gid's.

nope.  that doesn't count as a good reason because at least the linux ldap 
stuff makes it soo easy to restrict local access to the machine to people 
with particular group membership, particular fields set or whatever.

see /etc/ldap.conf and stuff like this in comments:


# Check the 'host' attribute for access control
# Default is no; if set to yes, and user has no
# value for the host attribute, and pam_ldap is
# configured for account management (authorization)
# then the user will not be allowed to login.
#pam_check_host_attr yes

# Group to enforce membership of
#pam_groupdn cn=PAM,ou=Groups,dc=example,dc=com

# Group member attribute
#pam_member_attribute uniquemember

# Specify a minium or maximum UID number allowed
#pam_min_uid 0
#pam_max_uid 0


it's really easy to use.  i like the group membership, personally, but to 
each their own.

doing qmail-ldap just because you don't know how to use the existing PAM 
tools to restrict access to the shell is not, in my opinion, a valid 
reason.

i stand by the two reasons i did suggest, however.

t.

-- 
todd underwood, vp & cto
oso grande technologies, inc.
[EMAIL PROTECTED]

"Those who give up essential liberties for temporary safety deserve
neither liberty nor safety." - Benjamin Franklin

Reply via email to