Administration
This page
Other pages
Account
Windows Server Platforms - Sharing Resources
On this page:
Access Control on Subcontainers
In Moira, each container is owned by an administrator list. Any member of a container's administrator list can assign (pre-stage) machines to the container in Moira, remove machines from the container in Moira, and make other changes (such as populate the "Description" field) in Moira. In general, anyone who is not a member of a container's administrator list cannot perform these actions. (Exceptions: A machine's owner can remove her machine from any container. Also, a machine's owner can add his machine to any container marked as "public.")
So, if two containers in Moira are owned by two different lists, and a user is on one list but not both, then that user has no access to one of the containers. Say "Machines/Metallurgy" and "Machines/Food-Science" are both non-public containers owned by "cont-adm-metallurgy" and "cont-adm-foodsci" respectively, and that "cont-adm-metallurgy" and "cont-adm-foodsci" do not share any members. In this case, no member of "cont-adm-metallurgy" has administrative access in Moira to "Machines/Food-Science" and no member of "cont-adm-foodsci" has administrative access in Moira to "Machines/Metallurgy". This is probably obvious.
Perhaps less obvious is that this is also true for subcontainers in Moira. Say "Machines/Metallurgy" and "Machines/Metallurgy/Smelting" are both non-public containers owned by "cont-adm-metallurgy" and "cont-adm-smelting" respectively, and that "cont-adm-metallurgy" and "cont-adm-smelting" DO NOT share any members. In this case, no member of "cont-adm-smelting" has administrative access in Moira to "Machines/Metallurgy", and, perhaps surprisingly, no member of "cont-adm-metallurgy" has administrative access in Moira to "Machines/Metallurgy/Smelting".
To summarize, in Moira, the access control rights for two containers are independent of whether or not one container is a descendant or ancestor of the other.
The situation in Active Directory is different. By default, WIN.MIT.EDU grants "Full Control" of a container object in Active Directory to the administrator list of the analogous container in Moira. Thus, from our example, "cont-adm-metallurgy" will have "Full Control" over WIN.MIT.EDU/Machines/Metallurgy in Active Directory, and "cont-adm-smelting" will have "Full Control" over WIN.MIT.EDU/Machines/Metallurgy/Smelting in Active Directory. "Full Control" means that the container administrator can create objects in the
container, as well as seize ownership over objects in the container. Once ownership of an object has been seized, the object can be deleted or changed easily. This includes subcontainer objects.
Therefore, in Active Directory, the administrator of a container can eventually seize ownership and change or delete any object in any subcontainer (or descendant container). This means that whereas "cont-adm-metallurgy" has no administrative access in Active Directory to WIN.MIT.EDU/Machines/Food-Science, it can acquire administrative access in Active Directory to WIN.MIT.EDU/Machines/Metallurgy/Smelting.
In summary, in Active Directory, access control rights over a container are effectively inherited from parent containers.
Thus, the semantics of access control of subcontainers is not the same in Active Directory as it is in Moira. This situation would be difficult or tedious to rectify. It is not plausible to change Moira permissions so that container administrators have access to subcontainers. In Active Directory, it is probably impossible to prevent container administrators from being able to gain access to subcontainers without removing administrative rights entirely. So the disparity will probably persist for some time.
Recommendations for Container Creation:
We recommend that a subcontainer's administrator list be a superset of its parent container's administrator list. That is, when creating a subcontainer, the administrator list should either be the same as or include the administrator list of its parent container. This way, container administrators have rights in Moira to the subcontainer, as well as in Active Directory. It is the responsibility of the list owners to maintain this setup.
If this recommendation cannot be followed, (say if the head of the Metallurgy Department's container really doesn't want the ability to administer the Smelting Lab's container) then it is the parent container's administrator's responsibility to respect the autonomy of the subcontainer in Active Directory. The parent container's administrator should be careful not to do anything in Active Directory which would violate the access rights convention as defined in Moira.
Finally, if two containers are really to be administered by different groups, and neither should be allowed to administer the other, and neither administrator wants to take responsibility for being careful in Active Directory, then the best solution is to make neither container a descendant of the other. Whereas Machines/Metallurgy/Smelting would be accessible in Active Directory by the administrator of Machines/Metallurgy, a container named Machines/Metallurgy-Smelting would not.
Access to Distributed File Systems
DFS Troubleshooting
You may from time to time experience a problem accessing a directory within the \\win.mit.edu\dfs namespace, or the namespace itself. This may have been triggered by a problem with DFS including, but not limited to, the following causes:
- A switch in your building goes offline temporarily or is rebooted
- A switch in our machine room goes offline temporarily or is rebooted
- One of the DFS servers goes offline temporarily
- The DFS topology is changed (links are added or removed, replicas are added or removed, roots are added or removed)
Unfortunately, your DFS client caches some information that inhibits a rapid recovery or easy failover to alternate servers. DFS clients cache the portions of the DFS namespace (PKT) for the duration of time specified in the Distributed File System Manager and referred to as the Time to Live (TTL). For DFS 4.1, the PKT was cached for a hard coded 7 days. Windows 2000 servers use 1800 seconds (30 minutes) as the default TTL. All Microsoft DFS clients delete the PKT for a given folder in the DFS tree if not accessed by the TTL expiration or when the client is rebooted, whichever occurs first.
When you run into a problem contacting DFS, perform the following steps to troubleshoot:
- Make sure you are logged into a machine in the WIN domain, as a WIN domain account. If you type "whoami" at a command prompt, you should see something like "WIN\username". (If you see "MACHINENAME\username", you are logged in with a local account.)
- Make sure that you specify the fully qualified domain name. There are certain locations where "\\win\dfs" may not resolve properly. Always specify "\\win.mit.edu\dfs".
- Make sure that your machine is on the network.
- Reboot your machine to effectively flush its DFS cache. After your machine has been rebooted, try to contact DFS again.
- If you still cannot contact DFS after a reboot, please let us know more about the problem. If you can contact DFS after a reboot, but this problem recurs frequently (e.g., every day), let us know that too.
This should mitigate the problems you may encounter with DFS.
 | Note: While all client machines have a copy of the dfsutil.exe that may be used to troubleshoot DFS, many of the options will generate misleading errors unless run by a Domain Administrator. For advanced users, some options of this tool may provide useful information; however, the use of this tool is not recommended for the typical end user. |
Printing
In order to provide additional machine configuration options for container administrators, win.mit.edu has occasionally extended Group Policy. These extensions can be found (via the Windows Group Policy editor, gpedit.msc) in all group policy objects in the WIN domain under Computer Configuration/Administrative Templates/WinAthena Settings.
