I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?
-Rex
Rex Roof writes:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?
I don't quite get this. If they can run /usr/bin/finger, can't they also run /usr/bin/ldapsearch - or if that is missing, an ldapsearch they've installed somewhere else?
With "access to the system" do you mean someone who can log in, or just physical access to a system which allows anyone to run finger without logging in?
The server doesn't know it is finger which is doing the search, but you can use access controls to limit searches to certain hosts, or only authenticated users, or whatever. You don't need to provide anonymous read access if all you need is authentication, so maybe you can turn off such search altogether. Also you can use the unchecked and size limits to ensure people can't just search for *, they must at least provide a match which narrows down the search well.
running ldapsearch they'd need to authenticate with their own credentials, and with their own credentials, they can't search the entire ldap tree. the proxy user defined in /etc/ldap.conf can search the entire tree.
I have limited which of our LDAP users can connect to the machine using a pam_groupdn defined in /etc/ldap.conf. No one has physical access to the machine, it is virtual ;) I mean users that have shell access via sshd.
Doesn't the proxy user defined in /etc/ldap.conf need access to search for users and figure out their DN's to authenticate them and to check group access?
FYI this is CentOS release 5.3 and my openldap servers are still running openldap 2.3.36.
thanks for your response, sorry I wasn't completely clear.
-Rex
On Sep 11, 2009, at 11:23 AM, Hallvard B Furuseth wrote:
Rex Roof writes:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?
I don't quite get this. If they can run /usr/bin/finger, can't they also run /usr/bin/ldapsearch - or if that is missing, an ldapsearch they've installed somewhere else?
With "access to the system" do you mean someone who can log in, or just physical access to a system which allows anyone to run finger without logging in?
The server doesn't know it is finger which is doing the search, but you can use access controls to limit searches to certain hosts, or only authenticated users, or whatever. You don't need to provide anonymous read access if all you need is authentication, so maybe you can turn off such search altogether. Also you can use the unchecked and size limits to ensure people can't just search for *, they must at least provide a match which narrows down the search well.
-- Hallvard
Rex Roof writes:
running ldapsearch they'd need to authenticate with their own credentials, and with their own credentials, they can't search the entire ldap tree. the proxy user defined in /etc/ldap.conf can search the entire tree.
I don't know CentOS nor PAM/NSS, which limits what I can say here... maybe someone else can be more of help. Anyway:
I'm still not getting it.
ldapsearch defaults to anonymous, and can be run anonymously even if you have changed the default for each user to use his DN and password. For that matter, if someone is doing it from a remote site, they aren't using the defaults you provided. But maybe your slapd access controls prevent access from other machines?
But if they are to use an ldapsearch which is installed on your machine, then they must of course provide their credentials in order to log in first.
How is finger different in this? Is it a setuid program with access to the password of the proxy user in ldap.conf? If so, maybe the fix is just to un-setuid it. Unless OS updates on CentOS will restore the setuid bit. Or delete finger, replacing it with /bin/false.
I have limited which of our LDAP users can connect to the machine using a pam_groupdn defined in /etc/ldap.conf. No one has physical access to the machine, it is virtual ;) I mean users that have shell access via sshd.
Doesn't the proxy user defined in /etc/ldap.conf need access to search for users and figure out their DN's to authenticate them and to check group access?
If you need to search for a user to figure out his DN, yes you need that to authenticate. That means you must provide at least read (including search) access to at attrs=entry and search access to attrs=uid.
OTOH if they have DNs like uid=<username>,cn=users,dc=example,dc=com, you can construct the DN directly without search. (I don't use PAM so I don't know the config directives for doing that.)
Also checking group access needs to look up the group, or it needs at least compare access to the group entry (compare the user DN with 'member' of the group). Again, I dont' know what PAM does.
Both searches sound like sizelimit=1 in the server would be sufficient though, which would at least slow down attemts to search for a lot of users.
FYI this is CentOS release 5.3 and my openldap servers are still running openldap 2.3.36.
On Sat, Sep 12, 2009 at 1:08 AM, Rex Roof rex@wccnet.edu wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?
This sounds more like a firewall / iptables issue to your finger server than anything else ?
Just allow finger port from localhost or the local machine's ip address, and nowhere else.
Or redirect the finger port from "outside" users to a "fake" finger server on another (non-default) port which does not do ldap lookups.
Cheers Brett
Brett @Google wrote:
On Sat, Sep 12, 2009 at 1:08 AM, Rex Roof <rex@wccnet.edu mailto:rex@wccnet.edu> wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly. This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?This sounds more like a firewall / iptables issue to your finger server than anything else ?
No, doesn't sound like that to me.
Essentially he wants an ACL that grants access to nss-ldap searches based on the target entries belonging to a group associated with a particular peeraddr. But at the moment, I can't think of any mechanism to do this in the current ACL engine.
On Friday, 11 September 2009 16:08:17 Rex Roof wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames.
At the PAM level.
This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine.
What about the standard user information available via 'getent passwd' ?
How can this be controlled?
If you are referring to the same information as in 'getent passwd', your first problem is whether you need the OS to be able to resolve UIDs to usernames for the users who should not have access. After that, worry about (the same information via) finger ...
Regards, Buchan
On Sep 14, 2009, at 5:21 PM, Buchan Milne wrote:
On Friday, 11 September 2009 16:08:17 Rex Roof wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames.
At the PAM level.
This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine.
What about the standard user information available via 'getent passwd' ?
How can this be controlled?
If you are referring to the same information as in 'getent passwd', your first problem is whether you need the OS to be able to resolve UIDs to usernames for the users who should not have access. After that, worry about (the same information via) finger ...
Yes! 'getent passwd' returns all of the 100,000 entries in my LDAP tree, I'd rather it returned the 30 or so users that have access to the particular machine plus whatever is in /etc/passwd.
Is it possible to do this? Perhaps via a PAM configuration?
Thank you very much for your understanding of my question. -Rex
Yes, or a configuration for PAM that limits which users it provides information for.
-Rex
On Sep 12, 2009, at 9:17 PM, Howard Chu wrote:
Brett @Google wrote:
On Sat, Sep 12, 2009 at 1:08 AM, Rex Roof <rex@wccnet.edu mailto:rex@wccnet.edu> wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?
This sounds more like a firewall / iptables issue to your finger server than anything else ?
No, doesn't sound like that to me.
Essentially he wants an ACL that grants access to nss-ldap searches based on the target entries belonging to a group associated with a particular peeraddr. But at the moment, I can't think of any mechanism to do this in the current ACL engine.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On 15/09/2009 14:31, Roof,Rex wrote:
On Sep 14, 2009, at 5:21 PM, Buchan Milne wrote:
On Friday, 11 September 2009 16:08:17 Rex Roof wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames.
At the PAM level.
This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine.
What about the standard user information available via 'getent passwd' ?
How can this be controlled?
If you are referring to the same information as in 'getent passwd', your first problem is whether you need the OS to be able to resolve UIDs to usernames for the users who should not have access. After that, worry about (the same information via) finger ...
Yes! 'getent passwd' returns all of the 100,000 entries in my LDAP tree, I'd rather it returned the 30 or so users that have access to the particular machine plus whatever is in /etc/passwd.
Is it possible to do this? Perhaps via a PAM configuration?
If I understand correctly, you're enforcing access to this machine by telling PAM to allow only a given group, presumably via an option in pam_ldap.conf like "pam_groupdn cn=yourgroupe,dc=etc".
But, NSS (and therefore finger), is still seeing all users in the directory, and not only the ones from that group?
One solution would be to configure your libnss-ldap to use a binddn to connect to the LDAP server, and set up ACLs so that that binddn only has access to users from that group.
Jonathan
Rex Roof wrote:
Yes, or a configuration for PAM that limits which users it provides information for.
PAM doesn't return user information at all. This is strictly for nss-ldap. You could also add a filter to nss-ldap's config file. Unfortunately the most straightforward filter (memberOf=<the group DN>) won't work with OpenLDAP's memberof overlay. If your group was actually a dynamic group, then you could use the same filter criteria that the dynamic group uses.
-Rex
On Sep 12, 2009, at 9:17 PM, Howard Chu wrote:
Brett @Google wrote:
On Sat, Sep 12, 2009 at 1:08 AM, Rex Roof<rex@wccnet.edu mailto:rex@wccnet.edu> wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames. Thisis all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine. How can this be controlled?This sounds more like a firewall / iptables issue to your finger server than anything else ?
No, doesn't sound like that to me.
Essentially he wants an ACL that grants access to nss-ldap searches based on the target entries belonging to a group associated with a particular peeraddr. But at the moment, I can't think of any mechanism to do this in the current ACL engine.
On Sep 15, 2009, at 9:15 AM, Jonathan Clarke wrote:
On 15/09/2009 14:31, Roof,Rex wrote:
On Sep 14, 2009, at 5:21 PM, Buchan Milne wrote:
On Friday, 11 September 2009 16:08:17 Rex Roof wrote:
I have some linux machines that I have configured for student access. We are authenticating against our OpenLDAP tree and limiting which users have access via an LDAP groupOfNames.
At the PAM level.
This is all working perfectly.
This is the problem I am having. Any user with access to the system can run the /usr/bin/finger command and do a name search against our entire LDAP tree. I would like to limit the info available via finger to just the users that have access to any particular machine.
What about the standard user information available via 'getent passwd' ?
How can this be controlled?
If you are referring to the same information as in 'getent passwd', your first problem is whether you need the OS to be able to resolve UIDs to usernames for the users who should not have access. After that, worry about (the same information via) finger ...
Yes! 'getent passwd' returns all of the 100,000 entries in my LDAP tree, I'd rather it returned the 30 or so users that have access to the particular machine plus whatever is in /etc/passwd.
Is it possible to do this? Perhaps via a PAM configuration?
If I understand correctly, you're enforcing access to this machine by telling PAM to allow only a given group, presumably via an option in pam_ldap.conf like "pam_groupdn cn=yourgroupe,dc=etc".
But, NSS (and therefore finger), is still seeing all users in the directory, and not only the ones from that group?
One solution would be to configure your libnss-ldap to use a binddn to connect to the LDAP server, and set up ACLs so that that binddn only has access to users from that group.
exactly.
Could I craft an ACL for my proxy user, "cn=UNIX Auth,ou=Utility", so that it only has access to objects that are in any group matching the pattern "cn=machine [^,]+,ou=Group"? (I've made groups for each unix machine in the form of "cn=machine hostname,ou=group")
Currently the "cn=UNIX Auth,ou=Utility" proxy user is in the group "cn=authdaemon,ou=group", which I've given read access to most of the directory.
-Rex
On Sep 15, 2009, at 10:41 AM, Howard Chu wrote:
Rex Roof wrote:
Yes, or a configuration for PAM that limits which users it provides information for.
PAM doesn't return user information at all. This is strictly for nss- ldap. You could also add a filter to nss-ldap's config file. Unfortunately the most straightforward filter (memberOf=<the group DN>) won't work with OpenLDAP's memberof overlay. If your group was actually a dynamic group, then you could use the same filter criteria that the dynamic group uses.
-Rex
From what I can tell, nss_ldap and pam_ldap use the same config file in centos, /etc/ldap.conf. So they both use the same proxy user?
What do you mean by dynamic group? I'm open to changing to some other setup.
-Rex
See the dynlist overlay: http://www.openldap.org/doc/admin24/overlays.html
On 15/09/2009, Rex Roof rex@wccnet.edu wrote:
On Sep 15, 2009, at 10:41 AM, Howard Chu wrote:
Rex Roof wrote:
Yes, or a configuration for PAM that limits which users it provides information for.
PAM doesn't return user information at all. This is strictly for nss- ldap. You could also add a filter to nss-ldap's config file. Unfortunately the most straightforward filter (memberOf=<the group DN>) won't work with OpenLDAP's memberof overlay. If your group was actually a dynamic group, then you could use the same filter criteria that the dynamic group uses.
-Rex
From what I can tell, nss_ldap and pam_ldap use the same config file in centos, /etc/ldap.conf. So they both use the same proxy user?
What do you mean by dynamic group? I'm open to changing to some other setup.
-Rex
Thanks to everyone on this list that helped with this problem. The answer (as with most answers) was in the documentation:
[from `man nss_ldap`]
nss_base_<map> <basedn?scope?filter> Specify the search base, scope and filter to be used for spe- cific maps.
I created a nss_base_passwd line looking like this:
nss_base_passwd ou=Accountssub?|(uid=user1)(uid=user2)(uid=...
it's dirty, but works until I upgrade to OpenLDAP 2.4 and can use the memberOf= search filter.
This successfully limits the output of getent passwd to just the users I want. It also limits the info that finger gives to just those users.
Hope this helps someone else. -Rex
On Sep 16, 2009, at 1:49 AM, Gavin Henry wrote:
See the dynlist overlay: http://www.openldap.org/doc/admin24/overlays.html
On 15/09/2009, Rex Roof rex@wccnet.edu wrote:
On Sep 15, 2009, at 10:41 AM, Howard Chu wrote:
Rex Roof wrote:
Yes, or a configuration for PAM that limits which users it provides information for.
PAM doesn't return user information at all. This is strictly for nss- ldap. You could also add a filter to nss-ldap's config file. Unfortunately the most straightforward filter (memberOf=<the group DN>) won't work with OpenLDAP's memberof overlay. If your group was actually a dynamic group, then you could use the same filter criteria that the dynamic group uses.
-Rex
From what I can tell, nss_ldap and pam_ldap use the same config file in centos, /etc/ldap.conf. So they both use the same proxy user?
What do you mean by dynamic group? I'm open to changing to some other setup.
-Rex
-- Sent from my mobile device
http://www.suretecsystems.com/services/openldap/ http://www.suretectelecom.com
openldap-technical@openldap.org
-
Brett ＠Google -
Buchan Milne -
Gavin Henry -
Hallvard B Furuseth -
Howard Chu -
Jonathan Clarke -
Rex Roof -
Roof,Rex