|
Hey Rick - sorry to hear - but from how I know you, this
has simply made it easier for you to move on to a new company, something you'll
have wanted to do for a while now and never did due to the complications
involved. I am very positive, that you won't need to worry about finding
anything.
As to this discussion, I find too often, that mid-size companies
are not willing to take that last step which would ensure a better security
model - and many have good reasons to do so and accept the risks involved. But
then again, they've never had a real issue and if they would, that thought would
likely be different. It's different with large corporations - I can
usually convince them to do the right thing. So I guess we must
differentiate the type of customer when discussing these sort of things.
This would make the discussion more "real world" like.
/Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Samstag, 11. Juni 2005 05:30 To: ActiveDir@mail.activedir.org Subject: RE: [ActiveDir] mstsc /console switch for non admins joe, Yeah, you
had to know it was coming – Rick’s $.02
worth. Remember
what we both were relieved of our positions for? Oh, that’s right – I
didn’t tell you about me! Suffice it to say I took one for my team because
upper management was trying to get things done that were wrong, technically,
tactically and strategically. They, in fact, are on the verge of
violating, IMHO, Sox 40x controls. I complained, I argued, I provided
information that they were on the precipice of something really bad.
Apparently, I finally hit nerve and my rubbing of folks the wrong way (from
their viewpoint) caused my layoff via ‘Elimination of my
position’. Whatever. I got fired for saying what I believed
was right. You and I see eye to eye as it is with DC permissions and
access controls. You and I see eye to eye on security as a
whole. However,
our view is not really a well accepted PRACTICE in Corporate environments.
Our beliefs are actually radical when compared to the norm in
practice. Does this
mean that we’re wrong? No. It DOES mean that our Secure Conscious
viewpoint can still get one fired. It’s not a popular stance to say “Of my
10 Systems Admins, only these two can log on to a DC.” The common
rebut is “Everyone needs to be able to do these functions when on call” or “when
the help desk calls, we need everyone capable of dealing with the problem at
hand”. I still
believe that we are correct, but – most folks don’t live in “Rick and
joe-land”. They live in the screwed up Corporate world where the only
endgame is money, and the generation of it [1]. With IT being a cost
center, and Security viewed as an even bigger inhibiter to Production, most
companies need to have a *Serious*
computer security event to be convinced that they have their priorities in the
wrong places. Money
generated doesn’t matter if you can’t guarantee that you can SECURE your
customer’s money / data / private information. Rick [1] Case in
point. One of the guys that I used to work with was told that one thing
management was really pissed about was the time it would take me to lock down a
server. For estimation purposes, I told folks to plan for (and published a
timeline for planning purposes) 2 days for initial lockdown, 2 days for final
lockdown and application of IPSec filters, and 3 days for InfoSec to certify the
system (The time for InfoSec is THEIR guideline from their VP – not my timeline
at all). Typically, I would have a server back to the application team the
same day to apply their apps, and would take one day to do the final lockdown,
apply IPSec, and scan it before sending to InfoSec (yeah, I’m kind of funny that
way – I like to KNOW what the scan looks like before I send it for
certification). Typically, it would take the application folks (who were
the ones that complained about the time *I* took) about 2 – 3 weeks to get their
applications on to the box. Now for the
funny part. No one else has a clue how to do what I was doing Nada –
nothing. Nobody wanted to learn the boring, mundane, and highly visible
process of hardening servers for the perimeter and DMZ. So, other
Supervisor gets this server that needs to be hardened. He assigns it to my
friend and tells him, “I don’t care if you know how to do it or not – just do
it.” He then proceeds to instruct him to just tell InfoSec you have a
server to scan. When you get the vulnerability report back, just fix what
shows up as problems and send it back over to them for certification
again. “And, I need it by Friday, end of business…” How long did
this ‘abbreviated, BS, crap, end run, corner cutting hardening method for
losers’ attempt take? Three
days. Yeah.
They shaved a whole bunch of time off of my usual time to delivery.
<G> R From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe I received a some
offline questions on this that can be collected into three main
questions 1. What are the things
these non-admin but natively enhanced users do to compromise the DC or enhance
their permissions? 2. What would you do in
this situation? 3. SBS seems to
contradict everything you say, MS obviusly doesn't have an issue with these
things all being together. The first I will not
respond to in any real detail. I do not want a response from me becoming the
guidebook for evil people on how to escalate privs on a DC and compromise a
forest, I am not thinking any customers I help would be appreciative of that
because there really is no feasible way of locking this stuff down. Suffice to
say that someone in that position can run anything they want to on the DC and
can easily get a security context over and above what they should have. If you
want the simplest stupid thing that could be done is they could put a trojan on
the box that some silly domain admin runs. Alternatively, because this is a
higher bar item I will mention it, servops can load drivers. Say like a keyboard
driver...Those are the hard ways to get things done.
The second is tough, it
depends on the specific situation. However those that have worked with me on
projects directly know that if a hard problem comes up, I can become pretty
creative. If I am responsible for the security of a domain controller, I can be
extremely creative. First off, print
sharing. I wouldn't do it through the DC, most corporate printers now are
connected through the network and have their own queuing mechanisms, use them.
If it has to go on a DC, I as a domain admin, would handle all server based
operations around it. I would not delegate it directly. As I had time, I would
whip up a web based proxy system to give others the ability to do limited
operations scoped by specific business rules on the print queue, such as being
able to clear it maybe. I have done this in the
past. Second off, file
sharing. Again, I wouldn't do it through the DC. I think setting up file sharing
through a DC is one way to lower your availability of f&p shares. Domain
controllers sometimes have to be rebooted to clear various replication issues.
The key components are so deeply embedded in DCs that you can't just stop and
start pieces. MS is working on that, but at the moment, it isn't there. If you
have a replication issue or authentication issues, do you boot everyone out of
the shares so you can fix it? If so do you go to everyone's desk to make sure
they properly close the Office Docs so they don't get corrupted? If I had to do
it, again, domain admins would have a new job, managing the file share info and
backup processes. The file shares would not be on any physical disk with my OS
or AD files. I would work on delegating off specific items through a web proxy
again with specific business rules. I would also make it so the stuff created
could NOT be regularly accessed by Domain Admins (only allow backup access which
is handled through different perms). This could be overridden so I would set up
a process that constantly was rewriting ACLs on the shares and the folder
structures. Reason being, you don't need some admin accidently running some
program that some knuckle head uploads to the server that can cause harm if run
by someone with a lot of rights. But wait, domain admins need to be able to work
and they keep files on those servers to.... Domain Admins should not be using
Domain Admin IDs for most work, they should only use those special IDs when they
are purposely making changes or looking at something they absolutely can not get
to without the domain admin ID. I was a domain admin for a long time, by far,
most of my time was spent using a normal userid for troubleshooting and
daily work. The third
question, SBS. Do not take your environment security and operations cues
from SBS. SBS is a very specific product for a very specific niche. It comes
with you having to understand that you are compromising best security and system
operating practices strictly for the sake of saving money. Microsoft isn't
saying these things are ok to do, they are saying, hey there is a market here
and we are going to take advantage of it, if the customers are willing
to assume the risk to save the money we are willing to supply the product
for them to do so. If any decent sized
company started running their environment by spinning up DCs with all SBS
services and got MS in to do a review MS would almost certainly report issues
with it. SBS is the solution when cost overrides security very early on in the
game. If someone ever comes up with something to target SBS by coming through
one of the many possible penetration vectors and then targeting the domain
controller aspects, there are going to be a lot of small businesses that are
really hurting. Imagine, if you will, an attack that comes through one of the
random and many services on the machine and gets localsystem access rights and
takes over the machine. That attack can now successfully eat every other machine
in that domain. Done properly, an attack here would completely wipe out all
Windows computing cabability of the business very quickly and very easily.
This is why you always
run as few services and people with access rights on Domain Controllers.
The more vectors for attack you have, the more insecure you are. Add to
that that a domain is NOT a security boundary. I won't describe the mechanisms
but someone you give serv op rights (or even less) to in one
domain one night could find you looking at that same person with Enterprise
Admin rights the next morning while you have no rights to correct it without
hacking the DC at a core rather unsafe level.
joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of joe Honestly any time
someone asks a question like this my response is make them domain admins because
any time they want it they can take it and making them server ops is just a way
so you can report you have fewer admins, basically you are adhering to the
letter of some rule instead of the intended spirit.
Someone who gives
enhanced rights less than administrator on a DC to someone either doesn't
understand how Windows works (nor Basically what security
do you think you have by not giving them domain admins right up front?
This has been a popular
discussion point over the years on this list. Look through the
archives. This also goes for
people who allow other non-admin groups to run things like monitoring, Software
Delivery, Auditing, and distributed AV solutions that have services running
on DCs as local system or with other high privileges that allow ad hoc software
load or process execution.
joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Frank
Abagnale Hi, Our IT Operations team will require access to our remote
Windows 2003 DC's which act as File & Print
Servers. At the moment, they are members of the Built-in domain
Server Operators group which they use Remote Desktop to connect through to the
DC's for data/print services support/administration which gives them the remote
access they require. I would like them to use the mstsc /console switch
however, it seems only members of the domain administrators group can use this
switch as they are unable to logon. The IT Ops user can logon to the server via the physical
kvm console using the same account and have access. Only through mstsc /console
are they denied access. The Server Operators group have the following
rights: Allow logon through Terminal Services Does anyone know of a way around this so I can allow
Non-Admins use the /console switch? Any ideas or alternative workarounds appreciated and I
already understand that Non-admins are not supposed to logon to DC's but due to
politics we have to allow this...for the time being.
Thanks - Frank Discover Yahoo! |
- RE: [ActiveDir] mstsc /console switch for non admins Grillenmeier, Guido
- RE: [ActiveDir] mstsc /console switch for non adm... Rick Kingslan
