Le lundi 07 mai 2007 à 09:57 +1000, Russell Coker a écrit :
> On Saturday 05 May 2007 16:13, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> > [Roberto C. Sánchez]
> >
> > > You mean that the passwords go in the clear?
> >
> > Yes, unless you are securing the entire LDAP session, using SSL.
>
> Does
On Saturday 05 May 2007 16:13, Peter Samuelson <[EMAIL PROTECTED]> wrote:
> [Roberto C. Sánchez]
>
> > You mean that the passwords go in the clear?
>
> Yes, unless you are securing the entire LDAP session, using SSL.
Does the pam_ldap module allow you to store the SSL key for the server or
authen
On Sat, May 05, 2007 at 01:13:36AM -0500, Peter Samuelson wrote:
>
> > On Fri, May 04, 2007 at 11:51:02PM +0200, Petter Reinholdtsen wrote:
> > > Actually, you got it backwards, as explained above. pam-ldap isn't
> > > using the password hash to check the password. It is passing the
> > > passwo
> On Fri, May 04, 2007 at 11:51:02PM +0200, Petter Reinholdtsen wrote:
> > Actually, you got it backwards, as explained above. pam-ldap isn't
> > using the password hash to check the password. It is passing the
> > password over to the LDAP server (using an LDAP bind), and letting the
> > LDAP s
On Fri, May 04, 2007 at 04:39:02PM -0700, Steve Langasek wrote:
> On Fri, May 04, 2007 at 06:19:34PM -0400, Roberto C. Sánchez wrote:
> > On Fri, May 04, 2007 at 02:49:40PM -0700, Steve Langasek wrote:
>
> > > It means that pam_unix is able to access your shadow hash on behalf of the
> > > user, w
On Fri, May 04, 2007 at 06:19:34PM -0400, Roberto C. Sánchez wrote:
> On Fri, May 04, 2007 at 02:49:40PM -0700, Steve Langasek wrote:
> > It means that pam_unix is able to access your shadow hash on behalf of the
> > user, when using root privileges (which is expected and required in the case
> >
On Fri, May 04, 2007 at 11:51:02PM +0200, Petter Reinholdtsen wrote:
>
> Actually, you got it backwards, as explained above. pam-ldap isn't
> using the password hash to check the password. It is passing the
> password over to the LDAP server (using an LDAP bind), and letting the
> LDAP server de
On Fri, May 04, 2007 at 02:49:40PM -0700, Steve Langasek wrote:
>
> It means that pam_unix is able to access your shadow hash on behalf of the
> user, when using root privileges (which is expected and required in the case
> where you want to support password changes via pam_ldap); and that if
> pa
On Fri, May 04, 2007 at 11:51:02PM +0200, Petter Reinholdtsen wrote:
> Yes, pam is needed to do proper authentication (password checking),
> and nss is needed to find information about users and groups. Yes,
> you can use nss to find password hashes and authenticate locally after
> fetching the ha
[Christoph Haas]
> Okay, so libpam-ldap is mandatory in that case? Good to know. Most
> of the documentation I found said that only libnss-ldap is needed
> for login and libpam-ldap's only use is for changing the password
> over LDAP.
Yes, pam is needed to do proper authentication (password check
On Fri, May 04, 2007 at 05:33:45PM -0400, Roberto C. Sánchez wrote:
> > If you use libnss-ldap+pam_unix for authentication, authentication involves
> > the system querying the password hash from LDAP across the network, and
> > using pam_unix to attempt to authenticate against it. If normal users
On Fri, May 04, 2007 at 12:17:03PM -0700, Steve Langasek wrote:
>
> If you use libnss-ldap+pam_unix for authentication, authentication involves
> the system querying the password hash from LDAP across the network, and
> using pam_unix to attempt to authenticate against it. If normal users do
> no
I suppose you have your immediate problem solved here, but this information
might be useful for others sometime later, so:
On Fri, May 04, 2007 at 07:29:17PM +0200, Christoph Haas wrote:
> > This sounds like you have set up LDAP authentication incorrectly, as I
> > am able to lock the screen with
On Friday 04 May 2007 12:34:23 Wesley J. Landaker wrote:
> On Friday 04 May 2007 05:23:17 Christoph Haas wrote:
> > libpam-ldap (optionally) people who lock their screen in KDE will not
> > be able to unlock the screen and may (like me) lose data because they
> > finally give up and Ctrl+Alt+Backsp
On Friday 04 May 2007 05:23:17 Christoph Haas wrote:
> libpam-ldap (optionally) people who lock their screen in KDE will not be
> able to unlock the screen and may (like me) lose data because they
> finally give up and Ctrl+Alt+Backspace. :( It turned out that unlocking
Unrelated to your *actual*
On Fri, May 04, 2007 at 07:55:14PM +0200, Bernd Zeimetz wrote:
> Christoph,
>
> > Thanks in advance for the hints. I'm taking notes already to document
> > this better.
>
> please post a link as soon as you have some documentation online. I'd
> think that a wiki would be a good place for it. pam-
Christoph,
> Thanks in advance for the hints. I'm taking notes already to document
> this better.
please post a link as soon as you have some documentation online. I'd
think that a wiki would be a good place for it. pam-ldap/libnss-ldap is
missing a good documentation definitely.
Cheers,
Bernd
Petter,
On Fri, May 04, 2007 at 05:29:07PM +0200, Petter Reinholdtsen wrote:
> [Christoph Haas]
> > I'm unhappy with the outcome of the bug #298148 (kdebase-bin: kcheckpass
> > needs setuid bit for ldap authentication). When using libnss-ldap and
> > libpam-ldap (optionally) people who lock their
[Christoph Haas]
> I'm unhappy with the outcome of the bug #298148 (kdebase-bin: kcheckpass
> needs setuid bit for ldap authentication). When using libnss-ldap and
> libpam-ldap (optionally) people who lock their screen in KDE will not be
> able to unlock the screen and may (like me) lose data bec
Dear list...
someone (curse you, Matthijs) motivated me to dump NIS in favor of LDAP
for user accounts on my small home net. Good thing I did it during my
vacation because it's not as trivial as I hoped.
I'm unhappy with the outcome of the bug #298148 (kdebase-bin: kcheckpass
needs setuid bit for
20 matches
Mail list logo
