KB0017 - Windows Auth Checklist

KB0017 - Windows Auth Checklist

Purpose

The purpose of this article is to list the prerequisite conditions for ensuring that Windows Authentication in PowerShell Universal will function as expected (i.e. seamless logon without authentication pop-ups)

Scope

The scope of this article is a scenario with a single domain using on-premises ActiveDirectory authentication along with standard Windows Integrated Authentication on a company intranet. Both IIS (zip install) and native Kestrel (MSI install) are applicable here. HTTP and HTTPS are also both applicable. 

Scenario

The documentation at  https://docs.powershelluniversal.com/config/security#windows-authentication  has been followed and Windows Authentication is known to be working on the PSU instance.

You have a single Windows domain (contoso.com) with PSU running on a Windows Server (psu.contoso.com) on the default port. You access the PSU instance from a Windows 10 workstation which is joined to the domain. You are logging in to the workstation with a user account from the same domain. Despite this, you are still getting prompted for authentication (pictured below) when trying to access the instance at  http://psu.contoso.com:5000 . 



Checklist

1) Is DNS configured correctly in your domain?

You should be able to access the instance from its fully qualified domain name.


2) Can you browse the domain from File Explorer (e.g. \\contoso.com)?

Any authenticated user on a properly joined computer should be able to browse the domain's NETLOGON and SYSVOL shares from File Explorer [1] . If you are getting prompted here for authentication, then that needs to be fixed first for this scenario before proceeding to the next item on the checklist.


(figure shows browsing the domain from the workstation that will connect to the PSU instance)


3) Are you using the fully qualified name of the PSU instance and is that fully qualified address added to the workstation's intranet sites?

Windows Integrated Authentication (WIA) is intended for intranets [2] . For this scenario, it's assumed that the administrator accessing the PSU instance from a workstation is doing so from the company intranet. Either the PSU instance will be treated as intranet by the computer or not depending on the Group Policy. Assuming that the PSU instance is not treated as an intranet site then you can still add it manually per below.


(figure shows how the entry for PSU should look in the workstations intranet sites from the Control Panel -> Internet Options -> [Security Tab] -> Local Intranet  -> Sites -> Advanced)

To check if a web site is considered intranet, Trusted or Internet, you can check the properties of the page with Internet Explorer (yes, this still applies on Windows 10). From the page in IE, type Alt-F, then select the Properties.





4) Have you set the SPNs for the service account running PowerShell Universal? 

SPNs are required for Windows Authentication to function properly when running PowerShell Universal outside of IIS. Ensure that you have correctly created the SPNs .

5) Does your service account have adequate encryption types enabled? 

If Group Policy is configured to enforce encryption types like AES128 and AES256 for Kerberos, you need to ensure that  msDS-SupportedEncryptionTypes attribute of your service account enables these types. You can set the value of this attribute to 28 to enable these encryption types[3].

6) If you are using a Chromium-based browser, is it correctly identifying the PowerShell Universal website as intranet? 
Chromium will not pass Windows credentials if it does not detect the website as an intranet site. You can work around this by setting Chromium policies in Windows to force the system to send the credentials. 
You can read more about this setting here: https://chromeenterprise.google/policies/#AuthServerAllowlist
7) Auth token is not forwarded in IIS
If the web.config file has not been updated to forward the Windows Auth Token, the authentication will fail. Update the web.config file with the following. 
  1. forwardWindowsAuthToken="true"

Conclusion

More scenarios will be added to this documentation. For now, you should be able to access your PowerShell Universal instance from a supported browser[4]  using Windows Integrated Authentication (without authentication pop-ups).



    • Related Articles

    • KB0066 - Get-WMIObject cmdlet not working

      Scope This article applies to any scenario where the Get-WMIObject cmdlet is expected to be available and functioning within a PowerShell Universal instance. Effectively, this article will only apply to instances that run under the Windows operating ...

    • KB0032 - (Windows) About the difference between the MSI and ZIP installs

      Question What's the difference between the MSI and ZIP installations of PowerShell Universal for Windows operating systems? Answer The MSI install is a self-contained web hosting platform using Microsoft Kestrel[1]. The ZIP installer is intended for ...

    • KB - 1008 Tax/VAT Exempt at checkout

      Scope In this article you will learn how to make a tax-free purchase at checkout. Problem How do you remove the Tax/VAT on an order? Impact Orders will then need to be refunded for tax if processed without the tax deducted. Resolution Follow the ...

    • KB0002 - Security features of PowerShell Universal

      In terms of security features, PowerShell Universal currently provides: HTTPS for over the wire encryption Authentication providers such as SAML2, OpenID Connect, Windows (NTLM\Kerberos), WS-Federation, client certificate, and basic auth Role-based ...

    • KB0018 - An anonymous request was received in between authentication handshake requests.

      Symptom #1 PowerShell Universal returns a 500 error when visiting the website that is using Windows Authentication. Symptom #2 When viewing the log file in C:\ProgramData\PowerShellUniversal or within the admin console under Settings \ General ...