Su alcuni client non riesco a collegarmi a SQL SERVER 2005, perché mi viene restituito il seguente errore, se provo a collegarmi in modalità TRUST.

...
Login failed for user ''. The user is not associated with a trusted SQL Server connection. [CLIENT: 192.168.1.52]
...

Qualche informazione sulle configurazioni. I client che hanno questo problema sono portatili di consulenti esterni. Con SQL SERVER 2000 bastava collegarsi al server con EXPLORER e salvare utente e password con cui si aveva accesso al server.

Dopo il cambio del server e l'upgrade da SQL SERVER 2000 a 2005 ho questi errori, si può bypasare soltanto collegandosi con utenti SQL SERVER.

Qualcuno a qualche dritta

takeru_ag ha scritto:

I client che hanno questo problema sono portatili di consulenti esterni.

...che quindi non fanno parte del dominio, giusto?
Non esistendo una authority comune in grado di validare l'account nei confronti del server, quest'ultimo è normale che rifiuterà i tentativi di connessione trusted che "non sono trusted".
Ci sono casi in cui risulta possibile connettersi ad una istanza pur non essendo autenticati da una authority comune; questo tipo di workaround si regge sugli spilli e presuppone tutta una serie di circostanze fortuite per cui si verifichi che viene meno quando viene richiesta l'autenticazione Kerberos (se abiliti il protocollo named pipe puoi ingannare NTLM ma non kerberos)...

Bye

takeru_ag ha scritto:

Con SQL SERVER 2000, bastava collegarsi con il server con esplora risorse, in questo caso ti chiedeva utente e password del dominio e bastava far MEMORIZZARE i dati.

Questo è il workaround che si regge sugli spilli. Più genericamente basta aprire una pipe, ad esempio con il comando NET SHARE e così riesci ad ingannare NTLM

Comunque te mi consigli di disattivare su questi portatili il collegamento con il protocollo TCP/IP e utilizzare solo NAMED PIPE.

Quando parlavo di protocollo named pipe mi riferivo al lato server e non sui portatili... e lato server è preferibile disabilitare del tutto il protocollo named pipe ANCHE per ridurre questi problemi. Ma quello che io considero un "problema" è evidente che non sia la stessa cosa per te visto che lo vai cercando... :-)
Tanto per capirci... è un problema quando un utente NON TRUSTED (tale è un utente non autenticato dal mio dominio) riesce ad accedere tramite una connessione TRUSTED...
Per contro tu stai cercando di fare di tutto per connettersi sfruttando quelle che sono, invece, delle vulnerabilità che andrebbero contrastate e non agevolate...

LA cosa strana è che sui 3 che funzionano hanno attivato solo il protocollo TCP/IP e nell'alias (tramite il comando "cliconfg") è stato forzato per il server di SQL SERVER il protocollo TCP/IP.

Evidentemente SQL Server è (mal) configurato per accettare anche connessioni NTLM (meno sicure di kerberos)

Io intanto provo con il NAMED PIPE, se ti viene in mente delle prove da fare o altro fammi sapere.

Ti auguro di non riuscirci... :-)
Se vuoi ridurre la sicurezza di un database server sei liberissimo di farlo, ma non avrai il mio supporto. Se fai una ricerca su internet non tarderai a trovare la strada per fare questa boiata, passami il termine, e in ogni caso sarà una soluzione che si regge sugli spilli...

Quel link ancora non funziona, ma credo di sapere quale sia il post...
Purtroppo credo che stia portando più danni che benefici diffondendo un concetto errato su quello che debba essere considerato "trusted".
Da un punto di vista concettuale una simile autenticazione posso chiamarla "windows authentication", ma non "trusted authentication". Le 2 definizioni dovrebbero essere fra loro sinonimi, ma in queste condizioni non lo sono affatto.
Non so se MS considera la cosa come un BUG (dichiaratamente o meno) ma da sempre coltivo la speranza che la cosa venga sanata. Prima o poi...

Bye