CSED 431 Week 13 -- April 26


Folder redirection

Can I redirect to \\server\folder\pld without group policy? Should work!

Groups v OUs

Reference: http://www.informit.com/articles/article.aspx?p=680826

Groups are generally used for permissions: file permissions are possible, but printer permissions and assignment of system "rights" are two other common uses. In fact, the proper name for a group is security group.

Groups can themselves be members of other groups. If group room212 is a member of group seventhgrade, then the members of group room212 automatically get any rights or permissions allowed to group seventhgrade.

If you're dealing with a "forest" containing multiple domains, you have to decide whether to make groups "domain-local" or "global".

There are some default, or built-in, groups (some of these may be specific to Server 2003):
    Administrators
    Backup Operators
    DHCP Administrators
    Guests
    Power Users: can manage only resources they have created. However, they can add software, and thus really make a mess.
    Remote Desktop Users
    Network Configuration Operators
    Users

    Domain Admins
    Domain Users
    Domain Computers -- a group of machine accounts
    Account Operators
    Group Policy Creators

Security Groups can be used to manage permissions for:
User Rights Assignment is found under Local Security Policy (and Group Policy). Values here are groups, which receive the right in question. The similar Security Options have values that are essentially enabled/disabled or some other selection as to response type.

When windows has to decide if a given user is allowed to do something, all groups that user belongs to must be checked. This is straightforward for windows, but sometimes tedious for the rest of us: it is an excellent strategy to keep security-group structure as simple and transparent as possible.
   
Groups are created and modified using Active Directory Users and Computers.

Groups belong to domains and OUs. However, if a group is a member of an OU, then the members of that group do not also have to be in that OU. This is only slightly odd.

Note that we can browse each group's members.

I'm not sure if ordinary users can create groups within a domain. (To make that more precise, the permissions to allow this are there, but I'm not sure if they're enabled by default, or if there are bad consequences if you do this.) This is possible in standalone XP. A reason you'd want that is if you wanted to share a few files with an ad-hoc set of coworkers, not having to seek IT intervention to set up the group is a big win.

Delegation

How can you give each teacher authorization to create accounts for his/her students, or authorization just to reset those passwords?

From the Delegation of Control Wizard:
This wizard helps you delgate control of Active Directory objects. You can grant users permission to manage users, groups, computers, OUs, and other objects stored in and Active Directory domain.

You delegate control of (attributes of) an OU (or other AD object or container) to a group. You cannot delegate control to an OU. Thus, if you want to delegate a certain degree of authority to everyone in an OU, you have to create a security group for the authority in question, and manually add everyone in the OU to the group. And keep the two synchronized as you add users to the OU. It's probably best not to think in terms of OUs for permissions.

For OU objects, the DoC Wizard lets you set the following options:
Example: labadmins is a security group that is part of the labusers OU, and has authority to reset labusers passwords. However, its one member, alicia, is not a member of the labusers OU.

Additional problem: alicia is not allowed to log on to the domain controller! How can she reset passwords?

Answer 1 (not ideal): modify default domain-controller policy (or create a "local domain-controller policy" overriding it). Then Alicia can log on to the DC, and gets a limited version of ADU&C.

Answer 2 (better): install the Windows Server 2003 Administration Tools Pack ("adminpak"). This lets (properly delegated) users make all sorts of AD changes (including GP editing) from ordinary domain-member computers.

Here's an example from the internet: organize your users into per-department OUs, and then delegate password-reset authority to one member of each department. Is this a good idea? Here's the problem: if the department manager is a member of the dept OU, then you've just granted a lower-level staff person the right to reset the manager's password. This is not good design, even if it works for you for a while (though a simple fix is to put all managers into a "managers" OU, and also to make sure that the password-changer signs a statement that they understand they are not to use the feature to access accounts).

Delegation for Group Policy

This is handled within the GP Management console. If you click on an OU or a GPO, there is a tab labeled "Delegation". This allows you to delegate control for that OU or GPO (realistically you'd want to do this to the GPO). You don't have terribly fine-grained control over which settings you want to allow the delegated user to edit, though.

More seriously for our purposes, the Remote Admin Pack does not include a remote Group Policy Editor, so if you delegate control over a GPO to a user, you have to allow that user to use the Domain Controller to make changes. There may be a remote GP editor available, though.
   

RAID

The original acronym was "Redundant Array of Independent Disks", but most people replace the "Independent" with "Inexpensive"; the idea is that you can create huge virtual disks by using cheap ones as building blocks. But with 1TB single-disk units available, there's more to this than cost savings, particularly since you will need some kind of upscale disk controller (eg SCSI; you might get away with SATA) to get this to work.

There are several "levels" of RAID, some of which are not really relevant to our concerns. Raid 0 is "striping": distributing disk blocks across multiple disks so that large-volume I/O can be done in parallel. That is, if we have 4 disks, we distribute data blocks 1,2,3,4,5,6,7,8 so 1 and 5 are on disk 1, 2 and 6 are on disk2, 3 and 7 are on disk 3, and 4 and 8 are on disk 4. More specifically, RAID blocks 1 and 5 are on disk1's physical blocks 1 and 2; RAID blocks 9, 13, 17 are on disk1 physical blocks 3,4,5.

Raid 1 is "mirroring": setting up two disks to be identical so that if either fails, the data is still there. That's important, but expensive.

The classic formulation of RAID is RAID 5, a combination of striping and error-correcting. We'll start with a formulation that is technically RAID 4. We'll start with 6 disks here; you can use any smallish number. Disk1-disk5 have striped data and disk6 has XOR "checksums" of the corresponding physical blocks of the other disks.

XOR (eXclusive OR) is well-behaved. Note A xor (B xor C) = (A xor B) xor C, and A xor B = B xor A, and A xor A = 0 (a block of all 0 bits). Also, A xor 0 = A. As a result, if A xor B = C, then C xor B = A xor B xor B = A; that is, we can "solve" for A.

A simple and effective encryption scheme is to generate a pseudorandom sequence of bytes (or blocks) Ri, and then if Di is the ith data byte, let the encrypted byte be Ei = Di xor Ri. Nothing more is needed (though the Ri need pretty good pseudorandomness).

disk1
 disk2
 disk3
 disk4
 disk5
 disk6
data1
 data2
 data3
 data4
 data5
 XOR of 1-5
data6
 data7
 data8
 data9
 data10
 XOR of 6-10
data11
 data12
 data13
 data14
 data15
 XOR of 11-15

To read a block, we just read the disk with the data (this requires figuring out which block it is).

To write: disk 6 gets written for every block , because the XOR needs to be updated. (Because XOR is pretty simple, we don't need to read all the other disks; we can just get XORnew = XORold XOR (dataNnew XOR dataNold)

To recover: if disk6 dies, just recompute the XORs. If disk1-5 dies, assume for definiteness that it is disk1. Then we had
    data1 xor (data2 xor data3 xor data4 xor data5) = disk6_block1
and so
    data1 = disk6_block1 xor (data2 xor data3 xor data4 xor data5)
That is, data1 can be recovered.

Typically, if an error in a disk is encountered, then a hot spare is activated, and that particular disk is entirely reconstructed onto the hot spare.
    
True Raid5: distribute the XOR blocks, so, for example, the XOR block is column 6 of row 1, but column 5 of row 2, column 4 of row 3, down to column 1 of row 6, and back to column 6 of row 7.
     
Bottleneck: on every write, two physical blocks get written. Can these be done in parallel?
     
This brings us to hardware RAID v software RAID. Other advantages of hardware raid: can be used as boot device.
     
Drawbacks to hardware raid: dependent on hardware type. If your controller dies and is no longer available, you're in trouble.

RAID 6 features, for N disks, two independent checksum disks, such that we can recover from the loss of any two disks. Finding an appropriate second checksum is a fairly deep mathematical process.

Wireless

General view

iwlist wlan0 scan

A "station" (that is, a wireless computer) must associate with an access point before any traffic can flow! This is sort of a software equivalent of plugging in, except that you have to be in range (I guess you have to be in range to plug into a wire too).

What about using wireless networks for a classroom lab? There are a few problems:
We're not even talking about the eavesdropping problem. Even read-only eavesdropping would allow an outsider to use your internet connection. The solution is encryption, using WPA or WPA2. The problem is then key management: how do you make sure every machine has the appropriate keys?


Lab

1. Install the Windows Server 2003 Administration Tools Pack on a domain-member computer (this works fine, even if the domain is Server 2008). It should be in the linux folder ~/virtual/adminpak, which should be mountable in windows as \\vboxsvr\virtual. The website is:
http://www.microsoft.com/downloads/details.aspx?FamilyID=C16AE515-C8F4-47EF-A1E4-A8DCBACFF8E3&displaylang=en
(note that what you get upon downloading is a self-extracting .exe zipfile; upon extraction it contains a .msi installer file, which is what the adminpak folder contains.)

(For win7 computers, install http://www.microsoft.com/downloads/details.aspx?FamilyID=7D2F6AD7-656B-4313-A005-4E344E43997D&displaylang=en.)

2. On the domain controller, create an OU, eg labusers. Add a user. (You can reuse an existing OU or user if you want.)

3. On the DC, create a new group within the OU, eg labadmins.

4. On the DC, create a user outside the labusers OU to the labadmins group.

5. On the DC, delegate "reset passwords" authority to the group.

6. Verify that if you log on to a domain-member computer using the labadmins-member account, you can reset the password of the labuser account from step 2.

7. Go back to step 5, and delegate "add users" authority.

8. Verify that you can add users from the domain-member computer.