Hi,
In my OpenLDAP server, it is possible to set a user as a member of a group, but it has another group as its primary group (I am using "LDAP Admin" as LDAP client tool). For example, in group1, I can see user1 as its "memberUid" attribute, but the "gidNumber" attribute of user1 is group2.
I'd like to know if this is a reasonable configuration, and in this case, should I consider user1 as the member of group2 too? For example, if I configure a machine to only allow gruop2 to login, can user1 log into that machine?
BTW, I do not know how to configure PAM to only allow a group or some groups to login the machine, if anyone can tell me the steps, it will be really appreciated!
Thanks, Qian
Le 01/08/2012 16:21, Qian Zhang a écrit :
Hi,
In my OpenLDAP server, it is possible to set a user as a member of a group, but it has another group as its primary group (I am using "LDAP Admin" as LDAP client tool). For example, in group1, I can see user1 as its "memberUid" attribute, but the "gidNumber" attribute of user1 is group2.
I'd like to know if this is a reasonable configuration, and in this case, should I consider user1 as the member of group2 too? For example, if I configure a machine to only allow gruop2 to login, can user1 log into that machine?
BTW, I do not know how to configure PAM to only allow a group or some groups to login the machine, if anyone can tell me the steps, it will be really appreciated!
Actually, those kind of question are not specific to openldap, nor to any other ldap implementation. You'll probably have better answers on dedicated mailing list, such as nss_ldap user list for instance.
Also, you can get the answer to your questions quite easily by editing directly good old /etc/{passwd,group} plain text files, and getent/id commands.
On 08/01/12 22:21 +0800, Qian Zhang wrote:
Hi,
In my OpenLDAP server, it is possible to set a user as a member of a group, but it has another group as its primary group (I am using "LDAP Admin" as LDAP client tool). For example, in group1, I can see user1 as its "memberUid" attribute, but the "gidNumber" attribute of user1 is group2.
I'd like to know if this is a reasonable configuration, and in this case, should I consider user1 as the member of group2 too? For example, if I configure a machine to only allow gruop2 to login, can user1 log into that machine?
BTW, I do not know how to configure PAM to only allow a group or some groups to login the machine, if anyone can tell me the steps, it will be really appreciated!
Yes. That's known to work.
The gidNumber should define the user's primary group. Otherwise, group membership (memberUID) attributes will define group membership as well. From your application's perspective, since it makes system getpwent/getgrent calls, there should be little difference between your described scenario and:
/etc/passwd: user1:x:<uidNumber>:<gidNumber>:.....
/etc/group: <group1>:x:<other_gidNumber>:user1
The function of mapping your LDAP groups to system groups is dependant on installing an nss ldap plugin, but this should be basic functionality among all of them.
Be aware that installing an nss ldap plugin to resolve group membership *can* be very resource intensive, since each call to getgrouplist(3), such as when ssh'ing into the host, can result in your entire ldap group OU being iterated over. Appropriate indexing and caching is critical.
Thanks Dan!
Basically, I also have concern about the performance. Because in that case, when figuring out how many users in a group, I need to not only consider the group's membership (memberUID) attribute, but also user's gidNumber attribute (I am trying to write a Java application talk to my OpenLDAP server with JNDI).
So I tentatively want to ignore that case, and only reply on group's membership (memberUID) attribute to determine group membership, but I am not sure if this is acceptable in general. Hope you can give me some advise :-)
Regards, Qian
On 08/01/12 10:00 -0500, Dan White wrote:
On 08/01/12 22:21 +0800, Qian Zhang wrote:
In my OpenLDAP server, it is possible to set a user as a member of a group, but it has another group as its primary group (I am using "LDAP Admin" as LDAP client tool). For example, in group1, I can see user1 as its "memberUid" attribute, but the "gidNumber" attribute of user1 is group2.
Yes. That's known to work.
Be aware that installing an nss ldap plugin to resolve group membership *can* be very resource intensive, since each call to getgrouplist(3), such as when ssh'ing into the host, can result in your entire ldap group OU being iterated over. Appropriate indexing and caching is critical.
On 08/01/12 23:53 +0800, Qian Zhang wrote:
Basically, I also have concern about the performance. Because in that case, when figuring out how many users in a group, I need to not only consider the group's membership (memberUID) attribute, but also user's gidNumber attribute (I am trying to write a Java application talk to my OpenLDAP server with JNDI).
Right.
So I tentatively want to ignore that case, and only reply on group's membership (memberUID) attribute to determine group membership, but I am not sure if this is acceptable in general. Hope you can give me some advise :-)
If your applications use getgrouplist(3), then you can't just ignore the gidNumber (see the manpage for details) from the passwd database, but you could change the gidNumber to match the secondary group if you're not concerned about the default gidNumber.
If your applications are PAM aware, then you have more flexibility in how your users are authenticated, and may not need to depend on an ldap nss configuration and the gidNumber attribute.
If your applications use getgrouplist(3), then you can't just ignore the gidNumber (see the manpage for details) from the passwd database, but you could change the gidNumber to match the secondary group if you're not concerned about the default gidNumber.
If your applications are PAM aware, then you have more flexibility in how your users are authenticated, and may not need to depend on an ldap nss configuration and the gidNumber attribute.
One of use cases in my application is, OpenLDAP client will be installed in machines, and for each machine, it will be configured (with PAM) to only allow a specific LDAP group to login it. In this case, I am not sure if I need to care about gidNumber attribute or not, i.e., in my previous example, can user1 log into the machine which has been configured to only allow group2 to login?
Thanks, Qian
On 08/03/12 09:13 +0800, Qian Zhang wrote:
If your applications use getgrouplist(3), then you can't just ignore the gidNumber (see the manpage for details) from the passwd database, but you could change the gidNumber to match the secondary group if you're not concerned about the default gidNumber.
If your applications are PAM aware, then you have more flexibility in how your users are authenticated, and may not need to depend on an ldap nss configuration and the gidNumber attribute.
One of use cases in my application is, OpenLDAP client will be installed in machines, and for each machine, it will be configured (with PAM) to only allow a specific LDAP group to login it. In this case, I am not sure if I need to care about gidNumber attribute or not, i.e., in my previous example, can user1 log into the machine which has been configured to only allow group2 to login?
If you were to use nssov, which is distributed in the contrib directory of OpenLDAP, then you could configure 'nssov-pam usergroup [...]' to accomplish that, which can sidestep posixGroup/gidNumber semantics altogether. See the slapo-nssov manpage for details.
There are other ldap pam modules to choose from, distributed by other vendors, with their own solutions to this problem.
On Wednesday, 1 August 2012 22:21:07 Qian Zhang wrote:
BTW, I do not know how to configure PAM to only allow a group or some groups to login the machine, if anyone can tell me the steps, it will be really appreciated!
This isn't specific to LDAP or any other nss plugin, but specific to PAM. You may want to look at the pam_listfile or pam_succeedif plugins, which should both be able to do this for any group (local, LDAP, other nss plugin).
Regards, Buchan
openldap-technical@openldap.org