Archive for April, 2019


Attack surface analyzer:

https://www.microsoft.com/security/blog/2019/05/15/announcing-new-attack-surface-analyzer-2-0

 

DSC-EA:

https://github.com/Microsoft/DSCEA

documentation: https://microsoft.github.io/DSCEA/

 

Microsoft security compliance toolkit:

Il remplace Security Compliance Manager. Cet outil permet de planifier, créer, et monitorer des baselines de sécurité pour vos postes clients. Le remplacement a été choisi par Microsoft du fait de la complexité de SCM et de la difficulté à maintenir l’outil pour chaque version de Windows. Aujourd’hui, SCT ne supporte pas Desired Configuration Management de System Center Configuration Manager ou SCAP.

https://www.microsoft.com/en-us/download/details.aspx?id=55319

how to use it:

https://arnaudloos.com/2018/intro-to-policy-analyzer/

https://github.com/MicrosoftDocs/windows-itpro-docs/blob/master/windows/security/threat-protection/security-compliance-toolkit-10.md

 

Other references:

2012 R2 hardening (CIS):

https://www.cisecurity.org/wp-content/uploads/2017/04/CIS_Microsoft_Windows_Server_2012_R2_Benchmark_v2.2.0.pdf

Windows 10 hardening:

https://www.asd.gov.au/publications/protect/Hardening_Win10.pdf

 

 

 

Advertisements

Security baseline reference article:

https://blogs.technet.microsoft.com/secguide/2019/04/24/security-baseline-draft-for-windows-10-v1903-and-windows-server-v1903/

Introduction:

Download the content here: Windows-10-1903-Security-Baseline-DRAFT. As usual, the content includes GPO backups, GPO reports, scripts to apply settings to local GPO, Policy Analyzer rules files for each baseline and for the full set, and spreadsheets documenting all available GPOs and our recommended settings, settings that are new to this Feature Update, and changes from the previous baselines.

Note that Windows Server version 1903 is Server Core only and does not offer a Desktop Experience (a.k.a., “full”) server installation option. In the past we have published baselines only for “full” server releases – Windows Server 2016 and 2019. Beginning with this release we intend to publish baselines for Core-only Windows Server versions as well. However, we do not intend at this time to distinguish settings in the baseline that apply only to Desktop Experience. When applied to Server Core, those settings are inert for all intents and purposes.

This new Windows Feature Update brings very few new Group Policy settings, which we list in the accompanying documentation. The draft baseline recommends configuring only two of those. However, we have made several changes to existing settings, and are considering other changes. Please review the changes carefully and let us know what you think.

The changes from the Windows 10 v1809 and Windows Server 2019 baselines include:

  • Enabling the new “Enable svchost.exe mitigation options” policy, which enforces stricter security on Windows services hosted in svchost.exe, including that all binaries loaded by svchost.exe must be signed by Microsoft, and that dynamically-generated code is disallowed. Please pay special attention to this one as it might cause compatibility problems with third-party code that tries to use the svchost.exe hosting process, including third-party smart-card plugins.
  • Configuring the new App Privacy setting, “Let Windows apps activate with voice while the system is locked,” so that users cannot interact with applications using speech while the system is locked.
  • Disabling multicast name resolution (LLMNR) to mitigate server spoofing threats.
  • Restricting the NetBT NodeType to P-node, disallowing the use of broadcast to register or resolve names, also to mitigate server spoofing threats. We have added a setting to the custom “MS Security Guide” ADMX to enable managing this configuration setting through Group Policy.
  • Correcting an oversight in the Domain Controller baseline by adding recommended auditing settings for Kerberos authentication service.
  • Dropping the password-expiration policies that require periodic password changes. This change is discussed in further detail below.
  • Dropping the specific BitLocker drive encryption method and cipher strength settings. The baseline has been requiring the strongest available BitLocker encryption. We are removing that item for a few reasons. The default is 128-bit encryption, and our crypto experts tell us that there is no known danger of its being broken in the foreseeable future. On some hardware there can be noticeable performance degradation going from 128- to 256-bit. And finally, many devices such as those in the Microsoft Surface line turn on BitLocker by default and use the default algorithms. Converting those to use 256-bit requires first decrypting the volumes and then re-encrypting, which creates temporary security exposure as well as user impact.
  • Dropping the File Explorer “Turn off Data Execution Prevention for Explorer” and “Turn off heap termination on corruption” settings, as it turns out they merely enforce default behavior, as Raymond Chen describes here.

 

 

 

Azure AD password protection is now generally available:

https://techcommunity.microsoft.com/t5/Azure-Active-Directory-Identity/Azure-AD-Password-Protection-is-now-generally-available/ba-p/377487

 

Azure AD password protection – how to eliminate bad passwords:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/concept-password-ban-bad

Deployment:

https://docs.microsoft.com/en-us/azure/active-directory/authentication/howto-password-ban-bad-on-premises-deploy

 

Architecture (to cover also onprem AD domain controllers):

 

 

 

Azure portal standalone application

Brand new standalone application for the Azure portal (does not need a browser).

https://preview.portal.azure.com/app/welcome (https://preview.portal.azure.com = new Azure portal in preview mode)

 

Introduction

 

  • A number of organizations use AD FS for SSO capabilities, but all such organizations do not have HA or Site resilience added to AD FS Deployment
  • The Password Sync option can be a great backup solution while AD FS is offline or while you are fixing AD FS problems
    • DirSync is already a core component required for AD FS, just required to enable the Password Sync feature
    • Alternatively, you could have Password Sync enabled running all the time. Does not interfere with SSO
    • During AD FS failure, fallback to Password Sync can be done through couple of methods. But it will takes time (up to 72 hours) to be effective for the users. Those methods must be only enabled in case of Disaster.

Implementation Method1

 

  • Method 1: Using Set-MsolDomainAuthentication cmdlet
    • This cmdlet is a good temporary option, as it,
      • Does not require AD FS to be online
      • Will only update the settings in Microsoft Online Services
      • Will not remove the Office 365 relying party trust information from AD FS
      • Will not change the User objects (from federated to standard)
    • Process to switch to Password sync:
        • Enable Password Sync (if not already enabled)

       

    • Set-MsolDomainAuthentication –DomainName <Domain Name> -Authentication Managed
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Managed and not Federated
      • Force full Password sync, if required
    • Revert to AD FS or SSO:
      • Convert-MsolDomainToFederated –DomainName <DomainName> (requires AD FS online)
      • This cmdlet will revert the domain back to Federated, and will re-establish the relying party trust
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Federated and not Managed

Implementation Method 2

 

  • Method 2: Using Convert-MsolDomainToStandard cmdlet
    • Is good for either temporary or exclusive switch over to Password Sync
      • Requires AD FS to be online
      • Will remove relying party trust information from MFG and on-premises AD FS (cleans-up)
      • Optionally converts Federated users to Standard users (which enables ‘change password’ option for them in portal)
      • Resets and generates temporary passwords for these users (can be overwritten with Password Sync)
      • Limited to process only 1000 user objects (use Convert-MsolFederatedUser or this script for more than 1000 objects)
      • Use Get-Msoldomain cmdlet to check if the domain is in mode Managed and not Federated
    • Process to switch to Password sync:
      • Enable Password Sync (if not already enabled)
      • Convert-MsolDomainToStandard -DomainName <Domain Name> -SkipUserConversion $True or, for permanent switchover that could take two hours, use -SkipUserConversion $false
      • 3. Force full Password sync
    • Revert to AD FS or SSO:

Convert-MsolDomainToFederated –DomainName <DomainName> (requires AD FS online)

      • Use Get-Msoldomain cmdlet to check if the domain is in mode Federated and not Managed

How the Modern Authentication Protocol Works

Once Modern Authentication is enabled a user will authenticate with one of the Office 365 services and they will be issued both an Access Token and a Refresh Token.  The Access Token is a short-lived token, valid for about 1 hour’s time.  The Refresh Token is longer-lived and can by valid for up to 90 days in some cases.  These longer cases include frequent use and when the user’s password has not changed.  The Access Token is what is used to gain access to the Office 365 services, and when the Access Token expires the Office client will present the Refresh Token to Azure Active Directory and request a new Access Token to use with the service.  The default lifetime for a Refresh Token is 14 days.  Features such as Conditional Access Policies may force users to sign-in again even though the Refresh Token is still valid.

How to use Modern Authentication

Client supportability

Modern Authentication is automatically on for Office 2016 client apps.

To enable modern authentication for any devices running Windows (for example on laptops and tablets) that have Microsoft Office 2013 installed, you need to set the following registry keys. The keys have to be set on each device that you want to enable for modern authentication:

REGISTRY KEY TYPE VALUE
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\EnableADAL REG_DWORD 1
HKCU\SOFTWARE\Microsoft\Office\15.0\Common\Identity\Version REG_DWORD 1

These can be changed manually or through a Group Policy object.

Office 2013 must be build 15.0.4605.1003 or higher (March 2015 PU)

Other Operating Systems

Modern authentication uses OAuth 2.0 standards and is supported on multiple platforms, including OSX, iOS, Android, and Windows.

Client supportability matrix: https://blogs.office.com/2015/11/19/updated-office-365-modern-authentication-public-preview/

Must be using MAPI / HTTP

We need to validate that every client is using MAPI over HTTP as this is a requirement for Modern Authentication.

The support article KB2937684 gives you some more info around ensuring MAPI-HTTP is enabled for your Office 2013/2016 client.

Office 365 services

Exchange Online is off by default.

  1. Connect to Exchange Online PowerShell as shown here.
  2. Run the following command in Exchange Online PowerShell:

Set-OrganizationConfig -OAuth2ClientProfileEnabled $true

  1. To verify that the change was successful, run the following command in Exchange Online PowerShell:

Get-OrganizationConfig

Format-Table -Auto Name,OAuth*

SharePoint Online is on by default.

Skype for Business Online is off by default.

  1. Connect to Skype for Business Online using remote PowerShell: https://aka.ms/SkypePowerShell 
  2. Run the following command:

Set-CsOAuthConfiguration -ClientAdalAuthOverride Allowed

  1. Verify that the change was successful by running the following:

Get-CsOAuthConfiguration

How Modern Authentication Works for Office 2016 / 2013

Office 2016 clients support modern authentication by default, and no action is needed for the client to use these new flows. However, explicit action is needed to use legacy authentication.

Office 2013 client apps support legacy authentication by default. Legacy means that they support either Microsoft Online Sign-in Assistant or basic authentication. For these clients to use modern authentication features, the Windows client must have registry keys set. (See notes above)

Exchange Online

Office client app version Registry key present? Modern authentication on? Authentication behavior with modern authentication turned on for the tenant Authentication behavior with modern authentication turned off for the tenant (default)
Office 2016 No, or EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled. Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled.
Office 2016 Yes, EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled. Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled.
Office 2016 Yes, EnableADAL=0 No Basic authentication Basic authentication
Office 2013 No No Basic authentication Basic authentication
Office 2013 Yes, EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled. Modern authentication is attempted first. If the server refuses a modern authentication connection, then basic authentication is used. Server refuses modern authentication when the tenant is not enabled.

Source: https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517#bk_echangeonline

SharePoint Online

Office client app version Registry key present? Modern authentication on? Authentication behavior with modern authentication turned on for the tenant (default) Authentication behavior with modern authentication turned off for the tenant
Office 2016 No, or EnableADAL = 1 Yes Modern authentication only. Failure to connect.
Office 2016 Yes, EnableADAL = 1 Yes Modern authentication only. Failure to connect.
Office 2016 Yes, EnableADAL = 0 No Microsoft Online Sign-in Assistant only. Microsoft Online Sign-in Assistant only.
Office 2013 No No Microsoft Online Sign-in Assistant only. Microsoft Online Sign-in Assistant only.
Office 2013 Yes, EnableADAL = 1 Yes Modern authentication only. Failure to connect.

Source: https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517#bk_sharepointonline

Skype for Business Online

Office client app version Registry key present? Modern authentication on? Authentication behavior with modern authentication turned on for the tenant Authentication behavior with modern authentication turned off for the tenant (default)
Office 2016 No, or EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then Microsoft Online Sign-in Assistant is used. Server refuses modern authentication when Skype for Business Online tenants are not enabled. Modern authentication is attempted first. If the server refuses a modern authentication connection, then Microsoft Online Sign-in Assistant is used. Server refuses modern authentication when Skype for Business Online tenants are not enabled.
Office 2016 Yes, EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then Microsoft Online Sign-in Assistant is used. Server refuses modern authentication when Skype for Business Online tenants are not enabled. Modern authentication is attempted first. If the server refuses a modern authentication connection, then Microsoft Online Sign-in Assistant is used. Server refuses modern authentication when Skype for Business Online tenants are not enabled.
Office 2016 Yes, EnableADAL = 0 No Microsoft Online Sign-in Assistant only. Microsoft Online Sign-in Assistant only.
Office 2013 No No Microsoft Online Sign-in Assistant only. Microsoft Online Sign-in Assistant only.
Office 2013 Yes, EnableADAL = 1 Yes Modern authentication is attempted first. If the server refuses a modern authentication connection, then Microsoft Online Sign-in Assistant is used. Server refuses modern authentication when Skype for Business Online tenants are not enabled. Microsoft Online Sign-in Assistant only.

Source: https://support.office.com/en-us/article/How-modern-authentication-works-for-Office-2013-and-Office-2016-client-apps-e4c45989-4b1a-462e-a81b-2a13191cf517#bk_sfbo

Additional Notes

ADFS

With modern authentication, all clients will use Passive Flows (WS-Federation), and will appear to be browser traffic to AD FS.

ADFS client access filtering policies

Once Modern Authentication has been enabled, any client access filtering policies will need to be changed as follows:

Current client access filtering policy After enabling  modern authentication Action needed
1 Block all external access to Office 365 Continue to rely on existing ADFS policies (client traffic now comes in on WS-Federation endpoint) None
2 Block all external access to Office 365 except Exchange ActiveSync Continue to rely on existing ADFS policies (client traffic now comes in on WS-Federation endpoint) None
3 Block all external access to Office 365 except Browser-based apps Implement conditional policies in Office 365/Azure AD to block “Rich Client” traffic (allow on ADFS). This scenario is not yet supported for public preview and we recommend organizations that rely on this scenario to not onboard their tenants for modern authentication.

Source:  https://social.technet.microsoft.com/wiki/contents/articles/30253.office-2013-and-office-365-proplus-modern-authentication-and-client-access-filtering-policies-things-to-know-before-onboarding.aspx