Active Directory and Accounts Management

Movitation

It has been our intent that accounts management should be automated and should tie in to Active Directory smoothly. Despite initial agreements on design and methodology, it has been observed that problems continue to appear, apparently as a result of manual activity that does not adhere to standards. In the long run, we intend to deploy an entirely new well-designed AD. However, that prospect is far enough away, and the problems with the current implementation are sufficiently significant, that it has been decided to spend some effort fixing the current situation.

A meeting was held August 14 2008 to discuss this. The results are below.

Planning Meeting Notes

Attendees: Tom, Naji, Nojen, Ray, Jim, Robyn

Presentations: Ray presented an outline of the problems from his point of view. Naji showed the current AD structure. Discussion ensued

Conclusions:

• All ordinary users (not talking about machines or privileged bang-account administrative users) should be in a single OU. This is called "MathUsers". There can be groups within OUs to differentiate permissions, resources, etc.

• All people/accounts should be created automatically via a central mechanism. In practice, this is done by Lori/Matt (accounts@math) by manipulating the control files, not by anybody else by hand directly in Windows / AD directly. Groups and other non-user objects are created manually, but must adhere to naming standards.

• We observe that some accounts and groups are being created in ways that cause problems:
  • manually
  • without all required fields completed
  • with inconsistent naming styles

• This approach must stop:
  • as indicated in previous point.
  • Ray will create a test account so Naji can examine it to expose which fields are being set, and which need to be set. [Account created August 14.]
  • Naji will give Ray a list of all existing groups. [List sent August 15.] Ray will comment on the naming style. Naji and Tom will then develop naming standards.

• The "MathUsers" object currently resides at too low a level in the AD structure. It will be moved up out of the 'Departments' level to the 'mfcfads' level, as a peer to the 'Departments' object. [Naji reports that no GPOs are applied at the Department level OU, so he can safely move the "MathUsers" OU up. Done on August 15.]

• The 'Users' object at the top level is a reserved object in AD and cannot be mucked with. The 'Users' object at lower levels, e.g. within each of the 'Departments', should be present, but empty. Special attributes that currently are accomplished by some special OUs like the 'Dean' can instead be achieved by groups. It will take careful attention to switch these special set-ups to make them standard using groups.

Observations

• There will be a fair bit of work involved in cleaning up the AD entries to make them conform.

• The rules will need to be well publicized to MFCF staff, and enforced. Lack of attention and adherence to the previously agreed upon methodology is a significant reason why we're in this situation now.