|
Hi Joe, I had to digest this a bit… Ø
I think
you are simply asking the disjoint namespace question That’s right. Ø
to allow
VWRITE to service principal name and dns hostname Ok, I found that permission. But I’m
still confused; to who should I assign that permission? Are you thinking of
allowing the branche office admins to set the SPN and DNS hostname? They have
FC on the computer objects, so that should not be a problem, right? I was thinking of just creating an AD
integrated zone, giving the appropriate admin group the permissions on the DNS
zone, and let the system take care of the rest. If the branch office admins
need to set SPN’s explicitly I will overshoot my purpose. I’m
pretty sure that very few of them can do that. Hey, I barely know what I’m
talking about. My alternative instruction (should the SPN
be a problem) for them would be to let the workstations register in their own
dedicated zone, but to let the servers register in the AD zone. The problems
are mostly with the workstations anyway. Think about imaging software that
recreates (not: resets) computer accounts. -- Regards, Willem From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe I think you are simply asking the disjoint
namespace question and if that is the case, default MS stuff, you will be fine.
Simply set the appropriate permissions on the computer objects (more likely set
it on the highest level OU or container you can) to allow VWRITE to service
principal name and dns hostname. Now if you have a delegated join process where
you don't give full control of the computer object to someone andyou are adding
Win2K3 machines you will need to give WP to DNS Host Name Attributes (this may
show up as WP on Validated Write DnsHostName if you use DSACLS though because
of a duped GUID MS used for the rights GUID. This gets you around having to
specify allowed suffixes. Now what can break? Most anything that
doesn't understand disjoint namespaces. Right off the top of my head that seems
to be smaller vendors though I have seen issues with EMC NAS devices as well.
They simply don't register the correct hostname and spn though you can
usually manually correct that. I would just the same test any important apps
that you have or use though just to make sure, for example any monitoring
software or software update software or auditing software or specific LOB
software. Overall I have good experience with
disjoint namespace and actually prefer it because of the way the records get
broken up in a generally geographically based manner. Much cleaner than
throwing everything for say Asia Pacific into one DNS Domain of
AsiaPac.company.com. If you can look at a machine and see
xxx.philipines.company.com you have more info right off than seeing
xxx.asiapac.company.com. The main issue has been the frustration
with vendors who didn't test their product with a disjoint namespace. joe From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Willem Kasdorp I’m working in a branch office deployment where the AD
is centrally managed, and all offices have a high level of autonomy. In MS terms:
central does the service management, branches do data management. I would like the branches to manage their own DNS A records.
In order to do that I am thinking of giving each a delegated subdomain of the
main AD (DNS-)domain and giving them the appropriate permissions. Now I’m
wondering if I’m going to have a problem with Kerberos. I tried to look
it up but what I found on Technet is less then clear. Workstations don’t usually offer services, so
I’m not too worried about that. But what happens when servers are going
to register (through their primary DNS Suffix) in a subdomain? Will they
automatically register the correct SPN, will other computers be able to find
that, and is there a difference between file/print sharing and more specialized
services? Do any of you have good/bad experiences to share? -- Regards, Willem |
