Discussion :

[Immobilis]

Bonjour,

J'essaye de me connecter à un serveur SQL avec une authentification Windows. Je reçoit constement ce message : "Not associated with a trusted SQL Server connection". La connection "Mixed" fonctionne avec "sa".
La config:
- W2003 SP1
- MS SQL 2000 SP4
- Authentification Mixed
- Le groupe Windows BUILTIN\Administrators est "System Administrators" sur toutes les bases.

Le serveur devrait faire parti d'un domaine par la suite.

Merci d'avance de votre aide.

[WOLO Laurent]

Le compte Windows n'est pas autorisé à se connecter au serveur.
Demmandez à votre admin de le faire.

[Immobilis]

Merci bcp de me répondre. Je me fait un peu ch..r à essayer de trouver le fix.

C'est un serveur de test. Je suis "l'admin". Le compte en question est un compte local appartenant au groupe des administrateurs. Dslé, j'ai pas précisé.
Par contre, aucune deux machines ne sont sur un domaine. Cela ne pourrait-il pas être l'origine du pb?
Quand on paramètre une connection SQL, si on choisit windows on ne peut préciser le login. Reprend-il celui de la station sur laquelle on travaille?

Merci de ton aide

[WOLO Laurent]

Et bien, sur le poste distant, vous devez également avoir le même compte avec le même mot de passe.
C'est le prix à payer pour un groupe de travail !

[Immobilis]

Merci bcp pour ces précisisons. MS SQL n'est pas mon domaine. C'est interessant, mais on avance à petits pas.
Le serveur devrait passer dans l'AD de ma société. Je supprimerai donc le compte local que j'utilise actuellement. Faudra-t-il que je mette mon compte/groupe AD dans l'ACL locale?

Merci bien.

[WOLO Laurent]

Dommage, je n'aime pas les abbréviations, elles me volent mon précieux temps .

[Immobilis]

Merci bcp pour ces précisisons. Microsoft SQL n'est pas mon domaine. C'est interessant, mais on avance à petits pas.
Le serveur devrait passer dans l'Acive Directory de ma société. Je supprimerai donc le compte local que j'utilise actuellement. Faudra-t-il que je mette mon compte/groupe Active Directory dans l'Access Control List (la liste des utilisateurs locaux) locale?

Dslé

[WOLO Laurent]

Vous devez donc créer le même compte sur tous les postes ciblés et en plus avec le même mot de passe !!!!

[Immobilis]

Horreur!!

Si un serveur fait partie d'un domaine, je ne je ne peux pas du tout utiliser les informations de l'active directory pour me connecter au serveur SQL???

[WOLO Laurent]

Si vous avez un domaine, le problème ne se posera pas, puis que l'authentification se fait par un serveur du domaine...
Par contre vous, vous avez plutôt un groupe de travail et il vous faut passer par cette horreur justement !!!

[Immobilis]

Mon serveur de test n'est pas encore dans le domaine. Par contre, le serveur de prod lui l'est. Malheureusement, je n'ai pas la main dessus.

L'administrateur qui le gère a fait une manip sensée me donner le droit de travailler sur le serveur SQL. Seulement, ça ne marche pas et cela n'a pas l'air de bcp le préocuper ni de l'intersser... Il va falloir que je lui mâche le travail. Passons.

Qd mon serveur de test sera dans le domaine, quelles étapes devrai-je suivre pour autoriser mon identifiant d'entreprise (du domaine donc) à se connecter au serveur?

J'imagine que la gestion des droits se fait ensuite comme pour un utilisateur local.

Merci de ton aide.

[Immobilis]

Salut,

Je reviens à la charge sur ce pb.
Mon serveur est maintenant sur le Domaine.
J'ai enregistré mon identifiant du domaine dans la liste des utilisateurs du serveur SQL autorisés à se connecter.
Pourtant, je reçois tjrs un message comme quoi y'a pas de "trusted connection" associée.

Que faire???

Merci d'avance.

[Immobilis]

J'ai du mal à croire que personne n'a d'idées sur le pb.

Help.

[Immobilis]

Bon, j'ai trouvé un FIX:

http://www.derkeiler.com/Newsgroups/...4-06/0709.html

Date: Mon, 28 Jun 2004 08:13:01 -0700


This beat me down for quite a while and it appears to be a problem only with Windows 2003 server. Eliminating the tcp/ip protocol from the network configuration seemed to fix it. My symptom was the inablility to register the local SQL server in enterprise manager.


"Steve Thompson" wrote:


> Hi Paul,
>
> I'm posting a message from Peter Afonin that had a very similar issue -- see
> if this helps you:
> ~~~~~~~~~~~~~~~
> Some time ago I posted a message here about my problem: after upgrading the
> domain controller to Windows Server 2003, I couldn't use the SQL server
> trusted connection due to the error: Login failed for user '(null)'. Reason:
> Not associated with a trusted SQL Server connection.
>
> To solve this problem, I had to open a case with Microsoft. Since recently
> I've received several emails from people with the same problem, I realized
> that I was not alone with this issue, so I decided to post the solution
> here.
>
> There are two ways to fix this problem: to remove TCP/IP protocol from SQL
> server or to impersonate users.
>
> Remove TCP/IP
>
> 1. Go to SQL Server properties, then to General tab - Network configuration.
> Remove TCP/IP protocol there.
>
> This worked for me. However, since TCP/IP is required for replication, I had
> to add it back.
>
> Impersonate SQL Server users.
>
> Usually you can impersonate users by going to the Local security policy in
> Administrative Tools, then to Impersonate a client after authentication.
> However, if you deal with the Domain controller, most of the controls there
> are disabled. So:
>
> 1. Go to the Active Directory, right-click on Domain Controllers and select
> Properties
> 2. Go to the Group Policy tab and highlight Default Domain Controller
> Policy, click Edit
> 3. Go to Windows Settings - Security Settings - Local Policies - User Rights
> Assignment
> 4. Double-click Impersonate a client after authentication
>
> Then Microsoft suggested to uncheck the box Define these policy settings,
> then go to the Local security policy and add users there. It worked.
> However, I think it would be better just add the users right there, without
> going to the Local security policy.
>
> Either way, this solved my problem.
>
> Hope this helps.
>
> --
> Peter Afonin
> ~~~~~~~~~~~~~~~
>
>
> "Paul Haltenberg" <haltenberg@yahoo.com> wrote in message
> news:c689f975.0406240221.54bb6d19@posting.google.com...
> > I am running a third-party web application (mainly ASP and specific
> > pages with their own extension that are processed by a third-party
> > ISAPI dll) on a Windows 2000 Server (IIS 5.0) which is also a domain
> > controller and has MS SQL 2000 installed. Anonymous access in IIS for
> > this application is set to use a domain account. This account is also
> > granted access to MS SQL 2000 database. Everything works just fine.
> >
> > For performance purposes I moved MS SQL 2000 Server to a new machine
> > (Windows 2003 server, domain member). When I did so, asp scripts in
> > the application work perfectly well. I have auditing turned on on MS
> > SQL running on Windows 2003 and I can see successful logins to MSSQL
> > for the user which is configured for anonymous access in IIS running
> > on Windows 2000.
> >
> > But, when I try to access any of those specific pages with their own
> > extension that are processed by ISAPI dll, the IIS log shows the
> > following error:
> > Out-of-process+ISAPI+extension+request+failed. 503
> > and the MSSQL errorlog shows the following error at once:
> > Login failed for user '(null)'. Reason: Not associated with a trusted
> > SQL Server connection.
> >
> > According to this application's documentation, TCP/IP and Named Pipes
> > are required on MS SQL (and they are there!). There's also a specific
> > mentioning that that particular ISAPI requires and works through Named
> > Pipes only.
> >
> > For testing purposes I have also deployed IIS on Windows 2003 and
> > installed the application telling it to use MS SQL server on the
> > Windows 2000 DC and this worked fine! But when I do backwards, I get
> > Login failed for user '(null)' and
> > Out-of-process+ISAPI+extension+request+failed. 503 in IIS.
> >
> > I need to have IIS on Windows 2000 DC and MS SQL on Windows 2003
> > domain member and it doesn't work, but works fine when I do vice versa
> > (IIS on 2003 and MS SQL on 2000 DC). I have checked all the policies
> > for 'access this computer from the network', 'log on locally',
> > 'accounts trusted for delegation', 'computer trusted for delegation'
> > and the behavior is still the same:
> >
> > - if IIS is on Win2000 DC and MSSQL is also there, everything works;
> > - if IIS is on Win2000 DC and MSSQL is on Windows 2003 domain member:
> > error;
> > - if IIS is on Win2003 domain member and MSSQL is on Win2000 DC:
> > everything works.
> >
> > Any ideas what I might be missing?