A blog with focus on Windows 10 and cloud <solutions
RSS icon Email icon Home icon

  • “The page can’t be displayed” in web apps after installing June (or July) CU update for Windows 10

    Posted on August 2nd, 2016 By Andreas Stenhall + No comments

    Some web apps might not work after installing the June (or July) 2016 Cumulative Update for Windows 10.

    Problem

    After installing June (KB3163018) or July (KB3172985) cumulative updates for Windows 10 a specific web app was broken, when browsing to it in Internet Explorer 11 or Edge lead to ”The page can’t be displayed”.

    Investigation

    Looking at the System log in Event Log showed Schannel errors:

    A fatal alert was generated and sent to the remote endpoint. This may result in the termination of the connection. The TLS protocol defined fatal error code 40. The Windows SChannel error state is 808.

    Doing a network trace showed that the web app server negotiated the TLSCipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA.

    Cause

    Windows as of update https://support.microsoft.com/en-us/kb/3061518 no longer support ciphers with 512-bits. Note that this KB was released in May 2016 but not anywhere stated to affect Windows 10. Nothing related to these changes points to Windows 10, but as we can conclude, these changes are introduced with June 2016 CU for Windows 10 (and thereby carried forward to July CU and any other CU to come).

    Workaround

    Use the workaround described in the registry section workaround in https://support.microsoft.com/en-us/kb/3061518 to go back to the 512-bits settings.

    Solution

    Make necessary server configuration changes to support the better ciphers.

  • Busting a myth: AppLocker do not magically allow standard users to install applications or updates

    Posted on May 10th, 2012 By Andreas Stenhall + No comments

    The one most common misconception around AppLocker is the fact that it could be used to allow standard users to install stuff that in any normal case would require administrator privileges. This is absolutely 100% incorrect.

    What AppLocker does is set a number of rules on what can be run and executed on a machine. It is important to note that if you allow something to run or be executed via AppLocker rules the user will still need the appropriate privileges if the setup or application itself require administrative privileges at some point in time such as when doing automatic updating for instance.

  • Windows client security lockdown with nifty tool from Microsoft

    Posted on October 18th, 2010 By Andreas Stenhall + No comments

    It’s been around for some time and if you did not already know about it Microsoft provide the free tool called Security Compliance Manager. You can use it to very easily manage and export a set of pre-configured (or settings that you configure on your own) settings that improve security. You can then export these settings to for instance a group policy and import it into your domain.

    There are templates with pre-configured security lockdowns for Windows XP, Windows Vista and of course also Windows 7. The tool works great for creating a security baseline for your client machines but the only downside is that you cannot import nor in a convenient way compare the settings in the templates with what you currently have.

  • Case of the mysterious issues with UAC in Windows 7 and Windows Server 2008 R2

    Posted on September 18th, 2010 By Andreas Stenhall + 3 comments

    At the TechNet/MSDN after work I attended last week I got an interesting question on why a user (domain admin) gets a UAC popup on trying to access folders via Explorer which he knows for sure he is supposed to be able to access looking at the ACLs of the folder. Instead, when clicking OK on the UAC popup the ACL is populated with his account.

    UAC requesting permission to continue

    My first thought to this behavior was Explorer.exe not being able to elevate and the “split personality” i.e. the two security tokens involved when UAC is in effect. Here comes a more detailed explanation that I think is of interest to more. Note that this problem also covers some other scenarios such as AppLocker rules not appearing to work as intended for administrators. Read on to learn what is causing this.

    First when UAC is enabled you get two security tokens when you log in, easily explained as one which contains the administrator privilege information and one which does not. Most of the times you run everything using the standard security token. When you for instance want to install software or change some system settings, then the security token containing the administrator privileges information is used.

    If you do not explicitly request an application to launch with higher privileges, or the applications itself request higher privileges, all processes and applications run in the user context with the standard security token. Virtually all applications including Windows applications and processes are possible to elevate by right clicking and choosing “Run as administrator”. This is not true for Explorer.EXE though as all your attempts to elevate it will not result in any actual elevation. There are a few caveats with this and let us continue with the example of access certain files and folders.

    So let’s have a look at what the ACL of the folder D:\Share looks like:

    ACL of users\stenis folder before UAC continue

    We can clearly see that there are no user accounts in this list. Under normal circumstances any user which is a member of the domain admins group should be able to access that folder but instead is presented with the UAC dialogue:

    UAC requesting permission to continue

    What happens when the user “stenis” in this case clicks “Continue” to that UAC dialogue box questions is that the ACL is populated with the user account in questions:

    ACL of users\stenis folder after UAC continue

    This happens because the fact that Explorer.exe cannot be elevated the normal Windows Explorer does not see that the user account should be able to access that folder. It is easy to verify as you can actually run Explorer.EXE elevated by changing the registry setting “RunAs” to “_RunAs” in HKEY_CLASSES_ROOT\AppID\{CDCBCFCA-3CDC-436f-A4E2-0E02075250C2}. Thanks goes to Andre Ziegler for this finding.

    So what does this tell us? It is a somewhat strange problem but still by design. The fact is that this “problem” is not applicable to the folder and file access as described in this blog but also for AppLocker rules for instance, as many domain administrators must choose “Run as administrator” to be able to run software which they think they should be able to run without this little procedure.

  • Case of the AppLocker default rules issue

    Posted on August 26th, 2010 By Andreas Stenhall + No comments

    If you have started using AppLocker with Windows 7 you know that the default rules for executable files make sure that administrators can run anything on the box, and that everything from the Windows folder and Program files folder are allowed to be executed. There exists a slight problem with this set of rules.

    The default rules are intended for non-administrator users on the machine to be prevented from running any software which is not already installed or managed centrally, in the Program files folder. The default rules are also intended to allow anything from the Windows folder to be executed. Both these rules are sort of safe, as a standard user per default cannot put files in the program files folder to execute them, nor anywhere in the Windows folder.

    But, there is this but. Inside the Windows folder there is a folder called “temp”, which believe it or not, standard users can write stuff to and consequently executing it thereby bypassing all the nice security benefits that AppLocker provide.

    Well, the standard user just cannot copy an executable to the Temp folder using Windows Explorer, but using traditional copy commands using the command prompt this is fine, and then the executable can be executed.

    The problem here might not be that the average user can bypass AppLocker this way, but when securing servers or clients, potential attackers can use this to bypass your security rules.

    A simple solution if running with the default rules is to simply add the Windows\Temp folder to the exception list, effectively blocking code from being executed.

  • Standard users installing applications? Say welcome to the new reality

    Posted on April 8th, 2010 By Andreas Stenhall + No comments

    If you think that you have come a far way making sure all users are running as standard users you must stop and rethink. Well, having all users as standard users is very good from many perspectives but with coming challenges your efforts must not stop there. A growing problem is the fact that more and more applications install in the user space, i.e. in the \users\username\appdata directory instead of the traditional “Program files”.

    Also Windows 7 contain Windows Installer 5.0 which sports a new feature which makes the software vendors easily make Windows Installer (MSI files) that install software in the user space instead of program files, and thereby not requiring the user to be administrator or even require a UAC prompt for credentials for an administrative account.

    The standard users of course think this is great, meaning they after all can install and run for instance Google Chrome without needing to ask that restrictive IT department. From the IT departments view this fact that standard users can install and run applications is a concern.

    The answer to take care of this problem is simply the new Windows feature AppLocker. To be honest it is somewhat like Software Restriction Policies (SRP) but whatever bad things you have heard about SRP you can forget about them. AppLocker contains new features that make the implementation and ongoing management very easy compared to Software Restriction Policies. More about AppLocker in the AppLocker walkthrough.

  • Hide files and folders which users don’t have permission to

    Posted on September 24th, 2008 By Andreas Stenhall + No comments

    The other day I implemented the Microsoft tool Access-based Enumeration tool for the first time with a customer. The tool installs on Windows Server 2003 and present you with a new tab when you choose Properties on shares on the server. When activated it will make sure that users on their client computers don’t see files and folders in Windows Explorer to which they do not have permission.

    Download the Access-based Enumeration tool

  • Collection of best practices guides

    Posted on May 21st, 2008 By Andreas Stenhall + No comments

    Microsoft is providing best practice analyzers for most of their server products and I have gathered them on a list, for your convenience. These best practices analyzers are extremely good for troubleshooting and for making sure that the servers are performing at their best. Here is the link for the article:
    http://www.theexperienceblog.com/technical-articles/collection-of-best-practices-guides/

  • Turn off UAC in a domain using Group Policies

    Posted on March 30th, 2008 By Andreas Stenhall + No comments

    Some people for whatever reason want to turn off UAC for all or certain computers in a domain using Group Policies. This is done by setting the Computers Configuration > Windows Settings > Local Policies > Security Options > User Account Control: Run all administrators in Admin Approval Mode to disabled. As usual when turning off UAC a reboot is required for the changes to take effect.

  • Backing up BitLocker recovery keys to Active Directory

    Posted on October 21st, 2007 By Andreas Stenhall + 1 comment

    Using BitLocker to encrypt your system partition is a very good option to keep the computer and the data on it secure. Starting with Vista SP1 you will be able to encrypt not only the system partition but all the other partitions as well, offering even better security. When you encrypt a partition with BitLocker a recovery key is automatically generated so that you can recover the data on the computer when necessary. By default you have the choice of printing the recovery key or saving it to a USB stick or a network share.

    BitLocker Key Recovery ToolHowever using a group policy setting (Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Turn on BitLocker backup to Active Directory)  you can also backup the recovery key to Active Directory, which is a very good suggestion I must say. If you are running Windows Server 2008 you do not have to anything to get this working but if you would like to use Windows Server 2003 with SP1 or later to backup the BitLocker recovery key you must use scripts provided by Microsoft to extend the schema.

    Microsoft also offer a tool called BitLocker Recovery Password Viewer which can be downloaded directly from Microsoft Premier Services. When this tool is installed it introduce another tab in a computer objects Properties called “BitLocker Recovery” where the BitLocker recovery keys are listed for your viewing pleasure in the case of necessary restoration. The only negative part about the tool is that it can only be installed on a Windows XP or Windows Server 2003 computer as it require that you have installed the “Window Server 2003 Administration tools for SP1” on Windows XP to get the control panel for Active Directory Users and Computers.

    UPDATE: I forgot to add the link to the page where you can find all the necessary information as well as the “extend schema”-script. Here it is!