DIRT restore recreated deleted active directory accounts

maratimer_2 · ‎05-07-2007

During a DIRT restore recently, there were approximately 20 unity accounts which we determined were still in Unity even though the employess had left the company. (the security team had deleted the AD/exchange accounts when these people left the company but they did not delete them from Unity).

The restore process (the unitydirsvc to be exact) has recreated these 20 active directory accounts in the Unity OU. This has raised alot of flags with the security team as Unity is not supposed to be able to create AD accounts, only to import existing user accounts from AD.

I realize the unitydirsvc has the permissions to actually do this, but should this be happening? We are now under security audit due to this issue and need to give the security team an explanation as to why this happened.

My question is : if we have configured Unity only to import existing accounts during the PW configuration, should it be able to recreate these deleted AD accounts? Or is this going to continue to happen everytime a unity account deletion is missed and a restore/resync is performed..?

ranpierce · ‎05-07-2007

it is my understanding here that if on of the followning is present the the AD accounts are created. Someone correct me if I am wrong.

The DiRT restore will create new accounts in AD/NT (Ex2K/EX2K3/EX55) on the fly if necessary or will bind to existing accounts already in the directory. DiRT populates SQl with the subscriber information from the backup and then kicks off the SQLSyncSvr process noted above. It is this process that then looks through the directory to see if each subscriber is already represented there or not. If the user is not found in the directory then, in the case of an Exchange back end, a new object is created in the container selected during Unity installation (i.e. the Users container in AD is the default). In the case of a Domino restore if a user in SQL is not found in the directory they are removed from the database. When searching for a user in the directory with an Exchange back end, the Syncher does the following lookups in this order

Looks for the user?s directory ID. If you are restoring into the same directory where the Unity you backed up was installed, this will match and the user will be updated to be a subscriber on the new local Unity server.

Looks for the user by their Relative Distinguished name (RDN).

Looks for the user by their mail alias. If more than one object is found with the same mail alias, that subscriber is skipped ? the syncher does not make a ?best guess? here as to which one to use. Remember that the syncher is looking from the root of the forest down in AD, it is legal (although not a good idea) to have multiple users in AD with the same mail alias across domains.

If no user is found by the above three searches, then a new user is created in the default container noted above. If, for instance, the aliases of the subscribers have changed between the system you backed up on and the system you are restoring to (i.e. you are migrating from VM only to a UM installation) you can use the Migrate Subscriber Data tool to move the Unity data off these newly created accounts onto the desired email account already in the directory. See that tool?s help and training videos on the link above for details.

Caution! If the partner Exchange server is running Exchange 2003 or Exchange 2000, Cisco Unity can only create accounts in Active Directory if, when you ran Permissions Wizard, you chose the option to create users using the Cisco Unity Administrator. If you did not choose this option when you ran Permissions Wizard, the DiRT restore will fail because AD accounts cannot be created.

NOTE: You can change the alias strings for subscribers during DiRT restore starting with version 1.0.264. See the Remapping Subscriber Alias Strings During Restore section below for more on that.

rlp

ranpierce · ‎05-07-2007

the above was taken from the help file from http://www.ciscounitytools.com/HelpFiles/DiRT/index.html

rlp

maratimer_2 · ‎05-07-2007

The reason why I am stumped is because when we run the PW, we specifically do NOT enable Unity to create AD accounts, but to import only existing accounts - this is why I am curious as to how this could have happened. In such a large environment, I suppose it is possible that a field engineer ran the PW and enabled that feature contrary to the configuration/documentation. So two issues here, first fix the gap/process in removing users from Unity before AD so this doesnt happen (orphaned Unity accounts) and second, ensure configuration is set to only import existing accounts. Thanks for your feedback.