Re: Creating/editing user accounts

From: Laura A. Robinson (larobins@bellatlantic.net)
Date: 11/08/01 

Message-ID: <01a601c168a6$8af29ca0$01000001@lauradominion.com>
From: "Laura A. Robinson" <larobins@bellatlantic.net>
To: <Thor@HammerofGod.com>
Subject: Re: Creating/editing user accounts
Date: Thu, 8 Nov 2001 17:41:42 -0500

inline responses and snippage...

> AFAIAC, allowing any un-trusted process to create objects in AD, even in
> its own forest, is too much of a security risk. I would have the model
> based on some type of db records before I actually had them live in
> AD.

As would I. By doing this, you could gain more fine-grained control of
things such as requiring fields that would not necessarily be required by
default without having to modify the schema; applying data validation rules;
allowing a process to create the user object so that it would not be
necessary to delegate permissions to do so directly to the web users; and
even creating processes to approve the creation of the user objects before
they were added to AD.

> Heck, even the default Authenticated User's policy allowance of
> creating up to 10 machine accounts in AD is too much for me!

Ah, but that is easily fixed, which was the rationale behind it, IIRC. It is
simpler to remove that capability than it is to grant it, and setting it as
a default allows users to add their machines in the event that they're
running a scripted install, etc. In an internal environment, it is often a
useful setting, but in a DMZ forest, I'd be removing that right immediately.
The last thing I would want is some malicious d00d adding his machines to my
domain, DMZ or not. :-)

>
> I can see some posting script flooding AD with a million entries to crash
> it... infrastructure masters going nuts replicating global catalogs and
all
> kinds of fun stuff ;)

In theory, they could try to do this even with a separate database serving
as the initial entry point for the data, but it would certainly be more
controllable.
>
> But hey, he asked! You know there really are a lot of things he could
> do... Hmm, I wonder if Marc will allow us to go off on a "What If" tangent
> with AD possibilities??

Probably not. ;-)

Laura

Relevant Pages

  • Re: Assigned = yes installed=no different subnets,site and domain
    ... > For one the staff machines h+ave a differents naming scheme and two they also have a different IP Scheme. ... >> It is not supported for a site in one forest to have site systems in another>> forest. ... >> This posting is provided "AS IS" with no warranties, ... Will i be able to install the>> client and manage them. ...
    (microsoft.public.sms.setup)
  • Re: Assigned = yes installed=no different subnets,site and domain
    ... This posting is provided "AS IS" with no warranties, ... > For one the staff machines h+ave a differents naming scheme and two they ... >> forest. ... >> using the Client push technology on both the staff ans student machines. ...
    (microsoft.public.sms.setup)
  • Re: Do I need WINS?
    ... My take on the matter is this. ... your machines will default to broadcast mode if NetBios ... > If I add an additional child-domain to the existing forest or another ...
    (microsoft.public.windows.server.dns)
  • RE: Re[2]: [Full-Disclosure] Security aspects of time synchronization infrastructure
    ... least the MS machines that are part of it). ... assuming the time change would sync across the forest I would guess ... I am not sure how kerberos ... However the forest would be up and functioning in terms of authentication, ...
    (Bugtraq)
  • Re: DMZ and Domains
    ... The only machines that need to know of and use the DNS ... trusts are used with external forest, ... zone used by that AD. ...
    (microsoft.public.inetserver.iis.security)
Quantcast