Re: LDAP authentication with PAM
>>>>> "Wichert" == Wichert Akkerman <wichert@cistron.nl> writes:
Wichert> Not at all. ldap.secret can be used to allow root to
Wichert> login to the LDAP database as a special user so it can
Wichert> make changes normal users are not allowed to make.
Wichert> LDAP supports a special `auth' access option where it
Wichert> will verify a password which is what PAM uses.
So I don't need ldap.secret? However, if I deleted ldap.secret, then
normal authentications don't seem to work. Correction: normal
authentication didn't work. It works fine now. Go figure ;-).
I guess I should only have ldap.secret on the server, as if anybody
breaks into the server, security is lost anyway.
Wichert> Also, I have SSL-enabled LDAP package for potato
Wichert> available at ftp://ftp.valinux.com/pub/people/wichert/
Thanks. I will look at that.
>> Also, I am getting totally confused with the different PAM
>> services.
Wichert> That is nicely documented in the pam-doc package.
Perhaps it is better is unstable, I couldn't fine much in stable.
>> I don't like this duplication of information much though.
Wichert> You can also remove files so PAM will fall back to using
Wichert> /etc/pam.d/other which you can fill with standard
Wichert> settings.
I was considering this. Certain services have certain differences, and
I am not sure if you can make all the same.
snoopy:/etc/pam.d# grep pam_nologin *
gdm:auth required pam_nologin.so
kbdrate:#auth required pam_nologin.so
login:auth required pam_nologin.so
ppp:auth required pam_nologin.so
pppd:auth required pam_nologin.so
ssh:auth required pam_nologin.so
I guess this should really go everywhere, so that is OK.
However what about:
pam_env, pam_limits, pam_securetty, pam_lastlog, pam_motd, pam_issue, pam_mail?
I suspect some of these may only be suitable for telnet and ssh. Or
pam_wheel and pam_rootok, which is only suitable for su.
Also, anyone know why I have a pppd and a ppp file?
snoopy:/etc/pam.d# cat pppd
auth required pam_nologin.so
auth required pam_pwdb.so
account required pam_pwdb.so
session required pam_pwdb.so
I can't even find any information on pam_pwdb. It doesn't seem to
be used in any case.
I guess this means I can safely remove all files except telnet, ssh,
su, and other?
I might keep login too, just so I can use /etc/shadow for local root
logins in case something goes wrong with LDAP (I can't see any good
reason why this should be done for all services). Do others keep
/etc/shadow around for this reason too, or do you assume LDAP will be
running all the time in order to simplify this stuff?
>>>>> "Sami" == Sami Haahtinen <ressu@uusikaupunki.fi> writes:
Sami> are you sure it's in /usr/doc?
Yes I am sure it is /usr/share/doc <grin>!
Sami> it is not required, if it's not there.. it will fall back to
Sami> the dummy solution, requesting the user password.
Strange it didn't work first time. Probably come to a false conclusion
after doing something else wrong.
Sami> appears that you have gotten all your information from
Sami> directory-manager, which is not the best source for
Sami> information. it is a good tool for basic setup though.
Its the only source I have found so far (excluding this list of
course).
>> Also, I am getting totally confused with the different PAM
>> services. My understanding so far:
>>
>> auth - is this user allowed access? account - is the user's
>> account valid and not expired? (does this include password
>> expiry)? password - how to change the password. session - ???
Sami> -- setup session specific data, this could be used to
Sami> set up environment and other user session data. (i recall
Sami> some module which set up keys with this)
Ok.
>> Why do gdm and imap have password specified in
>> /etc/pam.d/gdm,imap? (I would be surprised if imap supported
>> changing the password, not sure about gdm). These are the only
>> files that didn't have entries for cracklib commented
>> out. Perhaps I should add them in, seeing as I have enabled
>> cracklib everywhere else. I don't like this duplication of
>> information much though.
Sami> i actually don't know why imap would have password
Sami> entry. IMAP as protocol does not to my knowledge allow
Sami> changing passwords.. maintainer mistake?
Perhaps. In any case, I will probably delete the imap entry anyway,
and make it use the other entry.
>>>>> "Steve" == Steve Langasek <vorlon@netexpress.net> writes:
Steve> Yes, pam_stack sucks. It can never work as well as
Steve> providing reasonable defaults in /etc/pam.d/other, because
Steve> there's no way to allow passing of information between the
Steve> two stacks, except to the extent that pam_stack itself
Steve> allows. It makes it much more difficult to follow the
Steve> stack flow, especially for those not overly familiar with
Steve> PAM. It's not particularly labor-saving, because there are
Steve> now two config files to keep track of for every service,
Steve> even those services which don't deviate at all from the
Steve> default settings.
Steve> Honestly I think pam_stack is a neat concept, and I can see
Steve> where it would come in handy. But using it for all of your
Steve> services when PAM already has a mechanism that will get you
Steve> the same results with less overhead seems silly to me.
What is pam_stack? (doesn't seem to be included on my stable
installation).
Oh, if no password service is found inside /etc/pam.d/login (for
instance) will it look in /etc/pam.d/other? I think it does.
Some bugs do exist of stable:
snoopy:/etc/pam.d# passwd bam
New UNIX password:
Retype new UNIX password:
LDAP password information changed for bam
passwd: password updated successfully
Actually I was pushing ctrl^C trying to abort... Can't it make up its
mind if its updating UNIX or LDAP? (this only happens when done as
root with a /etc/ldap.secret file).
Also I noted for login if I used:
auth sufficient pam_unix.so
auth required pam_ldap.so
The prompts are:
snoopy login: bam
Password:
LDAP Password:
Login incorrect
If I change this to
auth sufficient pam_ldap.so
auth required pam_unix.so
The prompts change to
snoopy login: bam
Password:
Password:
strange.
--
Brian May <bam@debian.org>
Reply to: