Re: Scheduled Tasks - Strange Permissions Issue
- From: "Roger Abell [MVP]" <mvpNoSpam@xxxxxxx>
- Date: Mon, 27 Nov 2006 23:50:59 -0700
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,
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?
Hi Eric,
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:
- Scheduled Tasks - Strange Permissions Issue
- From: e v t
- Re: Scheduled Tasks - Strange Permissions Issue
- From: Roger Abell [MVP]
- Re: Scheduled Tasks - Strange Permissions Issue
- From: e v t
- Re: Scheduled Tasks - Strange Permissions Issue
- From: Roger Abell [MVP]
- Re: Scheduled Tasks - Strange Permissions Issue
- From: e v t
- Scheduled Tasks - Strange Permissions Issue
- Prev by Date: Enable COM+ Access for Windows 2003
- Next by Date: Re: Enable COM+ Access for Windows 2003
- Previous by thread: Re: Scheduled Tasks - Strange Permissions Issue
- Next by thread: Automatically force propagation of NTFS permissions...?
- Index(es):
Relevant Pages
|