mssbsssr/sbsmonacct causing audit failure
- From: F2Andy <F2Andy@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Wed, 1 Aug 2007 01:46:00 -0700
We have been getting an audit failure in the event logs for some weeks, at
0430 each day. Here is the error:
Source: Security
Category: Logon/Logoff
Type: Failure audit
Event ID: 534
Logon Failure:
Reason: The user has not been granted the requested logon type at this machine
User Name: sbsmonacct
Domain: <ourdomain>
Logon Type: 2
Logon Process: Advapi
Authentication Package: Negotiate
Workstation Name: <ourserver>
Caller User Name: <ourserver>$
Caller Domain: <ourdomain>
Caller Logon ID: (0x0,0x3E7)
Caller Process ID: 2700
Transited Services: -
Source Network Address: -
Source Port: -
In Task Scheduler I found a task that runs at 0430 each day:
"C:\Program Files\Microsoft Windows Small Business
Server\monitoring\mssbsssr.exe" -usage
Collect usage data daily and store in the monitoring database
I have run this from the command line, with the same error, which confirms
mssbsssr is the problem, and not the task scheduler
These are scheduled too, but do not generate errors:
"C:\Program Files\Microsoft Windows Small Business
Server\monitoring\mssbsssr.exe" -C:Server Performance Report
"C:\Program Files\Microsoft Windows Small Business
Server\monitoring\mssbsssr.exe" -C:Server Usage Report
"C:\Program Files\Microsoft Windows Small Business
Server\monitoring\mssbsssr.exe" -perf
I had a look at the internet to see what I could find out.
Looking at the error code: "This event record indicates that an attempt was
made to log on, but the local security policy of the computer does not allow
the user to log on in the requested fashion (such as interactively)."
Log on type 2 is indeed interactively
(http://www.windowsecurity.com/articles/Logon-Types.html), and this would
seem wrong. A scheduled task should be logon type 4.
What it seems to do is collect data from somewhere, process it and dump it
into a database for monitor reporting. To do that (with the 'usage' option),
it first checks if the user account sbsmonacct exists, and deletes it if it
does. Then it creates the user account sbsmonacct again, enables it, gives a
password, changes some settings, puts it into Enterprise Admins group
(twice), logs on, does whatever it needs to do, logs off, and then deletes
the account. On our server, it is failing to log on, perhaps because it is a
scheduled task trying to log on interactively, and so the account does not
get deleted at the end of the process. As far as I can tell all reporting is
proceeding normally.
The sbsmonacct account describes itself as: "Account used by Small Business
Server Monitoring to collect e-mail usage data for server usage reports."
It is a member of Domain Users, Enterprise Admins, and by implication Users
From http://www.winserverhelp.com/ftopic5685.html
Check to see if the Administrator or the Enterprise Administrator account is
a member of either the Remote Operators group or the Domain Power Users
group. This happens because on SBS 2003, the "Deny log on locally" policy
setting is applied to the Remote Operators group in the Default Domain
Controllers Policy object. This policy setting also applies to the Domain
Power Users group because the Domain Power Users group is a member of the
Remote Operators group. Since a deny policy always overrides an allow policy,
this policy setting prevents users from logging on to domain controllers in
the domain, even if the "Allow log on locally" policy applies to the same
users. Be aware that in many cases the Administrator account becomes a member
of the Remote Operators or the Domain Power Users group because of group
nesting. For example, the Administrator account is a member of the Mobile
Users group. Therefore, if you add the Mobile Users group as a member of the
Remote Operators group, the Administrator account becomes a member of the
Remote Operators group because of group nesting.
This does not seem to be the case, sbsmonacct is not a member of a group
that has Deny Logon Locally set on it.
In the application log at about that time (and it also appeared when I ran
mssbsssr from the command prompt) is this informational message:
The description for Event ID ( 2004 ) in Source ( WBLOGSVC ) cannot be
found. The local computer may not have the necessary registry information or
message DLL files to display messages from a remote computer. You may be able
to use the /AUXSOURCE= flag to retrieve this description; see Help and
Support for details. The following information is part of the event: .
I tried reinstalling through the Monitoring Configuration Wizard, but with
no success.
By the way, I have instally SP2 on the server, and SP3 on ISA 2004, but this
problem dates from before then.
A search of the microsoft web sites turns up no reference to "mssbsssr",
"sbsmonacct" or "wblogsvc"!
Any ideas?
F2Andy
.
- Follow-Ups:
- RE: mssbsssr/sbsmonacct causing audit failure
- From: Manfred Zhuang [MSFT]
- RE: mssbsssr/sbsmonacct causing audit failure
- Prev by Date: Re: New one
- Next by Date: Re: Policty to disable shutdown only
- Previous by thread: Exchange Problem
- Next by thread: RE: mssbsssr/sbsmonacct causing audit failure
- Index(es):
Relevant Pages
|
