John A. Sullivan III wrote: > On Wed, 2008-11-19 at 12:21 -0800, George Holbert wrote: > >> John A. Sullivan III wrote: >> >>>> John A. Sullivan III wrote: >>>> >>>> >>>>> Hello, all. We're trying to move all our user access control to DS >>>>> including file system rights management and thus group management. >>>>> We've hit a few problems and would like to share how we've gotten around >>>>> them both for documentation and so someone with more experience can tell >>>>> us if we are going about this the wrong way. >>>>> >>>>> The first problem we hit was the various hosts could not resolve the >>>>> gidnumber to a name: >>>>> -sh-3.2$ id -gn >>>>> id: cannot find name for group ID 2000 >>>>> 2000 >>>>> >>>>> We noticed in the access query that the hosts were looking for >>>>> posixgroups: >>>>> SRCH base="dc=ssiservices,dc=biz" scope=2 >>>>> filter="(&(objectClass=posixGroup)(gidNumber=2000))" attrs="cn >>>>> userPassword memberUid uniqueMember gidNumber" >>>>> >>>>> The problem comes with user's initial groups which are typically named >>>>> after the uid. Since we had not created these explicitly as DS groups >>>>> but rather simply assigned the gidnumber in the posixaccount's gidnumber >>>>> attribute, there was no posixgroup to seek. >>>>> >>>>> I suppose the ideal way to address this is the change the query to look >>>>> for a posixgroup or a posixaccount. I do not see how one does this. >>>>> Instead, we added posixgroup as an objectclass to the users. Is this a >>>>> reasonable way to go about this? >>>>> >>>>> Then we hit our next problem. The user's initial group is usually the >>>>> same as their uid, e.g., user bsmith belongs to group bsmith. However, >>>>> the query is looking for cn rather than uid. I suppose this is because >>>>> a posixgroup, as opposed to a user, does not have a uid but does have a >>>>> cn. This turned up as a problem where we wanted to control the umask in >>>>> bashrc which uses logic such as: >>>>> if [ $UID -gt 99 ] && [ "`id -gn`" = "`id -un`" ]; then >>>>> umask 002 >>>>> id -un would return bsmith but id -gn would return something like Brian >>>>> Smith. >>>>> >>>>> Thus, we will need to make it a user creation procedure to override the >>>>> cn to be the same as the uid rather than FirstName LastName. Is this >>>>> the correct approach? Thanks - John >>>>> >>>>> >>>>> >>> On Wed, 2008-11-19 at 11:17 -0800, George Holbert wrote: >>> >>> >>>>> -sh-3.2$ id -gn >>>>> id: cannot find name for group ID 2000 >>>>> 2000 >>>>> >>>>> >>>> ... >>>> >>>> >>>>> Instead, we added posixgroup as an objectclass to the users. Is this a >>>>> reasonable way to go about this? >>>>> >>>>> >>>> Not really... >>>> id is asking your name service "what is the group name for gid 2000". >>>> You have no groups defined in your name service with that gid. >>>> The most common way to address this is to add a posixGroup object in >>>> your LDAP directory with gid 2000, and whatever name (cn) you like. >>>> I would suggest doing this for each account's primary gid. >>>> >>>> >>> <snip> >>> >>> Thanks for the reply. Perhaps this is a better approach but I have some >>> reservations (which may be more my ignorance than a real problem). If I >>> do this, I have the separate step of maintaining posixgroups for each >>> user in a separate entity. Not only must I create two instead of one >>> (times however many thousands of users I have) but I must keep them in >>> sync (user delete, user rename). >>> >>> By adding a posixgroup objectclass to my users, I solve those problems >>> and still give my name service a way to resolve the group name. It >>> seems much simpler to manage but I'm just not sure if this does >>> something "bad". Am I missing something? Thanks - John >>> >>> >> Most (if not all) LDAP client software that accesses posix attributes >> will not expect this arrangement. >> Most sysadmins or developers that might work with your directory >> probably would also not expect this. >> Those are the biggest drawbacks that come immediately to mind. >> But depending on your usage, might never be a serious problem. >> >> This is a good time to ask yourself: >> Do you really need a corresponding groupname / gid for every username / >> uid in your name service? >> >> The answer might certainly be "yes". >> But since you're spending time to accommodate this, could be helpful to >> be sure you have reasons beyond rote tradition. >> >> > <snip> > Thanks for the very thoughtful answer. I'm not only new to LDAP but > also to Linux based file servers. I've been in a management role for > the last decade and before then was doing NDS and NetWare for > directory/file. > > We were planning to use a umask of 007 for standard users and set the > sgid bit for shared folders. That's where we thought it would be > helpful to have a group associated with each user. In fact, it finally > made the default setup of creating a group for each user make sense as I > always wondered why that was done. I suppose we'll also need to > activate file system acls for more complex setups as when multiple > groups need varying access to a shared file system directory. > > If that's a silly approach, kindly let me know and point me to some good > documentation on the subject. Thanks - John > Sounds like you do have some good (non-silly) reasons. Just be aware the hybrid posixGroup / posixAccount thing is a unique approach, that might well set you up for uniqueness you won't want down the road.
