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).
One key thing that is missing with netgroup in LDAP is the equivalent of reverse netgroup maps. In NIS, a server can ask "what netgroups does this user belong to?" and get a reasonable answer. In LDAP, the server has to say "give me these netgroups so I can search through them to see if the user is a member." With a large environment, this has the potential to be a performance problem. I thought I heard that there was some ongoing work in this area, but I forget the details. In addition to pam_list, there is pam_access. While NIH, it does offer compatibility with existing Linux deployments and presumably BSD (some of the code in it was lifted from logdaemon which I believe is of BSD heritage). If you are interested in using pam_access as a starting point, I did some clean-up on it a long while back that I would be happy to contribute. Several years ago I was using this across Solaris, Linux, and HP-UX. Of course, if pam_list is more desirable, it should also be rather trivial to port to Linux and others for heterogeneous environments. > > 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. > > 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. Is this intending to imply that to get code into OpenSolaris it must also have appropriate integration with Sun's tools that are not open source? That seems like a reasonable gate to get it into Solaris, which non-Sun people can't do anyway. Having such a gate for OpenSolaris would have the effect of stopping a wide variety of sysadmin focused projects. -- Mike Gerdts http://mgerdts.blogspot.com/ > > 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 > _______________________________________________ > security-discuss mailing list > security-discuss at opensolaris.org > -- Mike Gerdts http://mgerdts.blogspot.com/
