Domain Controller Security

  • 4.1K Views
  • Last Post 16 April 2018
fvandonk posted this 20 September 2005

I have a contractor
in a remote site. There is only 1 server in that site which is a
DC.
 
He needs to
administer that server.
-Create
shares
-Make file/share
permissions
-Change user
passwords in the User OU for that site.
 
He is not allowed to
log on to any other server is the domain.
 
When I make him a
"Server Operator" he can logon to any server in the domain.
 
Any idea on how to
lock him down to that one server and then how to lock him down on that one OU
where he should only be allowed to change the passwords of the
users.
 
Thanks!
Fred

Order By: Standard | Newest | Votes
kamleshap posted this 21 September 2005

For changing NTFS permission, directly give him FULL CONTROL rights over a particular folder, and ask him to create everything inside that.
 
3) restricting to specific OU
You can use delegation wizard in ADUC console to give his user id rights to manage that OU.
 
Kamlesh-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~"Fortune and Love befriend the bold"~~~~~~~~~~~~~~~~~~~~~~~~~~~ 

show

hcoleman posted this 21 September 2005

Fred-
 
This is not possible. While you can make it more difficult
for the user to do things you don't want him to, if you give him either physical
access to the DC or the ability to log on to the DC, he is in a position to
elevate his permissions to the point of owning your forest.
 
If you can move the files and shares to another machine,
then restricting him to only be able to change passwords within a particular OU
is easy by either setting the OU security directly or going through the
Delegation of Control Wizard.
 
Hunter

show

kamleshap posted this 21 September 2005

Ultimately, choice is yours, as well the consequences. 
-- ~~~~~~~~~~~~~~~~~~~~~~~~~~~"Fortune and Love befriend the bold"~~~~~~~~~~~~~~~~~~~~~~~~~~~

show

abaker posted this 21 September 2005

That sounds dangerous.

If you give him access to that server, particularly local logon
access, you might as well just put him in the Enterprise Admin group
and save both of you a few moments of work.
-ASB
FAST, CHEAP, SECURE: Pick Any TWO
http://www.ultratech-llc.com/KB/

show

listmail posted this 22 September 2005

Look through the archives.
 
The short answer is... "Just don't do it". You can't
possibly secure this regardless of what anyone says. If someone says it can be
made safe, stop asking them technical questions about Domain Controllers and
Active Directory.
 
Either you trust the person or you don't. If you don't
trust the person, then don't put the person in a position to show you the
meaning of screwed.

show

fvandonk posted this 22 September 2005

Thanks all for your replies. Joe: I got you loud and clear
and agree.

show

prenouf posted this 22 September 2005

As joe just said: don't do this.
 
Phil 

show

gideona posted this 22 September 2005

The only thing to do is to make him an admin of that site, or better yet make that site a child domain and make him a domain admin of that child domain. I know from experience that using a DC as anything but a DC is a freakin pain in the ass, my predecessor set a DC up as a print/file server and another as a SQL server (finally able to demote that one now, soon hopefully). But my citrix profiles are on the domain controller, and after months of trying to set delegation up properly in AD and setting up permissions in the appropriate folders on the DC, the only way I was able to get my Helpdesk admin set up to create accounts with my scripts so that I didn't have to do it was to make him a domain admin. My company is too damn cheap to get me another server to put the citrix profiles somewhere else. Oh yeah, and its an app server for network install of office (can you feel my pain).
 
So, if there is only one server in the site and its a DC, the only way to get him to do anything is to make him a domain admin (make it a child domain so he can't climb up the tree)
 
Gideon Ashcraft
Network Admin
Screen Actors Guildct: RE: [ActiveDir] Domain Controller Security
Look through the archives.
 
The short answer is... "Just don't do it". You can't possibly secure this regardless of what anyone says. If someone says it can be made safe, stop asking them technical questions about Domain Controllers and Active Directory.
 
Either you trust the person or you don't. If you don't trust the person, then don't put the person in a position to show you the meaning of screwed.

show

aricbernard posted this 22 September 2005

Allow me to logon to any DC in any domain
and I will own your entire Forest.

 

Allow me access to the console of any DC
in any domain (assuming I can use a USB port or floppy drive) even without an
account that allows me to logon locally and I will own your entire Forest.

 

The point, as Joe so eloquently phrased
it, is Just don™t do it!  The forest is the security
boundary, and if someone can compromise a single DC regardless of domain they
can own your forest.
Aric

show

prenouf posted this 22 September 2005

The only thing to do is to make him an admin of that site, or better yet make that site a child domain and make him a domain admin of that child domain. I know from experience that using a DC as anything but a DC is a freakin pain in the ass, my predecessor set a DC up as a print/file server and another as a SQL server (finally able to demote that one now, soon hopefully). But my citrix profiles are on the domain controller, and after months of trying to set delegation up properly in AD and setting up permissions in the appropriate folders on the DC, the only way I was able to get my Helpdesk admin set up to create accounts with my scripts so that I didn't have to do it was to make him a domain admin. My company is too damn cheap to get me another server to put the citrix profiles somewhere else. Oh yeah, and its an app server for network install of office (can you feel my pain).

 
So, if there is only one server in the site and its a DC, the only way to get him to do anything is to make him a domain admin (make it a child domain so he can't climb up the tree)
 
Gideon Ashcraft
Network Admin
Screen Actors Guildct: RE: [ActiveDir] Domain Controller Security
Look through the archives.
 
The short answer is... "Just don't do it". You can't possibly secure this regardless of what anyone says. If someone says it can be made safe, stop asking them technical questions about Domain Controllers and Active Directory.

 
Either you trust the person or you don't. If you don't trust the person, then don't put the person in a position to show you the meaning of screwed.

show

deji posted this 22 September 2005

make it a child domain so he can't climb up the tree

Not only will (s)he be able to run up the tree, (s)he will own the tree, the
leaves, the bushes, the grasses, and, for that matter, the forest.

The Domain is NOT a security boundary. It is an administrative boundary.
Service administrators have the ability to cross domain boundaries within a
forest.

show

ddeStefano1 posted this 22 September 2005

I thought that in ad domains are
considered security boundaries. In the cert exams, namely the 70-219, they are
considered as such. Also, how would a domain admin of a child domain elevate
his privileges?

 

 

Dan

show

mike.hutchins posted this 22 September 2005

Wrongo...
...snip
Active Directory uses
domains and forests to represent the logical structure of the directory
hierarchy. Domains are used to manage the various populations of users,
computers, and network resources in your enterprise. The forest represents the
security boundary for Active Directory. Within domains you can create
organizational units to subdivide the various divisions of
administration
snip...
 
link to actual
doc
 
http://www.microsoft.com/technet/prodtechnol/windowsserver2003/library/TechRef/6f8a7c80-45fc-4916-80d9-16e6d46241f9.mspx
 
(mind if it wraps)

show

mike.hutchins posted this 22 September 2005

Oh, and as for how, easy, but I won't tell
here...

show

listmail posted this 22 September 2005

The docs are wrong. Many of us have been hounding MS on
this for years. They really started straightening out docs with K3. Some of the
older 2K docs still suggest this security boundary at the domain. It really came
to a head when Lucent put out a paper on this and it started getting quoted in
the newsgroups and some of us just flamed the crap out of it.

 
No one here or anywhere should really publish how to
exploit rights on a DC to take over a forest. The answer is pretty self-evident
if someone understands the underpinnings and processes used in AD and since we
can't fully protect against it, it is better left undocumented. If
there was a guaranteed safe way to protect ourselves, then we could publish
that workaround and some time later publish the issue.
 
  joe 

show

Mark.H.Lunsford posted this 22 September 2005

You might consider a lower level OU
under the Domain Controllers OU with a different GPO that grants him local
logon to just that DC.

Thank You ! And have a nice day !

*******************
Mark Lunsford
KAISER PERMANENTE
Security Operations
Remedy Group: NOPS SECURITY EDOS SYS
Direct Manager: Bud Furrow
Email: Mark.H.Lunsford@xxxxxx
Outside Phone: 925-926-5898
Tie Line Phone: 8-473-5898
C ell: 925-200-4077
*******************


"Gil Kirkpatrick"

show

prenouf posted this 22 September 2005

I don't think anyone is going to get into how privilege escalation can be done, I know I certainly won't get into it other than to make people aware that it is possible.
 
Phil 

show

al_maurer posted this 22 September 2005

Most of the answers to Fred™s
business need deal with the security issue of the domain: valid, certainly, but
if the contractor really has a need to access files & shares, how would he
do it?  Seems this DC is the sole site server and acting as a file server in
addition to it™s DC duties.

 

Short of buying another server, an idea I
read about on this list was to install vm software and run the file services as
a virtual server.  Anybody tried that?

 

And in the 3k R2 world, if that DC were a caching-only
DC, does that change the situation?

 

AL

Al Maurer
Service
Manager, Naming and Authentication Services
IT
| Information Technology

Agilent
Technologies
(719)
590-2639; Telnet 590-2639
http://activedirectory.it.agilent.com
---------------------------------------------- 
"Cry
'Havoc!' and let slip the dogs of war"  - Anthony, in Julius Caesar
III i. 

show

Gil posted this 22 September 2005

See, for instance, the demo Guido did in the security
workshop with Sanjay at DEC last year.
 
-g

show

ddeStefano1 posted this 22 September 2005

Thanks, I actually found and read that
after sending that last post.

 

 

Dan

show

ddeStefano1 posted this 22 September 2005

I am not asking for exact procedures, just
more of methods how.

 

 

Dan

show

deji posted this 22 September 2005

VM would be an option, but moving the files and share, re-permissioning,
repointing scripts and re-educating users may make that unattractive.

BTW, I heard that "caching-only" will not make it into the final R2. Can
anyone confirm or refute?

show

ddeStefano1 posted this 22 September 2005

Cool, thanks for the info “
excellent as usual, joe.

 

 

Dan

show

listmail posted this 22 September 2005

I would first recommend that the DAs manage the shares.
Most likely you will need a project type share and home drive share. So you set
up shares called Proj and U which map directly to the appropriate folders in the
OS of PROJ and U which are on a disk that has nothing to do with the OS or AD.

 
You grant everyone FC on those shares[1]. Then the
filesystem gets FC for the local admin at the root of those two folders.
He/She then adds new folders as necessary and grants the required rights to
those folders. No need for ability to manipulate shares nor log onto the server
locally.
 
The caching only DC is called the RO-DC: Read-Only DC. At
this point in time I would say it should be no different. No one can answer for
sure until we see the actual implementation and people outside of MS start
figuring out the holes that exist. Anyone who thinks that having an RO-DC (or
the other chatter about "separation" between admin and DA) means your issues
with administrator/DA separation are really solved are probably going to be
quite surprised to find that to not be the case. I would be extremely
happy if this is corrected, but I really don't expect anything near it. In
fact, I do not foresee anytime in the near future a time when you can allow
non-trusted people to have local access to your DCs. The security model is just
such that you can't guarantee anything.
 
ADAM is a step closer to this lockdown, but ADAM is much
more secure by default than AD due to better default SDs and lack of a bunch of
the "junk" that has been bolted onto AD. Many of the same tricks won't
work to compromise it. In fact, the only way I can think of off the top of
my head for a local admin to do anything other than blow away a properly
secured ADAM instance they don't have access to is to do a raw DIT edit. I
could be wrong as I haven't done a real intensive sit down and think about it
exercise, but I expect I am right.
 
 
   joe
 
 
 
[1] I hate, literally hate, setting up different perms on
the share and the file system. Most admins can't figure out what is screwed up
when something gets screwed up when that is in place.

show

mike.hutchins posted this 22 September 2005

what is the main security device in AD? What "features"
does it have?
 
nuff said

show

listmail posted this 22 September 2005

Had I been in the audience when Guido was
demonstrating how to compromise forests (if he was showing enough for people to
figure it out) I probably would have been throwing things at him if I didn't
outright drag him off the stage. Guido is tall but I am not too proud to bite.

 
:o)
 
Just serious. People shouldn't need that demonstrated and
people that know how to do it shouldn't feel that is it something they should
show-off. You never know when someone might choose to use it against
you.
 
People either can figure it out or they can't. It may
hold a wow factor so folks can say, "cool you should see what I found out
at xyz conference" but is dangerous to be showing off just like if I started
showing off how to do other evil "really can hurt you" things I know how to do
with AD or Exchange or other vendors' apps. Things that would curl
folks toenails to see. About as far as I will go in the sharing is with
Dean to get him to verify I am not crazy and then Stuart Kwan (of the Ottawa
Kwan Clan) or ~Eric or someone else in a position to fix the problem. Of
course, people can always just say, well you are just saying that and I don't
believe you. I don't have a problem with that. :o)
 
  joe

show

mark.parris posted this 22 September 2005

And in the 3k R2
world, if that DC were a caching-only DC, does that change the
situation?

 

This is a Longhorn Server
feature in the 2007 timeframe

 

Mark

show

listmail posted this 22 September 2005

Changes are made in the directory which allows people more
access than they should have.

show

Gil posted this 22 September 2005

Yes, untrusted admin + DC logon access = no more security.

If you're trying to lock him down, then you can't give him access to the
DC. Can you give him a member server for the file shares and just
delegate the password administraion on the OU?

-g

show

listmail posted this 23 September 2005

That is fine, I have no problem with people
disagreeing with me. It still won't make me prove a point by documenting how it is done. If I gave a step by step or even a high level that
gave people who couldn't figure it out on their own a clue as to how it is done,
I would have to kick my own ass.
 
As was stated by others, knowing how this is done does not
arm you so that you can do anything more about it. Windows has always had two
areas you needed to secure and had different
assumptions of who should be in those areas. There is the remote access "zone" and the local access
"zone". I am talking from a software angle, not physical. If someone has
physical access and can do what they want, there really isn't any security
that can not be compromised in some way shape or form.
 
So now you have
remote and local access (or unrestricted remote system access such as c$ or
registery access, etc). If you have remote access, you have to go up
against the fixed function interfaces MS has made available to connect to and
manipulate the machine such as LDAP or kerberos or remote RPC calls, etc.
These have
been built by MS to be as secure as they, at the time they built the interface,
could. This is the most secure you will find things to be and even this can be
compromised. I simply ask you to review the history of all of the various worms
and viruses that have torn through networks infecting machines through
unauthenticated remote access. Think RPC interfaces, web interfaces, SQL
interfaces, etc. Again, making people use the system resources through remote
fixed function access interfaces is going to be the MOST secure you
will see. Honestly, for a long time this only secured you against people who
didn't want to harm you that were smart enough to keep their machines from being
infected by keeping the services that exposed handles to THEIR machines to a
minimum and ran firewalls to block all but the smallest amount of remotely
activated connections and didn't run code that they didn't fully
trust.
 
If you have local
access (such as TS to the desktop or remote console), you have bypassed a great
deal of the security barriers Microsoft has put into place. You are within at
least the semi-trusted zone and quite honestly in my opinion, the pretty much
fully trusted zone. You know the MS history in keeping the untrusted zone
safe, do you expect the semi-trusted zone to be that much more successful at
repelling people trying to do you harm? Look at your own house as an example,
once someone is past your locked (lol) windows and doors, how much more security
is there in place to make sure people do not get access to sensitive information
or modify your stuff in a way that you do not know? Probably little to none
because it isn't feasible to audit and/or monitor everything in real time.
Further to that, how many automated systems do you have in your house that you
have no understanding of and wouldn't know one way or the other if they
were compromised and being used against you. How do you know someone hasn't
installed a mini-cam in your bathroom and bedroom and not filming your
most intimate moments that you want no one to know about. That is very much
like the state of having local access on a PC. You giving someone access to your
house to put a camera in place and me telling you, hey, they can put a camera in
place does not mean you can detect it or prevent it. Your option, is to disallow
the person from being in a position where they can easily put that camera in
place in to begin with.
 
How exactly are
you monitoring your group memberships, what interfaces are being used? Most
folks I have seen who implement group monitoring only watch the membership
and not both membership and primary group membership. These are recorded
differently for LDAP interfaces. In that case, someone could act fast
enough and get themselves primary group membership before your LDAP interfaces
ever picked up on the membership change. What about the binaries on your
machine. Having AV software on your machine doesn't mean the machine isn't
compromised. It doesn't look to determine what should be there, it looks at a
fixed set of signatures and tried to determine what shouldn't be there based on
those signatures. Just because it says that some important exe isn't infected
doesn't mean it is what MS produced. Are your favorite plugins and utilities
and CPLs all the way they should be from MS or have they been compromised?
Has someone replaced one or more of your service or driver binaries? How do you
know? This has become more difficult but still isn't 100%, heck it probably
still isn't even 50%. Show me someone who can tell me 100% where every single
file and component on their machine came from and I can almost certainly show
you a liar or at best, a hopeful guesser. I have asked Microsoft for years to
publish a database containing checksum codes and file date/times for every
single file they have ever installed on any machine ever so that you could scan
a machine and determine every file that came from MS (and those that didn't) and
where they are from and whether or not they should be on the machine at the
current patch level and OS. Sadly, the answer is always a look of incredulity
and an admittance that no that isn't even remotely possible. Heck I had someone
in a meeting at a MS Security conference tell me that they couldn't even do that
with NEW files coming out because too many are coming out through too many
different channels...
 
Again, once you
are on the local machine, you are in the semi-trusted zone. If someone isn't
fully trusted, they shouldn't be there in the first place because once there,
someone stupid or someone intentionally out to get you will eventually hurt you.
The deck is stacked against you.
 
Right now, we are
lucky in that no one who seriously understands the technology has gone after
domain controllers and domains and forests as a whole. This means a lot of the
possible holes that could be taken advantage of to cause enterprise wide
disruption and destruction are not being attacked or at least not being attacked
in the most advantageous way possible. You need to be thankful for that because
if you can't sit down and work out on your own how someone could attack your
forest and you feel that granting local access to DCs is a responsible thing to
do then you probably don't have anywhere near the skill set and understanding
needed to stop someone who does have the ability to figure it out on their own
or has been taught how to do it.
 
Something I like
to tell people about with security is simply this.... Just because YOU
don't know how to compromise a given system doesn't mean someone else doesn't
and it can't be compromised. You can never, yes NEVER, prove a system
to be secure, only secure from you. The best you can do is prove a
system to be insecure and hopefully come up with a workaround to prevent that
insecurity from biting you.
 
If we start
publishing the various ways in which someone could compromise your domain
controllers, your domains, and your forests, all we have done is lower the bar
for the script kiddies and others to start doing it. If someone is
adamant about giving local access to domain controllers or even remotely
allowing them to reconfigure services and/or modify system components there is
nothing that I nor anyone else can do to protect them. Simply step back and let
them play Russian roulette on their own.
 
In my mind,
anyone who allows people who are not fully trusted DAs local access to DCs
or allows remote modification capabilities of system components is simply
careless and deserving of anything that happens. This could be you or it could
be the manager who forces you to do it after you fought tooth and nail.
Microsoft has given you an untrusted area to place untrusted people into and you
have decided you know more than they do and that it is safe to put untrusted
people into an area that requires trust. At the same time I would both love
to see it and hate to see it if some admin who felt so strongly that they knew
all of the holes and all of the ways to protect themselves from someone with
local access to a DC walked into work one day to find that every single domain
controller in their forest had suddenly ceased to be a domain controller or they
had been locked out of their own forest.
 
Again, it isn't
just local logon capability, it is anything that can be done to modify the
system components of a DC. Remotely or locally. Locally is just scarier because
the bar is much lower once you are there. Why do you not run email programs as
Domain Admins (and if you do run email programs as domain admins I don't care to
hear about it, good luck) or any other ID with enhanced rights? Why do
people go through the hassle of having multiple IDs, normal business type IDs as
well as enhanced privilege IDs?
 
I know I don't
know every way a DC, a domain, or a forest can be compromised and/or damaged.
THAT is why I don't allow anyone but fully trusted DAs access to DCs that
I am responsible for. It isn't because I know of several ways in which
it can be compromised. My opinion is such that if I allow a porcupine
in my house instead of keeping it outside, I am at some point probably going to
get poked. The more determined that porcupine is to poke me, the more likely it
is going to happen and the less chance I have to prevent it even though I know
it can and I know what that poke will look and feel like. Knowing after the fact
that I was poked is moot in my book, too little too late.

 
 
  
joe 

show

stefann posted this 23 September 2005

Here is my idea, Fred

Open up ADUC and click View / Advanced Features. Right click
on that one OU where he should only be allowed to change the passwords of the
users and choose Properties. Click Security tab, click Advanced button. Scroll
down to highlight OU. Click it and choose Edit. Here you can give the
contractor ability to change or reset passwords.

show

ddeStefano1 posted this 23 September 2005

Excuse my ignorance, but what is a TAM?

 

 

Dan

show

slinehan posted this 23 September 2005

That is the acronym for a Microsoft Technical Account
Manager (TAM).  Customers with custom support such as Premier
Support generally have a TAM that is assigned to them.
 
Thanks,
 
-Steve

show

bdesmond posted this 23 September 2005

Technical Account Manager. When you spend ample money with MS, you get
one of these. I think a PSS contract is enough to have one. They™re sort
of your MS/Customer bridge.

 

Thanks,
Brian Desmond

brian@xxxxxxxxxxxxxxxx

 

c - 312.731.3132

show

Nathaniel.Bahta posted this 23 September 2005

I believe that is your Technical Account Manager, from
Microsoft.  If you have a support contract with them, they will assign a
TAM that will give you access to valuable Microsoft resources that pertain to
the contracted item(s).
 
Nathaniel V Bahta
MCSE,CCNA,CSS1
General Dynamics Network Systems

show

sbradcpa posted this 23 September 2005

Us in SBSland have newsgroups and MVPs.

Brian Desmond wrote:

Technical Account Manager. When you spend ample money with MS, you
get one of these. I think a PSS contract is enough to have one.
They™re sort of your MS/Customer bridge. *


Thanks,

Brian Desmond

brian@xxxxxxxxxxxxxxxx

c - 312.731.3132

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

show

abaker posted this 23 September 2005

Excuse my ignorance, but what is a TAM?
 
 
Dan

show

davidadner posted this 23 September 2005

More specifically, if in your Premier support contract you
agreed purchase a certain number of hours for a TAM, you'll have one.  Not
all support contracts include hours for a TAM.

show

kamleshap posted this 23 September 2005

So I am very much interested in knowing it.

show

ddeStefano1 posted this 23 September 2005

Thank you for the info

 

 

Dan

show

abaker posted this 23 September 2005

I have to disagree a bit here...
 
Certainly, obscuring of information is not the way to feel secure.
If I don't know, how it is done, then how do I know, that I will be able to detect it, and trace it.And knowing it, I can always take extra precautions. Which I think, better than not knowing it at all.
basically, 25% more prepared and secure against this type of attack is better than 0%. and certainly it helps calibrate how much paranoid I have to be. :-) 
I would like to know, how it is done, as our team is currently migrating some good number of domains to single domain. And we are going to give local guys rights to logon to DC for some system maintenance purposes, till final single domain is cleaned up and we revert back to core team for day-to-day maintenance.

 
So I am very much interested in knowing it.

show

listmail posted this 23 September 2005

Which on the whole you may find to be far more helpful than most TAM's you
might have gotten...

Not trying to be mean, but I haven't had the greatest luck with TAMs. There
have been two in ten years that I can think of off the top of my head that I
liked (hey Efrem, hey Michelle) and I still beat the crap out of them when I
had them available. Generally, IMO, a TAM is a person who tells you what you
can't have even if they don't know what you are asking for.

I once talked about looking into a TAM position and a high level MCS manager
who had been trying to get me to join MS for I don't know how long told me
(he was drunk at the time), hell no, you are far too technically gifted to
be a TAM...
Just a thought though mom, you guys in SBS land seem to stick together
pretty well. I wonder if you could form a union with all of the SBS crazies
(and I say that lovingly) and have dues and such and then get a joint
Premier Support Account for all of you together and funnel issues up through
it.

joe

show

James_Day posted this 23 September 2005

I have a wacky idea that just might work - because I like wacky ideas.

What if you made a new forest with say one DC and one account - the
contractor guy. (since the security boundary is the forest, put him in a
new forest)

Then what if you made a trust between the two with selective
authentication.

Then what if using selective authentication in AD you set that machine to
allow authentication from that user account.

Then what if you made that user account admin or less of that machine.

That should grant him full rights on the little baby stand alone DC that
you set up - which if he breaks it he cannot do anything at all. It will
also grant him admin rights to that server (you could give him less).

It would also keep him off every other machine because his account would
need explicit access rights via. the selective authentication set up on the
trust.

And, seeing he has no rights in the real domain he would not be able to
change that selective authentication check, nor would he be able to give
himself access on any other box.

Of course, he could just sit on the file server and sniff for passwords -
so if he really wanted the access he would eventually get it somewhere -
but he would have to work for it.

Just a thought;

James R. Day
Active Directory Core Team
Office of the Chief Information Officer
National Park Service
202-230-2983
james_day@xxxxxxxxxxxxxxxxxx
|---------+---------------------------------->
| | ASB |
| | Sent by: |
| | ActiveDir-owner@xxxxxxx|
| | tivedir.org |
| | |
| | |
| | 09/23/2005 03:10 PM AST|
| | Please respond to |
| | ActiveDir |
|---------+---------------------------------->

show

AndrewCace1 posted this 23 September 2005

-Andrew

show

davidadner posted this 23 September 2005

Houston and San Antonio TAM's are, IMO, generally more technical than the
average TAM. Or, if not technical, they're much more directly involved with
their customers and know how to take care of them. Regardless, you're
always going to hear the dev/support/sales engineers bag on TAM's. There's
a pecking order that must be followed. :)

show

listmail posted this 23 September 2005

Yep it is very hit and miss. Sort of the same with MCS and PSS folks and
honestly any consultants or support folks anywhere. There are good ones, not
so good ones, and those that couldn't get a job anywhere else.

My favorite TAM/PSS/MCS/CONSULTANT/SUPPORT folks are the ones that can
proudly say, I don't know, but I will try to find out.

show

kamleshap posted this 23 September 2005

On 9/23/05, ASB wrote:

>>And knowing it, I can always take extra precautions.
 
The knowing it consists of "don't do it, because you can't secure it"
 
There are no extra precautions to take.  Certainly, you can increase your auditing, but you could do that now without knowing anything else.
 
 
>>basically, 25% more prepared and secure against this type of attack is better than 0%.
 
The more people that know, the higher the potential of attack.   And, as folks have pointed out, since there are no viable workarounds, it doesn't help anyone to have the number of potential attackers increased.
 
Call your TAM and see if he or she will provide enough details for you to feel comfortable.
 
 
 
-ASB
 FAST, CHEAP, SECURE: Pick Any TWO
 http://www.ultratech-llc.com/KB/
 
 

On 9/23/05, Kamlesh Parmar wrote:

I have to disagree a bit here...
 
Certainly, obscuring of information is not the way to feel secure.
If I don't know, how it is done, then how do I know, that I will be able to detect it, and trace it.And knowing it, I can always take extra precautions. Which I think, better than not knowing it at all.
basically, 25% more prepared and secure against this type of attack is better than 0%. and certainly it helps calibrate how much paranoid I have to be. :-) 
I would like to know, how it is done, as our team is currently migrating some good number of domains to single domain. And we are going to give local guys rights to logon to DC for some system maintenance purposes, till final single domain is cleaned up and we revert back to core team for day-to-day maintenance.

 
So I am very much interested in knowing it.

 
On 9/23/05, joe wrote:
The docs are wrong. Many of us have been hounding MS on this for years. They really started straightening out docs with K3. Some of the older 2K docs still suggest this security boundary at the domain. It really came to a head when Lucent put out a paper on this and it started getting quoted in the newsgroups and some of us just flamed the crap out of it.

 
No one here or anywhere should really publish how to exploit rights on a DC to take over a forest. The answer is pretty self-evident if someone understands the underpinnings and processes used in AD and since we can't fully protect against it, it is better left undocumented. If there was a guaranteed safe way to protect ourselves, then we could publish that workaround and some time later publish the issue.

 
  joe 
From: ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of DeStefano, DanSent: Thursday, September 22, 2005 2:09 PMTo:
ActiveDir@xxxxxxxxxxxxxxxxxxSubject: RE: [ActiveDir] Domain Controller Security 

I thought that in ad domains are considered security boundaries. In the cert exams, namely the 70-219, they are considered as such. Also, how would a domain admin of a child domain elevate his privileges?

 
 
Dan
 


From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of Phil RenoufSent: Thursday, September 22, 2005 1:28 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
Re: [ActiveDir] Domain Controller Security
 

Even as a domain admin of a Child domain they will still be able to munge your forest or elevate their priviledges. The security boundary in AD is at the forest, not the domain.
 

Phil 

On 9/22/05, Gideon Ashcraft wrote:

The only thing to do is to make him an admin of that site, or better yet make that site a child domain and make him a domain admin of that child domain. I know from experience that using a DC as anything but a DC is a freakin pain in the ass, my predecessor set a DC up as a print/file server and another as a SQL server (finally able to demote that one now, soon hopefully). But my citrix profiles are on the domain controller, and after months of trying to set delegation up properly in AD and setting up permissions in the appropriate folders on the DC, the only way I was able to get my Helpdesk admin set up to create accounts with my scripts so that I didn't have to do it was to make him a domain admin. My company is too damn cheap to get me another server to put the citrix profiles somewhere else. Oh yeah, and its an app server for network install of office (can you feel my pain).
 

So, if there is only one server in the site and its a DC, the only way to get him to do anything is to make him a domain admin (make it a child domain so he can't climb up the tree)
 

Gideon Ashcraft

Network Admin

Screen Actors Guildct: RE: [ActiveDir] Domain Controller Security

Look through the archives.
 
The short answer is... "Just don't do it". You can't possibly secure this regardless of what anyone says. If someone says it can be made safe, stop asking them technical questions about Domain Controllers and Active Directory.

 
Either you trust the person or you don't. If you don't trust the person, then don't put the person in a position to show you the meaning of screwed.

 
 

From:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx [mailto:
ActiveDir-owner@xxxxxxxxxxxxxxxxxx] On Behalf Of van Donk, FredSent: Tuesday, September 20, 2005 4:52 PM
To: ActiveDir@xxxxxxxxxxxxxxxxxxSubject:
[ActiveDir] Domain Controller Security 

I have a contractor in a remote site. There is only 1 server in that site which is a DC.
 

He needs to administer that server.

-Create shares

-Make file/share permissions

-Change user passwords in the User OU for that site.

 

He is not allowed to log on to any other server is the domain.

 

When I make him a "Server Operator" he can logon to any server in the domain.

 

Any idea on how to lock him down to that one server and then how to lock him down on that one OU where he should only be allowed to change the passwords of the users.
 

Thanks!

Fred
 -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~"Fortune and Love befriend the bold"
~~~~~~~~~~~~~~~~~~~~~~~~~~~

neil.ruston1 posted this 23 September 2005

Why
not draw an analogy with viruses and malicious code. You'll happily protect
yourself against potential issues and loopholes without understanding how the
viruses take advantage of those loopholes and make their way into your
environment.
 
The
arguments outlined below are similar. It is not important how the attack is
made, but rather that it is possible if you grant a user physical access to a
DC. Your TAM, I suspect, will tell you that if you grant access to a DC to a
user, then "all bets are off". i.e. Don't expect the OS to protect you from
that user since you just gave him the keys to the forest. You may trust him to
not do anything untoward, but that's not the point. If he/she has access to a
DC, then he/she has absolute (potential) control over the
forest.
 
 
 
neil
_________ Neil Ruston Global Technical Infrastructure Nomura International plc Telephone: +44 (0) 20 7521 3481

show

prenouf posted this 23 September 2005

I know thats not what you were trying to say ASB, just making sure that no one was expecting to get that information from their TAM.
 
Phil 

show

roger posted this 24 September 2005

That's really what a TAM's job is. They're supposed to be advocates for
their customer within Microoft. If they're not beatting down (virtual) doors
within MS to get issues resolved for their customer, they're failing at what
they get paid to do...
--------
Roger Seielstad
E-mail Geek

show

kamleshap posted this 24 September 2005

I am also trying to setup a system for monitoring & reporting the changes to some specific user attributes. :-)

And changes made to special-privilege groups using some SPECIAL account.
 
I would like some pointers for nuts and bolts details of AD.
I already have some mspress books, and AD 2nd edition.
joe, I am eagerly waiting for 3rd edition.

show

listmail posted this 26 September 2005

When looking at group memberships, you will need to look at
the group itself, any groups nested into group (and so on), and any users with
primaryGroupID set to the value of any of those groups. Primary groups are not
represented in the normal group membership with the LDAP interfaces. An
alternative would be to look at the group with the NET* API as it would catch
primary group entries but would miss nested entries.
 
   joe

show

SmitaCarneiro posted this 13 April 2018

If you can do an ADRAP engagement with MS, that will help.

 

 

Smita Carneiro, GCWN

Active Directory Systems Engineer

IT Security and Policy

www.itap.purdue.edu

 

 

 

show

barkills posted this 13 April 2018

https://docs.microsoft.com/en-us/windows-server/identity/securing-privileged-access/securing-privileged-access

is probably the best single, comprehensive location to reference on that topic.

 

Conceptually, the key things noted there are:



  1. Separation of pools of risk (separate admin accounts, isolating admin credentials i.e. PAWS, separate local admin pwds i.e. LAPS)
  2. Limitations on admin accounts (time-limited roles i.e. PAM, principle of least privilege i.e. JEA & best practices)
  3. Hardening
  4. Detection (ATA & log analysis)


 

There are specific steps/solutions mentioned there that you can find out more details about elsewhere.

 

Brian

 

show

idarryl posted this 13 April 2018

Thanks folks. 
I also found this which is good: https://github.com/PaulSec/awesome-windows-domain-hardening/blob/master/README.md
~Darryl


show

PhilipElder posted this 13 April 2018

Suweet! Awesome resource thanks for posting!

 

Have a great weekend!

J

 



Philip Elder MCTS

Microsoft High Availability MVP

E-mail:

PhilipElder@xxxxxxxxxxxxxxxx


Phone: (780) 458-2028

www.mpecsinc.com

Blog Site

Twitter: MPECSInc

Skype: MPECS Inc.

Cloud: Canadian Cloud Worx

 

 

Please note: Although we may sometimes respond to email, text and phone calls instantly at all hours of the day, our regular business hours are 8:00 AM - 5:00 PM, Monday thru Friday.



 

show

kurtbuff posted this 13 April 2018

I don't have anything exactly like that, but I've been itching to try this out:
https://github.com/BloodHoundAD/BloodHound

It's for both red teams and blue teams.

show

kurtbuff posted this 13 April 2018

Oh, man - that's a great document, and it even references Bloodhound.

That's in my bookmark list now.

Kurt

show

darren posted this 14 April 2018

I would highly recommend running Bloodhound in a sanctioned way within your AD environment. Keep in mind that it will likely trip all of you IDSs when you run it 😊 (hence the suggestion for it being sanctioned) but it's usually highly illuminating at showing paths to elevated access that you would not have thought of.

Darren

show

kurtbuff posted this 14 April 2018

IDS? What is this IDS you speak of? :)

But seriously, that is exactly what I have in mind..

Kurt

show

ken posted this 16 April 2018

We have both internal red teams, and external red teams attack our environment. None rely simply on AD (mis)configuration to own our AD.

"Prolonged" attack implies that they're not simply going to throw some tools at AD aka a pen test. If that's the case, you need to take a more holistic approach to defending your DCs: service accounts on your DCs, physical security, social engineering attacks etc.

Cheers
Ken

show

ken posted this 16 April 2018

Happy to chat offline or hit me up on LinkedIn. Probably depends on the size of your environment whether the hoops/rigmarole we go through is applicable to you. May (or may not) be overkill.

show

Close