Consentitemi di iniziare dicendo che concordo con molti degli altri - o convincere il cliente altrimenti o scappare.
Tuttavia, dati i requisiti elencati (ce ne sono molti non elencati), posso pensare (e parzialmente testato) almeno le basi per farlo accadere.
Ci sono molti aspetti specifici che devono essere considerati.
- Replica dei servizi di dominio Active Directory
- Processo di localizzazione DC di client / server membri
- Risoluzione dei nomi e traffico per i servizi non di dominio Active Directory
Uno e due hanno molto in comune - in generale siamo per capriccio di Microsoft su questo e dobbiamo lavorare entro i limiti dei processi di Microsoft AD DS.
Numero tre, abbiamo un po 'di spazio con cui lavorare. Possiamo scegliere le etichette utilizzate per accedere ai servizi (file, istanze di database, ecc.).
Ecco cosa propongo:
Costruisci i tuoi controller di dominio (DC)
- Probabilmente almeno due.
- Ogni controller di dominio disporrà di due schede NIC, una in ciascun sito di rete IP / Servizi di dominio Active Directory, chiamandole per ora clt e srv.
- Configurare solo una scheda di rete in ogni controller di dominio in questo momento nella rete SRV.
Configurare correttamente siti e servizi AD
- sito srv e sottorete
- sito clt e sottorete
- deseleziona "Collega tutti i collegamenti ai siti" da Siti -> Trasporti tra siti -> Fai clic con il pulsante destro del mouse su "IP"
- elimina DEFAULTIPSITELINK se esiste (o se lo hai rinominato) in modo che non ci siano collegamenti al sito configurati. Si noti che questo è lo sconosciuto per me - KCC probabilmente scaricherà gli errori nel registro eventi del servizio directory dicendo che i due siti (srv e clt) non sono collegati a intervalli variabili. Tuttavia, la replica continuerà comunque tra i due controller di dominio in quanto possono contattare l'un l'altro utilizzando gli IP nello stesso sito.
Configurare la zona aggiuntiva nel DNS integrato di Servizi di dominio Active Directory
- Se il tuo dominio di Servizi di dominio Active Directory è acme.local , crea una seconda zona integrata AD primaria con gli aggiornamenti dinamici abilitati chiamato clt.acme.local .
Configura la seconda scheda NIC sul tuo controller di dominio
- Queste NIC saranno le NIC nella rete / sito clt.
- Imposta i loro IP
- Ecco la parte magica - Proprietà adattatore -> Proprietà IPv4 -> Avanzate -> Scheda DNS -> Imposta il suffisso DNS per questa connessione su clt.acme.local -> verifica Registra questa connessione ... -> Verifica Usa questa connessione Suffisso DNS ... -> OK fino in fondo.
- ipconfig / registerdns
- Ciò registrerà l'IP NIC clt nella zona clt.acme.local, fornendo un metodo per controllare quale IP / rete verrà utilizzata in seguito.
Configurare le schede NIC del server membro
- Le schede NIC del server membro nel sito clt devono avere il suffisso DNS e le caselle di controllo impostate di conseguenza, come sopra.
- Queste impostazioni possono essere utilizzate con statico e DHCP, non importa.
Configurare il comportamento del risolutore DNS [stub] nei siti
- DC's -> Configura DC srv NIC per usare se stesso e altri DC srv NIC IP. Lascia vuoto DC clt NIC DNS (è necessario un IP statico). (Il server DNS DC ascolterà comunque tutti gli IP per impostazione predefinita).
- Server membri -> Configurare la scheda NIC srv del server membro per utilizzare gli IP del sito DC srv. Lascia vuoto il server NTR DNS della NIC (è possibile utilizzare un IP statico).
- Client / Workstation -> Configura DNS (tramite DHCP o statico) per utilizzare gli IP NIC della clt del controller di dominio.
Configurare le mappature / risorse in modo appropriato
- Quando i server parlano tra loro, assicurati di usare .acme.local -> risolverà l'IP di rete srv.
- Quando i client parlano con i server, assicurati di usare .clt.acme.local -> risolverà l'IP di rete clt.
Di cosa sto parlando?
- La replica di Servizi di dominio Active Directory verrà comunque eseguita poiché i controller di dominio possono risolversi a vicenda e connettersi tra loro. La zona acme.local e _msdcs.acme.local conterrà solo la replica di Servizi di dominio Active Directory dell'IP di DS NIC DC srv avverrà solo sulla rete srv.
- Funzionerà il processo di localizzazione DC per i server membri e le workstation - anche se esiste la possibilità di ritardi in varie parti di vari processi di Servizi di dominio Active Directory quando il sito è sconosciuto, se vengono restituiti più IP DC - verranno tentati, non riusciranno e proseguiranno fino a quando uno funziona. Gli effetti su DFS-N non sono stati completamente valutati, ma funzioneranno comunque.
- I servizi non di dominio Active Directory funzioneranno correttamente se si utilizzano le etichette .acme.local e .clt.acme.local di cui sopra come descritto.
Non l'ho completamente testato in quanto è piuttosto ridicolo. Tuttavia, il punto di questa risposta (wow, lunga) è iniziare a valutare se sia possibile o meno - non se debba essere fatto.
@Commenti
@Massimo 1/2 Non confondere più siti di Servizi di dominio Active Directory nella zona acme.local, quindi i record SRV popolati dai controller di dominio in quei siti nella zona acme.local con la necessità di record SRV nella zona clt.acme.local. Il suffisso DNS primario del client (e il dominio Windows a cui sono uniti) sarà comunque acme.local. Il client / le stazioni di lavoro hanno una sola NIC, con il suffisso DNS primario probabilmente derivato da DHCP, impostato su acme.local.
La zona clt.acme.local non necessita di record SRV in quanto non verrà utilizzata nel processo di localizzazione DC. Viene utilizzato solo da client / stazioni di lavoro per connettersi ai servizi non AD DS del server membro utilizzando gli IP del server membro nella rete clt. I processi correlati a Servizi di dominio Active Directory (localizzatore DC) non utilizzeranno la zona clt.acme.local, ma i siti (e le sottoreti) di Servizi di dominio Active Directory nella zona acme.local.
@Massimo 3
Ci saranno record SRV sia per i siti di Servizi di dominio Active Directory clt che srv - solo che esisteranno nella zona acme.local - vedere la nota sopra. La zona clt.acme.local non necessita di record SRV relativi a DC.
I clienti saranno in grado di individuare una sanzione DC. I server DNS client puntano agli IP clt dei controller di dominio.
Quando inizia il processo di localizzazione DC sul client
- Se il client conosce il suo sito, la domanda DNS sarà _ldap._tcp. [Site] ._ sites.dc._msdcs.acme.local SRV. Ciò restituirà i controller di dominio specifici del sito in cui sono registrati record SRV.
- Se il client non conosce il suo sito, la domanda DNS sarà _ldap._tcp.dc._msdcs.acme.local SRV. Questo restituirà tutti i DC. Il client tenterà di collegarsi al LDAP di DC fino a quando non trova quello che risponde. Quando il client ne trova uno, esegue una ricerca del sito per determinare il sito del client e memorizza nella cache il sito nel registro in modo che le future istanze del localizzatore DC si verifichino più rapidamente.
@Massimo 4
Uff, bella cattura. Per come la vedo io ci sono due modi per aggirare questo problema.
- L'impatto minore (rispetto ai 2 seguenti) è quello di creare una voce nel file hosts sui client / workstation per dc1.acme.local e dc2.acme.local che punta agli IP NIC clt dei controller di dominio.
o
- Creare manualmente i record SRV necessari nel file netlogon.dns su ciascuno dei controller di dominio. Ciò probabilmente avrà delle conseguenze sulla rete del server. I server membri possono a volte comunicare con i controller di dominio sulla rete clt se questo è configurato.
Tutto sommato, non è bello, ma non è necessariamente l'obiettivo finale. Forse il cliente sta solo testando le tue costolette tecnologiche. Inseriscilo sul tavolo della conferenza e digli "Qui funzionerà, ma ti sto caricando 4 volte la mia tariffa normale per configurarla e supportarla. Puoi ridurla a 1,5 volte la mia tariffa normale - 0,5 volte la carica PITA, facendo [soluzione corretta]. "
Come notato in precedenza, la mia raccomandazione è di convincere altrimenti o correre. Ma è sicuramente un piccolo esercizio divertente in ridicolo. :)