none
Alcuni PC Windows 7 pro sono passati da rete di dominio a rete pubblica? RRS feed

  • Domanda

  • Come da titolo non capisco perché oggi alcuni PC in una subnet remota (collegata via WAN alla rete dove risiede il DC) sono passati come connessione da rete di dominio a rete pubblica, restringendo quindi le impostazioni del firewall e facendo si che non li possa più pingare da remoto né eseguire un Remote Desktop (entro solo con TeamViewer).

    Ho provato manualmente a modificarla in "rete aziendale" anche se non è proprio la stessa cosa, ma non mi risponde ugualmente al ping. Dalle proprietà di sistema il pc risulta correttamente collegato a dominio.

    Premetto che a livello di dominio abbiamo una policy da anni che permette l'accesso ai PC da parte di tutte le altre subnet aziendali.

    Abbiamo WSUS ma gli aggiornamenti non sono automatici e sono stati fatti qualche mese fa.

    Cosa potrebbe essere successo e come ripristinare la corretta connessione a dominio?

    mercoledì 13 maggio 2015 15:51

Risposte

Tutte le risposte

  • Ciao, il ping dipende dal firewall non dal tipo di rete, se hai gli icmp disabilitati sul fw di windows non saranno pingabili, devi quindi abilitarlo nelle regole. Sospetto comunque un aggiornamento la cosa che mi suona strana è: se questi pc hanno utenti solo user e non admin come hanno fatto a cambiare la rete? l'unica cosa è una policy o una update a questo punto..od un malware ma penso te ne saresti accorto...

    A.

    mercoledì 13 maggio 2015 18:29
    Moderatore
  • Ciao Marco, forse il problema è dovuto a qualche modifica/problema lato WAN che non permette una corretta identificazione NLA.

    Dai un lettura al Post Blog Network Location Awareness (NLA) and how it relates to Windows Firewall Profiles ed alla KB di riferimento A computer cannot identify the network when the computer is running Windows Vista, Windows Server 2008, Windows 7, or Windows Server 2008 R2, and is a member of a child domain.

    Saluti
    Nino


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.


    • Modificato NinoRCTNModerator mercoledì 13 maggio 2015 20:01
    • Proposto come risposta aperelli mercoledì 13 maggio 2015 20:54
    mercoledì 13 maggio 2015 20:01
    Moderatore
  • Buongiorno e grazie per gli spunti.

    Vorrei escludere dal problema i 2 DC (con 1 DNS ciascuno) che abbiamo nella nostra sede centrale, in quanto i PC nelle altre subnet dislocate in altre città non hanno questo problema e comunque hanno il registro eventi di sistema pulito.

    Per la subnet con i PC in errore ci sono 2 router MPLS in load balancing, e mentre le stampanti di rete sono tutte pingabili, solo un PC su 5 è pingabile ed entrando in remote desktop vedo che è correttamente connesso alla rete di dominio, tuttavia nel registro eventi di sistema registra 2 errori che sono in ordine cronologico:

    1014 - DNS Client events - Timeout della risoluzione dei nomi per il nome _ldap._tcp.dc._msdcs.dominio.local. Nessun server DNS configurato a risposto

    5719 - NETLOGON - Impossibile stabilire una connessione con il domain controller

    Cercando su internet riconducono ad una errata configurazione del DNS che però sembra essere OK, oppure alla Secure Channel rotta (potrebbe dipendere dal fatto che i PC sono stati preparati con copia clone).

    Sugli altri PC che non sono né pingabili né raggiungibili via RDP non ho ancora controllato il registro (dovrei entrare con TeamViewer previa disponibilità).

    Al momento mi viene solo da pensare ad una configurazione particolare dei router, ma è anche vero che in tal caso non dovrei raggiungere alcun dispositivo nella rete che sta dietro...

    Escluderei Virus (contemporaneamente su 4 PC di 5?) e GPO (uguali per tutte le subnet).

    Suggerimenti?

    giovedì 14 maggio 2015 09:18
  • Ciao Marco, non ho ancora capito se i client sono legati ad un DC presente nella subnet oppure no. Nel post iniziale hai scritto "...(collegata via WAN alla rete dove risiede il DC)" il che fa pensare che nella subnet non sia presente nessun DC e che i client siano connessi attraverso una rete lenta alla sede centrale.

    Alla luce della mia interpretazione ho girato i due link precedenti.

    Cosa hanno in comune questi PC (oltre ad essere, eventualmente, stati clonati)? Stessi aggiornamenti? Stessa OU?

    Dopo un riavvio accedi con utente Administrator e vedi se riscontri lo stesso problema. Esegui delle query DNS per verificare il corretto funzionamento ed una nuova eventuale registrazione con ipconfig /registerdns. Esegui un set logon per verificare quale DC risponde al client.

    Saluti
    Nino

     


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.


    giovedì 14 maggio 2015 09:45
    Moderatore
  • alle riflessioni di Nino aggiungo due cose anche io:

    1) Sfatiamo il mito che se, in una VPN o Rete Locale il ping  risponde allora è tutto a posto. Spesso ci sono porte ed interi protocolli chiusi (vedi proprio IP SEC, GRE ecc...capitato anche l'altro giorno su due telecom fibra) quindi il ping è quello che è: un echo request. Fine. Se pingo qualcosa e mi risponde sono a buon punto...errore, sono messo come prima solo che ho un dato in più.

    2) Quando dici "tutti clonati" mi viene un po di freddo dietro la schiena...quindi chiedo...clonati come? con una immagine syspreppata del sistema?

    Ciao!

    A. 

    giovedì 14 maggio 2015 10:05
    Moderatore
  • Nino, nella subnet locale non c'è un DC: questi si trovano nelle nostra sede master.

    I 2 router che la collegano alla sede master sono 2 ADSL da 1MBps in load balancing come MPLS

    I link che mi hanno girato mi hanno dato l'idea di aprire la porta 389 su Windows Firewall ma non ho ancora testato e comunque non ce ne dovrebbe essere bisogno in quanto nelle altre subnet non l'ho toccata...

    Non posso entrare come aministratore vero e proprio, ho dovuto dare i privilegi di domain admin all'utente e poi entrere via teamviewer per provare a fare i settaggi da me esposti in precedenza, la prossima volta che mi collego faccio anche le prove che mi hai suggerito.

    Alessandro, il ping è solo un indice del problema, se già non risponde a quello c'è sicuramente qualcosa che non va.

    La clonazione che ho fatto in precedenza, è stata poi successivamente sysreppata, ma al momento non posso controllarla perchè chiaramente se eseguo il comando psgetsid, da DC ora i PC non mi rispondono...

    giovedì 14 maggio 2015 10:29
  • dimenticavo x Nino, stessi aggiornamenti e stessa OU
    giovedì 14 maggio 2015 10:30
  • secondo me stiamo tralasciando un po il livello 0 del problema: sei su una wan ed hai una mpls che non gestisci tu...di punto in bianco smettono di andare i pc in questa sede...io per prima cosa farei fare un bel controllo sulla linea e sugli apparati...perchè succede spesso di perdere giornate a smanettare per poi rendersi conto che i poveri windows non contano nulla..questa la mia idea e vista un po l'analisi che o letto ci punto su anche qualcosa visto che non passano nemmeno gli icmp...sbaglierò...

    ciao!

    A.

    giovedì 14 maggio 2015 10:43
    Moderatore
  • Lato MPLS ho fatto controllare la linea dal primo livello di supporto e la configurazione dal secondo livello, ma escludono problemi (secondo loro poteva dipendere dai router solo se venivano sostituiti).

    Ho notato che il PC che in quella subnet è rimasto collegato alla rete di dominio con la set logon era agganciato al DC1, mentre gli altri erano agganciati al DC2, quindi ho provato a spengere il DC2 e a riavviare uno dei PC su rete pubblica ma al riavvio sebbene ora si sia agganciato al DC1, continua ad essere nella rete pubblica.

    Nel registro eventi, oltre ai 2 mensionati sul PC "raggiungibile" ho l'errore: 1129 - Group Policy - Elaborazione dei criteri di gruppo non riuscita a causa di problemi di connettività con il DC (che tuttavia dai PC incriminati riesco a raggiungere  anche come file server).

    Non posso fare ipconfig /registerdns perché mi dice che non ho i diritti(??) ma dovrebbe essere equivalente al restart? Cmq mi ha fatto modificare le impostazioni del firewall ed ho aperto la porta 389 sia TCP che UDP, ma al riavvio non ho benefici.

    L'ultima prova che mi rimane da fare è quella di provare a disabilitare il Windows firewall, anche se abbiamo un firewall fisico a monte l'operazione non mi piace per niente...

    giovedì 14 maggio 2015 14:03
  • Molte operazioni richiedono che la comunicazione via RPC funzioni

    Firewalls & RPC


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti


    • Modificato aperelli giovedì 14 maggio 2015 14:39
    giovedì 14 maggio 2015 14:39
  • Ho disattivato il firewall di Windows dui 3 profili di rete, riuscendo quindi ad entrare in desktop remoto come amministratore e a fare (con runas admin):

    ipconfig /flushdns

    ipconfig /registerdns

    Ma al riavvio del PC (senza firewall) non si connette ancora alla rete di dominio e sul registro oltre agli errori già citati ho notato un

    4321 - NetBT - Impossibile registrare il nome "DOMINIO     :1d" sull'interfaccia con indirizzo IP ..108.106. il computer con indirizzo IP ..108.101 non ha consentito a questo computer di richiedere il nome.

    Guarda caso quel 108.101 è proprio l'unico PC della subnet che è connesso alla rete di dominio!!!!!??????

    giovedì 14 maggio 2015 16:11
  • Puoi spegnere il 108.101?

    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    giovedì 14 maggio 2015 16:18
    Moderatore
  • Disabilita il servizio browser su 108.101, riavviali entrambi e vedi cosa succede

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    giovedì 14 maggio 2015 16:19
  • Ciao,

    se può essere utile, noi in azienda abbiamo avuto un problema analogo.

    Su alcuni client e purtroppo anche su alcuni server la rete di tipo Domain è sparita e in automatico sono passati su rete public.

    Per i client poco male, ma i server non accettavano nessuna connessione in entrata se non il ping e poco altro.

    Inizialmente avevo imputato si trattasse di una incompatibilità su hardware specifico con qualche aggiornamento WSUS, perché mi è successo su 2 domain controller che ho in una sede remota che hanno identico hardware. Poi mi sono dovuto ricredere perché mi è successo anche su 2 server su 20 virtuali che condividono ovviamente lo stesso identico hardware...

    insomma, per ora non ho trovato una logica, sembra che capiti a random

    In ogni caso io ogni volta ho risolto portando la rete da public a work (la rete domain non esiste più...)

    poi aggiornamenti da Windows update

    poi riavvio e se non al primo, ti ritrovi nuovamente la rete domain

    ...prova se funziona anche a te questa procedura e fammi sapere

    giovedì 14 maggio 2015 19:58
  • Mi sto facendo un'idea, penso che abbia a che fare con l'elezione del master browser, ma prima di dire cose strane (eufemismo) vorrei vedere cosa succede dopo avere applicato il mio suggerimento :)

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    giovedì 14 maggio 2015 20:56
  • La prima prova che ho fatto è quella di spengere il PC ..108.101, quindi ho riavviato uno dei PC che davano problemi, ma non risulta ancora sotto rete di dominio, quindi non pingabile, niente RDP, ecc...

    In compenso ora su sfoglia rete vedo tutti i PC Remoti, ma cmq non posso esplorarli... Ma a questo punto la disattivazione del  servizio browser sul 108.101 potrebbe influire solo sullo sfogliamento della rete.

    Finisco di controllare se il SSID dei PC è effettivamente diverso (per ora ne ho controllati 3 su 5 e sono diversi, quindi suppongo anche sui 2 rimanenti abbia fatto il sysprep), poi abiliterò RDP sul firewall in tutti i profili rete, infine come suggerisce Guerenzoni li metto da rete public a rete aziendale e proverò a sparare gli aggiornamenti da WSUS su uno dei PC remoto.

    Se avete altri suggerimenti sono ben accetti!

    venerdì 15 maggio 2015 10:20
  • non ho capito se sul 108 hai disabilitato il servizio browser prima di riavviarlo

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    venerdì 15 maggio 2015 10:24
  • 1il 108.101 è sempre spento da prima! Prima di riaccenderlo sto provando a riavviare gli altri e vedo che almeno sono passati da rete pubblica a rete aziendale, ma non sono ancora sotto rete di dominio.
    venerdì 15 maggio 2015 10:33
  • Infatti come ho riacceso il .108.101 e riavviato uno degli altri PC che era su rete aziendale ora mi è tornato su rete pubblica!

    Nel frattempo ho verificato che i SID dei PC della subnet fossero tutti diversi.

    @Aperelli: Ho disattivato il servizio Browser del computer sul pc .108.101, quindi ho riavviato il pc e poi uno degli altri PC che è tornato su rete aziendale.

    Di diverso dagli altri PC, il 108.101 ha da più di un anno un opzione sul client antivirus TrendMicro WFBS per cui funziona da update agent, ovvero gli altri pc prima cercano quello per scaricare gli aggiornamenti e poi se non lo trovano li scaricano direttamente dalla sede (generando più traffico sulla WAN): potrebbe essere indicativo?

    Resto però in attesa di un suggerimento per capire la causa del problema, visto che gli ultimi aggiornamenti di Microsoft sono stati distribuiti a Gennaio e questi problemi sono usciti solo adesso.


    venerdì 15 maggio 2015 14:41
  • Ok, prova a disabilitare il servizio browser su tutti i PC (poi devono essere riavviati oppure esegui nbtstat -R )

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    venerdì 15 maggio 2015 15:29
  • Al di là della causa, che imputerei a qualche aggiornamento visto che nessuno ha modificato nulla in queste macchine, mi è successa la stessa cosa in un'altra azienda su un SBS 2011.

    Anche qui risolto con la stessa soluzione già descritta sopra, che forse sembra troppo semplice, e la rete Domain è ricomparsa.

    domenica 17 maggio 2015 13:52
  • Ciao Marco, dovresti analizzare le chiavi di registro indicate nel Post Blog di Michael Platts per capire come sono messi quei valori. Valori che sono determinati durante la fase di avvio e di ricerca del DC.
    Il fatto che riesci a raggiungere i DC non è indicativo di corretto funzionamento. Per alcune attività vengono registrati dei valori attraverso algoritmi che calcolano la distanza dei DC e questi algoritmi determinano alcune impostazioni come ad esempio l'applicazione delle policy.

    Sempre nello stesso articolo sono presenti le indicazioni per assegnare via policy alcune impostazioni.

    Dai anche una lettura alla KB Group Policy Slow Link Detection Using Windows Vista and Server 2008.

    Saluti
    Nino

     

    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    domenica 17 maggio 2015 20:17
    Moderatore
  • Buongiorno,

    @Aperelli: mantenendo il Browser Computer disattivato sul 108.101 e su altro PC, questa mattina non è nemmeno servito a lasciare il PC sotto rete privata.

    @Guerzoni: Fare aggiornamenti di Windows se risolve solo TEMPORANEANTE mi serve solo a rimandare il problema. Proverò comunque su uno dei PC, ma devo tenere di conto che se questa operazione risolve solo modificando prima la connessione da pubblica in aziendale dovrò spegnere il PC che commuta gli altri su rete privata.

    @Nino: La soluzione1 di aprire la porta sul firewall 389 non ha risolto e toccare il registro di Windows da remoto per tentativi la vedo rischiosa. Dubito che dipenda dalla velocità o dalla distanza del collegamento in quanto uno dei PC nella stessa rete riesce a connettersi regolarmente al Dominio e comunque l'infrastruttura è la stessa da 5 anni.

    lunedì 18 maggio 2015 09:15
  • @Nino: La soluzione1 di aprire la porta sul firewall 389 non ha risolto e toccare il registro di Windows da remoto per tentativi la vedo rischiosa. Dubito che dipenda dalla velocità o dalla distanza del collegamento in quanto uno dei PC nella stessa rete riesce a connettersi regolarmente al Dominio e comunque l'infrastruttura è la stessa da 5 anni.

    Non ho detto di toccare, ma di analizzare...

    Ovviamente per distanza non intendo fisica ma logica ovvero il numero di salti necessari ad instaurare la punto-punto.

    Purtroppo non ho la bacchetta magica, mi limito ad analizzare le risposte e dare dei suggerimenti che, forse, possono sfuggire all'OP preso dal problema. Se non aggiorni i client/server da mesi quello che cambia è l'infrastruttura MPLS che non gestisci tu. Prova a fare un ping -l 2500 per una trentina di minuti e vedi se zoppica (fai la stessa identica prova dal client che funziona).

    Saluti
    Nino


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    lunedì 18 maggio 2015 09:40
    Moderatore
  • Ok, lascierei perdere la teoria del master browser.

    Hai controllato il dns domain suffix e la chiave di registro come indicato nell'articolo che ha mandato Nino?

    Il processo é descritto step by step, potresti verificarlo manualmente:

    Step 1 - Domain Determination

    In all cases, detection starts the same way that it does in Windows XP. If the Connection Specific DNS Name matches the “HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History\NetworkName” registry key then the machine will attempt to contact a Domain Controller via LDAP. If both these steps succeed, you will get the Domain profile. It is important to note that if the steps succeed, processing stops here. This allows you to roam across multiple access points in the same domain without having to stop and identify each of them individually.

    Step 2 - Network Identification

    If the above steps are complete and a match to the domain was not found, NLA will evaluate the network characteristics to see if it can identify a match. If there is a profile created for that network (not to be confused with the Firewall Profile) the interface will get the Firewall profile associated with that network either Private or Public. If the network is not identified by one of the above methods it will remain with the Public profile.


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 18 maggio 2015 09:42
  • Anzitutto vorrei nuovamente ringraziarvi per la vostra pazienza!

    Per quanto riguarda il ping pesante, su entrambi i PC ho perso meno dell'1% (ma ero in desktop remoto).

    Volevo subito segnalarvi il registro di Windows alla chiave "HKEY_Local_Machine\Software\Microsoft\Windows\CurrentVersion\Group Policy\History": sul pc 108.101 che è rimasto sotto profilo connessione dominio la chiave IsSlowLink è 1 (lento) mentre su altro PC è a 0 (veloce)! In entrambi la chiave NetworkName è vuota (a differenza dei PC nella stessa rete del Domain controller che hanno dominio.local)! I PC che sono nelle altre subnet remote e che si connettono alla rete di dominio hanno isSlowLink=1 e NetworkName= vuoto.

    Allora forse la connessione MPLS sta andando troppo veloce per come si erano configurati inizialmente i PC?!?!



    lunedì 18 maggio 2015 14:52
  •  In entrambi la chiave NetworkName è vuota (a differenza dei PC nella stessa rete del Domain controller che hanno dominio.local)!



    Vedi l'articolo che ti ha postato Nino... [postato di nuovo da me sopra]

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 18 maggio 2015 15:30
  • Questo problema può essere frutto di qualche aggiornamento dell'ultimo periodo? Come detto sopra lo ho riscontrato su molte macchine di diversi clienti, per cui non è un problema legato ad errate impostazioni, ma qualcosa che è successo ultimamente.

    Altro esperimento, oggi ho riattivato una ulteriore scheda di rete su un server che aveva avuto quel problema, precedentemente risolto, e me la sono ritrovata su public anche se era sulla LAN di dominio. Da questo, il mio metodo risolve il problema solo sulla scheda di rete a cui lo applichi, ma comunque resta qualcosa di latente nel sistema che riconosce erroneamente la posizione delle nuove schede...

    Spero riusciate a capire la causa e sinceramente che si possa risolvere automaticamente con patch.


    lunedì 18 maggio 2015 20:53
  • Se il mio inglese non mi inganna direi che i valori di IsSlowLink sono invertiti (The named value is IsSlowLink and is located at HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Group Policy\History. This value is an REG_DWORD value that is interpreted as a Boolean value; with a non-zero value equaling false and a zero value equaling true.).

    Verifica lo stesso valore su un client della stessa LAN del DC. Per i site remoti tieni conto di quanto riportato nello stesso articolo (If the Group Policy service encounters an error, it read the last recorded value from the history key and uses that true or false value for the slow link status). Ovvero se c'è un errore viene utilizzato il valore memorizzato nella chiave.

    Saluti
    Nino


    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    lunedì 18 maggio 2015 21:29
    Moderatore
  • Buongiorno a tutti,

    cattive notizie in quanto all'aggiornamento di Windows da WSUS: al termine degli aggiornamenti infatti si era ricollegato correttamente alla rete di dominio, ma al successivo riavvio è tornato sotto la rete aziendale!!!!

    Per quanto riguarda la KB capisco che il NetworkName deve coincidere con il DNS per poter essere considerato in una rete di dominio, ma in tutte le subnet remote il Network name è VUOTO, non so da quando perché questa chiave di registro la controllo ora, ma in tutte le altre subnet remote i PC risultano essere collegati correttamente al dominio (anche i PC che sono stati clonati e sysreppati e quindi praticamente uguali come HW e SW a quelli di questa subnet con problemi) e gli ultimi aggiornamenti dei PC risalivano a fine 2014, mentre per i DC addirittura dal 2013 nessuno li ha toccati.

    Possiamo trovare delle caratteristiche in comune con Guerzoni del tipo: Dominio al livello windows2000, un DC è windows2008R2 e uno è win2003r2, antivirus Trendmicro WFBS8, rete MPLS Telecom router Cisco, PC tutti win7Pro.

    Nella rete locale invece il NetworkName è corretto (dominio.local) e la chiave IsSlowLink è 0 (quindi mi viene da dire che il valore booleano non è inverito, ma zero effettivamente è FALSE).

    Al momento ho dovuto disattivare il firewall sul profilo privato per avere accesso ai registri e al desktop remoto e potrebbe essere anche la soluzione definitiva visto che i PC non suno pubblicati, anche se temo che alcune funzionalità di dominio potrebbero essere disabilitate.

    Aggiornamento:

    Lato supporto TrendMicro mi hanno fatto disattivare l'antivirus ed i servizi correlati ma al riavvio ho gli stessi problemi.

    Ho provato il metodo 3 della KB980873 suggerita da Nino ovvero impostare Failures a 1 e Successes a 0 (in precedenza Successes=4294967295 e Failures=0), ma al riavvio non ho risolto il problema e mi trovo questi valori: Successes=1; Failures=2)

    Ho provato a settare manualmente prima IsSlowLink=1 e riavvio (ritorna su 0 senza commutare la connessione) poi IsSlowLink=1 e NetworkName=dominio.local, al riavvio non è cambiato nulla...

    Per il metodo2 della KB980873 nel registro non ho il nodo "..\IntranetForest" ma solo "..\Intranet\domino.local", sarà un errore di digitazione? Comunque ho provato ad importare le chiavi del registro del PC .108.101 e al riavvio sono sempre sotto rete aziendale.

    Escluderei a questo punto problemi su NLA e li ricercherei altrove, qualche spunto?




    martedì 19 maggio 2015 10:08
  • Buongiorno,

    anche questa mattina, essendoci un nuovo aggiornamento Microsoft da wsus, ho provato ad eseguire gli aggiornamenti, ma al riavvio il pc è sempre sotto rete aziendale.

    Che problemi potrei avere a tenerlo sotto rete aziendale con firewall di Windows aperto, rispetto ad averlo sotto rete di dominio con firewall Windows chiuso?

    Alla luce delle prove che ho fatto ieri, avete qualche altro suggerimento da darmi?

    Grazie!

    mercoledì 20 maggio 2015 07:23
  • Ciao,

    mi sono riletto il thread (anche se un po' infretta).

    Mi pare che avremmo potuto fare tutti un po' meglio.

    Torniamo indietro.

    Riesci a risolvere il record SRV per _ldap._tcp.dc._msdcs.dominio.local  e successivamente il nome che ti viene restituito? Se si, riesci a collegarti al server che ti viene restituito alla porta 389 TCP e UDP?

    Avevi un errore in proposito e non mi pare se ne sia piú parlato.

    Testa su un client che non é nella rete di dominio:

    nslookup

    set type=SRV

    _ldap._tcp.dc._msdcs.dominio.local 

    Nel registro degli eventi "Application and Services/Microsoft/Microsoft/Windows/NlaSvc-Operational" dovrebbe loggare gli errori NLA se ce ne sono.


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti



    • Modificato aperelli mercoledì 20 maggio 2015 08:27
    mercoledì 20 maggio 2015 08:25
  • ciao aperelli,

    in effetti quell'errore ce l'ho su tutti i pc in quella sottorete, anche sul pc .108.101 che risulta essere connesso alla rete di dominio e sul quale provando a dare i tuoi comandi ho questo errore (a differenza dei pc locali che risolvono tutti i DC):

    *** server1.dominio.local non è in grado di trovare _ldap.tcp.dc._msdcs.dominio.local: Non-existent domain

    Anche se sul registro eventi questo errore non viene registrato come invece avviene all'avvio del PC (Chiaramente i nomi di server e domini sono casuali)


    P.S. Ad un secondo tentativo sullo stesso PC ha risolto tutti i DC !!?
    mercoledì 20 maggio 2015 10:27
  • Questo potrebbe essere il problema, il PC per entrare nella rete di dominio deve poter fare il bind LDAP ad un DC

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    mercoledì 20 maggio 2015 10:50
  • Bene, ma come faccio a capire la causa?
    mercoledì 20 maggio 2015 11:59
  • Network monitor o una traccia con netsh (piú difficile da leggere a mio parere) potrebbe aiutarti a capire.

    Esiste un modo per catturare una traccia con netmon all'avvio, trovi le istruzioni qui

    Utilizzare netsh é decisamente meno macchinoso, le istruzioni le trovi qui


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    mercoledì 20 maggio 2015 12:03
  • Grazie dei links (a parte che mi sembrano entrambi uguali e riferiti a netmon), ma non mi sembra un procedimento tanto semplice da applicare ad un PC remoto.

    Esiste qualcosa di più semplice?

    mercoledì 20 maggio 2015 12:12
  • ops, sorry questo é il link per netsh, molto piú semplice peró a volte ho trovato che le tracce catturate siano un po' piú ostiche da leggere

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    mercoledì 20 maggio 2015 12:22
  • Dal registro del DC1 abbiamo scoperto un errore di NETLOGON:

    During the past 4.01 hours there have been 37 connections to this Domain Controller from client machines whose IP addresses don't map to any of the existing sites in the enterprise. Those clients, therefore, have undefined sites and may connect to any Domain Controller including those that are in far distant locations from the clients. A client's site is determined by the mapping of its subnet to one of the existing sites. To move the above clients to one of the sites, please consider creating subnet object(s) covering the above IP addresses with mapping to one of the existing sites.

    Da questo abbiamo individuato che in AD Sites and Services mancava il Site di quella subnet. Una volta aggiunto, da uno dei PC che davano errore abbiamo fatto il wizard "ID di rete" dalle proprietà del sistema per riagganciarlo nuovamente al dominio, ma al riavvio il PC risulta sempre collegato alla rete aziendale.

    Con il NetSh suggerito da Aperelli abbiamo estratto nuovamente un registro .etl del boot del PC, e andando a controllare il dialogo (cosa non facile visto gli oltre 2000 frame), osservando specialmente le risposte dei server vediamo qualche sporadico errore tipo questi:

    DNS:QueryId = 0x95FF, QUERY (Standard query), Response - Name Error

    Kerberos: KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)

    Da riga del comando del pc abbiamo testato la connessione con i DC facendo "telnet DC 389" e si connette ad entrambi i DC della sede (viene lo schermo nero).

    Provato anche il comando "sfc /scannow" che non ha dato i risultati sperati.

    Suggerimenti?

    venerdì 22 maggio 2015 15:08
  • Questo potrebbe essere ignorabile:

    Kerberos: KRB_ERROR  - KDC_ERR_PREAUTH_REQUIRED (25)

    Per quanto riguarda la query DNS fallita, dovrebbe esserci un frame con la query vera e propria (devi espandere il frame nel pannello sotto (parlo di netmon)


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    venerdì 22 maggio 2015 15:19
  • Rieccomi, la query in errore al DNS dovrebbe essere la seguente:

    QRecord: isatap.dominio.local of type Host Addr on class Internet

    Altre richieste al DNS si risolvono con successo...

    martedì 26 maggio 2015 09:00
  • vedi query a _ldap._tcp....etc ?

    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    martedì 26 maggio 2015 09:20
  • Alle richieste di LDAP da parte del client  (e ne ho contate diverse come questa):

      Frame: Number = 143, Captured Frame Length = 311, MediaType = NetEvent
    + NetEvent:
    + MicrosoftWindowsNDISPacketCapture: Packet Fragment (210 (0xD2) bytes)
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[00-07-B4-00-01-02],SourceAddress:[E8-39-35-4F-4A-3B]
    + Ipv4: Src = xxx.108.106, Dest = xxx.100.11, Next Protocol = UDP, Packet ID = 250, Total IP Length = 196
    + Udp: SrcPort = 59464, DstPort = LDAP(389), Length = 176
      Cldap: (CLDAP)Search Request, MessageID: 1, BaseObject: NULL, SearchScope: base Object, SearchAlias: neverDerefAliases
    + LDAPMessage: Search Request, MessageID: 1

    Corrispondono le risposte netlogon dei uno dei DC:

      Frame: Number = 146, Captured Frame Length = 312, MediaType = NetEvent
    + NetEvent:
    + MicrosoftWindowsNDISPacketCapture: Packet Fragment (211 (0xD3) bytes)
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[E8-39-35-4F-4A-3B],SourceAddress:[00-22-55-9B-DC-00]
    + Ipv4: Src = xxx.100.11, Dest = xxx.108.106, Next Protocol = UDP, Packet ID = 13491, Total IP Length = 197
    + Udp: SrcPort = LDAP(389), DstPort = 59464, Length = 177
      Cldap: (CLDAP)Search Result Entry, MessageID: 1, Status: Success
    + LDAPMessage: Search Result Entry, MessageID: 1
    + NetlogonAttribute: LogonSAMLogonResponseEX (SAM Response to SAM logon request): 23 (0x17)
    + LDAPMessage: search Result Done, MessageID: 1

    Dove però leggo Success, sebbene sul registro eventi esca un errore di Netlogon. Sembra quasi che nonostante l'autorizzazione non riesca a registrarsi e continui ad inviare richieste.

    A parte questa risposta LDAP da parte di un DC:

      Frame: Number = 401, Captured Frame Length = 1615, MediaType = NetEvent
    + NetEvent:
    + MicrosoftWindowsNDISPacketCapture: Packet Fragment (1514 (0x5EA) bytes)
    + Ethernet: Etype = Internet IP (IPv4),DestinationAddress:[E8-39-35-4F-4A-3B],SourceAddress:[00-0F-24-B1-8E-12]
    + Ipv4: Src = xxx.100.10, Dest = xxx.108.106, Next Protocol = TCP, Packet ID = 17040, Total IP Length = 1500
    + Tcp: Flags=...A...., SrcPort=LDAP(389), DstPort=60791, PayloadLen=1460, Seq=2522747761 - 2522749221, Ack=230337823, Win=256 (scale factor 0x8) = 65536
      Ldap: Search Result Entry, MessageID: 11
    - LDAPMessage: Search Result Entry, MessageID: 11
      + ParserHeader:
      + MessageID: 11
      + OperationHeader: Search Result Entry, 4(0x4)
      - SearchResultEntry: NULL
       + ObjectName: NULL
       + Attributes: 8 Partial Attributes

    Dovrei espandere qualche nodo in particolare??




    martedì 26 maggio 2015 10:15
  • Pare che riescano a connettersi ai DC, risolvere record SRV e a connettersi in LDAP.

    Potresti abilitare il netlogon logging https://support.microsoft.com/en-us/kb/109626

    Forse peró sarebbe meglio coinvolgessi il supporto Microsoft a questo punto.


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    martedì 26 maggio 2015 10:31
  • Ma bisogna avere un contratto di supporto con Microsoft per questo?

    Quali modalità mi consigliate?

    martedì 26 maggio 2015 12:54
  • Non necessariamente, puoi aprire un caso PPI (Pay per incident):

    • Richieste PPI durante l'orario lavorativo (Telefono e Web): 299 euro + IVA

    Fonte: Opzioni di supporto (guarda su Professional support)


    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti


    • Modificato aperelli martedì 26 maggio 2015 13:01
    martedì 26 maggio 2015 13:00
  • Ok, valuterò. Intanto sto inviando un PC di scorta per eventuali problemi nelle prove e per vedere come si comporta una volta inserito in quella rete; me ne faccio mandare uno di quelli difettosi in sede per vedere se si riaggancia normalmente.

    Una volta eseguito il windowsupdate su un altro PC sono arrivato all'ultimo riavvio per il completamento degli aggiornamenti e ho visto che si è rimesso in rete di dominio come diceva Guerzoni, ma ho notato che si è tolto dal DNS!!!

    Può essere indicativo?

    mercoledì 27 maggio 2015 07:57
  • Nel mio caso la soluzione è stata quella di inserire il Fully Qualified Domain Name nel suffisso DNS della tab DNS delle proprietà IPv4 avanzate della scheda di rete, e di spuntarne l'utilizzo.

    lunedì 27 luglio 2015 13:34
  • Grazie per aver postato la soluzione.

    Sono personalmente ancora confuso, fallivano le query per FQDNs tipo _ldap._tcp.dc._msdcs.dominio.local.



    This post is provided AS IS with no warranties or guarantees, and confers no rights.
    ~~~
    Questo post non fornisce garanzie e non conferisce diritti

    lunedì 27 luglio 2015 13:48
  • Grazie per aver postato la soluzione.

    Sono personalmente ancora confuso, fallivano le query per FQDNs tipo _ldap._tcp.dc._msdcs.dominio.local.

    Concordo con te...

    ...esistono i motori di ricerca, facci un salto e troverai molte delle risposte che ti darò io.

    lunedì 27 luglio 2015 13:51
    Moderatore

  • Alessandro, il ping è solo un indice del problema, se già non risponde a quello c'è sicuramente qualcosa che non va.


    neanche questa affermazione è del tutto corretta: posso avere l'icmp bloccato dal firewall per ridurre la superficie d'attacco ma avere altri protocolli perfettamente funzionanti.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    mercoledì 5 agosto 2015 13:27
    Moderatore