Guido, Thanks
for the kind words. Very much appreciated. As to
qualifying the customer - ~50k staff and production, multi-national
company. And, as many companies tend to be – they value the opinion
of Consultants and outsiders rather than their own employees to some
degree. Many times, I think, management has a tendency to believe that
someone from the outside has a more “worldly” opinion or viewpoint,
while the employee is to narrow focused and too close to the problem. It has
been my observation as a Consultant that I had a much easier time conveying
ideas to Management than when I was the employee conveying the ideas in a quite
similar manner. In fact, I’ve garnered the respect and trust of
many of the folks that I worked with on projects as the outside consultant by
gathering some of their ideas and getting those implemented along with the
project – even though they had been trying to simply get and ear for 6
mos. or more. It’s
politics – and the bigger the company, the bigger the disconnect from the
worker to the decision makers. Rick From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Grillenmeier, Guido 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 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! |