Some partial solutions


> 1. One way to change a site's password policy is to edit the 
> Default Domain Policy GPO. What is the drawback to that approach,
> and what is an alternative approach?

The drawback is that it is rather hard to keep track of accumulated changes
made to the Default Domain Policy GPO. The alternative is to create a second
GPO, say Local_Mods, and apply that with higher priority (smaller link-order
number) than the Default Domain Policy. Local_Mods will just contain GPO 
settings that differ from the Microsoft default.


> 2. What are some of the advantages and drawbacks to giving each user their 
> own individual profile?

This allows users to make their own persistent configuration settings.
The drawbacks include the need to provide disk space, the overhead in
fixing profile problems, and the support overhead in dealing with those who
have configured something into brokenness. Finally, if users are not being
assigned individual disk space, individual profiles mean the difference
between needing to support individual accounts and passwords and being
able to adopt a much simpler system where everyone is, as far as 
Windows is concerned, the same user.


> 3. If all users share the same profile, you probably want to disallow 
> saving icons on the desktop. How could you implement that restriction 
> using file permissions?

Make the Desktop folder read-only.


> 4. What are some other system restrictions you might want to implement 
> if all users share the same profile?

It is important in this case to make it impossible for anyone to change
anything relating to the functionality of the system: the start menu,
the screen background, icons, and resolution, system drivers, etc.


> 5. Discuss how to use multiple Organizational Units (OUs) to arrange 
> for decreasing system restrictions for freshmen, sophomores, juniors, 
> and seniors.

We can create four DISJOINT OUs for the four classes, and rely on 
eternal vigilance to ensure that the restrictions are never increased
for older students. In practice this can be difficult to achieve.

Alternatively, we can create four NESTED OUs, called, say, First, Second,
Third, and Fourth, and nested as 
	Fourth contained in Third
	Third contained in Second
	Second contained in First
Each would have an associated GPO. Seniors would be contained in the First OU,
but not Second, and woudl be subject only to the First GPO. Juniors would
be members of Second but not Third, and would be subject to the GPOs 
First and Second, down to Freshmen who would be members of the Fourth OU and
would be subject to all four GPOs.

It is NOT an automatic consequence of this scheme, however, that the
restrictions never get stronger as students get older: it is perfectly possible
for a weaker OU to override a stronger one (I did this by accident, in fact,
when I created a 3-char-min-password OU that overrode a 10-char-min-password OU.)
However, it is much easier to audit nested OUs manually for progressive 
strengthening than it is to audit disjoint OUs.


> 6. Suppose you want juniors to encounter more restrictions than seniors, 
> but also to have special permissions (reduced restrictions) for students 
> (either juniors or seniors) in the theater class. Explain why OUs may not 
> be the easiest way to implement this, and suggest an alternative.

The problem with achieving this with OUs is that OUs must be nested,
and the Theater students are not a subset of Juniors nor vice-versa.

One alternative is to have Junior and Senior OUs, and to create a Theater 
*group*. Either juniors or seniors could be added to the group (anyone can
be added to any group). This approach requires that it be possible to 
offer the necessary added permissions through group membership; any GPO
rule can be applied to an OU but not every rule can be applied to groups.
Many rules can, however, and in practice this approach often works well.

 
> 7. Suppose we have two GPOs, G1 and G2, linked (in that order) to an OU A. 
> Any user or machine in A, then, is subject to both G1 and G2. 
> Explain how we could achieve the same effect using two nested OUs, 
> each associated with a single GPO. 

By "in that order" I guess I meant that G1 is applied first, and so G2
overrules G1. Using nested OUs, we would create OU1 and OU2, attach G1 to 
OU1 and G2 to OU2, and then put OU2 *within* OU1. Any host or user in OU2
would thus be subject to G1 and then G2, as desired.


> 8. Suppose we want to leave a certain software application, foo.exe, 
> on the machine, but prevent its use by students.
> (a). Suppose we remove it from the student start menu. Can students 
> still run the program? If so, how?

They can still run the program if they can migrate to the folder where
foo.exe is contained, and click on it. Alternatively, if they have the
full path to foo.exe, they can launch the program through CMD.EXE or
through Visual Basic scripting.


> (b). Suppose we make the software readable by everyone, but we DENY 
> execute permission to the STUDENTS group. Can students still run the 
> program? If so, how?

Alas, this is still not quite good enough: students cannot now execute
foo.exe, but if they can read it they can *copy* it, and they can then
execute the copy. A better approach is to make the software executable
but also non-readable.