lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [day] [month] [year] [list]
From: jason.eberly at (Jason Eberly)
Subject: Disabling DCOM: Ramifications?

  After some testing in the lab, I went ahead and disabled DCOM on all
of the Win2K AD Controllers in the environment I support (approx. 80

  While we haven't yet had the chance to test all of the finer points of
package distribution via SMS, we haven't yet seen or heard of any
strange behavior or lack of infrastructure services as a result of the

  Specifically, I have tested: Terminal services, remote management via
MMC (event viewer, etc.); mapping drives and whatnot; login script
functionality; and SMS remote management tools.  No issues whatsoever.

  If there are additional tests anyone would like to see performed,
please let me know.  If I can't safely perform the tests in production,
I'll try them out in the lab...

  The scripts I used to disable them aren't especially clever or unique,
but just in case you want to cut and paste, here is what I did.  Note:
requires Kix32, shutdown.exe, and nltest.exe - all of which (if memory
serves) may be found in the ntreskit.

--- DISCLAIMER: This is all stuff I stole from this list or other
sources and cobbled together haphazardly.  There is absolutely no
original thought or special effort here, just the quick-and-dirty
process I used to slam closed the gaping DCOM barn door.  So if torn
between the urge to skip the following or fire up the flamethrower -
please, just skip it!  :) ---

1)  Generate a list of DC's to deploy to: NLTEST /DCLIST:[mydomain] >
(Clean up resulting text file just enough to be suitable for parsing...)

2) I used the following KIX script to change the registry key which
enables/disables DCOM.  You can paste this into a text file and save it
as a *.kix file (I called mine killdcom.kix) :

  $ReturnCode =
  If @ERROR = 0
    ? "DCOM Disabled on target: " $target
    ? "SCRIPT FAILED ON " $target

3) Since this script is written to disable just one machine, I then used
a loop to feed it the list of targets previously generated.  From a
command prompt:

  FOR /F %P IN (dc.txt) DO kix32.exe killdcom.kix $target=%p

4) After reviewing the output, the servers still need to be rebooted.
(side note: dammit, Kix doesn't seem to like to output to a text file
with the > redirection symbol, so I had to run it a second time and just
watch the messages scroll...  Wasn't worth the energy to sort out
logging, heh, someone here will prolly do that soon anyway and include
it in the flamage) ... To do so, I used the same loop as before, but
with the shutdown command instead:

  FOR /F %P IN (dc.txt) DO SHUTDOWN -m \\%p -r -t 7200

Note: depending on where you got your version of shutdown, the syntax
may vary; mine was, I think from some antique NT4 reskit.  Also note,
the 7200 is an arbitrary number of seconds (from 0 to...?) until the
reboot - when I ran it, I just happened to need it to occur in 2 hours.

  OK, I know this whole post is probably going to just piss off the
really hard core admin types due to lack of new and clever insights, so
- I apologize in advance.  *sheepish grin as I duck for cover!*
We don't just delete spam, we delete spammers. []
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url :

Powered by blists - more mailing lists