Essayez Azure gratuitement pendant un mois avec 170€ offerts!


Créez votre compte Azure gratuitement

Commencez avec un crédit de 170€ et poursuivez avec les options gratuites !

Démarrer maintenant

Essayez Microsoft Azure pendant 1 mois
Microsoft vous propose de tester Microsoft Azure, pendant 1 mois. Vous recevez un crédit de 170 € que vous pouvez utiliser comme vous le souhaitez en créant et en essayant n’importe quelle combinaison de ressources Azure. Cela vous permet d’explorer et de vous familiariser avec l’ensemble de notre cloud gratuitement.
Utilisez votre crédit de 170 € et…

Approvisionnez jusqu’à 14 machines virtuelles, 40 bases de données SQL ou 8 To de stockage par mois
Créez des applications web, mobiles et API qui utilisent le Cache Redis, Search ou CDN (Content Delivery Network)
Exploitez les données Big Data avec Machine Learning, Streaming Analytics et Hadoop
Créez des applications IoT en temps réel avec des fonctionnalités de surveillance et de détection des anomalies

Créez votre compte Azure gratuitement

Publié dans Azure | Laisser un commentaire

Le cloud Microsoft est le premier cloud CERTIFIE par l’UE!


Pendant mes interventions sur les produits Microsoft autant en formation qu’en prestation, la question revient souvent quand à la privacité des documents stockés dans le cloud… De nombreux clients refusent tout simplement d’héberger leur données dans le nuage par crainte de les voir diffusées ou du moins accédées par leur tenant ou leur hébergeur. Cela est bien normal!

Et bien force est de constater que Microsoft a mis les bouchées doubles en la matière!

Les services cloud de Microsoft (Azure, Office 365, Intune, etc…) sont les premiers, et pour le moment les seuls, à avoir obtenu une validation de la “Data Protection Working Party”, l’entité responsable à l’échelle européenne de monitorer les services providers utilisables dans le cadre des régulations strictes de la commission européen. En d’autres termes, Microsoft a su prouver aux entités en charge de la privacité et de la confidentialité des données européennes, que ses services étaient gérés de manière à garantir la sécurité et la privacité des contenus pour leurs propriétaires.

Le blog post suivant explique en détail comment s’est conclu l’audit de l’UE auprés des services Microsoft: https://blogs.technet.microsoft.com/microsoft_blog/2014/04/10/privacy-authorities-across-europe-approve-microsofts-cloud-commitments/

et le résultat est bien là, Microsoft est validé comme Cloud Provider au niveau UE…voir les lettres de recommandations :

http://ec.europa.eu/justice/data-protection/article-29/documentation/other-document/files/2014/20140402_microsoft.pdf

merci à www.sillicon.fr pour la nouvelle et à Willliam BORIES pour le tweet la relayantSmile

http://www.silicon.fr/cloud-microsoft-obtient-blanc-seing-cnil-europeennes-93836.html

allez d’ailleur y lire les nouvelles sur Google et ses déboires au niveau européen: http://www.silicon.fr/google-les-cnil-europeennes-font-monter-pression-89404.html

amusant de voir le monde à l’envers Smile

La Prochaine fois qu’un client vous diras qu’il a plus confiance en Gmail qu’en Office365, envoyez lui de la lecture de ma part…

 

Pierre.

Publié dans Azure, Certification, Cloud, Formation, Security, Storage | Laisser un commentaire

WSUS planté? Rappel de la procédure….


Bon, plusieurs clients remontent des problèmes sur leurs WSUS suite à l’installation des MAJ WSUS de Mai/Juin…

cela concerne principalement https://support.microsoft.com/fr-fr/kb/3159706

Pour Rappel, Microsoft avait publié les instructions suivantes sur leur site accompagnant le KB mais bon…les voila encore une fois, on ne sait jamaisSmile:

 

Étapes manuelles requises pour terminer l’installation de cette mise à jour

  1. Ouvrir une fenêtre d’invite de commandes avec élévation de privilèges et exécutez la commande suivante (la casse, supposons que « C », que le volume système) :
    "C:\Program Files\Update Services\Tools\wsusutil.exe" postinstall /servicing
  2. Sélectionnez La fonction Activation HTTP sous .NET Framework 4.5 fonctionnalités dans l’Assistant Ajouter des rôles serveur gestionnaire et les fonctionnalités.
    Fonction activation HTTP
  3. Redémarrez le service WSUS.

Si SSL est activé sur le serveur WSUS

  1. Attribuer la propriété du fichier Web.Config au groupe Administrateurs (exécuter à une invite de commandes avec élévation de privilèges) :
    takeown /f web.config /aicacls "C:\Program Files\Update Services\WebServices\ClientWebService\Web.config" /grant administrators:f
  2. Recherchez le fichier Web.Config dans le chemin suivant :

    C:\Program Files\Update Services\WebServices\ClientWebService\Web.Config

  3. Apportez les modifications suivantes dans le fichier.
        <services>
              <service
                    name="Microsoft.UpdateServices.Internal.Client"
                    behaviorConfiguration="ClientWebServiceBehaviour">
                   <!-- 
                      These 4 endpoint bindings are required for supporting both http and https
                    -->
                    <endpoint address=""
                            binding="basicHttpBinding"
                            bindingConfiguration="SSL"
                            contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                    <endpoint address="secured"
                            binding="basicHttpBinding"
                            bindingConfiguration="SSL"
                            contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                   <endpoint address=""
                            binding="basicHttpBinding"
                            bindingConfiguration="ClientWebServiceBinding"
                            contract="Microsoft.UpdateServices.Internal.IClientWebService" />
                    <endpoint address="secured"
                            binding="basicHttpBinding" 
                            bindingConfiguration="ClientWebServiceBinding"
                            contract="Microsoft.UpdateServices.Internal.IClientWebService" />
              </service>
        </services>
  4. Remarque
    </bindings>
    <serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
    </system.serviceModel>

et après cela un bon redémarrage, et ça repart nickel!

@+

 

Pierre

Publié dans Windows10, WSUS | Tagué , , , , , , | Laisser un commentaire

NEW: Update 1606 for System Center Configuration Manager


Et encore une Smile

Once again, we’re pleased to announce that we’ve released a new version of our System Center Configuration Manager current branch (1606) that includes some great new features and product enhancements.

Looking back at the last 7 months, we’re encouraged by the positive response and momentum we’ve seen with our new current branch model; we now have over 16,000 organizations managing 30 million devices with Configuration Manager version 1511 or later. While we’re thrilled about the adoption we’ve seen, the real point of pride for our team rests in the fact that our quality and reliability have remained so high through this monumental shift. Incredibly, we haven’t seen any increase in the number of support incidents since launching our current branch model! Read more about the reasons behind our current branch success here.

As we release 1606, we’re optimistic that this winning streak will continue. Thanks to our active technical preview community, the 1606 update takes into account feedback and usage data we’ve gathered from customers who have installed and road tested our monthly technical previews over the last few months. It’s also been tested at scale — by real customers, in real production environments — with great success. As of today we have over 1 million devices being managed by the Configuration Manager 1606 update!

1606 is full of new features and enhancements in security and data protection, application management, content distribution, deployment and provisioning, end user experience, and includes loads of new functionality for customers using Configuration Manager in hybrid mode with Microsoft Intune. This is also the version that will bring support for the Windows 10 Anniversary update. Here’s a small sample of what you’ll get when you upgrade:

  • Windows Information Protection (formerly EDP) features allow you to create and deploy information protection policy, including the ability to choose your protected apps and define your EDP-protection level.
  • Windows Defender Advanced Threat Protection features enable the ability to on-board and off-board Windows 10 clients to the cloud service and view agent health in the monitoring dashboard (requires a Windows Defender ATP tenant in Azure).
  • Windows Store for Business Integration allows you to manage and deploy applications purchased through the Windows Store for Business portal for both online and offline licensed apps.
  • Windows Hello for Business policies for domain-joined Windows 10 devices managed by the Configuration Manager client.

We’ve also added a number of popular User Voice items, including:

  • The addition of content status links in the admin console
  • The option of list view for applications in the Software Center
  • The ability to select multiple updates and simultaneously install them with the new Install Selected Updates button in the Software Center

For more details and to view the full list of new features in this update check out our What’s new in version 1606 of System Center Configuration Manager documentation on TechNet.

Note: As the update is rolled out globally in the coming weeks, it will be automatically downloaded and you will be notified when it is ready to install from the “Updates and Servicing” node in your Configuration Manager console. If you can’t wait to try these new features, this PowerShell script can be used to ensure that you are in the first wave of customers getting the update. By running this script on your central administration site or standalone primary site, you will see the update available in your console right away.

For assistance with the upgrade process please post your questions in the Site and Client Deployment forum. To provide feedback or report any issues with the functionality included in this release, please use Connect.  If there’s a new feature or enhancement you want us to consider including in future updates, please use the Configuration Manager UserVoice site.

Thank you,

The System Center Configuration Manager team

Additional resources:

Afficher l’article…

Publié dans System Center, vNext | Tagué , | Laisser un commentaire

Hotfixes de Juin et GPOs… Attention!


 

Un super article du team PFE sur les Mises à jour de juin et les potentielles retombées sur les GPOs (si vous filtrez par groupes et que vous avez enlevé “Authenticated Users”…attention!!!! Lisez attentivement l’article ci dessous: je connais au moins 3 de mes clients qui ont utilisé ou qui utilisent encore ce systeme là!!!!

ça peut faire mal Sad smile

Hi folks. From Orlando, Florida, Sean Greenbaum here with some news about a recent set of security patches released on June 14, 2016. If you’re reading this, chances are you are having group policy issues, or you heard this patch will cause you to have issues and you want to get ahead of it. So, without further ado.

What did I miss.

We released new security patches for all currently supported Operating Systems. Among those patches was this one: MS 16-072, which is also referenced as KB 3163622. OS Specific articles are released as 3159398, 3163017, 3163018, and 3163016.

KB 3159398 – Vista, 2008, 7, 2008 R2, 2012, 8.1, 2012 R2
KB 3163017 – Windows 10 TH1
KB 3163018 – Windows 10 TH2 and Server 2016 TP4
KB 3163016 – Server 2016 TP5

After applying the appropriate patch to your systems, User group policies are retrieved from SYSVOL differently than before. Prior to the update, domain joined computers used the user’s security context to make the connection and retrieve the policies. After the update is applied, domain joined computers will now retrieve all policies using the computer security context. The users that get the policy is still controlled by the policy scope just like before. The only change is the computer is getting the policy for the user.

For group policies with the default permissions, this isn’t an issue. By default, “Authenticated Users” has Read permissions to all group policies when they are created.

But, why did you do that?

Well, it’s complicated. Insiders tell me (and by insiders I mean the very first link I supplied you with above) that this was done to prevent a possible Man-in-the-middle (MiTM) attack between the PC and the DC. Using the computer account helps mitigate this by enforcing the use of Kerberos.

Learn something new

Before I go too far, let’s make something clear. There is a difference between Group Policy scope and Group Policy permissions. The Scope is who can apply the GPO. The permissions control who can read, write, delete, or modify the permissions of a policy. These permissions are stored on the delegation tab of each policy. We are going to be focusing the rest of this article on the Delegation tab.

Let’s also make something else clear. For a policy that is scoped to Computer accounts, there is no functional change. In order for the computer to apply the policy, it needs read and apply permissions to the policy. By scoping a policy to apply to a certain group, that group automatically gets Read permissions. This functionality has not changed at all.

But for User policies, the ones that are scoped to a subset of your users, that’s where the issue is. This is a fairly common configuration for user policies, so there is great potential for problems here.

A default GPO looks like this.

As long as “Authenticated Users” has Read permissions, group policy application will continue to work after applying MS16-072 / KB 3163622. That’s because Computers are “Authenticated Users” too. Therefore, the computer that this user is logging on to has read permissions to this GPO already through “Authenticated Users”.

GPOs can be scoped to apply to a smaller audience than “Authenticated Users”. What happens if I scope this GPO down to an AD security group (or individual users) instead of “Authenticated Users”?

On the Scope tab, you typically remove “Authenticated Users” and add your own users or security group(s), populate it with users and go about your day. Like so:

Back on the delegation tab you see this:

As you can see, your user account has read permissions to the GPO through the AD Group “User Group 1”, but “Authenticated Users” is gone. That’s no longer enough permission after installing MS16-072. Since the computer account is now used to retrieve the policy, it needs Read access to the policy in order to retrieve it from SYSVOL and hand it off to the user for processing. As you can see, your computer account isn’t a member of any of these default groups.

Since I want this policy to apply to this user regardless of what computer they log on to, I need to add either “Authenticated Users” or “Domain Computers” to be able to Read this GPO as well. Here I’ve added “Domain Computers”.

If you look closely here, you’ll see “Domain Computers” has Read permissions. “User Group 1” has “Read (from Security Filtering)” permissions. That’s how you can tell User Group 1 is security filtered to apply this GPO from the Scope tab, and Domain Computers just has Read and not Apply permissions.

You: Well great. Now I have to go through each GPO and add the computers to have Read permissions. Right?

Me: Yep.

You: Well, I have hundreds of group policies. That’s going to take forever. Is there a way I can do this quickly?

Me: Yes there is. PowerShell to the rescue.

…but first….

Decisions, Decisions

Here you have some options on how to proceed, and you have to make a decision on which strategy is the best for you. The official guidance from Microsoft is to ensure the computer accounts have “Read” access to the user policies you wish to have applied. This can be done several different ways.

Strategy 1: Add “Authenticated Users” to each of your user policies. This is certainly the easiest method as it ensures that all authenticated computers and user accounts can read the settings in the policies. This works regardless of what domain, forest or trust they come from, as long as the local domain is able to authenticate it. However, it does grant all user accounts the ability to read the policy (Note: Not apply the policy, just read the settings contained in it.)

Strategy 2: Add “Domain Computers” to each of your user policies. Using “Domain Computers” will grant all member computer object the ability to read the GPOs, without also including user accounts. It too isn’t without its gotchas though:

Note: By default, when a computer is joined to the domain, it is automatically added to the “Domain Computers” AD security group. If you manually manage the membership of this group, then it’s possible “Domain Computers” won’t have a complete membership of all of your computer accounts.

Note: Remember that “Domain Computers” is exactly that – the computers in your current domain. If you have multiple domains, or trusts, and if you cross link any GPOs across those boundaries, you will also need to add the other domains “Domain Computers” group to the policies as well.

Strategy 3: Use your own custom groups. If you would like to granulize exactly which computers the user policy is able to be applied to, you will want to have your own custom AD security groups populated with those computer accounts.

As my lab is a single forest, single domain with no trusts, I’ve chosen to use “Domain Computers” for the rest of this article. Any PowerShell code or step by step instructions are the same whether you use “Authenticated Users”, “Domain Computers” or your own custom groups. Simply replace any instance where I use “Domain Computers” with the group you are intending to use.

Ok, I’m ready. Let’s fix it.

Great. Now that you’ve chosen a strategy that works for you, let’s begin.

Option 1: The “Just fix it already” option

Very simple and straight forward. Get a list of all the GPOs in the domain, and add “Domain Computers” to have read permissions. This script doesn’t distinguish between user policies, computer policies, scoped, not scoped.

$gpos = get-gpo -all
foreach ($gpo in $gpos)
{
Set-GPPermissions -Name $gpo.DisplayName -PermissionLevel GpoRead -TargetName “Domain Computers” -TargetType Group
}

That’s it! You’ve just added the “Domain Computers” group for the current domain to have GPORead permissions on all your GPOs currently in the domain. If you have other domains and are cross linking GPOs to the other domains, don’t forget to add the “Domain Computers” groups for those domains as well.

Option 2: I want to be more detailed than that. Can I get a list of all the GPOs that need my attention?

Of course. In fact, our product group published this very fine script here. This script searches for GPOs that are missing the “Authenticated Users” permissions, and prompts you to automatically fix them. Looking at the code, you could easily adjust this to use “Domain Computers” or whatever group you find appropriate in your environment.

Option 3: I prefer the personal touch with my policies

That’s the same way I prefer my fresh home baked cookies. No machinery or automation here. Start from the Delegation tab of the policy. Click Add, find the group, and make sure the permissions are Read. Easy. Now do that for each user policy.

Option 4: AGPM! Wait, I have AGPM!

AGPM (Advanced Group Policy Management)

If you already use AGPM to manage your policies, you can use the Production Delegation tab in AGPM to update the security on any GPOs you deploy going forward. See the AGPM section below for details.

Ok I fixed it, so I’m done right?

Temporarily. Our group policy tools GPMC and AGPM will continue to create GPOs using the default permissions I showed at the beginning of this article. As you create new user GPOs, and you scope them to specific user groups, you’ll need to continue to remember to add the appropriate groups to those GPOs before it can be processed.

If you are using a 3rd party tool to create and manage your GPOs, you’ll want to reach out to that vendor to see how their product is affected and if any change is needed to your policy creation and deploy process.

Remember: If you didn’t use “Authenticated Users” and you add additional domains to your forest, and if you are cross-linking GPOs between domains in your forest (the GPO exists in Domain1 and is linked to OUs in Domain2), be sure to remember you will need to grant the new domains “Domain Computers” or your custom group to the policy before it will have access in the new domain.

Do you use Deny:Read permissions on some of your GPOs? Read this.

When you grant the computer the ability to Read the GPOs, if your user account is in a group that grants apply rights, and in a group that denies read rights, previous to MS16-072 the user would not get the policy. Since the Read is now done by the computer context, there is a possibility that the user will now get the GPO when that is not your intention.

To fix this, update the permissions on any GPO where you are doing Deny:Read to also include Deny:Apply.


Using AGPM? Look here for some important information

Once you’ve installed the patches for MS16-072, if you are using AGPM you’ll want to make some changes here as well.

First, very important, make sure you reimport your GPOs into the AGPM database. Trust me, do this. We’ve already received reports from customers that did NOT do this step, and it caused some serious problems when they went to deploy later. This makes sure we have the latest copy of the production GPOs. Do it. Right now. I’ll wait.

All reimported? Good.

Now that you’ve reimported your GPOs in AGPM, lets configure AGPM so that it knows of the new permissions and deploys the correct security settings going forward.

From the AGPM module, select the Production Delegation tab. We need to grant “Domain Computers” Read permissions.

Only grant Read permissions.

Confirm the settings.

Now that the delegation settings are correct, redeploy your GPOs. This will make sure the permissions apply. Select all the GPOs you need, right click and Deploy.

Boom. Victory! We see that “Domain Computers” is here, “User Group 1” is the group that is scoped to apply these settings, and “User Group 2” is the group we specifically Denied Read and Apply permissions earlier.


One more thing

We also released MS16-075 / KB 3161561 in June 2016 to patch some SMB items. SYSVOL and Netlogon use SMB. There have been reports of users getting Access Denied when trying to access \\domain.fqdn\sysvol or \\domain\sysvol.

If you are experiencing this error, the current workaround is to set the SmbServerNameHardeningLevel registry value to 0 on the DCs. It is not needed on the other servers. If you experience this issue on other DFS servers, see the KB for the updated workaround info for those servers. Specifics are detailed in the KB 3161561 article.

More Info

Our Directory Services team has also published information about this update on their blog. If you have any questions, be sure to check there too.

Until next time,

Sean Greenbaum

Premier Field Engineer, Secure Infrastructure

Afficher l’article…

Publié dans 2008R2, 2012R2, GPOs, Scripting, Security, vNext, Windows 7, Windows 8, Windows 8.1, Windows10 | Tagué , , , , , , , , , , , , , , , | Laisser un commentaire

Super article sur App Locker vs Malware!


Un très bon article sur App Locker, du  team PFE, par Paul Bergson …

Hello, Paul Bergson here with a discussion on Security in particular utilizing Microsoft’s AppLocker to help prevent the infection of Malware.

Ransomware has been getting a lot of attention. There have been several high profile attacks in the press over the past few months and Understanding the Risk is important. If people don’t understand the risk, changes won’t be made. To protect your enterprise, there are many steps for a Defense in Depth strategy to be taken. One of the recommended steps is to run a Whitelisting tool. Microsoft provides a built-in tool named AppLocker. Initially AppLocker was only available on enterprise level desktop versions but, starting with Windows 10, it is now available for all versions. AppLocker has always been available for all versions of Windows Server, with the exception of Server Core. For a complete list of version availability, see here.

AppLocker is an update from Software Restriction Policies feature (XP/2003) that was released with Windows 7/Server 2008 R2. AppLocker allows an administrator to define a set of rules to be applied against non-admins, which can be based on attributes from a file’s digital signature including the Publisher, Product or Version. You can also create rules from a hash of the file or a path to a set of files. Along with the Whitelist rules, exceptions can be defined to prevent certain files from being executed from the initial larger rule set. Exceptions are an important part of the rules; a non-admin shouldn’t need to modify system files or the registry. So when a rule is defined to allow “Everyone” to execute all files located in the %WinDir% folder an exception should be made to block applications used to managed the operating system (Registry Editor for example).

The default NTFS permissions grant a user Read/Write permission to their workspace, as well as all “Authenticated Users” have Read/Write permissions to %WinDir%/Temp (see diagram below). Malware authors take advantage of this and other writable areas within the operating system to load and execute their malware. If NTFS permissions allow the storage and Anti-Virus doesn’t block the malware from executing the software, then the user has been compromised. AppLocker’s role in the Defense in Depth strategy is to prevent the execution of software from a non-admin’s writable workspace.

You will notice I don’t use the term user, but instead refer to the standard desktop user as a “Non-Admin”. One of the most important steps in the Defense in Depth strategy is to only provide your users with the permissions that are needed. AppLocker can be easily bypassed if a user is a member of the local administrators group. Therefore it is recommended to remove all desktop users from the local administrators group.

AppLocker has default rules right out of the box, but these rules are just a starting point, not the end point. With the understanding that for AppLocker to be an effective tool, the administrator needs to know what folders the non-admins have both execute and write permissions on. This is the key point, since if a non-admin can’t save to an executable location, then there won’t be an opportunity for malware to be run on the system.

Planning a roll out is probably the most important step in an AppLocker delivery. To enforce a single set of the rules across the enterprise is not a reasonable task. Departments within a company will each have their own set of applications that they need to run and rules for one department might not work for another. The installation of applications will create new files and folders that will need to be defined and managed, since the creation of these new folders might grant a user write capability that could be then become a dropping point for malware. A task the administrator will want to do, is create a script to read the folders on the non-admin’s system to find where they have execution capabilities (Program Files and Windows for example).

There are documents on the planning and management of AppLocker (below), but the non-admin’s workspace will change over time, so to ensure that these changes are included in AppLocker’s rule set it is important to understand what and where these writable folders exist.

· Microsoft’s Torkington design guide

· National Security Agencies “Application Whitelisting Using Microsoft AppLocker”

o Acceptance of a certificate required, so hyperlink was not included

· National Security Agencies “AppLocker-Guidance” on GitHub

· United Kingdom’s CESG “End User Devices Security Guidance: Windows 10

· Australia’s DoD “Implementing Application Whitelisting

· New Zealand’s NCSC “Application Whitelisting with Microsoft AppLocker

This blog doesn’t define how to configure the AppLocker rules themselves, several of the documents above do an outstanding job of this.

Once AppLocker has been applied, it is important to monitor the effectiveness of the rules. The Windows Event Logs provide great information on this.

In the initial roll out of AppLocker, it is first recommended to place the rule set in “Audit Only” mode. By using auditing, you can then evaluate the rules you have defined against what is actually occurring. The Event Id’s used by AppLocker range from 8000-8027. For a complete list of what each event is see here. To read through a single Event log for missed applications is ok, but if the rules are going to be applied against 50 non-admin desktops, the review would be daunting. That is where another free tool from Microsoft comes into play, Windows Event Forwarding (WEF).

WEF allows an administrator the ability to define an Event Log to be filtered by a defined set of criteria including a range of events with the results forwarded to a collector. An enterprise can use Group Policy to define to the clients where to find the WEF “Collector”. The Collector will then define what log and the events it will aggregate for the clients.

Since we already have a great a series of TechNet Wikis on this subject, I won’t be going into it. Not only does this Wiki cover WEF configuration, it goes into details on uses for WEF to help in Malware detection.

A quick look at how to configure a policy

Whether you want to use a local or domain policy the process to edit it is the same. Open up the Computer Policy and drill down to – Computer Configuration \ Policies \ Windows Settings \ Security Settings \ Application Control Policies \ AppLocker.

From here there is the ability to enable rule sets by selecting the properties of the AppLocker icon.

From the properties page the rules can be “Enforced” or “Audited”.

When you are building a new rule set it is recommended that you start with “Audit only” and review the client Event Log to ensure that what you had expected to be allowed to be run…

… or blocked was as expected.

To define the rules from one of the four (Five with DLL) rules sets, you just right click on one and a context sensitive menu will pop-up.

From here you can either “Create a Default Rules” set, “Automatically Generate Rules” or “Create New Rule”. I will briefly cover how to create default rules and creating a new rule.

Each rule set has a default set of rules.

For example: AppLocker defines executable rules as any files with the .exe and .com extensions that are associated with an application.

Because all of the default rules for the executable rule collection are based on folder paths, all files under those paths will be allowed. The following table lists the default rules that are available for the executable rule collection.

Purpose

Name

User

Rule condition type

Allow members of the local Administrators group access to run all executable files

(Default Rule) All files

BUILTIN\Administrators

Path: *

Allow all users to run executable files in the Windows folder

(Default Rule) All files located in the Windows folder

Everyone

Path: %windir%\*

Allow all users to run executable files in the Program Files folder

(Default Rule) All files located in the Program Files folder

Everyone

Path: %programfiles%\*

For complete details on “Default Rules” for each of the rule sets, please see:
https://technet.microsoft.com/en-us/library/ee460941(v=ws.11).aspx

If you want to Create a new rule you can define it as “Allow” (Whitelist) or “Deny” (Blacklist). By Whitelisting only certain files to be executed you are implicitly denying all others, which is the recommended strategy. As with any rule within AppLocker you can define exceptions.

Take for example I have a test lab that I want to allow “Everyone” to install “Security Compliance Manager” that will be pushed to “C:\SCM”.

The option “Create New Rule” was selected.

The option to use the “Publisher” will be the selected method.

I want to ensure as the administrator only “Version 3.0.60.0” is permitted to be run (Installed in this instance). By using the slider the control of the application ca be adjusted from Version, File name, Product name, Publisher or Any publisher.

Finally, the name of the new rule is entered and it can then be created.

Once you have your rules defined, you will then want to link the group policy to a test group of clients, remember to start in “Audit Only” mode. Linking and managing group policy is beyond the scope of this blog.

I hope I have helped educate you on some of the capabilities of AppLocker and, although it has been around for quite some time, I think it has been over-looked. With the uptick in Ransomware and other malware activity, administrators are giving it a second look since it can help you stop the proliferation of malware within your enterprise.

Afficher l’article…

Publié dans Applocker, Security | Laisser un commentaire

Posez vos questions en Live au Team ConfigMgr!


Vous avez des questions sur SCCM? Ils ont les réponses, alors notez la date et foncez, c’est l’occasion ou jamais de déballer toutes les incertitudes, questions et problèmes rencontrés… y’a pas plus efficace que de demander à la personne qui conçoit et code le produit!!!

 

 

When: June 29, 2016, 1:00 – 5:00 PM PST

Where: www.reddit.com/r/sccm

Did you know the Configuration Manager team boasts one of the most active and dedicated user communities within Microsoft? Our community consistently inspires us to deliver the best PC management experience available. We’re always looking for new ways to interact with you, which is why we’re excited to announce a live Ask Me Anything event that we’ll be hosting on reddit.com/r/sccm on June 29, from 1:00 – 5:00 PM PST.  

An Ask Me Anything event is a live Q&A forum, where the entire Configuration Manager engineering team will be available to answer your questions about features new and old. That’s four hours of live chat time with the ConfigMgr team! And when we say ask us anything, we mean it. We’ll chat about everything from the upcoming 1606 release to the esoteric SMS 4.0. Bring ‘em on!

All team responses will be from “TheConfigMgrTeam.”

Spread the word! If we have a strong turnout and we like this format, we’re confident we can convince @djammmer to host a live Q&A for every release. If you can’t make it, we’d still love to hear from you. Post your question in the Comments section, and check back for responses.  

Mark your calendars. We’re looking forward to a great discussion!

Additional resources:

Afficher l’article…

Publié dans Deployment, Event, System Center, vNext | Laisser un commentaire