authenticationactive-directorykerberosntlmwise

Encountering Kerberos and/or NTLM authentication failures in custom application packages written using the WISE packaging Installer


We are encountering Kerberos and/or NTLM authentication failures in custom application packages orinally designed for Windows 7 using the WISE packaging Installer. On Windows 7 they work fine but they now fail on Windows 10. They fail both during installations on Windows 10 using the Microsoft SCCM tool, and they fail specifically when using Kerberos authentication to an SMB Share on the network durign the installation process. We can see inside the network trace that the client application fails over to NTLM from Kerberos durign the authentcation transaction. We are unsure why. We have a large scale Active Directory environment. Because the WISE package is comiled we cannot look into it. On successful Windows 7 machines, it appears the computer requires access to the Share while the package is being executed and the loggged-in user must have read and execute access on the SMB Share. We are able to access the same SMB Share using the Windows 7 system account but not when using the Windows 10 system account. Very odd! Is this a code issue inside the package? This may be important: The SMB share is using an DNS alias, not sure if this makes any difference. The real name of the host is different. When using the real name of the host instead of the alias the access issue appears to be resolved.


Solution

  • The network share wouldn't happen to be hosted by a non-Windows server by any chance, would it? If so, see if this article applies:

    SMB file server share access is unsuccessful through DNS CNAME alias

    Basically there was a change in the security model of Windows 10. Windows 10 by default won't request a Kerberos ticket for a DNS alias, but Windows 7 will. The SMB server is basically saying since you're not using my actual name (as shown by the service ticket), I won't allow the connection. Create a new SPN using the name that the successful Windows 7 machines are connecting with, but in SPN form. For example, if a Windows 7 is using something like this:

    \servername.domain.com\sharename

    ..then find that name of the AD computer object representing the host and add a secondary SPN to that AD object like so:

    HOST/servername.domain.com