Here's a "real world" example that we hope both illustrates why we're choosing to implement security as we have, and gives you a sense of how it can reduce your workload.
The Scenerio
Let's say that the folks running the Remedy system on campus want to provide some files, but not anonymously.
In a perfect world, only the Remedy Admins would be able to update the files, only current Remedy Users would be able to access or even list the them, and they would be available regardless of workstation platform.
Traditional Implementations
Traditionally, it's extremely hard to even approach the perfect world just described.
The Remedy Admins would have to maintain a minimum of two access control lists, as an example both an .htaccess file to control read via a web page, and some sort of access control in AFS or whatever native filesystem was serving the web pages (to allow the admins write access). Whenever any Remedy User or Admin came or went, the appropriate access control list would have to be hand updated.
For groups with high turnover or even slightly decentralized administration, this model quickly becomes a nightmare (if done dilligently) or a security hole (if not done dilligently)
Unity.AD best practice
To implement this sort of access control in the Windows Unity environment, the following steps were performed ONE TIME ONLY.
- Two domain-local groups were created, ITD_Remedy_Locker_FullAccess and ITD_Remedy_Locker_ReadOnly, to control full and read only access to the files.
- A "locker" was created on a fileserver, with the domain local groups set up for full and read-only access.
- The Autogroups REMEDY_Remedy and All_Remedy were added as the only members of the ITD_Remedy_Locker_FullAccess and ITD_Remedy_Locker_ReadOnly security groups.
The REMEDY_Remedy and All_Remedy groups are automatically populated each night. All such groups have the suffix "_Remedy" which makes them look pretty wierd, but they're useful non the less. A complete list of AD Groups based on Remedy is at http://microsys.unity.ncsu.edu/status/Remedy-Autogroups.html .
Everyone assigned to the REMEDY workgroup in the Remedy application make up the membership of the REMEDY_Remedy domain local AD group, and All_Remedy is a domain local group whose members are all the Remedy groups.
So, anyone who is actual an Admin, in the sense that they're a member of the workgroup supporting the Remedy system, is automatically granted access to the locker with full access control.
If they change their job functions such that they are no longer responsible for Remedy, they will automatically have their access privileges to the locker changed appropriately.
By the same token, the Remedy Admins do not need to grant or revoke locker access to their users. All they do is manage Remedy, and the autogroups will automatically take care of providing or removing access to the filesystem via the All_Remedy group.
For the pilot, we're only targeting access from Windows computers, but in production we'll support SMB access from other systems, like Linux and Mac machines. For remote access, we'll have some sort of WebDav or other remote access system, in addition to VCL.
Sysnews
Unity Forums
Microsys Blog
Documentation