|
“other members of their particular market
segment get hit, or their customers start worrying.... “ In my case, the other folks that were
being lied to (outside of the Cxx’s signing false documents and the Auditors
collecting bad information) ARE the customers. They are being told that the
correct practices (Such as CISP, etc.) *are*
being followed and adhered to. Bull-Hockery… Rick From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of ASB >>Hopefully this will change now that it seems there is a
company a day releasing that customer information has been compromised. Ha. Everyone thinks that OTHER
companies make mistakes, but not them. Plus, most Senior Managers aren't going to
see it as a problem unless the other members of their particular market segment
get hit, or their customers start worrying.... -ASB
On 6/12/05, Douglas
M. Long <[EMAIL PROTECTED]>
wrote: Hopefully this will change now that it seems there is a
company a day releasing that customer information has been compromised. Here in
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 |
- RE: [ActiveDir] mstsc /console switch for non admins Douglas M. Long
- Re: [ActiveDir] mstsc /console switch for non adm... ASB
- RE: [ActiveDir] mstsc /console switch for non... Rick Kingslan
- RE: [ActiveDir] mstsc /console switch for non adm... Rick Kingslan
- RE: [ActiveDir] mstsc /console switch for non adm... deji
- RE: [ActiveDir] mstsc /console switch for non adm... Grillenmeier, Guido
- RE: [ActiveDir] mstsc /console switch for non... Rick Kingslan
