Enumerating services on remote 2008 fails to enum all services
Corinna Vinschen
I just came across another problem. Consider two machines, one XP SP2,
one 2008 Server. Both machines are not part of a domain, but rather
stand-alone machines in a workgroup. I opened up the service control
manager access rights on the 2008 machine so that I can access the SCM
from another stand-alone machine according to
http://support.microsoft.com/kb/907460/en-us
I have a self-written service helper application which can, as one
functionality, enumerate services similar to `sc query'. The only
difference is that it reports about Cygwin services exclusively.
I found that I could remotely enumerate services running on the XP machine
without problems, but when I try to remotely enumerate services on the
2008 machine, the Cygwin processes never showed up in the list.
After some debugging I found that the call to
EnumServicesStatus (sm_handle, SERVICE_WIN32, SERVICE_STATE_ALL,
buffer, 65536, &bytes_needed, &num_services,
&resume_handle);
does not return all 113 WIN32 services running on the 2008 machine when
called from the XP machine, but only 24. And always the same 24.
When I call the same function locally I get a list of all 113 services.
As for the services running on the XP machine, EnumServicesStatus always
returns all 95 entries, regardless of being called locally or remotely.
As a sanity check, I tried to do the same using sc. The result is
identical to what my own call to EnumServicesStatus returns:
xp-box$ sc query state= all | grep SERVICE_NAME | wc -l
95
2008-box$ sc \\xp-box query state= all | grep SERVICE_NAME | wc -l
95
but:
2008-box$ sc query state= all | grep SERVICE_NAME | wc -l
113
xp-box$ sc \\2008-box query state= all | grep SERVICE_NAME | wc -l
24
I'm calling EnumServicesStatus in a loop which checks for ERROR_MORE_DATA,
but it always returns TRUE in the first call.
Does anybody know why this happens? Is there anything I can do
about this, preferrably programatically?
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Jeffrey Tan[MSFT]
I did not find any existing bug report in the internal database yet. Does
this problem exist if the two machines are in the same domain? Based on my
test, it seems that my Win2003 machine can query the remote Windows
Server2008 services without any problem. I suspect there may be some
security enhancement in the Windows Server2008 that blocks the remote query
remotely.
Also, have you tried to run the ProcMon on the Server2008? Does it report
any registry access failure during the remote query? If not, I suspect the
remote query is rejected at the firewall level instead of the local
registry service information level.
Anyway, I will spend more time on this issue and get back to you ASAP.
Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Corinna Vinschen
Jeffrey Tan[MSFT] wrote:
> Hi Corinna,
>
> I did not find any existing bug report in the internal database yet. Does
> this problem exist if the two machines are in the same domain? Based on my
> test, it seems that my Win2003 machine can query the remote Windows
> Server2008 services without any problem. I suspect there may be some
> security enhancement in the Windows Server2008 that blocks the remote query
> remotely.
I made some further tests and it appears that the same problem exists
when trying to enumerate the services on another machine in the domain,
if the enumerating user is not a domain admin. I could reproduce this
behaviour (missing services in the listing) with a non-admin user in a
domain, accessing the SCM on a 2003 SP1 machine with SCM security
descriptor reverted to the settings given in
http://support.microsoft.com/kb/907460/en-us.
If you logon as domain admin, it's no problem to get a list of *all*
services on the remote machine in the same domain.
Given that, I *assume* that in a non-domain relationship, all users
accessing the SCM from another machine are treated as non-privileged
(maybe even guest) users, beginning with 2003 SP1.
However, what I don't understand is, why it's not even possible to
enumerate all services, even though the security descriptor is set to
the more open setting from http://support.microsoft.com/kb/907460/en-us.
It makes sort of sense that subsequent calls to OpenService fail,
because the SDs of the services didn't change, but the SCMANAGER access
should at least work, shouldn't it?
I have the vague feeling there's no solution to my problem, rather
it's a situation which is planned from a security perspective.
Given that it works fine when running EnumServicesStatus within a domain
from a domain admin account, this doesn't seem to be a bug, but a
feature. However, I would at least like to understand why that happens.
> Also, have you tried to run the ProcMon on the Server2008? Does it report
> any registry access failure during the remote query? If not, I suspect the
> remote query is rejected at the firewall level instead of the local
> registry service information level.
May I express serious doubts that in the same EnumServiceStatus call
some service entries are send back to the calling machine and some are
not due to a firewall setting? Especially given that none of the
machines has an active firewall because they are running in an isolated
test environment.
> Anyway, I will spend more time on this issue and get back to you ASAP.
> Thanks.
Thanks,
Jeffrey Tan[MSFT]
Thanks for your feedback. I have got the SCM team working with me with this
issue now.
Do you mean that you can only successfully perform remote query with domain
administrator account? This is different from our test result.
In my testing scenario, the Win2008 and Win2003 machines are both in our
corp domain. My domain account is not a domain administrator but a normal
account in the domain. My domain account is in the local Administrators
group of these two machines. In this test scenario, I get the same query
result from local Win2008 and remote Win2003 machine query.
Also, based on the feedback from the SCM team, they also can not reproduce
this problem.
Is it possible for you to get more details to help us reproducing this
problem? Thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=========================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Corinna Vinschen
"Jeffrey Tan[MSFT]" wrote:
> Do you mean that you can only successfully perform remote query with domain
> administrator account? This is different from our test result.
>
> In my testing scenario, the Win2008 and Win2003 machines are both in our
> corp domain. My domain account is not a domain administrator but a normal
> account in the domain. My domain account is in the local Administrators
> group of these two machines. In this test scenario, I get the same query
> result from local Win2008 and remote Win2003 machine query.
Ok, so I said "domain admin" but actually it's any account which is in
the local admin group of the machine you're querying. Sorry, I didn't
care if it's a domain admin or local admin.
Anyway, what I said in my previous postings is that this problem occurs
with *non-admin* accounts in a domain, as well with every account,
including admin accounts when running in a non-domain environment. I'm
sorry, but I'm really at a loss what I should explain more detailed. I
was sure I explained this rather detailed in my previous two postings.
Ok, so below you'll find the two scenarios I tested, in a step-by-step
approach. I'm interested to get answers to the four questions asked
at the bottom of this posting.
A preliminary note: All services on the test machines are either OS
services, or Cygwin services. No third-party products are involved.
The Cygwin services get installed with default security descriptors.
Another preliminary note: When I mention the non-admin account below,
it's really a non-admin account. It's member in the groups "Users",
"Remote Desktop Users" and, in the domain scenario, in "Domain Users".
First scenario:
Two machines, both are stand-alone machines, no domain wide and far.
One is a 2008 server (now called SERVER) with the setting from
http://support.microsoft.com/kb/907460/en-us applied.
The other machine is some Windows machine, no matter what, now called
REMOTE.
On SERVER, 113 services exist (111 OS, 2 Cygwin).
Calling `sc query state= all' on that machine locally from the
SERVER\administrator account returns all 113 services.
Calling `sc query state= all' on that machine locally from the
SERVER\non-admin account returns all 113 services.
Calling `sc \\SERVER query state= all' on REMOTE from the
REMOTE\administrator account returns only a subset of the services,
actually 24 out of the existing 113. None of them is a Cygwin
service.
Calling `sc \\SERVER query state= all' on REMOTE from the
REMOTE\non-admin account returns only a subset of the services,
actually 24 out of the existing 113. None of the two Cygwin services
show up in this list.
Second scenario:
Two machines, both are members of the same domain called DOMAIN.
One is a 2003SP1 server (now called SERVER) with the setting from
http://support.microsoft.com/kb/907460/en-us applied.
The other machine is some Windows machine, no matter what, now called
REMOTE. The machine is a member of DOMAIN.
On SERVER, 93 services exist (91 OS, 2 Cygwin).
Calling `sc query state= all' from the DOMAIN\administrator account on
that machine locally returns all 93 services.
Calling `sc query state= all' from the DOMAIN\non-admin account on
that machine locally returns 92 services. The single missing service
in the non-admin listing is SysmonLog.
Calling `sc \\SERVER query state= all' on REMOTE from the
REMOTE\administrator account or from the DOMAIN\administrator account
returns all 93 services.
Calling `sc \\SERVER query state= all' on REMOTE from the
REMOTE\non-admin account or from the DOMAIN\non-admin account returns
only a subset of the services, actually 67 out of the existing 93.
None of the two Cygwin services show up in this list.
Q1. In the first scenario, why can I only enumerate a subset of the
services running on SERVER from the REMOTE machine? Why is this
independent of the admin-ness of the REMOTE account?
Q2. In the second scenario, why can I only enumerate a subset of the
services running on SERVER from the REMOTE machine, if the
enumerating account is a DOMAIN\non-admin or REMOTE\non-admin
account?
Q3. In the second scenario, why can I enumerate (almost) all services
(92 out of 93) from the DOMAIN\non-admin account when it's logged in
on SERVER, while I can only enumerate a subset of services (67 out
of 93) when I'm logged in with the same DOMAIN\non-admin account on
REMOTE?
And, last but not least, the most important question:
Q4. What are the criteria which decide whether a service can be
enumerated from the REMOTE machine or not? Is it something in
the SD of the SCM or something in the SD of the service itself?
Anything else?
Just for clarity, to me it does not look like it has to do with the
SERVER machine being 2003SP1 or 2008. The results seem to be
exchangable, just the numbers are slightly different.
Thanks in advance,
Jeffrey Tan[MSFT]
Thanks for your detailed information.
I finally asked our lab to setup a virtual Win2008 machine for
testing(because I do not want to modify my working Win2008 machine SCM
security setting). It seems that I can reproduce your problem now, below
are the details:
First, I added the Win2008 machine into the domain, because if the machine
did not join the domain, the query from my work machine will get "Access is
Denied" error. This is because the Win2008 workgroup will treat the remote
query as Anonymous and reject it. Also, since the Win2008 machine can not
recognize the domain, I can not add any remote accounts into its local
"Users" group.
We setup a Win2008 virtual machine adding to my corp domain. This operation
will automatically add "[Domain Name]\Domain Users" group into the local
"Users" group on Win2008. Then, from my Win2003 working machine, I called
"sc \\Win2008_VirtualMachine query state= all>F:\services.txt". I find the
queried services result will be much less than the local query on Win2008
with local administrator. Then, I created a new account "SecurityTestUser"
on Win2008 adding to the local "Users" group. If I runas this
"SecurityTestUser" locally on Win2008 for querying, I will get the same
result as local Administrator query(full services list). "fareast\Domain
Users" and "SecurityTestUser" are both in the local "Users" group on
Win2008 machine, but querying from locally and remotely.
Could you help to confirm if this is exactly the same scenario and problem
as yours?
I have tried to use ProcMon to track registry access to "services" registry
category. However, I did not find any processes accessing it. I suspect it
is the OS kernel that is accessing registry.
Anyway, I will help our SCM team to reproduce this issue and try to find
out the root cause. I will update you as soon as we get anything useful.
Jeffrey Tan[MSFT]
Sorry for letting you wait.
Oh, it seems that this is a security enhancement after Win2003 SP1. The
MSDN page below documents the SCM and services security settings:
"Service Security and Access Rights"
http://msdn2.microsoft.com/en-us/library/ms685981(VS.85).aspx
Summary is that starting Win2003 SP1 non-admins were not allowed remote
service enumeration by default to prevent hackers from understanding what
services are in a box and attack high value targets (SQL servers, exchange
servers, etc.) This included not only OpenSCManager access but also
default security of individual services.
Also, if you wanted, they can set the security descriptor on the individual
services of interest (cygwin services?) using SetServiceObjectSecurity API
to allow whichever user SERVICE_QUERY_STATUS access and such services will
show up in the enumerated list. Please note that it is a security risk
deviating from the default security descriptor.
Hope this helps.
Corinna Vinschen
> Hi Corinna,
>
> Sorry for letting you wait.
>
> Oh, it seems that this is a security enhancement after Win2003 SP1. The
> MSDN page below documents the SCM and services security settings:
> "Service Security and Access Rights"
> http://msdn2.microsoft.com/en-us/library/ms685981(VS.85).aspx
Thanks for the info,
Jeffrey Tan[MSFT]
Glad to see my reply can help you. For all the services that can be queried
from remote non-Admin, I think they modify their service DACL explicitly to
grant "Authenticated Users" "GENERIC_READ" permission.
If anyone in the community is interested, regarding my original "ProcMon"
did not report any registry
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ for services.exe
problem, this is because the service control manager keeps track of service
status internally so for a query like state=all, it doesn't need to refer
to the registry. If we use SC to query a service for information the SCM
doesn't retain, like the description or privileges, we'll see registry
accesses from services.exe.
Additionally, I find another different behavior of Windows Server2008 below:
I have performed some test on both Win2003 SP1 and Win2008 machine. I used
sysinternals accesschk and process explorer tool to check the service
object security setting.
On Win2003 SP1, if I create a .Net Windows service without any security
setting modification, it will be correct: grant only
SERVICE_USER_DEFINED_CONTROL to the "NT AUTHORITY\Authenticated Users" by
default. This is consistent with the link below:
http://msdn2.microsoft.com/en-us/library/ms685981(VS.85).aspx
On WS2008, if I create a .Net Windows service without any security setting
modification, it will *not* grant any permission to the "NT
AUTHORITY\Authenticated Users" by default. DACL panel did not contain ACE
for "Authenticated Users". So it seems that its default security setting of
service object changes in Win2008 now. I have requested the SCM team to
document this change.
Anyway, although the default security setting is different on Win2003 SP1
and Win2008, they both deny non-Admin remote by default. So they appear to
be the same in your scenario.
Thanks.
Jeffrey Tan[MSFT]
enough.
Also, the SCM team has confirmed that they had even turned off
SERVICE_USER_DEFINED_CONTROL for "NT AUTHORITY\Authenticated Users" in
Windows Server2008. They will notify the MSDN document team to add this.
Thanks.
Jeffrey Tan[MSFT]
Have you reviewed my last replies to you? Do they make sense to you? If you
still need any help or have any concern, please feel free to tell me,
thanks.
Corinna Vinschen
Jeffrey Tan[MSFT] wrote:
> Hi Corinna ,
>
> Have you reviewed my last replies to you? Do they make sense to you? If you
> still need any help or have any concern, please feel free to tell me,
> thanks.
The problem is solved as far as I'm concerned.
Thanks,
Jeffrey Tan[MSFT]
Thank you for the confirmation.
If you need further help, please feel free to post. Thanks.