Re: Using filter passwd

[Hugo Deprez <hugo.deprez [at] gmail.com>]

Hello,

sorry for spamming...

It seems that if the filter return "no match found" loggin is accepted (as explain in the man page =>

The default behaviour is not to do this extra search and always grant access.),

If I give an attribute host=none to all the users without host atrribute, it match and access is denied.

Is there a way to change this default behaviour ? I would like to avoid providing this attribute to all the users.

Regards,

Hugo

On 26 May 2011 23:24, Hugo Deprez <hugo.deprez [at] gmail.com> wrote:

Hello,

this filter works but allow user withtout any host attribute to connect...
So i tried :
pam_authz_search (&(objectClass=IT)(uid=$username)(|(host=host1)(host=all)(!(host=*))))

but it didn't work as expected.

Is there a way to avoid this behaviour ?

Regards

Hugo

On 26 May 2011 11:47, Hugo Deprez <hugo.deprez [at] gmail.com> wrote:

Hello,

I finally found the solution to my needs :

pam_authz_search (&(objectClass=IT)(uid=$username)(|(host=host1)(host=all)))

The user need a least one the the following attribute :

host = all
or
host = host1

I am still blocked with the user from two other  o=service2,ou=Users and o=service3,ou=Users.
I run the ldapsearch commands in anonymous, and I can get the answer.
So I don't really understand why I have this behaviour.

If I find a solution I'll let you know.

Regards,

Hugo

On 25 May 2011 15:00, Hugo Deprez <hugo.deprez [at] gmail.com> wrote:

Hello Arthur,

thank you for your answer.

I try to use the following :

pam_authz_search (&(objectClass=posixAccount)(uid=$username)(|(host=server1)(host=all)))

I created a test user account without 'host' attribute and the user was able to connect to the server. So its seems that this filter didn't work.
In the debug output, I was not able to see the 'filtering debug line'.

- Does nslcd is able to understand any attribute ? For exemple If I rename my attribute host as Access, will it still work ?
- For my second issue, If I understand well, the user hugo.test is trying to do a 'ldapsearch' on his own account ?

The user should not be able to change is password from the shell.


Regards,

Hugo

On 24 May 2011 23:18, Arthur de Jong <arthur [at] arthurdejong.org> wrote:

On Tue, 2011-05-24 at 15:17 +0200, Hugo Deprez wrote:
> I need to specify user by user who can have access to each server.
> In order to achieve this in our ldap we created a host attribute for
> each user.

[...]

> When I used libpam-ldap I used the following syntax
> (/etc/pam_ldap.conf) :
>
> pam_filter | (host=server1)(host=all)
>
> With libpam-ldapd  (/etc/nslcd.conf) I tried the following :
>
> filter passwd (| (host=server1)(host=all))

The replacement for pam_filter is pam_authz_search. It is a little more
flexible than pam_filter. You probably want something like

pam_authz_search (&(objectClass=posixAccount)(uid=$username)(|(host=$hostname)(host=$fqdn)(host=all)))

which allows the host attribute to contain "all", the current host name
or the fully qualified domain name.

You could also do the same with "filter passwd" but you cannot use
$hostname and $fqdn then. You also have to specify "filter shadow" then
because otherwise pam_unix could give you problems.

I have a personal preference to do expose all users through NSS but to
do the filtering in PAM because it is easier to avoid uid clashes and it
avoids problems with NFS or other means of sharing files between
machines that do and don't allow access. If you have a huge directory of
users limiting the users exposed through NSS could be a good idea though
to speed things up.

> The issue is that I created a test user in the service2 with the
> attribute of the host, but the ssh login failed.
> This work for my user which is in o=service1,ou=Users
>

> nslcd: [b0dc51] DEBUG: connection from pid=21377 uid=0 gid=0
> nslcd: [b0dc51] DEBUG: nslcd_shadow_byname(hugo.test)
> nslcd: [b0dc51] DEBUG: myldap_search(base="dc=exemple,dc=org", filter="(&(objectClass=shadowAccount)(uid=hugo.test))")
> nslcd: [b0dc51] DEBUG: ldap_initialize(ldaps://ldap.exemple.org/)

> nslcd: [b0dc51] DEBUG: ldap_simple_bind_s(NULL,NULL) (uri="ldaps://ldap.exemple.org/")
> nslcd: [b0dc51] DEBUG: ldap_result(): end of results
> nslcd: [495cff] DEBUG: connection from pid=21377 uid=0 gid=0
> nslcd: [495cff] DEBUG: nslcd_pam_authc("hugo.test","","sshd","***")
> nslcd: [495cff] DEBUG: myldap_search(base="dc=exemple,dc=org", filter="(&(| (host=mut)(host=host1))(uid=hugo.test))")
> nslcd: [495cff] DEBUG: myldap_search(base="uid=hugo.test,ou=Users,o=service2,dc=exemple,dc=org", filter="(| (host=mut)(host=host1))")
> nslcd: [495cff] DEBUG: ldap_initialize(ldaps://ldap.exemple.org/)

> nslcd: [495cff] DEBUG: ldap_simple_bind_s("uid=hugo.test,ou=Users,o=service2,dc=exemple,dc=org","***") (uri="ldaps://ldap.exemple.org/")
> nslcd: [495cff] ldap_result() failed: No such object
> nslcd: [495cff] lookup of user uid=hugo.test,ou=Users,o=service2,dc=exemple,dc=org failed: No such object
> nslcd: [495cff] DEBUG: ldap_unbind()

The problem is probably that the user is not allowed to search it's own
entity. For password modification it is usually a good idea to let an
LDAP user modify it's own userPassword attribute.

After connecting as the user nslcd tries to perform a search for the
user's DN to ensure that a valid LDAP connection is available. It is
this search that is failing in the log above.

--
-- arthur - arthur [at] arthurdejong.org - http://arthurdejong.org --

--
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe [at] lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users

-- 
To unsubscribe send an email to
nss-pam-ldapd-users-unsubscribe@lists.arthurdejong.org or see
http://lists.arthurdejong.org/nss-pam-ldapd-users