2017-06-05 5 views
3

Nous rencontrons des échecs d'authentification Kerberos et/ou NTLM dans des packages d'applications personnalisés ou conçus pour Windows 7 à l'aide du programme d'installation WISE. Sur Windows 7, ils fonctionnent correctement, mais ils échouent sur Windows 10. Ils échouent lors de l'installation de Windows 10 à l'aide de l'outil Microsoft SCCM et échouent lors de l'utilisation de l'authentification Kerberos pour un partage SMB sur le réseau pendant le processus d'installation. Nous pouvons voir à l'intérieur de la trace réseau que l'application client bascule sur NTLM à partir de Kerberos pendant la transaction d'authentification. Nous ne savons pas pourquoi. Nous avons un environnement Active Directory à grande échelle. Parce que le paquet WISE est comblé, nous ne pouvons pas l'examiner. Sur les machines Windows 7 réussies, il semble que l'ordinateur nécessite l'accès au partage pendant l'exécution du package et que l'utilisateur connecté doit avoir un accès en lecture et en exécution sur le partage SMB. Nous sommes en mesure d'accéder au même partage SMB en utilisant le compte système Windows 7 mais pas lors de l'utilisation du compte système Windows 10. Très étrange! Est-ce un problème de code à l'intérieur du paquet? Cela peut être important: le partage SMB utilise un alias DNS, pas sûr si cela fait une différence. Le vrai nom de l'hôte est différent. Lorsque vous utilisez le nom réel de l'hôte au lieu de l'alias, le problème d'accès semble être résolu.Echec de l'authentification Kerberos et/ou NTLM dans les packages d'applications personnalisés écrits à l'aide du programme d'installation WISE

+1

de la documentation MIT Kerberos: _ » ... à la recherche DNS ** Canonicalisation ** noms principaux ... ** résolution DNS inverse ** (recherche le nom d'hôte associé à l'adresse IP ...) 'rdns = false' va désactiver la recherche DNS inversée sur les clients" _ https://web.mit.edu/kerberos/krb5-1.15/doc/admin/princ_dn s.html –

Répondre

6

Le partage réseau ne serait pas hébergé par un serveur non Windows par hasard, n'est-ce pas? Si oui, voir si cet article applique:

SMB file server share access is unsuccessful through DNS CNAME alias

Fondamentalement, il y avait un changement dans le modèle de sécurité de Windows 10. Windows 10 par défaut ne demandera pas un ticket Kerberos pour un alias DNS, mais Windows 7 volonté. Le serveur SMB dit essentiellement que puisque vous n'utilisez pas mon nom réel (comme indiqué par le ticket de service), je ne permet pas la connexion. Créez un nouveau SPN en utilisant le nom avec lequel les machines Windows 7 réussissent à se connecter, mais sous forme de SPN. Par exemple, si un Windows 7 est d'utiliser quelque chose comme ceci:

\ servername.domain.com \ nom_partage

..then trouver ce nom de l'objet ordinateur AD représentant l'hôte et ajouter un SPN secondaire par rapport à objet AD comme ceci:

HOST/servername.domain.com

+4

Ceci est destiné à aider avec des situations MITM et je suis d'accord, la cause probable. – markgamache