RE: [ActiveDir] Sites and Services Permissions

[GRILLENMEIER,GUIDO (HP-Germany,ex1)]

thanks Joe for the clarification - yes, I meant it the way you said ;-)   I don't know who creates the NTDSDSA object for a new DC (however, I believe it's the one your machine connects to when you do the DCPROMO), but you can definitely change the behaviour for your clients that they don't choose ANY DC in the world to logon while the promotion process is still going on - you simply have to restrict the registration of generic records to your "Hub" or "Datacenter" DCs.   Restricting the generic list to the Hub-Site DCs improves the time to find the own site DC and restricts a client to use the Hub-Site DCs during a fail-over scenario (instead of connecting to another DC in ANY randomly selected remote DC in your enterprise over the WAN) This change involves adding the following Registry-Key on all current and future remote DCs:   HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters Registry value: DnsAvoidRegisterRecords Data type:     REG_MULTI_SZ Data:          Dc DcByGuid Pdc Gc GenericGc GcIpAddress Kdc Ldap LdapIpAddress Rfc1510Kdc Rfc1510UdpKdc Rfc1510Kpwd Rfc1510UdpKpwd The following service records would still be registered by all DCs, ensuring local coverage: DcAtSite, GcAtSite, GenericGcAtSite, DsaCname, KdcAtSite, LdapAtSite, Rfc1510KdcAtSite   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of joe Sent: Montag, 26. Januar 2004 04:17 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Sites and Services Permissions Yes, it is anchored in the root domain naming... :o)   And it does exist on every DC. :o)   <I'm just a grape in the middle of the road.>   I want to restate one item from Guido as I misread it at first so I wanted to make it a little clearer.   "Child DAs do have the permissions to create connection objects on DCs in their own domain "   I believe he meant to state that Child DAs do have the permissions to create connection objects FOR DCs in their own domain ". Choice of domain controller in the forest where they do that creation does not matter, the reason they can do it is due to explicit rights on the NTDSDSA object under the Server object and obviously those permissions would be replicated to all DCs within the forest. The first and second time I read that I incorrectly read it as they could make the change because it was on their DC.   I was poking around trying to figure out how the initial object is created and it seems it could be one of two ways. A special call to an existing DC to say, hey could you help me out here and create this OR if at the start of the promo process the new DC gets recognized as part of the Enterprise Domain Controllers well known security principal group. The NTDSDSA object gets created within minutes of the promo process before anything is replicated so I know it am pretty confident it doesn't do it on the local machine and replicate it out.   Actually I have a problem with that process and asked for a possible functionality change around that because that new NTDSDSA object can have adverse affects on the coverage generation for sites that previously didn't have coverage for a specific domain. Say you have a siteX that usually gets domainA coverage from DCs for domainA in siteW. Well you start to spin up DC1X for domainA in siteX and the NTDSDSA object hits the rest of the Forest fairly quickly. If it is a large domain, far in advance of DC1X being able to actually cover the site. But since there is no flag on the NTDSDSA object to say whether or not it is actually live or not the DCs that previously covered siteX stop covering it and remove their DNS entries from that site. This means any MS clients start failing over to ANY site in the world that has a DC for domainA and non-MS clients that only know how to read a single DNS SRV Record for site coverage fail completely.   I also asked that they add a checkbox for autoreboot of a DC that successfully promotes in the wizard that works like the INI file switch does for unattended dcpromos.     Anyway, anyone know if the new DC registers that new object or does another DC register it on the first DC's behalf?     joe     From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Saturday, January 24, 2004 9:57 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Sites and Services Permissions Guido,   Thanks for the corrections and for the information.  Granted, the Configuration Container is a writeable NC in the forest, and available on all DCs.  But, by DN - is anchored at the root, yes?   -rtk From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of GRILLENMEIER,GUIDO (HP-Germany,ex1) Sent: Saturday, January 24, 2004 4:59 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Sites and Services Permissions the configuration container is not in the root - it's a writable naming context on any DC in the forest (obviously it is created when you create the root).    one more minor correction: Child DAs do have the permissions to create connection objects on DCs in their own domain (to replicate from any DC in the forest - they can't add a CO to the other DCs in the forest to have it pull the changes from their DC...)   /Guido From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rick Kingslan Sent: Samstag, 24. Januar 2004 00:52 To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] Sites and Services Permissions John,   We have a multi-tree environment with domains below the empty root.  Our admins in the child domains can promote DCs in their own domain, even though they have no implicitly granted rights in Sites and Services.  I know where the Configuration Container is - it's in the root.  The other tree Admins can promote/demote DCs as well.  BUT! make no mistake - I DO NOT want anyone else short of myself and the other AD Engineer making any changes to the replication topology.   By default (and, I honestly have no idea if I have changed this) our empty root grants the empty root DA and the Enterprise Admin rights to Site and Services.  Other than (well, there is SYSTEM) Authenticated Users have READ - that's about it.   What I'm saying is that I suspect that the Child DA's don't have to have explicit permission to the Sites and Services.  System is there, and I suspect that System is actually taking care of what the child admins need in creating the server and NTDS objects.  Then, the KCC would take over.  Unless the KCC has been shut off, of course.  In this case, the EA or DA of the root is going to have to handle it.   Rick Kingslan  MCSE, MCSA, MCT Microsoft MVP - Active Directory Associate Expert Expert Zone - www.microsoft.com/windowsxp/expertzone WebLog - www.msmvps.com/willhack4food   From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Witasick Sent: Thursday, January 22, 2004 3:47 PM To: [EMAIL PROTECTED] Subject: [ActiveDir] Sites and Services Permissions We have a multi-domain environment (empty root & 7 child domains).  Our Central Office is responsible for creating and maintaining sites, site links, subnets, connection objects, replication schedules, . . .   We'd like to restrict all child domain admins from making any modifications within Sites and Services.  If we restrict their access to read-only throughout all of Sites and Services, will domain admins still be able to promote and demote DCs?  Will we break replication?  Will we break anything?   Thanks.   John This E-mail, including any attachments, may be intended solely for the personal and confidential use of the sender and recipient (s) named above. This message may include advisory, consultative and/or deliberative material and, as such, would be privileged and confidential and not a public document. Any Information in this e-mail identifying a client of the department of Human Services is confidential. If you have received this e-mail in error, you must not review, transmit, convert to hard copy, copy, use or disseminate this e-mail or any attachments to it and you must delete this message. You are requested to notify the sender by return e-mail.