changing the Unity Administration account

[mbell]

I installed a Unity server with a particular domain account as the installation and service account. I need to associate the Unity Administration account with a different AD user account now. Without uninstalling and reinstalling Unity, is there a way to do this? I know about the "grantunityaccess" utility but I don't know what user the default Unity Administration account is associated with. I have already changed the domain account that the AvDSAD and AvDSGlobalCatalog services run with to the new account and Unity appears to be running fine but I cannot log into the SA with the new domain account. I can, however, still log into the SA with the original account that I used to install Unity.

[lindborg]

The easiest way to do this is to make that account a Unity subscriber and assign it to the administration class of service. If that's not a possibility then you can use GrantUnityAccess and assign it to the same rights as the "Installer" account gets. The example test spit out when you run GrantUnityAccess with the /? option shows how to do this...

[mbell]

Thanks, Jeff. How can I prevent the original account that was used to install Unity from being an administrator?

[oliviers]

GrantUnityAccess.exe can also do this. If you run it without any arguments, it will display help about different options.

[mbell]

I was aware about the grantunityaccess utility. But since I do not know the Unity username (a required field with this tool), how can I de-associate the original Unity Administration account using this tool? Also, grantunityaccess can only remove associations that it created.

For example, if I used the domain account "unity1" to install Unity originally but now I want to have "unity2" as the administrator, Jeff said just create a Unity account for "unity2" and assign the administrator CoS to it. That's fine but "unity1" can still log in to the SA as an administrator. How can I prevent "unity1" from logging in? Grantunityaccess didn't originally create that association, so I don't believe it would be able to change that. Even if it could, what would I specify for the "Subscriber Alias" that grantunityaccess requires? The only accounts that are in Unity when it is first installed are Installer, Eadministrator, and Esubscriber. The latter two have their own domain accounts. Even if I use the grantunityaccess tool to associate the Installer account with my "unity2" domain account, "unity1" can still log in. I need to figure out how to prevent "unity1" from logging in.

[lindborg]

First, is Unity1 a subscriber in Unity? If they are associated with the Admin COS then you need to be sure to assocate them with the subscriber COS that doesn't allow SA access first.

GrantUnityAccess simply allows non subscriber accounts SA access by adding entries in the SIDHistory table for this - if Unity1 is an admin subscriber then this wont have any bearing on their access to the system or not.

You need to run GrantUnityAccess with the -L option to get a full list of every entry in the SIDHistory table. Yes, setup did use GrantUnityAccess to punch the installer's account into this table during install. If the user is not a subscriber and they're getting into the SA they will have an association in this table that will show up here and you can remove it with the -U option.

[mbell]

Unity1 is not a subscriber in Unity. I double-checked this by doing a subscriber search for that alias. "GrantUnityAccess -L" shows "0 items in list". If I use the "-U" option the GrantUnityAccess utility, what should I use for the "Subscriber Alias" since the domain account "unity1" is not associated with a Unity subscriber?

For a basic install, if "domain\unity1" is specified for the Unity Installation and Unity Service accounts, how does Unity know that this account has SA access? That domain account is not associated with the Example Administrator and that and Example Subscriber are the only two subscribers that I have seen immediately after finishing a Unity install.

[lindborg · Accepted solution]

OK… did some digging here and I figured out what’s going on.

At the end of setup, we take the account that’s installing and we add it’s SID to the SID History table and map it to the local, hidden “Installer” account in Unity (can’t be seen in SA, can’t be deleted, has SA access rights). However, there’s a bug in that it sets the “IsPrimary” field in the SIDHistory table in SQL to “1” instead of “NULL”. The Grant Unity Access tool will only show entries that have “NULL” which is why you’re having trouble.

So I ran a quick test on my 3.1(4) install here to make sure I could get around this. Here’s what I did:

Open SQL Query Analyzer, connect and then select the UnityDB database in the drop down.

Type “Select * from SidHistory” and run the query. You should see 4 entries there, all of which have “1”. If that’s not the case, ping me back before going further.

Now type “Update SidHistory Set IsPrimary=NULL” and run the script. It should tell you 4 rows have been affected.

Now truck out to a DOS box and run GrantUnityAccess –L and you should see all four accounts listed with their NT account association on the right and which local object they are mapped to on the left. You should see that the Unity1 account is associated with the Installer account here.

Then you can type “GrantUnityAccess –u DOMAIN\Unity1 –s Installer –d” and hit enter. This should toast that association… you can run the –L again to make sure it’s gone.

Now go back to the SQLQuery Analyzer tool and type “Update SidHistory Set IsPrimar=’1’” and run it.

You should be good to go. I filed a bug on this against the DB folks and they’ll make sure the install account association gets set to “NULL” here by default.

[mbell]

That did it! Thanks very much!