I am designing a single forest with multiple child domains for organisational purposes so the security boundry is the single forest and not the domains. Our client has instructed us to work with the third party compnay who whill be administrating the McAfee EPO 4.5 and Agnet deployment.
We asked the customer to ask the 3rd party to supply the types of user and service accounts required for the EPO and agent installation and deployment to all the domains.
they cam back witht he following.
For EPO Installation on the server
Enterprise Administrators rights.
Deployment of the AGENT on all client computers and servers
Domain Service account with Domain and enterprise administrator privlages.
On all Client servers and Computers
Local services account with local administrative permissions.
Ok, i know this is not right and i have tried to find the permissions required and i can only find that the EPO server requiers an account with Local administrators privliges to install the EPO Server and SQL Server (Or an AD account for the sql.)
As we will not be giving the 3rd party company these rights I am looking for assistance in obtaining the required rights for them to do their job but not give them domain or enterprise administration.
they say their job functions are as follows.
rights an all devices
· For remote agent installation and hot fixes
· For remote McAfee Installation and Hot fixes
· For daily pattern file updates and scan engines
· As part of daily pattern file update process this account needs to authenticate to the EPO server
I would like your opinion on this
As i am reading in the EPO 4.5 the person who is resposible to just administrate the EPO server and agents ont he network has to be a domain administrator, so in the forest root domain this means he is also a schema administrator by default... What a poor design.Please prove me wrong.
Deploying the agent via push technology
Use this task to deploy agents to your Windows systems using ePolicy Orchestrator.
This method is recommended if large segments of your System Tree are already populated.
For example, if you created System Tree segments by importing domains or Active Directory
containers, and you chose not to deploy the agent during the import.
Before you begin
To use this method, these requirements must be met:
• Systems must already be added to the System Tree.
If you have not yet created the System Tree, you can deploy the agent installation
package to systems at the same time that you add groups and systems to the System Tree.
However, McAfee does not recommend this procedure if you are importing large domains
or Active Directory containers. Those activities generate significant network traffic.
• The account specified must have local administrator privileges on all target systems. Domain
administrator rights are required on a system to access the default
Admin$ shared folder.
The ePO server service requires access to this shared folder in order to install agents.
Apologies for coming to the thread late...
The primary issue here appears to revolve around the permissions required to perform a push agent install - where the agent is sent to a client machine from the ePO server / agent handler via the console. (Please correct me if that's not correct.)
If this is the case, then as far as I know, domain admin rights are not required: local admin rights are, however. I'm not sure why the product guide specifies domain admin rights for accessing the admin$ share: I'll try and clarify that - it may be a documentation error.
KB 60351 details the requirements for push installs - it's not completely up to date but it's still relevant. Permissions are only part of the picture for push installs to succeed - as per the article lots of other things can affect pushes, such as removal of admin$ share, windows firewall settings and so on.
1) I believe only local admin rights are required
2) I'll try and confirm this as soon as possible
3) Rights are not the only issue affecting push installs
I agree, eventually local admin rights are required, which can be achieved by either of the following:
1. You know a local admin user login name and password for a single client subject to push agent to.
2. You know that all your clients have the same password for their local Administrator user (or you know an equivalent local user name and password being identical on each one).
3. You know the domain admin username and password of the client's domain.
I think for most domain based environment for mass epo agent push the 3rd option is the most likely to work for each client regardless. So to surely have admin rights locally on clients, a knowledge of a domain admin user and password may be required. In this context, a specification of domain admin account requirement may not be out of place.
The problem with option 3 is, WOuld you give some one the pin code to your back account witht he back card and tell them that they are only allowed to check the ballance. You then know that that person works in a team who is your competitor. do you think that your bank account is is not going to be touched.
By giving someone the domain administrators account and password and telling is that they are not allowed to log in on any computers with it is like asking a FAT kid not to eact the candy bar infront of him.
Would it work if we gave then a domain service account for the user name and password? Service accoutns are domain administrators anyway but they do not have the rights to log in. But this can also be abused by making scripts with the service username and password to change domain structre and making accounts that they are not supposed to have.
It reappy looks as though we are not going to be able to use EPO if this is the case
As I said though - I do not believe that domain admin rights are required: only local admin rights on the machine you are trying to push to (as well as the ancillary items like an admin$ share and so forth.)
Everyone's environment is different - have you tried pushing using a local admin account? What were the results?
I have managed just fine with a standard domain account granted local admins to the workstations, there is no need for domain admins unless someone starts changing the config down the road
Can you please tell me how you deploy your agent to devices please? This sounds helpfull. Again as i read it when you are in the interface and you push the agent to a machine you need to put in a user name and passwrod. So what you saying is to make a domain user account and place that in a global group called EPO Local admin group (For example) then add this group to local service account gpo as this would grant it local administration and deny local login. The EPO agent would then be deployed.
Im trying not to give the 3rd party compnay local administrators account as they have a tendancy of adding anyone wh asks them local admin rights. So by giving them a local service account they can do the same thing but not be able to log in..
This sounds acceptable to me.
I just use a domain account credential that has been placed in the local admins group for that domain, I have to use this method for one of my EPO servers that supports users across 100 different domains.I have been using actual local admins group not service account group though.
Once you have an agent in place it should install and maintain AV via the local service account.
I do also use domain admin credentialed users on some other EPO setups but its not technically neccessary