[ActiveDir] OT: DHCP Capacity Planning

[Brian Desmond]

Has anyone got some insight/links about a scenario like this?

 

Three DHCP servers (could offload to separate machines). ~650 sites, 2
subnets a pop, ~70K dhcp clients (maybe another 10K, no idea what the mac population
is). 

 

What kind of hardware requirement would I have to support this on Windows
2003 doing DHCP for this kind of setup. I haven’t a faintest clue what
the load on the current environment is (runs AIX).

 

Also wondering what DNS servers running hundreds if not thousands of
zones looks like from a hardware standpoint. 

 

Thanks,
Brian
Desmond

[EMAIL PROTECTED]

 

 

 

RE: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)

[Eric Fleischman]

Sadly, a misstep on the part of our friendly garage door operator.

> use the ldp.exe from the %windir%\ADAM directory

The LDP required for this is the LDP in R2's ADAM, not in the currently
shipping one. Sorry.
We can send this to you if you need it now, or just fetch it out of the
R2 beta bits.[1]

I'll go ahead and pass this along to garage door operator management,
perhaps move him to a garage door painter role. This way he has the time
required to really focus without the distractions of being a full garage
door operator.

> - Select the attribute to be set as confidential. Category 1
> attributes are not possible to select, which rules most of the base
> schema attributes out but not all... Cat1 is marked in the
> corresponding attributeSchema object in its systemFlags attribute, as
> bit 0xF (or 16 in decimal).

We actually block all base schema elements if I remember correctly.

> B) Why can't you grant the explicit extended right for reading the
> confidential attribute?  I assume there is one, there has to be.

I agree with Brett. Please see CONTROL_ACCESS.

~Eric

[1] - There goes my mail quota for the week.


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Brett Shirley
Sent: Sunday, July 10, 2005 4:56 PM
To: ActiveDir@mail.activedir.org
Subject: Re: Confidential Attributes (was RE: [ActiveDir] Who was asking
for a list of SP1 changes? I think it was this DL..)


First off I don't really know security, so I'm like 43% confident in the
accuracy of what I'm about to say ...

Two things:

A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set
(0b),
you either meant 0x10 (16 decimal) or 0x8 (8 decimal) probably.  Really
you should understand which bits you want to set, be careful with that.

B) Why can't you grant the explicit extended right for reading the
confidential attribute?  I assume there is one, there has to be.

Finally, I'd say any "All Extended Rights" should not be granted to
anyone.  Other stuff, like the right to replicate changes in or out, go
in
that bucket, it would be dangerous.

So I'm not sure what the problem is ... is the problem that the tools
(ACL
editor and DSACLS) don't provide a way to explicitly and easily grant
the
desired extended right?  That wouldn't be the first time such a thing
got
dropped. :P

BTW, this might work, download ADAM, and install tools, and use the
ldp.exe from the %windir%\ADAM directory.  This ldp.exe has an ACL
Editor
in it that is vastly superior more powerful, providing very explicit
control over almost everything about the ACL.

Cheers,
-BrettSh [msft]
Building 7 Garage Door Operator

Posting "AS IS" ...


On Mon, 11 Jul 2005, Sakari Kouti wrote:

> About confidential attributes in SP1:
> 
> When you set an attribute to be confidential, mere read permission is
> no longer enough for you to see the attribute value.
> 
> HOW TO ENABLE
> 
> - Select the attribute to be set as confidential. Category 1
> attributes are not possible to select, which rules most of the base
> schema attributes out but not all... Cat1 is marked in the
> corresponding attributeSchema object in its systemFlags attribute, as
> bit 0xF (or 16 in decimal).
> 
> - Locate the corresponding attributeSchema object in the schema, and
> set bit 0x80 (or 128 in decimal) in its searchFlags attribute.
> 
> HOW TO DELEGATE
> 
> - Grant "All Extended Rights" for anyone, who needs to see the
> confidential attribute and grant this on the object, where the
> attribute is (or you could also use inheritance, of course). For
> example, grant "All Extended Rights" on the Sales OU, where are the
> user Jill and contact Carl.
> 
> - SP1 ACL Editor hides "All Extended Rights" on object classes that
> don't have any extended rights associated, such as contact. In that
> case you would use DSACLS, such as the command "dsacls
> cn=jill,ou=demo,dc=sanao,dc=com /G jim:ca"
> 
> PROS
> 
> - If you delegate "Read All Properties" to someone, you can exclude
> some attributes from this "All" by marking them as confidential. This
> also applies when people have "Read All Properties" through the
> "Pre-Windows 2000 compatible access" group.
> 
> CONS
> 
> - As you need to grant "All Extended Rights", the trustee who got the
> permissions, gets not just permission to see a confidential attribute,
> but she also gets all current and future extended rights on the target
> object. For example, if you want Jim to see the users' social security
> numbers, he will also get permission to reset their passwords. And if
> one year later a directory-enabled application adds its own extended
> right to your AD, Jim will have that new permission right away on the
> affected users.
> 
> - Account Operators have Full Control over user objects, so they also
> have "All Extended Rights", so they are able to read users's
> confidential attributes.
> 
> If this feature were implemented as a new access mask bit, it would
> have removed the first described drawbac

Re: Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)

[Brett Shirley]

First off I don't really know security, so I'm like 43% confident in the
accuracy of what I'm about to say ...

Two things:

A) Small note, 0xF is 15 decimal and is equivalent to 4 bits set (0b),
you either meant 0x10 (16 decimal) or 0x8 (8 decimal) probably.  Really
you should understand which bits you want to set, be careful with that.

B) Why can't you grant the explicit extended right for reading the
confidential attribute?  I assume there is one, there has to be.

Finally, I'd say any "All Extended Rights" should not be granted to
anyone.  Other stuff, like the right to replicate changes in or out, go in
that bucket, it would be dangerous.

So I'm not sure what the problem is ... is the problem that the tools (ACL
editor and DSACLS) don't provide a way to explicitly and easily grant the
desired extended right?  That wouldn't be the first time such a thing got
dropped. :P

BTW, this might work, download ADAM, and install tools, and use the
ldp.exe from the %windir%\ADAM directory.  This ldp.exe has an ACL Editor
in it that is vastly superior more powerful, providing very explicit
control over almost everything about the ACL.

Cheers,
-BrettSh [msft]
Building 7 Garage Door Operator

Posting "AS IS" ...


On Mon, 11 Jul 2005, Sakari Kouti wrote:

> About confidential attributes in SP1:
> 
> When you set an attribute to be confidential, mere read permission is
> no longer enough for you to see the attribute value.
> 
> HOW TO ENABLE
> 
> - Select the attribute to be set as confidential. Category 1
> attributes are not possible to select, which rules most of the base
> schema attributes out but not all... Cat1 is marked in the
> corresponding attributeSchema object in its systemFlags attribute, as
> bit 0xF (or 16 in decimal).
> 
> - Locate the corresponding attributeSchema object in the schema, and
> set bit 0x80 (or 128 in decimal) in its searchFlags attribute.
> 
> HOW TO DELEGATE
> 
> - Grant "All Extended Rights" for anyone, who needs to see the
> confidential attribute and grant this on the object, where the
> attribute is (or you could also use inheritance, of course). For
> example, grant "All Extended Rights" on the Sales OU, where are the
> user Jill and contact Carl.
> 
> - SP1 ACL Editor hides "All Extended Rights" on object classes that
> don't have any extended rights associated, such as contact. In that
> case you would use DSACLS, such as the command "dsacls
> cn=jill,ou=demo,dc=sanao,dc=com /G jim:ca"
> 
> PROS
> 
> - If you delegate "Read All Properties" to someone, you can exclude
> some attributes from this "All" by marking them as confidential. This
> also applies when people have "Read All Properties" through the
> "Pre-Windows 2000 compatible access" group.
> 
> CONS
> 
> - As you need to grant "All Extended Rights", the trustee who got the
> permissions, gets not just permission to see a confidential attribute,
> but she also gets all current and future extended rights on the target
> object. For example, if you want Jim to see the users' social security
> numbers, he will also get permission to reset their passwords. And if
> one year later a directory-enabled application adds its own extended
> right to your AD, Jim will have that new permission right away on the
> affected users.
> 
> - Account Operators have Full Control over user objects, so they also
> have "All Extended Rights", so they are able to read users's
> confidential attributes.
> 
> If this feature were implemented as a new access mask bit, it would
> have removed the first described drawback.
> 
> Yours, Sakari
> 
> 
> ===
> 
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
> Sent: Monday, May 09, 2005 4:31 PM
> To: ActiveDir@mail.activedir.org
> Subject: RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it 
> was this DL..
>   
> Excellent thanks ~Eric... This looks to be a good document.
>
> However, anyone else think this info on confidential attributes is a bit weak 
> in the documentation
>
> Improved security to protect confidential attributes
> 
> To prevent Read access to confidential attributes, such as a Social Security 
> number, while allowing Read access to other object attributes, you can 
> designate specific attributes as confidential by setting a search flag on the 
> respective attributeSchema object. By default, only domain administrators 
> have Read access to confidential attributes, but this access can be 
> delegated. For more information about access to attributes, see "How Security 
> Descriptors and Access Control Lists Work" on the Microsoft Web site 
>   at 
> http://go.microsoft.com/fwlink/?LinkId=45972. 
> 
> The link takes you to a document from March 28, 2003 which I highly doubt has 
> more info about confidential attributes. This is something that actually 
> requires you to make changes to use, not like saying hey we also keep SID 
> Histories 

Confidential Attributes (was RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it was this DL......)

[Sakari Kouti]

About confidential attributes in SP1:

When you set an attribute to be confidential, mere read permission is no longer 
enough for you to see the attribute value.

HOW TO ENABLE

- Select the attribute to be set as confidential. Category 1 attributes are not 
possible to select, which rules most of the base schema attributes out but not 
all... Cat1 is marked in the corresponding attributeSchema object in its 
systemFlags attribute, as bit 0xF (or 16 in decimal).

- Locate the corresponding attributeSchema object in the schema, and set bit 
0x80 (or 128 in decimal) in its searchFlags attribute.

HOW TO DELEGATE

- Grant "All Extended Rights" for anyone, who needs to see the confidential 
attribute and grant this on the object, where the attribute is (or you could 
also use inheritance, of course). For example, grant "All Extended Rights" on 
the Sales OU, where are the user Jill and contact Carl.

- SP1 ACL Editor hides "All Extended Rights" on object classes that don't have 
any extended rights associated, such as contact. In that case you would use 
DSACLS, such as the command "dsacls cn=jill,ou=demo,dc=sanao,dc=com /G jim:ca"

PROS

- If you delegate "Read All Properties" to someone, you can exclude some 
attributes from this "All" by marking them as confidential. This also applies 
when people have "Read All Properties" through the "Pre-Windows 2000 compatible 
access" group.

CONS

- As you need to grant "All Extended Rights", the trustee who got the 
permissions, gets not just permission to see a confidential attribute, but she 
also gets all current and future extended rights on the target object. For 
example, if you want Jim to see the users' social security numbers, he will 
also get permission to reset their passwords. And if one year later a 
directory-enabled application adds its own extended right to your AD, Jim will 
have that new permission right away on the affected users.

- Account Operators have Full Control over user objects, so they also have "All 
Extended Rights", so they are able to read users's confidential attributes.

If this feature were implemented as a new access mask bit, it would have 
removed the first described drawback.

Yours, Sakari


===

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe
Sent: Monday, May 09, 2005 4:31 PM
To: ActiveDir@mail.activedir.org
Subject: RE: [ActiveDir] Who was asking for a list of SP1 changes? I think it 
was this DL..

Excellent thanks ~Eric... This looks to be a good document.
 
However, anyone else think this info on confidential attributes is a bit weak 
in the documentation
 
Improved security to protect confidential attributes

To prevent Read access to confidential attributes, such as a Social Security 
number, while allowing Read access to other object attributes, you can 
designate specific attributes as confidential by setting a search flag on the 
respective attributeSchema object. By default, only domain administrators have 
Read access to confidential attributes, but this access can be delegated. For 
more information about access to attributes, see "How Security Descriptors and 
Access Control Lists Work" on the Microsoft Web site 
  at 
http://go.microsoft.com/fwlink/?LinkId=45972. 

The link takes you to a document from March 28, 2003 which I highly doubt has 
more info about confidential attributes. This is something that actually 
requires you to make changes to use, not like saying hey we also keep SID 
Histories in the tombstone objects now which doesn't take any action on the 
part of the admins
 



From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Eric Fleischman
Sent: Monday, May 09, 2005 12:22 AM
To: ActiveDir@mail.activedir.org
Subject: [ActiveDir] Who was asking for a list of SP1 changes? I think it was 
this DL..

http://www.microsoft.com/downloads/details.aspx?familyid=C3C26254-8CE3-46E2-B1B6-3659B92B2CDE&displaylang=en

I didn't read it for completeness, but spot checked, and many are there. Though 
certainly not every one I'm sure.

~Eric
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

RE: [ActiveDir] GPMC Error

[Darren Mar-Elia]

That's part of it. That doesn't control whether Domain Admins can create
GPOs in the first place. It just controls the ACLs a new GPO object gets
when its created. You have to also modify the permissions on the
System\Policies container in the domain and the permissions on the
Policies folder in Sysvol.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Matt Holland
Sent: Sunday, July 10, 2005 2:45 PM
To: ActiveDir@mail.activedir.org
Subject: Re: [ActiveDir] GPMC Error

Hi Mike,

This article should help you out.

http://support.microsoft.com/kb/321476/EN-US/

Cheers, Matty

On 09/07/05, mike kline <[EMAIL PROTECTED]> wrote:
> I would like to delegate GPO creation to a handful of people.  I open 
> GPMC and then go to group policy objects.  I select the delegation tab

> and try to remove the domain admins.  I receive an error -- "The 
> Request is not Supported"
> 
> Is my only option to go into the ACL on the domain using ADU&C and 
> strip their rights that way.
> 
> I realize that a lot of people on this board are going to ask why are 
> these people domain admins?  If you don't trust them to create a GPO
> then they probably shouldn't be a DA.   I agree with those that share
> that sentiment but I have given up on that fight at this point.
> Sometimes the people the sign the checks win.
> 
> Thanks
> 
> Mike
> List info   : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> List archive: 
> http://www.mail-archive.com/activedir%40mail.activedir.org/
>
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive:
http://www.mail-archive.com/activedir%40mail.activedir.org/
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/

Re: [ActiveDir] GPMC Error

[Matt Holland]

Hi Mike,

This article should help you out.

http://support.microsoft.com/kb/321476/EN-US/

Cheers, Matty

On 09/07/05, mike kline <[EMAIL PROTECTED]> wrote:
> I would like to delegate GPO creation to a handful of people.  I open
> GPMC and then go to group policy objects.  I select the delegation tab
> and try to remove the domain admins.  I receive an error -- "The
> Request is not Supported"
> 
> Is my only option to go into the ACL on the domain using ADU&C and
> strip their rights that way.
> 
> I realize that a lot of people on this board are going to ask why are
> these people domain admins?  If you don't trust them to create a GPO
> then they probably shouldn't be a DA.   I agree with those that share
> that sentiment but I have given up on that fight at this point.
> Sometimes the people the sign the checks win.
> 
> Thanks
> 
> Mike
> List info   : http://www.activedir.org/List.aspx
> List FAQ: http://www.activedir.org/ListFAQ.aspx
> List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
>
List info   : http://www.activedir.org/List.aspx
List FAQ: http://www.activedir.org/ListFAQ.aspx
List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/