Windows 8.1

When an Application Really Doesn’t Need Admin Rights

Posted by James F. Prudente on December 10, 2015
Posted in: Permissions, Windows 10, Windows 8.1. Tagged: , , . 2 Comments

When Windows Vista launched, we made the decision to disable User Account Control – UAC – because it seemed to be an unnecessary complication. We were already tightly locking down our PCs with Group Policy and none of our users have admin rights, so our exposure to threats was comparatively limited. We kept UAC disabled through Windows 7 and our limited use of Windows 8.1, but as we prepped for Windows 10, we needed to completely revisit UAC.

In Windows 10, Metro apps – which includes the Edge browser – require UAC to be enabled to work properly. With UAC disabled we had inconsistent behavior, where sometimes Metro apps would launch, and other times they would fail with the below error:

So it was time to turn UAC back on.

We immediately ran into problems with a couple of end-user applications that were requesting elevation. Since our users do not have admin rights and therefore cannot elevate, these applications would not run. What made no sense though is these were programs that had worked fine with UAC off, and with standard user rights, so it stood to reason they didn’t actually need elevation to function.

Thus began my exploration into why these applications were requesting elevation. They weren’t installers, and they weren’t trying to write to protected directories. Turns out they were just poorly coded.

UAC-compliant applications are supposed to explicitly request the level of permissions they require through an application manifest.

You can use mt.exe found in the Windows SDK to extract and change application manifests.

To extract:     mt.exe –inputresource:myexecutable.exe;#1 –out:extracted.xml

The manifest itself is just XML, so open with whatever plain-text editor you like and look for the section like this:

<requestedPrivileges xmlns="urn:schemas-microsoft-com:asm.v3">
   <requestedExecutionLevel level="requireAdministrator" uiAccess="false"></requestedExecutionLevel>
</requestedPrivileges>

Notice the “level” parameter, set here to “requireAdministrator” – this, not surprisingly, tells Windows that the application requires administrator rights and thus must request elevation.

Change “requireAdministrator” to “asInvoker” – this will allow the app to run in the security context of the user launching it. Now we need to import the edited manifest back into the application.

To import:    mt.exe –nologo –manifest “editedmanifest.xml” –outputresource:”myexecutable.exe;#1″

Once that was done, our problem application stopped asking for elevation. Problem solved.

Understand though that this only works because the application didn’t need admin permissions – it just wanted them. An app that actually requires admin rights will not work properly without them.

There was one lingering question I had though: Why did this app actually work with UAC turned off? Turns out the answer is simple. With UAC disabled, when a standard user runs an application that’s set to “requireAdministrator,” the elevation fails silently, allowing the app to launch. Since this particular app didn’t need elevation, it ran fine, and we had no idea of the underlying problem.

Now if we could just get the developer to do things properly…

ADFS Authentication Failures on Domain-Joined PCs when Running off Domain

Posted by James F. Prudente on May 6, 2014
Posted in: Office 365, Permissions, Windows 8.1, Windows Server. 1 Comment

If you’re going to be using Office 365 in any capacity, you essentially need to setup Active Directory Federation Services (ADFS). This will sync your on-premise AD to Microsoft’s cloud and allow your users to sign-on to Office 365 using their domain credentials. I did most of this setup using ADFS 2.0 on Windows Server 2008 R2 about a year ago when we first starting using some O365 features and thought everything was working fine. Of course if it was, this post wouldn’t exist.

For the 2008 R2 variant of ADFS (there’s a newer version on Server 2012), Microsoft recommends five (5!) servers: one to sync your AD to the cloud, two load-balanced as the actual ADFS servers to authenticate users, and two more (also load-balanced) as ADFS proxies, which would typically sit in your DMZ and relay authentication requests to your ADFS server(s).

NOTE: A Microsoft Office 365 expert I saw speak at a recent presentation indicated that installing the DirSync tool on a domain controller is now supported, so that would at least eliminate one of the five servers mentioned above. I haven’t verified that elsewhere, and I’m not sure if it’s only applicable to ADFS on Server 2012, but it’s worth looking into if you’re doing a setup from scratch.

I balked at installing five servers, especially as we were (and for the most part, still are) in a testing phase with Office 365. I setup the AD sync server and one ADFS server and started testing. After the usual teething issues, everything looked good and users could authenticate to Office 365 using single-sign-on (SSO) from behind the corporate firewall. That left dealing with users outside the firewall. Basically you can handle this one of two ways; either install the ADFS proxy server(s) as per Microsoft, or expose port 443 on the ADFS server to the Internet. The later choice is considered slightly riskier from a security perspective, but unless you’re going to put the proxy server(s) in a DMZ, there’s really no (security) difference that I can see. I went with the easier approach, which as it turns out was a mistake.

After opening port 443, I tested ADFS from a non-domain joined PC outside our firewall. As expected, I was prompted for credentials and was able to login successfully. I also tested using my domain-joined laptop (running Win 7) from home, and was likewise able to login. So everything was good as far as we knew.

Until we started testing Windows 8.1, that is. I noticed pretty quickly that the domain-joined 8.1 machines could not connect to O365 when running off-domain. So for example, a user with a domain-joined tablet could not connect when using that tablet from home, yet back in the office everything worked fine. A non-domain joined Windows 8/8.1 system would however prompt for credentials and allow the user to login.

At this point I re-tested this same scenario on Windows 7 and found that most of the time, the Win 7 client could connect from outside the domain. Sometimes though I would repeatedly be prompted for credentials and could not connect. Inconsistent behavior. Lovely.

I opened a ticket with Microsoft, who, to their credit, provides free support for O365 on top of providing O365 itself for free to K-12 schools. It took a while, but the ADFS team I was working with eventually established that ADFS was working properly and that Kerberos authentication was failing. Of course troubleshooting that would require involving the directory services team, so I’d need to open a new ticket with them. Sigh.

Before I go any further, let me summarize the behavior I was seeing:

OS

Domain-Joined

Connected From

Behavior

Windows 7

Yes

Behind Firewall

Login worked via SSO

Windows 7

No

Outside Firewall

Login worked after prompting for credentials

Windows 7

Yes

Outside Firewall

Inconsistent; login worked when the system did not prompt for credentials, but failed when it did prompt

Windows 8.1

Yes

Behind Firewall

Login worked via SSO

Windows 8.1

No

Outside Firewall

Login worked after prompting for credentials

Windows 8.1

Yes

Outside Firewall

Login failed, never prompting for credentials

 

Incidentally, a login failure showed in the browser as “page could not be displayed,” but was actually a “401 Unauthorized” reply from the ADFS server.

Having now been pointed in the direction of Kerberos, I decided to do some more troubleshooting before opening a ticket with the directory services team. I stumbled on this KB article, which came pretty close to describing the problem we were experiencing. Unfortunately I went through that entire article and none of the resolutions shown had any effect.

That KB article did at least force me to look at web.config and the different types of authentication that ADFS supported.

I knew “Integrated” authentication was working fine behind the firewall, using Kerberos. And likewise I knew “forms”-based authentication worked from outside the firewall. Now, in theory, the client should be trying these authentication methods in order, negotiating the most secure one available to both the server and the client. And that seems to be the cause of the problem.

Now, I’ll freely admit that Kerberos and negotiating authentication methods is not one of my areas of expertise, but a packet-trace showed a clear problem. The 8.1 client was attempting to contact a domain controller from outside the firewall, to find a Kerberos SRV record; obviously there’s no way that would work. So my best guess is this: when joined to the domain, the client believes it can/should be able to authenticate with Kerberos; this prevents the negotiation of the authentication method from “falling-back” to forms-based. But without connectivity to a domain controller, Kerberos authentication fails, at least most of the time. I can’t explain the inconsistent behavior on the Win 7 systems, other than guessing that I was switching a test machine from my domain network to my off-domain network so quickly that the client didn’t need to request another Kerberos ticket.

So after all this, I ended up coming full circle to the ADFS proxy server I chose not to install initially. Apparently while you don’t need an ADFS proxy for most functionality, getting things working 100% does require one. After installing the proxy and making the necessary firewall changes, all of our problems went away. (See this link for a quick rundown on installing and configuring an ADFS proxy. Keep in mind there is a newer update rollup than the article references.)

The reason for this is simple: the ADFS proxy is only setup for forms-based authentication. Using split-brain DNS, an internal client connects to your ADFS server and authenticates with Kerberos, but an external client connects to the ADFS proxy and is (always) prompted for credentials via forms-based authentication.

In retrospect I should have just followed Microsoft’s recommendations and installed the proxy from the beginning. Unlike the ADFS setup itself – which is quite time consuming – installing and configuring the proxy is quick and easy. It’s just another server to manage. But then again, what would modern IT be without virtual server sprawl?

With that, another obscure problem comes to a resolution. If this helps you please leave a comment; I love getting feedback.

Bonus Info: If you want to customize the ADFS proxy login page to make it look better, check out this page.

I also recommend making the changes shown at the bottom of this page to FormsSignIn.aspx.cs so that the username field automatically gets populated.

Finally, after making the changes above, you can make one more change to FormsSignIn.aspx.cs so that the focus is set to the password field. Find UsernameTextBox.Text = userName; in FormsSignIn.aspx.cs and add PasswordTextBox.Focus(); right below it.

With those changes made, you’ll have a much better looking login page that will automatically populate the username field and set the focus to the password field. Not bad for a few minutes work.

Setting Windows 8.1 All Apps View Sorting via GPO

Posted by James F. Prudente on March 28, 2014
Posted in: Windows 8.1. 3 Comments

As a K-12 school dealing with students as young as five who, over the course of a week might use a dozen computers in different locations, we work hard to present a consistent experience from PC to PC. One way we do this is by redirecting the start menu to a network share, so every PC has the same start menu. This has worked great as far back as Windows 2000, but of course Windows 8/8.1 brought major changes to the OS, replacing the start menu with the start screen and tiles. While we are running Win 7 on the desktop, the Windows tablets we are beginning to roll out are of course, on 8.1, and we’re likely to be dealing with both versions for some time.

When the policies that redirect the start menu are applied to an 8.1 system you end up with an interesting result. The start screen will show the shortcuts from the redirect, along with the ‘default’ Metro shortcuts – and that’s all. Even the “Desktop” tile will be missing. That’s at least an easy enough fix, as detailed here; download the desktop shortcut and put it into your redirected start menu. Note that this shortcut is by default a system file; it seems in order for it to properly display you need to remove the system attribute; “attrib -s desktop.lnk” from a command prompt.

Now, probably the biggest start screen improvement from 8 to 8.1 from an administrator’s perspective is the ability to control the start screen via group policy. You can create a reference start screen, export it via PowerShell, then import it into group policy and push it back out to multiple computers through a GPO. We will probably do this eventually but right now our priority was getting a functional start screen that was reasonably consistent with the Windows 7 machines.

We ended up setting the following through group policy:

  • User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\List desktop apps first in the Apps view à Enabled
  • User Configuration\Policies\Administrative Templates\Start Menu and Taskbar\Show the Apps view automatically when the user goes to Start à Enabled

With these two settings in place, clicking Start brings up the “All Apps” view rather than the start screen tiles, and displays the desktop apps before any Metro apps. However, for that later setting to matter, you have to sort the “All Apps” view by Category.

This unfortunately is a setting that’s not natively exposed by Group Policy, but it is stored in the registry and thus can be controlled with a Group Policy Preference.

The registry key is HKCU\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\Grid\LauncherSortOption

Options are:

0 – Sort by Name
1 – Sort by Date
2 – Sort by Most Used
3 – Sort by Category

Between the earlier two GP settings and this registry entry (set to 3), we end up with the start button showing a list of all apps, with the shortcuts from our redirected start menu listed first. While this is still significantly different than a Win 7 desktop and its traditional start menu, I think this is the best solution for using a redirected start menu on Win 8.1. You can see below the similarities between the customized 8.1 app view and our redirected Win 7 start menu. The “Desktop” icon will show on the Win 7 start menu but doesn’t here because I hadn’t yet changed the shortcut’s system attribute as referenced earlier.


All in all these are an easy few tweaks to hopefully make 8.1 a little friendlier for those of you already redirecting the start menu.