>>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.-ASBFAST, CHEAP, SECURE: Pick Any TWO
On 9/23/05, Kamlesh Parmar <[EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of DeStefano, Dan
Sent: Thursday, September 22, 2005 2:09 PM
To: ActiveDir@mail.activedir.org
Subject: 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Phil Renouf
Sent: Thursday, September 22, 2005 1:28 PM
To: ActiveDir@mail.activedir.org
Subject: 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 < [EMAIL PROTECTED]> 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 Guild
ct: RE: [ActiveDir] Domain Controller SecurityLook 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: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of van Donk, Fred
Sent: Tuesday, September 20, 2005 4:52 PM
To: ActiveDir@mail.activedir.org
Subject: [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"
~~~~~~~~~~~~~~~~~~~~~~~~~~~
