Referring to the comments, I think User B needs at least the "Log on as a batch job" right. If the process running under User B's credentials is meant to accomplish certain tasks, then additional rights or privileges may need to be granted to User B for those tasks to function correctly.
This article lists rights and privleges and details cases where a right or privilege may be needed for certain tasks:
https://technet.microsoft.com/en-us/library/cc755971(v=ws.10).aspx
It seems what you may be trying to do is allow a process to run as User B on a computer even though User B cannot log on interactively due to User B having the "Deny log on locally" right or not being a member of a group that has the "Allow log on locally" right.
"Log on as batch job" would allow User B to be used for processes initiated by Task Scheduler. It's possible that trying to launch a process in an interactive session (i.e., logged on as User A) with a user that only has batch job rights and does not have interactive rights will fail. In this case, "Allow log on locally" granted to User B should enable the use of User B for the process. The only catch is then User B can log on interactively, which is probably not desired.
A workaround might be to "trivially schedule" the job. Instead of User A actually running the command, User A sets up a task schedule job that they then set to run in one minute (or something).