Complex topics often require lengthy answers and since little background information was provided in the initial question, I figured I'd try and cover all bases.
As for ensuring a connection to the RID and PDC FSMOs ... I certainly agree (based on theory alone and having not tested the alternative) ensuring a connection to the PDC is a priority. I do believe, however, with the necessary effort, this requirement could too be eliminated albeit with some obvious sacrifices ... a good number of which are highly undesirable. The scenario in question would dictate the choice, i.e. - the lesser of two evils. The requirement for the RID FSMO is easily mitigated (though in this particular case it would seem to be something of an all or nothing). To be clear, it's certainly not something I would recommend nor have I recommended or implemented it in production myself but, as you well know, sometimes scenarios dictate undesirable solutions. Increasing the RID pool size to an arbitrary number deemed sufficient to handle the origination of security principals on that one DC alone would remove the direct connectivity requirement between the isolated DC and the RID FSMO. Since RIDs have a potential scope of 2^30, the size of isolated DC's RID pool can be extreme to say the least ... it would require temporary connectivity in order to obtain the original pool or the temporary transfer of the RID FSMO to a DC whose connectivity is common to both the isolated DC and those housing the FSMOs. An interesting topic indeed and one that I personally found useful and thought provoking. Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Joe Sent: Monday, October 20, 2003 7:06 PM To: [EMAIL PROTECTED]; 'AD mailing list (Send)' Subject: RE: [ActiveDir] FSMO role holding DC's A little long but I enjoyed it and I think you did provide an answer Dean. It is best to make sure you can talk to the Rid Master and PDC. :op To also bring in something Tony said, if this is a box out in the DMZ or internet, don't do it. joe -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dean Wells Sent: Monday, October 20, 2003 11:55 AM To: AD mailing list (Send) Since you didn't mention your OS, I'll base this reply on the premise that 2003 may well be present. Let's start by looking at this from the opposite direction, assuming the DC in question does not *exclusively* (bad idea anyway) house any other critical AD resources such as holding the role of the GC, holding a FSMO role itself or providing name resolution services etc. then communication directed "towards" it from *all* other DCs will not be a requirement. As for its ability to directly communicate with the FSMO role holders within its domain and forest, I think that would be best addressed on a FSMO by FSMO basis by simply outlining the facts (in other words and for the most part, I'll leave you to draw your own conclusions); Domain Naming - Responsible for the creation of, manipulation of and deletion of new and existing partitions (more specifically, the crossRef that represents them). Assuming this DC will never be the point of focus (originating write) when either creating new domains or new application partitions, no issues exist. It's worth mentioning here that the write operations performed when creating, manipulating or deleting partitions can be submitted against any DC and will be proxied by that DC against the Domain Naming FSMO not by the client submitting the action. Any changes made against the Domain Naming FSMO will transitively replicate back to the isolated DC. Schema - Responsible for arbitrating originating updates to the Schema NC. Errors WILL occur if Schema extensions are executed against this DC as it will be incapable of chasing the referral to the Schema master. This can be easily resolved by merely originating the updates against an intermediary DC (i.e. - a DC capable of communicating directly with the Schema FSMO and the isolated DC). Any changes made against the Schema FSMO will transitively replicate back to the isolated DC through the intermediaries. Infrastructure - Responsible for fixing up cross-domain references (maintained by phantoms). This role is irrelevant in a single domain forest. In a multi-domain forest, the functions performed by this FSMO have no dependencies on any other non-GC DC (DC-A to DC-B) nor are there any direct communication requirements between any particular DC and the Infrastructure FSMO (DC-B to DC-A). Any changes made by the Infrastructure FSMO will replicate transitively back to the isolated DC. RID - Responsible for allocating RID pools to DCs within the same domain. RIDs are the per domain uniquifying numeric component of a SID (security identifier) which is used to identify each and every security principal (users/inetOrgPersons/groups/computers). If the isolated DC receives originating writes that attempt to create security principals, the next RID from the current pool is used to construct the new object's objectSID attribute. Once exhausted, any further attempts to create security principals will fail. The default RID pool size has remained consistent since Windows 2000 RTM (500), however, the threshold for triggering a request for a new pool has been reduced from 80% exhaustion to 50% in both 2000 SP4 and 2003 RTM. The following article discusses increasing the RID pool allocation size (on a per requesting DC basis) and is applicable to the scenario you outlined - http://support.microsoft.com/default.aspx?scid=kb%3Ben-us%3B316201 Please note that increasing the RID pool size in Windows 2000 pre-SP4 is, to the best of my knowledge, NOT possible (although there may well be a hotfix with which I am not familiar). PDC - Responsible for ... well, just about everything else requiring a single point of origin or arbitration including; * Preferential password push (configurable) * Authentication retry (controlled by above setting) * (Distributed) account lockout (will cease to function adequately) * Time synchronization (configurable and likely a non-issue) * Domain functional level increases (easily resolvable) * Preferential GP update (configurable) * Downlevel BDC replication source (significant problem should NT4 BDCs remain) * Downlevel (non patched) member account maintenance (depends on client OS/likely resolvable) * Master browser (as above) * Maintenance and coordination of shared secrets between trusted/trusting domains ... writes to the trustAuthIncoming, trustAuthOutgoing & trustPosixOffset attributes of the respective TDOs are originated by the PDC FSMO (non problem) Some of PDC FSMO's functions have no impact on other DCs at all, many require no direct communication with the isolated DC whilst others will only manifest errors should certain administrative operations be originated against the isolated DC. Key functionality such as distributed account lockout will simply cease to function as expected. Since I have never attempted to entirely isolate the PDC FSMO from a particular DC or group of DCs, I'm afraid I can't comment intelligently as to the potential impact of attempting to "configure around" any remaining dependencies. Many tweaks are available (frequently registry based per DC) to alter default behaviors but often cause a ripple of unforeseen anomalies especially when used in conjunction with other such tweaks. In short, if you intend to attempt this level of isolation, I would strongly suggest that you test this thoroughly and for an extensive period of time (4+ weeks) before introducing it to a production environment. I hope the information I outlined serves some purpose though I fear I've failed to provide an answer ... either way, good luck and let the group know how this shapes up! Dean -- Dean Wells MSEtechnology * Tel: +1 (954) 501-4307 * Email: [EMAIL PROTECTED] http://msetechnology.com -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Abbiss, Mark Sent: Monday, October 20, 2003 5:58 AM To: '[EMAIL PROTECTED]' Subject: [ActiveDir] FSMO role holding DC's I have nudged this issue in an earlier post but would like to ask again for confirmation from the collective genius contained in this list. Do all DC's in a domain HAVE to have a direct connection to the FSMO role holding machines or is there a way of "proxying" these roles ? What are some of the likely major implications of maintaining a DC without access to FSMO role holders ? The DC in question is replicating with other DC's, so has all objects but just doenst have any connection to the FSMO role holders. Any thoughts ? Many thanks List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
