How does DHCP check if its authorized?

Hi all,

(for native english speakers, please excuse the use of the letter Z in the
word authorise. Americans may be able to fake a good moon landing, but they
still can't spell coloUr properly..;-)

I have a semi complicated question. We have a protected forest root domain
and 2 domain root domains. There are dhcp servers in the 2 domain root
domains (lets call them DRD1 and DRD2), each looking after seperate subnets
by seperate administartors. The DHCP servers have all been authorized and are
working fine.

The DRD1 domain does not trust any users from the root or DRD2. We changed
the Default Domain Controllers Policy in DRD1 to "deny logon locally" to
ROOT\Domain Users and ROOT\Domain Admins and DRD2\Domain Users and
DRD2\Domain Admins.

Users from the other domains now cannot logon to their accounts using DRD1
DCs. Brilliant.

When we restarted the DHCP services on the DCs in DRD1 they cannot start
saying that they cannot tell if they are authorized.

We removed the entries for ROOT\Domain Users and ROOT\Domain Admins in the
DC policy on DRD1 and the DHCP services start fine.

The question is why should user accounts in the root domain need to logon to
the DRD1 DCs when DHCP starts and the authorization check is done?

In news7B72ACB-7DAE-4D1D-9DCA-(E-Mail Removed),
evilcraig <(E-Mail Removed)> stated, which I commented on
below:
> Hi all,
>
> (for native english speakers, please excuse the use of the letter Z
> in the word authorise. Americans may be able to fake a good moon
> landing, but they still can't spell coloUr properly..;-)
>
> I have a semi complicated question. We have a protected forest root
> domain and 2 domain root domains. There are dhcp servers in the 2
> domain root domains (lets call them DRD1 and DRD2), each looking
> after seperate subnets by seperate administartors. The DHCP servers
> have all been authorized and are working fine.
>
> The DRD1 domain does not trust any users from the root or DRD2. We
> changed the Default Domain Controllers Policy in DRD1 to "deny logon
> locally" to ROOT\Domain Users and ROOT\Domain Admins and DRD2\Domain
> Users and DRD2\Domain Admins.
>
> Users from the other domains now cannot logon to their accounts using
> DRD1 DCs. Brilliant.
>
> When we restarted the DHCP services on the DCs in DRD1 they cannot
> start saying that they cannot tell if they are authorized.
>
> We removed the entries for ROOT\Domain Users and ROOT\Domain Admins
> in the DC policy on DRD1 and the DHCP services start fine.
>
> The question is why should user accounts in the root domain need to
> logon to the DRD1 DCs when DHCP starts and the authorization check is
> done?

The authoriZation/unauthoriZation and check for authoriZation process is
performed (internally at the forest level) using the Enterprise
Administrator account. The authoriZation process places DHCP authorization
status data in the forest level Configuration Container. You can view that
data by using ADSI Edit, expand CN=Configuration,DC=domain-name,DC=com;
CN=Services, CN=NetServices, select the dHCPClass object. Since the Config
Container is not specifically bound to any domain, it is forest based,
therefore uses forest credentials.

However, since you happened to deny Root\Domain Users, which includes the
Enterprise Administrator account, forest root domain Administrator, System,
Interactive, and numerous other forest root domain "user" objects. All user
objects, even the dynamically created ones which are appear during network
or local activity such as, Network, Creator Owner, Service, Interative, etc
(except the Everyone group and Guest account), is part of the Domain Users
group.

One of these user objects the Enterprise Admin, is used to
check/authorize/unauthorize. It would have been better off to specifically
create a DRD2 Domain Users group, and a list of user accounts you want to
deny, and then deny only that group within DRD1, instead of a blanket denial
for DRD2 Domain Users.

Delegate ability to authorize DHCP servers to a non-enterprise
administrator:
http://technet2.microsoft.com/Window....mspx?mfr=true

Remember, a deny overrides all other permissions.

btw - Did you know the United Federation of Planets truly exists?

--
Ace
Innovative IT Concepts, Inc
Willow Grove, PA

This posting is provided "AS-IS" with no warranties or guarantees and
confers no rights.

Ace Fekay, MCSE 2003 & 2000, MCSA 2003 & 2000, MCSE+I, MCT, MVP
Microsoft MVP - Directory Services
Microsoft Certified Trainer

Having difficulty reading or finding responses to your post?
Instead of the website you're using, I suggest to use OEx (Outlook Express
or any other newsreader), and configure a news account, pointing to
news.microsoft.com. This is a direct link to the Microsoft Public
Newsgroups. It is FREE and requires NO ISP's Usenet account. OEx allows you
to easily find, track threads, cross-post, sort by date, poster's name,
watched threads or subject.
It's easy:

How to Configure OEx for Internet News
http://support.microsoft.com/?id=171164

Infinite Diversities in Infinite Combinations
Assimilation Imminent. Resistance is Futile
"Very funny Scotty. Now, beam down my clothes."

The only constant in life is change...

Yes, I would agree that the "network" user from ROOT is, indeed, logging on
to the DRD1 servers when DHCP is started. That would make some sense.
I don't think an "enterprise admin" user account would be the one logging
on, because that group could be empty, or populated with users other than the
built-in administrator.

Thanks very much for your dose of sanity.
UFPI's offical language is English, and while they spell authorise
incorrectly in their own charter, when the word English is used without
specifying which regionalisation of English, standard proceedure is to assume
the Queen's English.

In news:F76B040F-D777-43F5-8C28-(E-Mail Removed),
evilcraig <(E-Mail Removed)> stated, which I commented on
below:
> Yes, I would agree that the "network" user from ROOT is, indeed,
> logging on to the DRD1 servers when DHCP is started. That would make
> some sense.
> I don't think an "enterprise admin" user account would be the one
> logging on, because that group could be empty, or populated with
> users other than the built-in administrator.

Whether the group is empty or not, no one specific user is logging on as the
EA, but rather the DHCP authorization checking is done in the background
using the EA as credentials. The default Dom Admin in the forest root is
automatically part of EA group. You can probably check the authorization
traffic using a sniffer and looking for DSAccess and/or LDAP traffic.

Those articles kind of explain what is going on.

>
> Thanks very much for your dose of sanity.
> UFPI's offical language is English, and while they spell authorise
> incorrectly in their own charter, when the word English is used
> without specifying which regionalisation of English, standard
> proceedure is to assume the Queen's English.

I do believe that standardization across most of the globe (correct me if
I'm wrong) is to use US English, unless the specific country had some roots
from English conquerings years ago. But then again, who am I to question
what to use?

Keep in mind, UFP was developed in the US...

Ace

Afte re-reading my own post, I see that in the following passage I made a
poor choice of words in a way that may get misconstrued or sound derogatory.
It was not intentional.

"> had some roots from English conquerings years ago."

I meant to say "...had some roots from English presence years ago."

I apologize for any misunderstanding.

Ace