Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
Regards
On 03/14/13 12:52 +0000, Gerhardus Geldenhuis wrote:
Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
You apparently have this in your ldap tree:
memberUid: uid=ggeldenhuis,ou=People,dc=example,dc=com
for your adm group. Instead, that should be:
memberUid: ggeldenhuis
Regardless, your group names and guids *should* be unique to the system.
You could remove the entry that's located in /etc/group or, instead of creating an ldap adm group, you could specify a gidNumber of 4 for uid=ggeldenhuis, which will place the user in the group - 'groups ggeldenhuis' should then report the user as a member of adm.
Thanks Dan, That is working much better now... However I still have two group showing and not sure what determines which group entry will be honoured. At the moment the ldap group settings is honoured but not sure if that would always be the case. nsswitch is set to files ldap so by that logic it should not work... as in if files are queried first then it should show that I am not a member of adm unless the OS just assumes 4 is 4 regardless of the source.
Just to clarify how I am testing: If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
My user has another primary group so I am unable to specify the gid as 4.
So my question really is which group would get preference to specify membership and how/where is that determined?
Another alternative is to use /etc/security/groups.conf but a note in the default config file recommends against it... so that would be a last resort to determine group membership upon login.
Regards
On 14 March 2013 13:45, Dan White dwhite@olp.net wrote:
On 03/14/13 12:52 +0000, Gerhardus Geldenhuis wrote:
Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=**People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
You apparently have this in your ldap tree:
memberUid: uid=ggeldenhuis,ou=People,dc=**example,dc=com
for your adm group. Instead, that should be:
memberUid: ggeldenhuis
Regardless, your group names and guids *should* be unique to the system. You could remove the entry that's located in /etc/group or, instead of creating an ldap adm group, you could specify a gidNumber of 4 for uid=ggeldenhuis, which will place the user in the group - 'groups ggeldenhuis' should then report the user as a member of adm.
-- Dan White
On 03/14/13 15:02 +0000, Gerhardus Geldenhuis wrote:
Thanks Dan, That is working much better now... However I still have two group showing and not sure what determines which group entry will be honoured. At the moment the ldap group settings is honoured but not sure if that would always be the case. nsswitch is set to files ldap so by that logic it should not work... as in if files are queried first then it should show that I am not a member of adm unless the OS just assumes 4 is 4 regardless of the source.
Think of libnss as a database which returns entries. getgrent(3), and related system calls, makes use of that data without regard to the source of the information.
If 'getent group' is returning two entries for a given name, that is equivalent two sticking 'adm' into /etc/group twice, which is a bad idea, and may lead to ambiguous scenarios. Even though things may seem to work in spite of that, different applications may treat that data differently now or in the future.
I recommend:
1) removing adm from /etc/group OR 2) simply adding your ldap user (ggeldenhuis) to the adm entry in /etc/group
Just to clarify how I am testing: If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
My user has another primary group so I am unable to specify the gid as 4.
So my question really is which group would get preference to specify membership and how/where is that determined?
Another alternative is to use /etc/security/groups.conf but a note in the default config file recommends against it... so that would be a last resort to determine group membership upon login.
Regards
On 14 March 2013 13:45, Dan White dwhite@olp.net wrote:
On 03/14/13 12:52 +0000, Gerhardus Geldenhuis wrote:
Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=**People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
You apparently have this in your ldap tree:
memberUid: uid=ggeldenhuis,ou=People,dc=**example,dc=com
for your adm group. Instead, that should be:
memberUid: ggeldenhuis
Regardless, your group names and guids *should* be unique to the system. You could remove the entry that's located in /etc/group or, instead of creating an ldap adm group, you could specify a gidNumber of 4 for uid=ggeldenhuis, which will place the user in the group - 'groups ggeldenhuis' should then report the user as a member of adm.
Thanks, That is an emphatic no then. I appreciate the clarification.
Regards
On 14 March 2013 15:22, Dan White dwhite@olp.net wrote:
On 03/14/13 15:02 +0000, Gerhardus Geldenhuis wrote:
Thanks Dan, That is working much better now... However I still have two group showing and not sure what determines which group entry will be honoured. At the moment the ldap group settings is honoured but not sure if that would always be the case. nsswitch is set to files ldap so by that logic it should not work... as in if files are queried first then it should show that I am not a member of adm unless the OS just assumes 4 is 4 regardless of the source.
Think of libnss as a database which returns entries. getgrent(3), and related system calls, makes use of that data without regard to the source of the information.
If 'getent group' is returning two entries for a given name, that is equivalent two sticking 'adm' into /etc/group twice, which is a bad idea, and may lead to ambiguous scenarios. Even though things may seem to work in spite of that, different applications may treat that data differently now or in the future.
I recommend:
- removing adm from /etc/group
OR 2) simply adding your ldap user (ggeldenhuis) to the adm entry in /etc/group
Just to clarify how I am testing:
If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
My user has another primary group so I am unable to specify the gid as 4.
So my question really is which group would get preference to specify membership and how/where is that determined?
Another alternative is to use /etc/security/groups.conf but a note in the default config file recommends against it... so that would be a last resort to determine group membership upon login.
Regards
On 14 March 2013 13:45, Dan White dwhite@olp.net wrote:
On 03/14/13 12:52 +0000, Gerhardus Geldenhuis wrote:
Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=****People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
You apparently have this in your ldap tree:
memberUid: uid=ggeldenhuis,ou=People,dc=****example,dc=com
for your adm group. Instead, that should be:
memberUid: ggeldenhuis
Regardless, your group names and guids *should* be unique to the system. You could remove the entry that's located in /etc/group or, instead of creating an ldap adm group, you could specify a gidNumber of 4 for uid=ggeldenhuis, which will place the user in the group - 'groups ggeldenhuis' should then report the user as a member of adm.
-- Dan White
Just a little bit of follow up, I would have preferred to do all user and group management in ldap. We are reluctant to get rid of the adm group because of reliance on it from other services. In the case authentication failure (ldap) it would mean the server can still function without any problem. We can use puppet to configure group members of adm but that fractionates user management.
Regards
On 14 March 2013 15:22, Dan White dwhite@olp.net wrote:
On 03/14/13 15:02 +0000, Gerhardus Geldenhuis wrote:
Thanks Dan, That is working much better now... However I still have two group showing and not sure what determines which group entry will be honoured. At the moment the ldap group settings is honoured but not sure if that would always be the case. nsswitch is set to files ldap so by that logic it should not work... as in if files are queried first then it should show that I am not a member of adm unless the OS just assumes 4 is 4 regardless of the source.
Think of libnss as a database which returns entries. getgrent(3), and related system calls, makes use of that data without regard to the source of the information.
If 'getent group' is returning two entries for a given name, that is equivalent two sticking 'adm' into /etc/group twice, which is a bad idea, and may lead to ambiguous scenarios. Even though things may seem to work in spite of that, different applications may treat that data differently now or in the future.
I recommend:
- removing adm from /etc/group
OR 2) simply adding your ldap user (ggeldenhuis) to the adm entry in /etc/group
Just to clarify how I am testing:
If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
My user has another primary group so I am unable to specify the gid as 4.
So my question really is which group would get preference to specify membership and how/where is that determined?
Another alternative is to use /etc/security/groups.conf but a note in the default config file recommends against it... so that would be a last resort to determine group membership upon login.
Regards
On 14 March 2013 13:45, Dan White dwhite@olp.net wrote:
On 03/14/13 12:52 +0000, Gerhardus Geldenhuis wrote:
Hi Admittedly this is slightly OT but I were hoping someone could point me in the right direction.
I want to be able to grant LDAP users group membership to local groups on a Ubuntu box. For example the adm group.
How would I go about doing this?
As a very quick test I created a adm group in ldap but it is not having the desired effect. Output from getent group | grep arm
adm:x:4: adm:*:4:uid=ggeldenhuis,ou=****People,dc=example,dc=com
The first adm group is the local file group and the second my ldap group.
Am I going about this in the wrong way... ?
You apparently have this in your ldap tree:
memberUid: uid=ggeldenhuis,ou=People,dc=****example,dc=com
for your adm group. Instead, that should be:
memberUid: ggeldenhuis
Regardless, your group names and guids *should* be unique to the system. You could remove the entry that's located in /etc/group or, instead of creating an ldap adm group, you could specify a gidNumber of 4 for uid=ggeldenhuis, which will place the user in the group - 'groups ggeldenhuis' should then report the user as a member of adm.
-- Dan White
On Thu, 14 Mar 2013, Gerhardus Geldenhuis wrote:
Just to clarify how I am testing: If my user is part of the adm user in Ubuntu it can less log files if not then it can't less log files. Adding myself to an ldap based adm group gives me the abillity to access the log files but as said above this does not seem to correlate with what nsswitch is configured to do.
I don't know if this is your actual use case, but a classic trick for file access is to make multiple groups:
adm:*:4:foo adm2:*:4:bar
with the same gid. Then you'll initgroups() the proper gid (regardless of if you're in adm or adm2) and the kernel should let you less log files or whatever. In your environment, you might consider it safe to even have adm on disk and adm2 in LDAP.
Things can get less clear for userspace programs that might do a getgrnam() or similar, of course...and for sysadmins thereof.
Just a little bit of follow up,I would have preferred to do all user and group management in ldap. We are reluctant to get rid of the adm group because of reliance on it from other services. In the case authentication failure (ldap) it would mean the server can still function without any problem. We can use puppet to configure group members of adm but that fractionates user management.
If your main concern is (potentially) offline access to LDAP this has been approached dozens of times at every possible layer. As an example of doing this on the OpenLDAP side, a local slapd(8) fed with syncrepl providing nssov can gracefully resync as network is available and still function fully when detached (for example, on a laptop or other poorly connected site). There are options at other layers (e.g. offline-aware nss providers) as well.
openldap-technical@openldap.org