Backup Exec 12 REQUIRES that "Deny Logon Locally" is NOT enabled

[Paulie-D]

As of 2013 AUG, I have confirmed that Backup Exec 12 REQUIRES that the Backup User account MUST NOT have "Deny Logon Locally" enabled / defined.

Running Backup Exec 12 rev 1364 on a Win2003 R2 server, and having "Deny logon locally" enabled for the Backup User Account, will create the circumstance outlined in KB article Tech129293. 

I also confirmed that the backup user account has all of the required Rights assigned, as mentioned in the KB articles:

http://www.symantec.com/business/support/index?page=content&id=TECH129293

http://www.symantec.com/connect/forums/backup-exec-cant-access-local-ressources-list

SYMPTOM: Local and Remote resources are not displayed / inaccessible while editing Backup Selection Lists.

ERROR MESSAGE: Connection with server failed. Hit <F5> to retry.

RESOLUTION:  Do not block / deny the right for the backup user account to log on locally.

This is an issue for administrators who wish to improve their system's security posture, because the Backup Operator is able to log into the Domain Controller using their backup user account's credentials.  The backup operator is not typically the same person as the systems administrator and, therefore, should not have physical logon access to a DC or any other system, merely to manage backup jobs, selection lists and/or related objects.

[MusSeth]

Hello Paulie,

Please have a look at the article below, hope this answers your question

http://www.symantec.com/docs/TECH136148

[Paulie-D]

Hello MusSeth, Thanks for the feedback, however, I assure you that all of the required permissions are set as the KBs (my example as well as yours) define. Please allow me to me clarify. Let's say the domain user account is "OP1". When OP1 is defined in GPO "Default Domain Controllers Policy" > "Deny Logon Locally", the aforementioned symptom occurs. Conversely, merely removing the user account from the GPO allows the symptom to cease. No other changes made; only a GPUpdate /Force. Therefore, it's seems safe to conclude that the user account OP1 requires ability to log on locally. Looking forward to your continued feedback.

[Paulie-D]

It may be noteworthy to mention that the same user account OP1 is assigned to the various BE Windows Services. In other words, there is only one domain account for the purposes of running BE ... instead of having TWO separate user accounts; one for the interactive user and one for the services. Different accounts is the approach I would typically apply in general ... but this particular system was established before my involvement. Point being; is it contributing to the symptom?

[pkh]

You can create another id to logon to the BE console.  This do not have to be the same account  used to start up BE services.  However, the BE logon account must have sufficient rights to the backup.

[Paulie-D]

PKH, Thanks. A single account was used, in the particular solution for which we're discussing, and it has the required User Rights outlined in Symantec KB articles. My described test scenario seems to provide definitive proof that the user account requires the Right to log on locally.

[pkh]

I am not saying that the BE logon account does not need the right to logon locally.  What I am driving at it does not have to be the same as the account which starts the BE services.

[Paulie-D]

PKH, Understood and appreciated. Coming back to topic, I am looking for the solution to the particular issue which I described, regardless of best-practice configurations. I'd prefer not to change anything, unless using a single account for interactive + services is definitively the cause.

[Paulie-D]

I suppose another way to ask is: Does either the BE User Account or BE Service Account require the User Rights Assignment for interactive logon?

[pkh]

Logging on locally does not just mean interactive logon.  If the BE id cannot logon to the media server, then how can be BE jobs be run?

[Paulie-D]

PKH, Thank you for the continued feedback. In a Windows 2003 Active Directory Domain, the User Rights Assignment titled "Deny Logon Locally" prevents the assigned list of accounts from gaining access by entering their credentials at any computer upon which the GPO is applied. In my case, this requirement applies to the Backup Operators Group as well as all systems. Despite the fact that the backup operator (physical person) is also the domain admin, I must comply with strict security guidelines that specifically require the Backup Operators Group to be denied the right to log into any computer on the domain. Given that additional clarification, assigning the BE user to the "Deny Logon Locally" policy causes the issue I outlined in my opening post. Conversely, removing the BE user from that policy allows all functionality to resume. It seems to me that the User Right in question is required for BE to work. Assuming you'll disagree, please outline how it may be resolved while adhering to the aforementioned security requirements.

[VJware · Accepted solution]

Verbatim from TECH130255:-

Backup Exec requires either membership in the Backup Operators group, or Administrators group to protect NTFS file data. Specifically, Backup Exec requires the following rights:

1. Backup files and directories
2. Restore files and directories
3. Allow log on locally (Windows 2000, 2003 and XP only)
4. Logon as  Batch (Windows 2008/Vista and above)

"Allow log on locally (Windows 2000, 2003 and XP only)" is indeed required.

[Paulie-D]

VJware, Thanks for the KB reference; it's *precisely* what I needed as a documented mitigation statement. For clarity, do you agree that Symantec's use of the word "protect" (in the KB various paragraphs) means to limit exposure to the accessed data?

[VJware]

I would say yes & IMO, it simply means 'backup' with 'minimal' exposure.

[Paulie-D]

VJware, Thanks, again. While I realize there are likely numerous articles on the (or related) subject, please consider providing a link to that KB on the original KB I referenced which is: Tech129293, since it currently OMITS that User Right from the list provided therein.

[VJware]

Acknowledged & I'll inform the appropriate team. Thanks

[Paulie-D]

MusSeth and PKH, Thanks for jumping into this topic originally. Your insight was appreciated as well.