RE: Domain Controller Best Practice - Thanks!

• Previous message: Aditya Deshmukh: "RE: Prohibit Folder Compression"
• Maybe in reply to: Frank Knobbe: "RE: Domain Controller Best Practice - Thanks!"
• Next in thread: Adam Vaxvick: "RE: Domain Controller Best Practice - Thanks!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]

Date: Thu, 03 Mar 2005 11:36:10 -0500
To: "Murtland, Jerry" <MurtlandJ@Grangeinsurance.com>, Frank Knobbe <frank@knobbe.us>

Jerry,

1. You are correct about the virus issue.

2. Out of the box, users have access this server from the network on all
the domain controllers. I.e. They already have the capability to use
any of the remote admin access vulnerability to gain Admin right to the
domain. (You do patch your domain controllers right!!!)

3. This default behavior is changed in Windows 2003 I believe.

4. Having access to shares on the server does not give you the ability
to logon via terminal services. The former requires "Access this
computer from the network" while the later require "logon locally"
rights.

Dennis

-----Original Message-----
From: Murtland, Jerry [mailto:MurtlandJ@Grangeinsurance.com]
Sent: Sunday, February 27, 2005 7:21 PM
To: 'Frank Knobbe'
Cc: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!

I'm not even sure where to start. I've gone over this a few times, and
there are just too many things wrong with this scenario. I'm not going
to
go into details about how to hack a Windows box for obvious reasons, but
here are some simple no brainers:

1. Single Point of Failure (Infrastructure) A virus on this machine
can
knock out your entire infrastructure. A trojan on this machine and the
integrity of your data, along with protection of any sensitive
information
is gone.

2. Even if they don't have access locally, you give them access to the
box
over the network. Pick any one of Microsoft's critical (Remote Admin
Access) vulnerabilities coming out each month to gain access to the box
with
a legitimate User ID and Pass to the system. (Example:
http://www.microsoft.com/technet/security/Bulletin/MS05-011.mspx) SMB
traffic has been known to have tons of vulnerabilities, just do a google
search on "SMB Vulnerability". There is ample traffic to be footprinted
to
identify what systems do what, especially if authentication and file
sharing
happen to go to the same IP. Remember, defense in depth. Your internal
users are more dangerous than your external threats. It's one thing to
authenticate everyone on this system, but it's another to give everyone
access to this system via share permissions.

3. You may not be sharing your SAM file, but then again you probably
don't
need to after a simple Null Session displays every user ID on the
system.
And isn't it just handy that this same system is the Domain Controller.
Frank, you are probably familiar with this, but here is a link:
http://www.softheap.com/security/session-access.html.

4. Remember there is a difference between shares and NTFS permission
access. If you have shared permission on this system, the users ID's
are
authenticated locally as well. This means that Terminal Services can be
used to access the system via remote access. I think you mentioned that
you
would use NTFS throughout your system, this would be critical if you
want to
keep users off your DC.

Generally speaking and in your defense, you can come up with security
controls for just about any attack I throw out there. The key is knowing
how
much time you plan to spend on keeping your system up to date with
patches
(testing included), anti-virus, log reviews, user access reviews, etc.

I certainly am not trying to sell fear, my job is to minimize it by
deploying those security controls of which we are both speaking. Is it
incredibly wrong to put both on the same system? Maybe, maybe not.
It's
certainly not best practice, but it's also not the end of the world.
For
every pro there's a con and visa versa.

Jerry J. Murtland, CISSP

-----Original Message-----
From: Frank Knobbe [mailto:frank@knobbe.us]
Sent: Saturday, February 26, 2005 11:00 PM
To: Murtland, Jerry
Cc: focus-ms@securityfocus.com
Subject: RE: Domain Controller Best Practice - Thanks!

On Thu, 2005-02-24 at 16:00 -0500, Murtland, Jerry wrote:
> I don't think I've heard anyone say that "you are not creating a real
> security risk by allowing your DC to also function as a file server".
In
> fact you are. All user authentication is occurring on this system.
User
> ID's and Passwords for your entire organization are stored here in the
SAM
> file. I would consider this a substantial risk to any IT
infrastructure.

But you wouldn't be sharing the "SAM file" now, would you?

Aside from availability/load issues, what security risks are really
present? You have a Domain Controller in your network. Network
authentication is possible/exposed one way or another. One the other
hand, you have a simple file server service files via a share point. Why
can't the domain controller also be sharing files? (Again, focus on
security, not availability concerns. For this example, assume that hosts
has oodles of CPU power and bandwidth, and the share is located on a
separate dive from the AD data.)

Could you please outline some attack vectors that you would not have on
a layout using two servers (one for authentication and one for file
sharing)? Remember, we're talking access to file shares, not local logon
access.

Thanks in advance,
Frank

------------------------------------------------------------------------

---
------------------------------------------------------------------------
---
---------------------------------------------------------------------------
---------------------------------------------------------------------------

• Previous message: Aditya Deshmukh: "RE: Prohibit Folder Compression"
• Maybe in reply to: Frank Knobbe: "RE: Domain Controller Best Practice - Thanks!"
• Next in thread: Adam Vaxvick: "RE: Domain Controller Best Practice - Thanks!"
• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]