Description:
There is no way to leverage eDirectory group information through Kanaka except for primary GID, which is a very limited attribute. Without this information, some rights operations become tricky, and a host of scripting possibilities (including home-brewed local MCX via nested groups) becomes impossible.

Proposed Solution:
Upon login, Kanaka should read the group membership attribute on the user record, and then populate these groups (and selected attributes) in the /Kanaka/Groups directory node in the DirectoryService framework in OS X.

That is, Kanaka should populate groups properly in dscl, but should only do so for groups that the currently logged-in user belongs to. I believe this will give us eDirectory group functionality with a minimum of overhead.

Value Proposition:
It would be possible to use eDirectory group membership to make decisions about the user on the local machine. For example, Local MCX (see managingosx.wordpress.com ) could be implemented with a nested group whose members were selected groups in eDirectory. File rights could be granted based upon eDirectory group. Scripts could make decisions based on better eDirectory information.

Comments

  • Make the Kanake Client more like the Windows client, or we will lose customer base by the droves.