Try logging onto a computer as your Veritas user and confirm you are in fact able to browse to the data you're trying to back up, and try copying something from the network share to the computer. Also check you can browse to the NAS share and create files on that.
On your Backup Exec Media Server, try and browse to the root of \\NSS324. I don't know about this particular NAS, but if it's a Linux based NAS, I have seen those sometimes either not register themselves in DNS properly (or at all) or they don't consistently answer to their assigned name. If that doesn't work, you might want to try a fully qualified name (i.e \\NSS324.corp.acme-widgets.com (obviously replace that with your actual FQDN)).
In your B2D media, there is no need to map the share on the NAS to a Windows drive letter - Backup Exec will be perfectly happy with simply \\NSS324\IT_Admin\Backup.
I've experienced some idiocy from the Backup Exec interface before, where it claimed the user I has specified as the backup user didn't have enough permission (when it really did). If I ran the job manually, it backed up everything and the job completed successfully (confirmed with a restore).
I've also found any errors in the Backup Exec job log are more useful than the error messages you get when setting up a job. It might be worth setting up the job and ignoring any permission errors you get and run it anyway so you can interrogate the job log. Any errors or warnings in the job log generally point to a Symantec KB article, which admittedly isn't always helpful, but might prompt you to think about something you maybe overlooked.
Of all the hoops I had to jump through, this was the EASIEST SOLUTION by far:
http://www.em-soft.si/myblog/elvis/?p=403
Just install WS2012R2E, CANCEL the WIZARD, use the Powershell (run as admin), and enter the commands, HIT "Y" to continue (finish) WIZARD.... than VOILA! It's DONE! SIMPLE AS THAT. Why is something that should be SO simple so complicated WITHOUT this? I have NO idea. : (
Open the PowerShell as Administrator and write the syntax:
Start-WssConfigurationService -CompanyName "MyCompany" -DNSName "Internal.MyCompamny.com" -NetBiosName "MyCompany" -ComputerName "MyServer" -NewAdminCredential $cred -Setting All
The explanation of all used switches is available on TechNet. Enter your AD administrator credentials in the window that will appear. This will be the new administrator – the same as you configure it in the Essential server wizard.
CREDIT to Elvis!
Highly disappointed in Microsoft for this. : \
Best Answer
Here's Symantec's document re: Active Directory integration: http://service1.symantec.com/SUPPORT/ent-security.nsf/docid/2007092721431648 When you talk about "how SEP authenticates on the domain", I'm going to assume you're referring to SEP's access to the directory to perform its cruddy "synchronization" of OUs of AD into its own database. When add a "Directory Server", you will enter a username and password used to bind to the LDAP server. The account used here does not need "Domain Admin" or any other high level of privileges. The stock permissions on an Active Directory permit a non-privileged account to perform the LDAP query necessary to return user, computer, and OU objects. Unless you've made heavy modifications to your AD's stock permissions, you won't need this account to be an "Administrator".
The account used for directory service access is not created by the product's installer automatically. I'd turn on "Advanced Features" in Active Directory Users and Computers and examine the "Object" tab of the "Symantec" user you found to try and pinpoint when it was created to figure out where it came from.
My condolences to you for having to deal with SEP. We had some awful experiences with it and are transitioning Customers away from Symantec. At this point, I wouldn't even recommend SEP to terrorists, thieves, or other malcontents. It's just that bad.