Nos serveurs Microsoft SQL fonctionnent sur des serveurs Windows qui font partie d'un domaine Active Directory.
Pour une gestion facile des utilisateurs, notre autorisation SQL est configurée à l'aide des groupes d'utilisateurs Active Directory, comme expliqué dans cet article .
Maintenant, cela fonctionne bien tant que tout le monde travaille à l'intérieur du domaine. Les utilisateurs se connectent à leur ordinateur à l'aide de leurs informations d'identification AD et peuvent se connecter au serveur SQL à l'aide de «l'authentification Windows».
Le problème est que nos utilisateurs travailleront également sur d'autres ordinateurs clients qui ne font pas partie du domaine Active Directory (et les ajouter au domaine n'est pas une option).
J'espérais qu'ils pourraient simplement continuer à utiliser leurs informations d'identification AD pour se connecter au serveur en utilisant l'authentification AD comme mentionné dans l'écran de connexion SQL Server.
Cependant, cela ne semble pas fonctionner.
La connexion avec l'authentification par mot de passe du répertoire actif crée des problèmes de certificat. Erreur: "La chaîne de certificats a été émise par une autorité qui n'est pas approuvée."
Cannot connect to x.x.x.x.
===================================
A connection was successfully established with the server, but then an error occurred during the login process. (provider: SSL Provider, error: 0 - The certificate chain was issued by an authority that is not trusted.) (.Net SqlClient Data Provider)
------------------------------
For help, click: http://go.microsoft.com/fwlink?ProdName=Microsoft%20SQL%20Server&EvtSrc=MSSQLServer&EvtID=-2146893019&LinkId=20476 (page does not exist)
Curieusement, si je vais dans les paramètres "options" de la fenêtre de connexion et que je coche la case "certificat de serveur de confiance". Je ne peux soudainement pas me connecter au serveur et j'obtiens simplement l'erreur.
Cannot connect to x.x.x.x.
===================================
Login failed for user ''. (.Net SqlClient Data Provider)
La configuration que je souhaite réaliser est-elle possible? Et si oui, comment y parvenir? :)
Récapitulation: les serveurs SQL s'exécutent dans le domaine AD, les utilisateurs ont des informations d'identification AD mais doivent également pouvoir se connecter à partir d'ordinateurs clients ne faisant pas partie du domaine AD avec leurs informations d'identification AD.
la source
C:\WINDOWS\system32\cliconfg.exeet vérifiez si le cryptage forcé du protocole est activé. S'il est désactivérunas /netonly /user:domain\username "c:\path\ssms.exe"mssqltips.com/sqlservertip/3250/…Réponses:
Le message d'erreur est que les certificats ont été émis par une autorité non approuvée. Ce serait votre domaine AD, très probablement.
Quelques solutions de contournement que vous voudrez peut-être essayer:
TrustServerCertificate=Truesous Paramètres de connexion supplémentaires. C'est essentiellement dire à SSMS que oui, vous savez, faites-le.runas /netonly /user:domain\username "C:\path_to\ssms.exe"je n'ai jamais fait cela avec SSMS mais cela vaut la peine d'essayer, car l'OP semble être dans une situation similaire à vous (et je fais confiance au gars qui répond).Quoi qu'il en soit, j'espère que l'une de ces solutions de contournement fera l'affaire pour vous.
la source
runas /netonly /user:domain\usernameà la chaîne de début d'un raccourci copié. Cela a bien fonctionné, bien qu'il ait également fait apparaître une invite de commande pour qu'ils saisissent leurs informations d'identification.Le moyen le plus simple consiste simplement à cliquer avec le bouton droit sur "Microsoft SQL Server Management Studio" - "plus" sélectionnez "Exécuter en tant qu'utilisateur différent". Ça a marché pour moi. Je pensais que si je sélectionnais "Active Directory - Mot de passe" dans l'écran de connexion, cela ferait le même travail mais ... malheureusement ce n'est pas le cas.
la source