[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 account required /lib/security/pam_pwdb.so session required /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 account required /lib/security/pam_pwdb.so password required /lib/security/pam_cracklib.so password required /lib/security/pam_pwdb.so shadow nullok use_authtok session required /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]