[EMAIL PROTECTED] (Adam P. Harris) writes:
> Norbert Veber <[EMAIL PROTECTED]> writes:
> > What sorts of things can pam do? I only know that for example a
> > long program that uses PAM works regardless of weather the
> > password file is shadowed or not, but can it do more advanced
> > authentication, ie. could it be used to replace radius?
There currently is support to log to a RADIUS server, I think
authentication is still being worked on. The main point of PAM is to
allow the sysadmin to configure his choice of all of the various
authentication methods via text files, without recompiling anything.
It gives the sysadmin the flexibility (choice) that many people
claim Debian strives to provide.
> PAM, as I understand it, provides the hooks that enable you to plug in
> different authentication/authorization (NIS, NIS+, shadow, passwd,
> kerberos, radius, etc). That way, you have a pam'ified /bin/login,
> rather than having a kerbified login, a shadow login, etc etc.
> It's used by RedHat and Solaris.
Basically, it lets you specify in a file the rules that programs use
for determining whether someone can log in.
Below are some examples of pam configuration files, but first a bit
about what you can do with it:
* Locally, we are writing a module to stack on top of the password
modules, so that "passwd" will set both NIS passwords and store a
samba password. (This is necessary to use encrypted samba
passwords.)
* There are modules to implement:
securetty,
anonymous access,
group access,
access at particular times of day,
"wheel" group access,
print last login time
print a file
"chroot" (automatically chroot a user)
S/Key
(so you could, by editing text files, restrict xdm, ppp, ftp, rsh,
to a certain group, to certain times of day, etc.)
* There's a toy "filter" module, along with an example filter that
transposes upper and lowercase characters (This could be used to
implement an annoying cybersitter-like functionality.)
* There is a module to authenticate against an NT server.
* I believe there is a module for secureid cards.
* Future directions include authentication against a LDAP server.
If you don't like /etc/securettys, you can just edit a file to take it
out. If you don't like .rhost files, you can just as easily disable
that. If you only want people in the "manager" group to be able to
use rsh, you edit a file, etc. If you want wheel on su, just edit a
text file.
Some examples of configuration files. Here is "/etc/pam.d/rsh"
auth required /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_nologin.so
accountrequired /lib/security/pam_pwdb.so
sessionrequired /lib/security/pam_pwdb.so
Says that the "pam_rhosts_auth.so" library has to be satisified, that
"pam_nologin.so" has to be satisfied (checks /etc/nologin). That
"pam_pdwb.so" has to find an account and that "pam_pdwb.so" is used to
set up the session. Compare to the "rlogin" file:
auth required /lib/security/pam_securetty.so
auth sufficient /lib/security/pam_rhosts_auth.so
auth required /lib/security/pam_pwdb.so shadow nullok
auth required /lib/security/pam_nologin.so
accountrequired /lib/security/pam_pwdb.so
password required /lib/security/pam_cracklib.so
password required /lib/security/pam_pwdb.so shadow nullok use_authtok
sessionrequired /lib/security/pam_pwdb.so
The first module checks /etc/securetty (the library fails if the
person is trying to login as root and the tty is not listed there - if
you don't like securetty, you just delete the line). The second says
that an rhost file entry is sufficient. Otherwise pam_pwdb.so is
consulted (null passwords are allowed because of the option, and the
shadow file is consulted). The account and session info is gotten
from pam_pwdb.so. I don't the the password stack is actually used
here (it is in the file for the passwd program).
Steve
[EMAIL PROTECTED]
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
