Forum Discussion

Khue's avatar
Khue
Level 4
18 years ago

Service Account Setup

Recently, we've made some changes to our domain infrastructure relating to Domain Admin accounts. When that happened we, of course, broke storage exec. I managed to find the article on how to reset the DCom object password and username and I am in the process of doing so. I read the overview of how SE is supposed to be setup, however I am uncomfortable with returning Domain Admin access levels to the SE service account. I have no problem giving a single domain account local admin to that box. Is there any real need to give the account Domain Admin? I think what I really need is a quick overview of just what exactly this service account is going to need to do its job affectively.
business continuity
Storage Foundation

2 Replies

Sort By
  • matheesha_weera's avatar
    matheesha_weera
    Level 3
    18 years ago
    Hi Khue
     
    I am currently evaluating SE 5.5. for deployment within our infrastructure and so I have limited experience with the product. Nevertheless I hope my observations will be of some use to you/anyone.
     
    The SE service credentials most definitely needs local admin rights over any server it is running on. If you dont do this, one of things you will see is the inability to see managed resources. I.e. If you allocate a storage policy and then save it, then browse SE as if trying to apply a policy to the same resource, you will see an icon indicating a policy is applied but it wont list itself in the SE console as a managed resource when you refresh (or close and relaunch the console). I hope that makes sense.
     
    I dont see why SE needs to have domain admin rights. Basically when you launch the EAO configuration option for the 1st time the CN=WQuinn,DC=<insert FQDN for domain here> gets created. For this to happen, the person doing the EAO needs domain admin rights. This is because no one has been delegated control over the domainDNS object to say "allow create child(CC in sddl) and delete child (DC in sddl) rights for the wquinn-Container/wquinn-Value classes". But if you for example use the wquinn.LDF file in the c:\program files\veritas\storage exec\utility\adconfiguration\ldf folder to create the CN=WQuinn,DC=<insert FQDN for domain here>  and then delegate full control to the object and sub objects to a group (e.g. My Storage Exec Admins) , then all you have to do is run the EAO configuration as a user that is a member of the above "My Storage Exec Admins" group. Note this group is fictitious ;-)
     
    The SE credentials get added to the SCWrite so it should have rights to modify objects beneath cn=WQuinn assuming the rights are present for SCREAD and SCWRITE. I have an issue at the moment where the ACL for CN=WQuinn is not getting set at EAO configuration time and I need to raise a support incident.
     
    If you create your own CN=WQuinn objects (e.g.beneath any OU which have SE servers housed) then you will need to ACL them such that SCREAD and SCWRITE have the necessary permissions. there is a section in the helpfile that explains whats required.
     
    I guess the point I am trying to make is put the SE account into an additional group (other than SCWRITE) and delegate control to objects in AD that SE needs to control. That way, regardless of the permissions beeen explicitly granted to SCWRITE or not, SE credentials will have the necessary permissions to make the modifications it needs. If I were you, I will delegate full control to the wquinn-Container and wquinn-Value class objects and read/modify (also known as RPWP in sddl) for the wquinn-String and wquinn-dataType attributes wherever they exist. At the moment by default they are only in CN=WQuinn,DC=FQDN_OF_DOMAIN.
     
    HTH
     
    M@
     
    P.S. If you find any more info on the subject please post for the benefit of others. cheers
  • Khue's avatar
    Khue
    Level 4
    18 years ago
    Thanks for responding to my post. I had nearly forgotten about it.

    I am not sure if I get the process. When you install the product it will prompt you for a username and password. If this computer is a member of a domain, then the account must have the rights to create the CN for wquinn, correct? Once you have created the WQuinn account, can permissions be reduced for that account? My problem is I am not comfortable with granting administrator level privledges to all servers for this account when imho it should really only need local administrative access.

    On top of that, does this account need to be a member of SCRead and SCWrite? Do those groups then get added to local administrator of the machine?

    Sidenote: These are all steps for configuring Enterprise Administration, correct? If that's the case, I dont think I need this much detail any longer as we do not have that option with our serial key.

    Message Edited by Khue on 07-02-200701:27 PM