I don't know if you are trying to bait me or your head
recently got stuck between your gluteus maximi.
Obviously since you have your mouth to the firehose
you know that I was pointing out that the ACL change on an object that
previously couldn't have the ACL changed now disallows a normal user from
enumerating services on an SP1 Server remotely. This means that either A) They
need to be logging on locally (interactively) or B) They need to be given Admin
rights to the machine where previously they didn't need them or C) The ACL needs
to be modified from what MS set in order to use the least
privileged account to monitor the services. Also obviously, this means you know
that your monitoring must change considerably or you need to at least partially
undo what MS did. The issue on the last being that the documentation on how to
do it was terribly lacking and the point where most of these security settings
are handled is barren of anything for this setting. Creating a service account
and disabling interactive auth does nothing to help anything, in fact it can
open up holes itself. Thankfully when this was previously discussed on the list,
there was an MS person reading that knew what was going on and could point at
his blog for how to correct the problem.
If I cared to sit
down with the security folks who came up with it I would ask, all of this for
what real security benefit? If you are attacking a specific service, you either
just fire the "magic pill" across regardless or you can still view
individual service status by asking for it if the tool you are using knows
how to ask for the right level of perms when connecting. Enumeration isn't
needed for hacking. It only slows normal people down because most of MSes
tools don't access the services with the proper level of
perms requested either. That means all of the MS GUI service tools are
now useless to people who maybe want (and have been delegated) to manage a
single service or use the GUI to verify that the server IT manages for them is
running their services. As for monitoring itself, if the previous
mechanism to monitor the service was with an ID that had no special permissions
on the server, creating a new ID and spinning up a service on the local machine
is more invasive and insecure as you now have a new vector to actually attack
the machine, a service that is inside the main wall of security as it already
running on the local machine. This change stopped a lot of people, at least
for a while, who had least privileges configured for managing stuff from being
able to manage and required them to be given a lot more permissions than they
really needed. Go team!
I don't mind if you don't comment on why MS did something
or even how, obviously you have no control over anything they do, you are MCS,
you try to implement what they give you. However, your first response in light
of your second combined with the conversation at hand doesn't seem to make any
sense. It didn't make a lot of sense even without your second
response.
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Sunday, November 27, 2005 12:01 AM
To: [email protected]
Subject: RE: [ActiveDir] Windows 2003 SP1 upgrade...
<yawn>
Sometimes, I realize that I commented on something, go back
and read the thread and come upon a novella.
Occasionally, all I want is a paragraph. Hopefully,
all of this information wasn't meant for me, because all I do day in, day out
these days is drink from a fire hose - hence why I'm not around so much these
days. This hopefully helped others, as it presents no value to me right
now at all. I'm versed in this quite well.
Yes - the question was meant to stir a conversation - more
about interactive as a mechanism to remove a looming hole for accounts that NEED
high level permissions but don't NEED to be logged into. Surprisingly,
this is a vector that most people forget about. If you don't need to log
in to it - why does it have interactive?
As to which LUA - the actual, higher level principle of
giving nothing (not just people) any more access than it absolutely
requires. I made the assumption that the ACLing that you referred to had
already removed any and all unnecessary permissions to things unsavory,
dangerous, and shiny-but-sharp from touch.
Hence the question about interactive. It's not an
ACL.
And, as to our direction with software and decisions made -
I don't comment much public ally anymore. I've gotten myself into too much
trouble of late, another reason I'm not here as much.
Brett can answer some of these, or get someone from the dev
team on Security issues. I'll answer anything you want on MCS and how to
implement. But, as to why things are or where they are going to be in
future product - I won't be commenting on that. That's another pretty,
shiny, sharp-thing.
Rick
--
Posting is provided "AS IS", and confers no rights or
warranties ...
From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe
Sent: Monday, November 21, 2005 7:45 AM
To: [email protected]
Subject: RE: [ActiveDir] Windows 2003 SP1 upgrade...
Sent: Monday, November 21, 2005 7:45 AM
To: [email protected]
Subject: RE: [ActiveDir] Windows 2003 SP1 upgrade...
No. MS made it now so that you either need to use an ID
that has admin rights or you have to change the ACL on the SCM to monitor the
services OR the application doing the monitoring needs to know specifically what
service to look at AND know how to ask how to open it WITHOUT asking for
enumeration rights which is unusual since it was always possible previously
because the ACL on the SCM wasn't configurable. All example source showed how to
do it in a way that would break after the change.
What this change does is require more privileges to do work
easily done with an unprivileged account or to require you to partially undo
what MS did to lock it down. Since the ability to change the SCM ACL
previously wasn't something that could be done at all, I understand the idea to
lock it down once it could be modified. However, MS didn't really give much in
the way of tools to operate with it set that way. There was one tool, SC
that was modified in order to work with it and at least initially, it
wasn't very well documented. This easily should have been a GPO config item just
like the other service ACL configs. Personally, I would have greatly
appreciated say a new group... RemoteServiceEnumeration or something like that,
then people simply add principals to that group in order to keep their apps
working.
I have often monitored services on servers remotely with an
ID that has normal user rights in the domain. The ID had no permissions on the
servers at all other than to look at them. Others have done the same. The
monitoring scripts/apps would list all services to see what was running and what
wasn't running, any changes whatsoever would be reported so you knew when
something got added and when something got removed or if something was started
that wasn't previously running or something that was previously running no
longer was running. After SP1, it took modifying the ACL or granting admin level
rights or required the ID to be used locally on the local machine instead of
remotely.
This change, forced people, at least initially until
documentation started coming out, to use higher power IDs to do
something that previously could be done with lower power do-nothing IDs.
To put it another way, there is no technical reason whatsoever that an
admin ID is required to monitor services. Heck you can even delegate service
control to non-admins, I have been giving out ability to stop/start specific
services on servers since early NT4 days.
BTW, which LUA are you referring to? The actual principal
of least user access where you don't give people access to things they shouldn't
have or the LUA to allow non-privileged users to actually do things without
being an admin? I think the first, but it caught me by surprise and I read it as
the second initially because most MS folks are using LUA strictly to speak about
the new capability in Vista. I didn't mention LUA but was referring to
not having to be an admin to do something simple.
I have no problem with locking things down, but don't catch
people by surprise. This should have been something you are told about DURING
the lockdown where you are asked WHO should be able to do it by adding
them to a security group or worse but better than nothing a right, or it
should have been something easy and intuitive to back out or modify the
functionality for. Most MS admins haven't a clue what SC is, those of us that
did had no clue there were changes in it until people started talking a lot
about this issue. Even still, the MS GUI service tools don't work correctly with
this change.
I have heard people using this "fix" as an excuse for why
people should have admin rights for doing things they don't need admin rights
for because, they say, you never know when an MS fix is going to change things
such that delegation won't work and you can't afford to not have things
work.
I think I understand the logic behind the change, it is
about obscuring what is running. Obviously that is worthless from an automated
hacking tool standpoint because they don't generally try to enumerate services,
they just attack ports. Hiding the service list isn't going to do much just like
renaming the admin account isn't going to do much if you allow enumeration of
the SIDs. Which is another good example, instead of just blocking that
capability, what did MS do? They gave you the option....
joe
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan
Sent: Sunday, November 20, 2005 7:19 PM
To: [email protected]
Subject: RE: [ActiveDir] Windows 2003 SP1 upgrade...
True. But, to monitor services does someone have to
log on to the server? Would a good and SAFE work around - if the said user
doesn't need to log on, to create a service account to do the work, but remove
the interactive rights?
Seems to me that proxying the access would be the close to
ultimate in LUA.
Rick
--
Posting is provided "AS IS", and confers no rights or
warranties ...
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Sunday, November 20, 2005 5:21 PM
To: [email protected]
Subject: RE: [ActiveDir] Windows 2003 SP1 upgrade...
The biggest thing people complaint to me about that isn't
documented as an issue below is with the new ACL on the service control manager.
The new ACL really locks down who can enumerate services remotely. This has
impact on multiple different applications and services, especially any
monitoring that isn't using full admin IDs. Kind of sad actually, people trying
to run with least privs for the monitors got nailed and had to give out more
perms until info started getting out on how to fix the
problem.
Check out the items exposed by the following
query
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Frank Abagnale
Sent: Sunday, November 20, 2005 3:47 PM
To: Active
Subject: [ActiveDir] Windows 2003 SP1 upgrade...
Hello all,
I am planning on rolling out SP1 to my
Domain Controllers. I have looked through msn search to find known issues with
applying SP1 to DC's.
I found the following kb articles
(below) so I can prepare if I have issues. I haven't run into any issues in
my test environment however, has anyone else had any undocumented problems they
may wish to share? One of my DC's is also a WINS, DNS, DHCP, FSMO role holder,
so any issues or pointers that you may have come up against would be
appreciated.
Also, is there any recommendation as to
which DC you choose first when you upgrade to SP1?
The Windows Time service
may generate event ID 7023 after you upgrade to Windows Server 2003 Service Pack
1
Network issues that affect TCP/IP and RPC traffic across firewall or
VPN
The incorrect HAL may be applied if your computer uses a custom HAL
Thanks
Frank
Yahoo! FareChase - Search multiple travel sites in one click.
Yahoo! FareChase - Search multiple travel sites in one click.
