On Mon, 15 Jul 2013, Daniel Eischen wrote:
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 04:28, Daniel Eischen wrote:
[ ... ]
I think something is lost on me here. getpwent/getpwuid do
not return the password hashes in the returned struct passwd
unless the calling process is root.
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 04:28, Daniel Eischen wrote:
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 00:47, Ben Morrow wrote:
Quoth Jan Bramkamp :
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
On 07/15/13 22:28, Daniel Eischen wrote:
> I think something is lost on me here. getpwent/getpwuid do
> not return the password hashes in the returned struct passwd
> unless the calling process is root. So you have to be root in
> order to see the hashes anyway. Not all users are going to
> hav
On 16.07.2013 04:28, Daniel Eischen wrote:
> On Tue, 16 Jul 2013, Jan Bramkamp wrote:
>
>> On 16.07.2013 00:47, Ben Morrow wrote:
>>> Quoth Jan Bramkamp :
On 15.07.2013 21:51, Daniel Eischen wrote:
>
> Wouldn't it be easier just to edit /etc/nsswitch.conf
> anyway?
PAM and NS
On Tue, 16 Jul 2013, Jan Bramkamp wrote:
On 16.07.2013 00:47, Ben Morrow wrote:
Quoth Jan Bramkamp :
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (us
On 16.07.2013 00:47, Ben Morrow wrote:
> Quoth Jan Bramkamp :
>> On 15.07.2013 21:51, Daniel Eischen wrote:
>>>
>>> Wouldn't it be easier just to edit /etc/nsswitch.conf
>>> anyway?
>> PAM and NSS switch are two different subsystems. NSS is just for
>> resource lookups (users, groups, hosts, ...).
Quoth Jan Bramkamp :
> On 15.07.2013 21:51, Daniel Eischen wrote:
> >
> > Wouldn't it be easier just to edit /etc/nsswitch.conf
> > anyway?
> PAM and NSS switch are two different subsystems. NSS is just for
> resource lookups (users, groups, hosts, ...). PAM is for access control.
>
> With ldap i
On Mon, 15 Jul 2013, Jan Bramkamp wrote:
On 15.07.2013 21:51, Daniel Eischen wrote:
Wouldn't it be easier just to edit /etc/nsswitch.conf
anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access control.
With lda
On 15.07.2013 21:51, Daniel Eischen wrote:
>
> Wouldn't it be easier just to edit /etc/nsswitch.conf
> anyway?
PAM and NSS switch are two different subsystems. NSS is just for
resource lookups (users, groups, hosts, ...). PAM is for access control.
With ldap in nsswitch.conf for users and groups
On Mon, 15 Jul 2013, Jan Bramkamp wrote:
On 15.07.2013 21:44, Daniel Eischen wrote:
On Mon, 15 Jul 2013, Jan Bramkamp wrote:
On 15.07.2013 21:09, Daniel Eischen wrote:> On Mon, 15 Jul 2013, Michael
Loftis wrote:
nss_ldap fulfills most of the get*ent calls, thus based on the bits of
your co
On Mon, Jul 15, 2013, at 14:51, Daniel Eischen wrote:
>
> Wouldn't it be easier just to edit /etc/nsswitch.conf
> anyway?
>
Yes, but bad things happen if you're upgrading a server and there are
library changes but you've left it in the pam.d/* files. I guess I
wasn't very specific.
_
On Mon, 15 Jul 2013, Mark Felder wrote:
On Mon, Jul 15, 2013, at 14:09, Daniel Eischen wrote:
Ok, thanks. But shouldn't the documentation be changed
to reflect that?
Whoa, I need to test this now, as we are used to being able to turn this
on/off by editing /etc/pam.d/system and sshd
Would
On 15.07.2013 21:44, Daniel Eischen wrote:
> On Mon, 15 Jul 2013, Jan Bramkamp wrote:
>
>> On 15.07.2013 21:09, Daniel Eischen wrote:> On Mon, 15 Jul 2013, Michael
>> Loftis wrote:
>>>
nss_ldap fulfills most of the get*ent calls, thus based on the bits of
your configuration you've expose
On Mon, 15 Jul 2013, Jan Bramkamp wrote:
On 15.07.2013 21:09, Daniel Eischen wrote:> On Mon, 15 Jul 2013, Michael
Loftis wrote:
nss_ldap fulfills most of the get*ent calls, thus based on the bits of
your configuration you've exposed I think you're ending up with that
behavior and not using pa
On 15.07.2013 21:25, Mark Felder wrote:> On Mon, Jul 15, 2013, at 14:19,
Jan Bramkamp wrote:
>>
>> More than that. In my opinion it should be updated by replacing nss_ldap
>> and pam_ldap with nss-pam-ldapd which splits the job of both into a
>> shared daemon talking to the LDAP server and small st
On Mon, Jul 15, 2013, at 14:19, Jan Bramkamp wrote:
>
> More than that. In my opinion it should be updated by replacing nss_ldap
> and pam_ldap with nss-pam-ldapd which splits the job of both into a
> shared daemon talking to the LDAP server and small stubs linked into the
> NSS / PAM using proces
On 15.07.2013 21:09, Daniel Eischen wrote:> On Mon, 15 Jul 2013, Michael
Loftis wrote:
>
>> nss_ldap fulfills most of the get*ent calls, thus based on the bits of
>> your configuration you've exposed I think you're ending up with that
>> behavior and not using pam_ldap at all. Instead the authenti
On Mon, Jul 15, 2013, at 14:09, Daniel Eischen wrote:
>
> Ok, thanks. But shouldn't the documentation be changed
> to reflect that?
>
Whoa, I need to test this now, as we are used to being able to turn this
on/off by editing /etc/pam.d/system and sshd
___
On Mon, 15 Jul 2013, Michael Loftis wrote:
nss_ldap fulfills most of the get*ent calls, thus based on the bits of
your configuration you've exposed I think you're ending up with that
behavior and not using pam_ldap at all. Instead the authentication is
happening via nsswitch fulfilling getpwent
nss_ldap fulfills most of the get*ent calls, thus based on the bits of
your configuration you've exposed I think you're ending up with that
behavior and not using pam_ldap at all. Instead the authentication is
happening via nsswitch fulfilling getpwent() call's (the passwd: files
ldap line in nssw
There's an article on LDAP authentication on FreeBSD here:
http://www.freebsd.org/doc/en/articles/ldap-auth/article.html#client
I'm confused as to why pam_ldap and nss_ldap do not need
/etc/pam.d entries, as described in the above link in
section 3.1.1. Meaning, I do not have any ldap entries
21 matches
Mail list logo