Re: Scheduled Tasks - Strange Permissions Issue
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Tue, 28 Nov 2006 23:00:32 -0700
Well, yes, but that actually effected a workaround,
rather that a resolution to the problem, right?
In other words, the issue is still sitting there waiting
to foul up an NTLM based Windows integrated (re)login
attempt, right?
Anyway, glad you have things resolved to your satisfaction.
Roger
"e v t" <msnewsacct@xxxxxxxxxxxxxx> wrote in message
news:%23HL8JgyEHHA.3600@xxxxxxxxxxxxxxxxxxxxxxx
Hi Roger,
Thanks so much for your continued help on this. I figured out the issue.
In fact, it was so easy and right under my nose. I actually had to log
into the server as the account running the scheduled job, then open IE and
disable the "Integrated Windows Authentication" option. It was such an
easy solution because I had to do the same exact thing to the
administrator account in order to browse the local website on the server.
Thanks again!
-eric
Roger Abell [MVP] wrote:
Well, yes, it does provide more clues. I am just not sure to what.
If there is some special handling given to the well-known SID of
the built-in administrator account, it does make sense that it would
be implemented in advapi.dll (which IIRC came about in early NT4).
I tend to not use the built-in, giving it a 120+/-n char password and
on OSs that allow disabling it. So I have not ever noticed that the
handlers for authentication are noted so "uniquely" as you have said.
That disabling Windows integrated authentication would avoid the
issue that causes an NTLM authentication to fail (with the odd code)
does make sense.
However, we are still at the main question - why is NTLM authN
failing? Here is an odd example of this for you to consider. On a
webserver (W2k3 R2, IIS) that is tightly controlled as to network
activity, if while logged into the server I attempt to authenticate to
a webpage that requires it, using IE, I can. If however I attempt to
open that web in FrontPage it fails, giving the failed login event
log message with the odd code. If I open that web with FrontPage
from any machine (other than the IIS server) all works just fine.
On that server the firewall is not in use, and if the IPsec filtering
is lifted temporarily the local login works (i.e. no failure message
with the odd code). The IPsec filters allow all combinations I have
been able to thing of for allowing tcp and udp communications by
the IPs of the machine with itself. It is rather perplexing,
particularly
as the authN from off-box, that always works is happening over only
http tcp 80.
Like I said to begin with, I have seen the issue but have no solution.
Roger
"e v t" <msnewsacct@xxxxxxxxxxxxxx> wrote in message
news:OrRZkmlEHHA.3660@xxxxxxxxxxxxxxxxxxxxxxx
I've noticed that when I run as Administrator, the Logon Process is
always 'Advapi' and the Authentication is 'Negotiating'. If I run as
'task_user', the Logon Process is the weird unicode and the
Authentication is 'NTLM'. This is a long shot, but is there some DLL
that my user perhaps doesn't have access to run? Basically, the program
that the Scheduled Task is running is supposed to log into a web page
that is local to the server, format it into an email, then send it to a
sysadmin. It seems to be getting hung up at the Authentication portion.
I had the *same* exact problem browsing the local website from the
server until I disabled the IE option 'Enable Integrated Windows
Authentication'. Once I disabled that, I was able to log into the
website.
Does this provide any more clues?
Thanks again,
eric
Roger Abell [MVP] wrote:
"e v t" <msnewsacct@xxxxxxxxxxxxxx> wrote in message
news:OySkR2iEHHA.1196@xxxxxxxxxxxxxxxxxxxxxxx
Hi Roger,Hi Eric,
Thanks for the info. What I don't understand is why it works
perfectly when the task is run as Administrator. I've tried assigning
the account I'm using to be in the Administrators group, removing all
other groups, and assigning the permissions in Local Security Policy.
I'm trying to figure out what other permissions the Administrator has
that are not obvious. Does this make sense?
Your words make sense, the behavior they describe does not.
There are very few things hardwired for the Administrator SID,
like not being able to be locked out from login (although this may
require safe mode boot to use). I am not sure whether there is a
list of the hard-wired to be found anywhere.
Roger
Roger Abell [MVP] wrote:
I have seen that odd, unicode-ish, proc id in these failure events
on W2k3 R2 systems. In each case I have tracked it only so
far as due to excessive network restrictions (ipsec, firewall)
on communications either by the machine with itself or with
the domain controllers. I have not pinned it down to exactly
what, which protocol/ports. Similarly when I last attempted
searches for info on the failure with odd logon process id,
I turned up nothing specific.
"e v t" <msnewsacct@xxxxxxxxxxxxxx> wrote in message
news:u8MTWSxDHHA.1748@xxxxxxxxxxxxxxxxxxxxxxx
I have a question about Scheduled Tasks on Windows 2003 Server.
I've got several scheduled tasks that are exhibiting some strange
behavior. They appear to run and don't issue any errors in the
scheduled tasks log, yet they seem to be having permissions
problems. Here's an example...
There's a job that's configured to run under a specific user. The
user has "Log on as a service" and "Log on as a batch job"
permissions. When I run the job, no errors are reported in the
'SchedLgU.txt' file. However, the application that I'm running via
the Scheduled Task has its own log which states, "Access is denied".
When I change the user to 'Administrator', the job works just fine.
I've tried adding the user who runs the job into the Administrators
group, but this doesn't appear to work, either. I notice in the
Security Event Log that when the job is run under the other user,
the following shows up:
Logon Failure:
Reason: An error occurred during logon
User Name: task_user
Domain: SERVER1C
Logon Type: 3
Logon Process: Ðùl
Authentication Package: NTLM
Workstation Name: SERVER1C
Status code: 0xC000006D
Substatus code: 0x0
Caller User Name: -
Caller Domain: -
Caller Logon ID: -
Caller Process ID: -
Transited Services: -
Source Network Address: 192.168.1.20
The only strange thing I can see above is the 'Logon Process'
output. What's up with that?
The scheduled jobs worked fine under Windows 2000. I've been
pulling my hair out over this for the past two days and I know it's
got to be something simple. Can anyone assist, please?
Thanks in advance for any assistance you can provide.
-evt
.
- References:
- Re: Scheduled Tasks - Strange Permissions Issue
- From: e v t
- Re: Scheduled Tasks - Strange Permissions Issue
- Prev by Date: Re: Scheduled Tasks - Strange Permissions Issue
- Next by Date: Lookup a "Caller Logon ID"
- Previous by thread: Re: Scheduled Tasks - Strange Permissions Issue
- Next by thread: Lookup a "Caller Logon ID"
- Index(es):
Relevant Pages
|
