AdSync validated for the plant network

Last week my AdSync application was validated for running on the plant network.

The plant network exists for running the DCS application that controls everything and the kitchen sink. The application runs on a different desktop as some sort of kiosk application. This means that the users have no access to the windows desktop.

The user management of this network is completely implemented within the DCS software. This means that all groups and privileges are application defined. I can create new groups and modify permissions, but all of that stays within the application. Of course the user accounts themselves exist in Active Directory, but everything that is DCS related (groups and permissions) is configured in an application database.

The main reason that this is done (I think) is that the software can also run in a workgroup environment where no Active Directory exists. Imo they should deprecate this and switch to AD only as soon as possible. It's not like there's any reason not to run a domain, given the size of the networks for which this software is intended.

Anyway, this is a bit of a problem because people get assigned to groups, based on the department they are working for, and the things they need to do. E.g. people are in the QA group, or Automation, or Technology…

So far so good, but unfortunately, the department someone is in also has implications for Active Directory. Automation people need to be able to reboot certain servers, including the domain controller. The technology group needs a protected folder on the fileserver for storing the reports they generate for the FDA filing of our product…

Before now, there was no way to handle all these things, other than manually creating groups and assigning people to it on an as-needed basis. This is tedious for one thing, but it people change groups, their other permissions would not be changed accordingly.

To solve this problem is a scalable way, I've programmed an application called 'AdSync'.

AdSync will be executed every night after the daily backup scripts have taken an export of the DCS configuration database. Another of my applications will parse this database file and generate an XML file containing just the user account configuration, including users, groups and permissions.

AdSync will first check the groups that exist in the XML file, and verify if they exist in AD. If they don't exist, they will be created, but with a 'DCS ' prefix. This way there is a clear distinction between the existing groups, and those that are managed by my application.

When that is done, the group membership of the user in the XML file is compared with the Active Directory group membership. If they are different, the necessary changes will be made to the AD group. This way, the AD membership is always a mirror of the DCS group membership.

The synchronization is done only once per day, because it is based on the nightly backup of the configuration database. Exporting that database takes about an hour, and renders the system unusable for engineering work. This means we can only do it at night.

Every change that is made by my application, as well as the execution timestamp and any errors that may occur are logged in a custom Windows Event Log for auditing.

Since this is a production environment of pharmaceutical products, installing this on the system takes a good amount of paperwork. The change has to be approved by QA and other relevant departments; I have to do an impact assessment; I have to write an installation manual; I have to set up a validation protocol, and execute it with a witness from validation to prove that the application works as intended; …

So all in all, it takes quite a lot of work, but now everything is ready. Yaay me. J

My application was written with VC# 2008, but built to run on the .NET 2.0 framework, which is qualified by the DCS vendor for use alongside the DCS software. The Active Directory interface was made using the System.DirectoryServices namespace. I used the .NET Developer's Guide to Directory Services as a reference, because the System.DirectoryServices namespace is horrible underdocumented in MSDN.

I have to admit it is nice to keep on developing software. Officially I am a system administrator, but my boss agrees with me that making custom tools like these is something of real value to the company, and something that cannot be outsourced without spending a significant amount of money.