Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We are using an LDAP server with both Solaris and RHEL servers and planning to migrate more servers over to RHEL. However we have an issue with LDAP on all Red Hat servers.

When I type "getent passwd", all users on the entire LDAP Server are shown, instead of only the users that have access to this server. Normally about 10 to 50 people have access to a server, so Solaris prints out this list of users, while Red Hat flat out prints out a list of all users that exist in the LDAP (about 650).

I prefer the behavior as on Solaris, where only the users that have permission to access the server are listed with "getent passwd".

How can I configured RHEL to list only the users that have access to the server?

share|improve this question
3  
How are you restricting access to your servers? –  John Jul 29 '13 at 12:23
    
The restriction is configured in /etc/security/access.conf with: "+ : @hostname : ALL". –  ujjain Jul 29 '13 at 13:59

3 Answers 3

If it is an option you could extend your ldap schema as per the following

from http://www.secure-computing.net/wiki/index.php/OpenLDAP/Authentication

To get this host verification, we're going to add a custom schema to allow for the host attribute on a posixAccount objectClass. You can download the new schema here. To use this new schema, unzip and save the scn.schema file to /usr/local/etc/openldap/schema and add the following line to your slapd.conf file:

...

Then add in nss_ldap.conf nss_base_passwd dc=base,dc=local?one?host=thismachinehost

the syntax is base?scope?filter

This is tested on freebsd where getent passwd then only list the users matching the filter.

share|improve this answer

You're restricting access in /etc/security/access.conf, which while it controls who can access the server has no impact on what users are visible to the server. This is generally what you want: even if user alice is unable to log into the server, if she owns files on a shared filesystem I want to see:

$ ls -l ~alice
-rw-rw-r--. 1 alice alice 0 Aug  1 09:09 afile

Instead of:

$ ls -l ~alice
-rw-rw-r--. 1 5234 5234 0 Aug  1 09:09 afile

That is, I want the system to know about users even if they aren't able to log into the system.

If you want to restrict the set of users visible to the system, you'll need to configure the NSS subsystem to implement some sort of LDAP filter. How you do that depends on what tools you're using:

  • user993553 mentions nss_ldap, which is the legacy tool for integrating with LDAP.

  • Some newer distributions use SSSD, which includes an ldap_service_search_base parameter in the LDAP module,

  • The nslcd program has filter option that can be applied to each map

Which mechanism you use depends on what version of RHEL you're running: RHEL 6 has both nslcd and sssd (I'm using nslcd), while earlier versions I think are limited to nss_ldap.

share|improve this answer
up vote 0 down vote accepted

This is default behavior, RHEL restricts the users using PAM, nss tries to resolve all available user/group entries in the given ldap search base.

There might be situations where the system has an nfs mount which includes files owned by users who do not have access to the machine, you can still resolve the users if all are visible to the OS (the access is restricted by PAM, so they wont be able to login).

You can use one of the following options to change the behavior.

  1. Use SSSD, it will not enumerate users/groups by default. (ie; getent passwd will only list the local users).

  2. Use an ldap filter so only the required users are visible to the machine. This is possible only if there is a particular filter which can be used to filter the user (for eg: using a memberof attribute on a group).

  3. Use compat mode to filter the users.

for eg:

nsswitch.conf 
passwd: files compat
passwd_compat: ldap

in passwd file, add +@netgroup.
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.