On 10/19/07, Darren J Moffat <darrenm at opensolaris.org> wrote: > Jason King wrote: > > Probably not quite the best description, but since I opened my big > > mouth last weekend, thought I should probably go ahead and propose > > this as a formal project. > > > > Currently, all of the supported methods of specifying server access > > control with LDAP (netgroups, or pam_list) involve storing some aspect > > of the policy on the managed systems themselves. As a result, changes > > in policy requires touching all impacted servers. I think it would be > > very useful if this could be centralized in LDAP. > > pam_list was purposely per system rather than held in LDAP. Since you > can use netgroups in pam_list's files that allows you to put the "real" > policy in the LDAP database. It could be extended to look in LDAP as > well but that probably requires defining and deploying a new schema. As > a historical note pam_list actually existed long before we adopted LDAP > as a nameservice even though it was only recently integrated (my oldest > SCCS version for it is 99/10/12).
Moving into LDAP the list of netgroups whose members are allowed to access a particular server is one potential solution. I actually had something a bit more generic in mind, however I wanted to initially avoid focusing too much on a specific solution. I've always thought it strange that LDAP can contain a very rich amount of information about a user, but there is really no easy way to leverage it when it comes to implementing any sort of server policy. This may partially be a philosophical difference -- in my mind at least, the question of who a user is, how they are identified, and what they can do are closely linked. I want one place to manage all of this versus 'go to LDAP for this, but go to individual servers for that'. > > > Also, there is no easy way to do fine-grained control of group and > > role membership for LDAP managed systems and still maintain > > centralized management within LDAP. For example, I might want 'jason' > > to have access to the 'root' role on systemA, but not systemB. Or, on > > systemC, 'bob' should have access to different groups than systemD. > > Any of the ways I can imagine doing this w/ LDAP are not particularly > > pretty (and have problems). > > It shouldn't be limited to LDAP but to any supported nameservice. > > I've implemented the enforcement part before of this and a possible > implementation is in 4986798, have a lot at that CR and see if the > proposed solution meets your needs. That could work as well. It would be interesting to explore the differences in (for lack of a better term that I'm aware of) a 'user-centric' versus a 'host-centric' approach -- do you effectively list the hosts a user has access to or do you list the users allowed on a given host (I'm including in this variations on this theme)? While ultimately the two are equivalent, there might be advantages to representing it in one form or the other (for management or audit, etc.). > > It is great you want to help implement a project however to do this the > hard part (and the reason this hasn't been done already) is extending > smc. Unfortunately smc is also closed source. There maybe light at the > end of the tunnel though if Visual Panels[1] gets traction. At least for the project as I initially envisioned it, I was more concerned about first deciding how to approach it, then implementing the client side. Most of the server side would be more of a configuration exercise than code, so could be done even without the support of mgmt tools (though potential combersome). I would prefer any implementation be optional (i.e. if you don't configure the server side, the LDAP behavior is the exact same as it is today), so would smc be a hard requirement in the face of that? > > Finally I assume since you are proposing a project you actually want to > write code for this rather than you are asking someone else to do so ? > > -- > Darren J Moffat > I'm actually proposing writing the code (either myself or with others interested in doing it). As I said, I have some ideas on how to do this (different from what was suggested), but don't want to lock myself into any particular implementation from the start.
