Errore di accesso di autenticazione Windows di SQL Server 2008: l'accesso proviene da un dominio non attendibile

Quando si tenta di connettersi a un'istanza di SQL Server 2008 utilizzando Management Studio, viene visualizzato il seguente errore:

Accesso fallito. L'accesso proviene da un dominio non attendibile e non può essere utilizzato con l'autenticazione di Windows. (Microsoft SQL Server, errore: 18452)

Posso accedere utilizzando l'autenticazione SQL senza problemi. Ho ricevuto questo errore all'improvviso. Ho attivato l'autenticazione in modalità mista.

Qualcuno ha esperienza con questo?

Ulteriori informazioni: versione a 64 bit di SQL Enterprise Edition su Windows 2003 Server

Un altro motivo per cui questo potrebbe accadere (è appena successo a me) ... è che la password dell'utente scade. Non me ne sono reso conto fino a quando non ho provato a collegarmi in remoto al server effettivo e mi è stato chiesto di cambiare la password.

Per me, questo è accaduto quando ho modificato un drivers/etc/hostsfile vuoto e ho aggiunto una voce per un sito Web locale, ma ho trascurato di aggiungere127.0.0.1 localhost

Il problema è stato causato da un server Active Directory inattivo, che ovviamente non è stato in grado di autenticare l'account di Windows. Grazie per il vostro aiuto.

Per chiunque altro si imbattesse in questo, avevo questo nel mio file hosts:

127.0.0.1   localhost
127.0.0.1   customname

e avevo bisogno che fosse questo:

127.0.0.1   localhost
127.0.0.1   localhost   customname

"Il problema è stato causato da un server Active Directory inattivo, che ovviamente non è stato in grado di autenticare l'account Windows"

Non lo è "ovviamente - perché se AD non è disponibile, l'autenticazione Kerberos ricade su NTLM (le credenziali dell'account di dominio sono memorizzate nella cache locale, si può accedere con esso anche se AD / Kerberos non è disponibile). Immagino che tu abbia probabilmente 2 condizioni simultanee perché questo fallimento avvenga:

• SQL Server non è locale (su un'altra macchina)
• La fiducia è configurata "solo Kerberos"

o altre configurazioni di rete / server / AD / macchina di sicurezza specifiche

Ho avuto questo problema per un'istanza del server sulla mia macchina locale e ho scoperto che era perché stavo indicando 127.0.0.1 con qualcosa di diverso da "localhost" nel mio file hosts. Esistono due modi per risolvere questo problema nel mio caso:

1. Cancella la voce incriminata che punta a 127.0.0.1 nel file hosts
2. usa "localhost" invece dell'altro nome che nel file hosts che punta a 127.0.0.1

* Questo ha funzionato solo per me quando stavo eseguendo l'istanza del server sql sulla mia macchina locale e tentavo di accedervi dalla stessa macchina.

Assicurati di non essere connesso a una VPN su un altro dominio \ utente . Oppure, al contrario, assicurati di essere connesso, se questo è ciò che è richiesto.

Ho risolto questo problema sulla macchina disabilitando l'impostazione del controllo di loopback:

1. Modifica il registro di Windows: Start -> Esegui> Regedit
2. Vai a: HKLM \ System \ CurrentControlSet \ Control \ LSA
3. Aggiungi un valore DWORD chiamato "DisableLoopbackCheck"
4. Imposta questo valore su 1

provare a utilizzare un login valido diverso utilizzando il comando RUNAS

runas /user:domain\user “C:\Program Files\Microsoft SQL Server\90\Tools\Binn\VSShell\Common7\IDE\ssmsee.exe” 

runas /user:domain\user “C:\WINDOWS\system32\mmc.exe /s \”C:\Program Files\Microsoft SQL Server\80\Tools\BINN\SQL Server Enterprise Manager.MSC\”" 

runas /user:domain\user isqlw 

Per me, è stato perché non ho aggiunto l'account per avere ruoli che volevo utilizzare al database SQL stesso. E anche a causa di tentativi di password errati tramite l'account di blocco del problema di copia incolla.

Ok, rispondi completamente da me. Ho ricevuto questo errore da un ambiente di sviluppo ospitato su VM VirtualBox. Tre server; SharePoint, DB SQL e controller di dominio. Il server SharePoint non è riuscito a connettersi al database di configurazione. Potrei ancora connettermi tramite ODBC per l'autenticazione Sql utilizzando l'account SA ma non l'autenticazione di Windows. Ma quell'utente accederà felicemente a SSMS sul server sql stesso. Ho ricevuto anche un messaggio di errore migliore da ODBC e anche controllando i messaggi di accesso non riusciti sul server sql:

select text from sys.messages where message_id = '18452' and language_id = 1033

Non posso prendermene il merito perché ho chiesto aiuto a uno dei nostri amministratori di sistema aziendale e lui l'ha diagnosticato in circa 5 minuti dopo aver guardato alcune schermate che gli avevo inviato. Il problema era che l'orologio del controller di dominio era impostato in modo errato! Non potevo crederci. I server sono configurati per la rete solo host, quindi non avere Internet con cui sincronizzare l'orologio. Questo spiega anche perché tornare a un'istantanea precedente quando so che il sistema funzionava non ha risolto il problema.

Modifica: l'installazione di Guest Additions sul server sincronizza l'orologio del guest con l'host.

C'è un'impostazione sul driver jTDS chiamata USENTLMV2 che è impostata su false per impostazione predefinita. L'impostazione di "true" nel mio software db (DBVisualizer) lo ha risolto.

Un altro scenario in cui potresti vedere questo è quando stai tentando di connetterti a un altro server SQL da una sessione SSMS che era già loggata mentre hai cambiato la password. La sequenza di eventi potrebbe essere qualcosa di simile:

1. Da RDP a Server-A (il tuo SQL Server), apri SSMS e accedi
2. RDP su Server-B nello stesso dominio e cambia la tua password
3. Tornare alla sessione RDP su Server-A e tramite SSMS tentare di aggiungere un altro DB in un gruppo di disponibilità AlwaysOn esistente. Quando ci si connette alle repliche, viene visualizzato un errore di accesso "dominio non attendibile"

Per risolvere, è sufficiente disconnettersi e accedere di nuovo

Potresti essere fuorviato riguardo al nome utente che utilizzi localmente. Questo è stato il mio caso in Windows 10 Home. Quando guardo gli utenti nel pannello di controllo, vedo il nome usrpc01 . Tuttavia, quando digitonet config workstation , sembra che il nome dell'utente sia spc01 . Sembra che qualcuno abbia rinominato l'utente, ma il nome interno è rimasto invariato.

Non sapendo come correggere il nome utente di Windows (e il nome della cartella sotto C:\Users, che si riferisce anche al nome interno originale), ho aggiunto un nuovo account utente sul mio server db.

Ho provato ad accedere a SQL Server 2008 da un account di dominio. SQL Server 2008 è ospitato su un computer del gruppo di lavoro diverso che non fa parte del dominio. Per quanto strano possa sembrare, sul server del gruppo di lavoro in cui è in esecuzione SQL Server 2008, ho dovuto andare su Proprietà del sistema | Nome computer (scheda) | Cambia (pulsante) | Modifica nome computer | Altro ... (pulsante) e inserisci il "Suffisso DNS primario di questo computer" (era vuoto, quindi inserisci il suffisso desiderato per la tua rete) e seleziona la casella "Cambia suffisso DNS primario quando cambia l'appartenenza al dominio". Ciò ha consentito il completamento del processo di autenticazione di Windows durante l'accesso a SQL Server 2008.

Ho dovuto usare netonly per farlo funzionare su Windows moderno:

runas /netonly /user:domain\user "C:\Program Files (x86)\Microsoft SQL Server\110\Tools\Binn\ManagementStudio\ssms.exe"

Un altro motivo> qualcuno ha cambiato la password per l'utente SQL predefinito

questo mi è successo un paio di minuti fa passando a un nuovo controller di dominio ...

Ho sbagliato a inserire il file hosts sotto C:\Windows\System32\drivers\etc

[Microsoft][SQL Server Native Client 11.0][SQL Server]Login failed. The login is from an untrusted domain and cannot be used with Windows authentication.

Assicurati di avere una voce come sotto

127.0.0.1   localhost
127.0.0.1   localhost   servername

Stavo usando un alias per un'istanza di SQL Server che puntava a "127.0.0.1". Cambiarlo in "localhost" invece ha funzionato.

Se il tuo server SQL è in esecuzione su un server che non fa parte di un dominio e nella stringa di connessione utilizzi un nome di dominio completamente qualificato (ad es. Xyz.mypc.com) con Integrated Security = True, potresti dover passare all'utilizzo di entrambi l'indirizzo IP, MachineName (SERVER01) o il punto (.) nel caso in cui sia ospitato localmente.

Questo ha funzionato per me, l'utilizzo di fqdn ha provocato l'errore precedente.

per abilitare l'autenticazione di Windows, entrambi i computer devono trovarsi nello stesso dominio. per consentire agli studi di gestione di passare le credenziali correnti e di autenticarsi nella casella sql

Per me, devo disconnettermi (cambiare gruppo di lavoro / dominio) dal dominio e ricollegarmi.

E un'altra possibile ragione: il nuovo account locale creato su DB Server aveva il flag: "L'utente deve cambiare la password al prossimo accesso" impostato.

Ecco cosa lo ha risolto per me: Proprietà della connessione di rete Fare clic su: "Protocollo Internet versione 4 (TCT / IPv4)". Fare clic sul pulsante "Proprietà". Fare clic sul pulsante "Avanzate". Seleziona la scheda "DNS". Elimina il testo in "Suffisso DNS per questa connessione".

Non sono stato nemmeno in grado di connettermi da remoto al server SQL. Sia il server SQL che il server remoto si trovano nello stesso dominio. E mi era stata richiesta una modifica della password alcuni giorni prima. Il riavvio sia del server SQL che del server remoto da cui stavo tentando di accedere al server SQL ha fatto il trucco per me.

Nel nostro caso era il fatto che lo sviluppatore stava eseguendo il pool di applicazioni con il proprio account e aveva reimpostato la sua password ma si era dimenticato di cambiarla nel pool di applicazioni. Duh ...

Nel mio caso, il server era stato disabilitato nel controller di dominio. Sono andato nell'unità ORGANIZZATIVA COMPUTER in Active Directory, ho fatto clic con il pulsante destro del mouse sul server, l'ho abilitato, quindi ho eseguito un gpupdate / force dal server SQL. Ci è voluto un momento, ma alla fine ha funzionato.

Nel mio caso, nel file host, il nome della macchina è hardcoded con IP precedente. Sostituisco l'IP precedente con quello nuovo, il problema è risolto.

Posizione del file host

WindowsDrive: \ system32 \ drivers \ Windows \ etc \ hosts

Modifiche apportate 159.xx.xx.xxx MachineName

Nessuno dei precedenti ha funzionato per me. Quello che dovevo fare era: In SQL Server Management Studio nella schermata di accesso, selezionare Opzioni >> Nella sezione Rete, modificare il protocollo di rete in Named Pipes.

Inoltre, quello che dovevo fare per farlo funzionare con l' <default>impostazione era disabilitare la rete wireless (la macchina era anche collegata alla rete LAN cablata).

La mia soluzione era cambiare il file web.config in modo che fosse correlato al mio nuovo nome server per SQL Connection (la sicurezza IT aveva appena rinominato netdom sulla mia scatola di sviluppo.