Connexion à Microsoft SQL Server à l'aide des informations d'identification Active Directory

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.

— Gilles Lesire
source

Ouvrez C:\WINDOWS\system32\cliconfg.exeet vérifiez si le cryptage forcé du protocole est activé. S'il est désactivé

— Drifter104

Non, ce n'est pas activé.

— Gilles Lesire

Problème intéressant. Cela semble valide: runas /netonly /user:domain\username "c:\path\ssms.exe" mssqltips.com/sqlservertip/3250/…

— Michal Sokolowski

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:

Ce message dba.stackexchange.com suggère de cliquer sur le bouton Options de votre fenêtre de connexion ci-dessus et de l'ajouter TrustServerCertificate=Truesous Paramètres de connexion supplémentaires. C'est essentiellement dire à SSMS que oui, vous savez, faites-le.
Si cela ne fonctionne pas, ce billet dba.stackexchange.com suggère d'utiliser des runas afin de tromper Windows. Par exemple, 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.

— Katherine Villyard
source

La première solution n'a pas fonctionné, elle était déjà abordée dans ma question. La deuxième solution semble fonctionner, même lorsqu'elle est connectée, elle indique toujours mon nom Windows à côté de la connexion, doit faire des tests si c'est réellement le compte de domaine et s'il fonctionne correctement comme espéré. Doigts croisés.

— Gilles Lesire

Si les runas fonctionnent, existe-t-il un moyen d'éviter l'invite de commande? Tous nos utilisateurs ne sont pas technophiles.

— Gilles Lesire

Peut-être pourriez-vous créer un raccourci personnalisé? En fait, je viens de tester cela moi-même en ajoutant 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.

— Katherine Villyard

Ou utilisez Sysinternals ShellRunAs

— noam

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.

— Peter V
source