LDAP users and groups, and local groups
Following on from my previous topic:
http://forum.java.sun.com/thread.jspa?threadID=5173933&tstart=20
I have several LDAP users and netgroups, all working well now....
I have posix groups configured, and they all work well too....
E.g. LDAP uid ofdmacphersonis a member of the LDAP posixgroupsuppadmin....
There is an LDAPsuppadmin-ng netgroup which allows access to certain hosts through the +@suppadmin-ng
entry on the passwd and shadow files.
I have localroot users, andsuppapp (application) users and groups on the machines which run the ldap client .
I also have some local users -suppapp is a member of theapplications group.
The local uid forsuppappis 1001
The local gid forapplicationsis 1000
As thesuppappuser runs the application, all the directory structure under which the app files sits is owned bysuppapp/applications
We want the userdmacpherson, who is a member of thesuppadminLDAP posix group to also be a member of theapplicationsgroup, and therefore have the group privileges required to allow access to the files / dirs.
As posixaccounts in LDAP cannot have multiple specified gids, I also created the groupapplications in LDAP with the gid of 1000, and addeddmacpherson as a memberuid.
Now, when using the "groups" command in my clients, I get multiple group memberships -suppappandapplications- but when I try to write a file to a directory with appropriate permissions for the local group applications (again, with the same gid as the LDAP one), I get "permission denied".
Can anyone shed some light on how I should be configuring my LDAP accounts to have multiple group memberships, including local groups on my systems?
Thanks.
[1918 byte] By [
Dougiesica] at [2007-11-27 5:39:05]
# 1
From a quick look it sounds as if you may have the "applications" group defined in both /etc/group and in LDAP. I assume that your /etc/nsswitch.conf has:
group: files ldap
I believe that if you've got the group "applications" defined in both places that you'll only get the version from "files" (i.e. /etc/group).
When in doubt the "getent" command is your most reliable mechanism for checking anything (that it knows of) handled through /etc/nsswitch.conf. So try: "getent group applications" and look at the results.
If that doesn't answer it you want to check if the process is getting the right list of groups. The most reliable command for this is "id -a" (that's an "i" as in Identification) which gets the values for the current process (actually the forked child which should be identical). If id has the wrong values then your problem lies somewhere in the group assignment or process creation path. If id has the right values (unlikely in this case) then you need to look at filesystem security (including features such as ACL's).
Good Luck,
-Scott-
# 2
Hi again Scott,
OK - so you're correct with my nsswitch.conf entries - we look for files before we look for ldap.
Also, you're right about the applications group being listed both in /etc/groups and in ldap.
Our application user exists locally on the machine, and it has its own group -applications, which the directories the app runs under are group owned by.
We want the dmacpherson user (and my colleagues) to be able to log into the machine and have a primary group of suppapp - we're all in the support administration group.
BUT the members of the suppapp group should also have permissions to navigate / edit the filesystem, as if they were in the local applications group, and we don't want to throw the permissions open for "other".
The only way we could seem to get dual memberships to work where one of the groups was a local group was to create groups in both locations with the same gid, and to have the memberuid list on the ldap groups contain the user ids.
It would appear to work for querying, but in practice it doesn't seem to work... my dmacpherson is not allowed to write files which have group write permissions for applications despite the fact that the user is being listed as being a member.
Maybe there is a more practical way of implementing this, but I'm pulling my hair out at present!!!
Below is the (slightly edited) output from the various queries on the dmacpherson user.
root # getent group applications
applications::1000:
root # getent group suppapp
suppapp::1001:
root # id -a dmacpherson
uid=5013(dmacpherson) gid=1001(suppapp) groups=1000(applications)
root # ldaplist -l passwd dmacpherson
dn: cn=Douglas Macpherson,ou=People,dc=test,dc=com
userPassword: <passwd>
gidNumber: 1001
cn: Douglas Macpherson
sn: Macpherson
uid: dmacpherson
uidNumber: 5013
homeDirectory: /
loginShell: /usr/bin/bash
objectClass: top
objectClass: shadowAccount
objectClass: person
objectClass: posixAccount
description:
root # ldaplist -l group suppapp
dn: cn=suppapp,ou=Groups,dc=test,dc=com
cn: suppapp
gidNumber: 1001
objectClass: top
objectClass: posixGroup
description: For people in the admin team
root # ldaplist -l group applications
dn: cn=applications,ou=Localgroups,ou=Groups,dc=test,dc=com
memberUid: dmacpherson
gidNumber: 1000
objectClass: posixGroup
objectClass: top
cn: applications
root # grep applications /etc/group
applications::1000:
root # grep suppapp /etc/group
root # grep dmacpherson /etc/passwd
root #
# 3
I forgot the "id" command could take a user parameter. It actually does two different things depending on whether or not you give it an user parameter:
(1) With a user parameter it's performing it's own series of lookups and calculations to figure out what ID THINKS that user's group SHOULD be. That's what you got. This should also match what a "groups user" command returns.
(2) What I was referring to was to become dmacpherson using the method your normally would and then just type "id -a" w/o a user parameter. In this case it will read the CURRENT unix uid, gid, and secondary group information out of the local process structure. Depending on the options and id variant (/usr/xpg4/bin/id is often useful), you can control whether it gives you real or effective id, etc. This should always be exactly what your process actually is.
One way #1 & #2 can get out of sync is between the time a user's groups are changed in the naming services and the lifespan of login sessions/process trees created before that change. During that time #1 will reflect the way things WILL BE, and #2 will reflect the way things WERE (and still are for some).
Another way #1 and #2 could be out of sync is if #1 somehow didn't calculate the groups correctly. If that is happening (and it might be here) I would consider it a bug.
One option you always have if you're not happy with the results of your LDAP group membership manipulations or need something you just can't express in Unix semantics would be to use FILE based Access Control Lists (ACL's). The main commands to manipulate them are "setfacl" and "getfacl". Unfortunately, few systems administrators know about them (despite the fact they've been around for a long time), it's a real pain to "find" files with ACL's because very few utilities know about them, it's easy to loose them in archives & backups, and because of all of these reasons even fewer sysadmins actually use them. However, if you get your whole team using them and used to them you have added a powerful tool to your arsenal (although normal Unix group manipulations can often reduce the need).
Ok, on to the main issue. "getent group applications" is returning what is presumably the actual entry from /etc/group. This means that the competing LDAP entry is never processed or queried since "files" gave a good answer. That's what I would expect, and with that it doesn't list dmacpherson as a member of the group, so you're not supposed gain it in your list of groups.
Both the "groups dmacpherson" and "id -a dmacpherson" commands are giving you the wrong answer in this case. "getent group applications" is giving you the right answer.
In this configuration I doubt you're ever cleanly going to get the applications being synthesized from the entry in /etc/group and the entry in LDAP. You're probably best off if you don't put the same entry in files and a naming service without very careful consideration that the entry in "files" will override the naming service when the order is "files ldap".
There is one possibility of which might (probably won't) let you combine them. But if you're really committed to this approach (i.e. neither suggestion I make below sounds good) you can experiment with the "SUCCESS=continue" syntax discussed the the nsswitch.conf(4) manual page (but be prepared for a possibly breaking your authentication or boot sequence). There's just enough ambiguity in the phrasing that I don't know how it will behave (don't expect it to be supportable). I wouldn't try myself (except on an experimental system during a slow day).
Simple solution (A): Make sure that everything in (every) /etc/group is represented in ldap and then change /etc/nsswitch.conf to read:
group:ldapfiles
You should be fine as long as "files" contains everything you need to boot up to the point the ldapclient is running and stable, AND if files can still let the sysadmins get in to fix things when ldapclient isn't happy (definitely check that case).
Simple solution (B): Keep the "applications" group out of /etc/group altogether, only listing it within LDAP. This can be combined with (A).
Many people look at (B) and scream "but my applications would all fail if LDAP is down!!!" But, like DNS, if you really use LDAP heavily for naming services then it's likely that your systems and applications will run into plenty of trouble and possibly end up half-broken if there is a failure of LDAP or DNS. So then you focus on making the DNS and LDAP infrastructure robust and capable of supporting mission-critical configurations. Then you end up with significant gains on ease and consistency of administration (which can reduce the number of configuration errors effecting the system -- possibly increasing actual uptime).
At one customer we did exactly this. We had lots (~20-30) of different SAP instances (plus other applications) which had their own dedicated Oracle servers and Application servers. The most mission critical system was clustered. Every Oracle and SAP instance had its own unique set of user accounts that they ran under and were administered by. All of these were exclusively listed in LDAP, not in /etc/group or /etc/passwd (which would have been a pain since some of the accounts & groups had to exist on multiple systems).
We created a dedicated, replicated set of 3 robust infrastructure servers (DNS, Directory Server, NTP, etc), any one of which independently could provide any Sun (or Linux) host with all of the network services they needed (beyond SAP, Oracle, and other application services provided by the nodes themselves). This was integrated with the services provided by the corporate Active Directory infrastructure without creating real-time dependencies which could allow problems to cross over between Active Directory and the Suns. The fact that this created strong fault isolation for the mission critical Suns combined with the fact that only a single team would be required to resolve such failures of the mission critical Suns, justifying the separate infrastructure (which Identity Management could have integrated achieving all of the business goals of the customer).
