Simple and secure by Design but Business compliant [Benoît SAUTIERE / MVP]

Simple, yes, Secure Maybe, by design for sure, Business compliant always

Common Tasks

Recent Posts

Tags

Community

Email Notifications

Blogs

Archives

Un portail SCSM alternatif

Avec l’arrivée de Windows Azure Pack, on peut dire que le portail SCSM a pris un coup de vieux. Ca fait quelques temps que même Microsoft Azure a abandonné Silverlight pour une interface plus au gout du jour. C’est le problème de la majorité des solutions d’ITSM. C’est conçu pour les IT donc l’esthétique n’est pas le premier critère Sourire. Par contre, le premier utilisateur c’est bien l’utilisateur final.

 

En lisant le billet Windows Azure Pack: GridPro – Installation and Overview, j’y ait vu une solution “temporaire”. GridPro est une extension proposée depuis le portail WAP. Autant dire tout de suite que ça a un autre look maintenant :

View1

C’est une approche intéressante car on peut utiliser le portail WAP comme nouveau portail pour une infrastructure Service Manager existante et les services qu’elle propose. L’intéressant, c’est qu’on peut rapidement tester presque toutes les fonctionnalités avec la version gratuite.

Comparaison

 

Je dis bien que c’est une solution “temporaire” car il y a bien des domaines dans lesquels le portail SCSM reste loin devant. Rien que l’aspect multi-langue, ça pèse lourd.

 

Voila une alternative intéressante à mettre en face des produits de substitution tels que ceux proposés par Cireson qui sont fortement intégrés à SCSM.

 

BenoîtS – Simple and Secure by design but Business compliant

Petit debug de Service Manager 2012

Cela faisait quelques temps que j’avais pas redémarré ma plateforme Cloud privée basée sur le Cloud Services Process Pack. Après avoir installé les mises à jour, j’ai constaté quelques problèmes mais j’arrivais pas à mettre le doigt dessus.

 

Premièrement ma console Service Manager était bien capable de se connecter au Management group mais étrangement, il n’était plus possible de se connecter au Datawarehouse. La lecture du journal “Operations manager” confirme cela mais sans donner plus d’information. Pourtant, on parle de de temps, timeout, …

0

 

Pourtant, sur le Datawarehouse, tous semble bien opérationnel. Après, j’ai constaté un problème en relation avec SCSM lors de l’exécution d’un Runbook Orchestrator qui utilisait l’Integration Pack de Service Manager :

1

 

A la lecture du journal détaillé de l’activité, je constate la présence du même code erreur que sur ma console SCSM.

2

 

Et effectivement, lorsque j’ai tenté de vérifier le bon fonctionnement de l’Integration Pack dans la console Orchestrator, il y a bien un problème.

 

Au final, j’ai passé par mal de temps sur le problème, jusqu’à me rendre compte que ma machine virtuelle SCSM n’était pas à la même heure que les autres et pour cause, suite au changement d’heure, elle s’est mise à l’heure au contraire de toutes les autres pour lesquels j’avais désactivé la fonctionnalité des le services d’intégration.

 

BenoîtS – Simple and secure by Design but Business compliant

DirectAccess remote management from Jedi knight to master seating at the Jedi council

DirectAccess remote management from Jedi knight to master seating at the Jedi council

Let’s continue our learning. Master Yoda did not deserve you the rank of master. You still have much more to learn about the power of DirectAccess. Let’s see what aspects of the force you have to improve your skills. Have a seat young Jedi. Time for master Yoda to reveal you last secrets of the DirectAccess force. Show me how you master IPSEC.

clip_image002[7]

IPv6 Filtering at protocol level on DirectAccess client-side is not a choice for a DirectAccess Jedi Master. We are sure that communication is secure because it pass through the tunnel. But what would happen if an attacker understand your solution? With a simple network trace any attacker could easily recognize an ISATAP address structure (5EFE block). It would be easy to build an ISATAP router providing the same ISATAP prefix and bypass your IPV6 filtering based security. OK that’s the paranoid-mode point of view of an IT security guy. But as a Master of DirectAccess you must be able to face to the dark-side (from paranoid security guy point of view, only old legacy technologies respond to the new security challenge of tomorrow. For them NAT and port filtering represent the only answer).

To deserve the rank of DirectAccess Master you must prove your knowledge of the IPSEC force. It's not the dark-side of the DirectAccess force. Let's review some IPSEC basic:

  • IPSEC tunnel
  • IPSEC transport

IPSEC tunnels are used to secure communications between two networks through network equipment establishing a secure communication tunnel. Authentication header and payload are protected (AH+ESP). IPSEC tunnels are used by DirectAccess clients to connect to the DirectAccess gateway.

IPSEC transports are used to secure communications between two computers by establishing a secure communication transport (ESP only). It sound to be the same as IPSEC tunnels, except only payload it protected. Most of Jedi apprentices ignore the fourth step of a DirectAccess configuration:

clip_image004

It’s not the dark-side of the DirectAccess force. Dark-side is when you start customizing DirectAccess tunnels. Don’t even think about that! In DirectAccess, IPSEC transports can be used to extend authentication to a selected set of resources located on internal network.

clip_image005

Selected application servers mean IPv6 address are used as a criteria for the IPSEC transport. Providing end-to-end authentication and encryption between a DirectAccess client connected on Internet and a host located on internal network require good knowledge of the ISATAP. Fell the force around you Jedi knight and master the end-to-end authentication and encryption to secure your remote management.

 

At the source of the remote management

clip_image007

To become a DirectAccess master Jedi, you must overcome IPSEC transports and show you know what is behind the wizard. Objective is to isolate RDP protocol in an authenticated transport IPSEC. If we have an IPSEC transport, we must configure both side with matching parameters. Let’s start with the source of the traffic with the tunnel-definition on helpdesk computers.

 

We are talking of IPSEC, so unsheathe your light saber (Windows Firewall with Advanced security), select the “Connection Security Rules” node and select Isolation rule type. It seems to match to our need.

clip_image009

IPSEC transport means authentication. On this side of the transport, we’ll chose to request authentication for both inbound and outbound traffic but not enforce. Why master? Maybe your helpdesk is IPv6 capable and configured for ISATAP but I’m not sure the rest of your internal network support IPv6 and for sure we don’t have IPSEC generalized on LAN.

clip_image010

But what authentication? The default choice would lead to use IPSEC tunnels configuration provided for DirectAccess. If you think you deserve the rank of master, no other choice than “advanced”. Show you skills Jedi knight.

clip_image011

And what skills. We’ll be using a combination of computer certificate delivered to the helpdesk computers and user Kerberos as credentials.

clip_image012

With this choice, remote management will only be possible if initiated from clearly identified computer having a certificate and helpdesk user security context. Because helpdesk computer is located on LAN, there is no need to apply this connection security rule on private or public locations. If this computer is also a DirectAccess client, remote management will be impossible if connected on Internet (think of the paranoid IT security guy. What a shock it would be for him to discover that we can establish secure communication between DirectAccess clients located on Internet).

clip_image013

A connection security rule need a name. ISOLATION perfectly fit to our case.

clip_image014

Isolation yes but for what protocol? By default any protocol for witch the rule match the required conditions. To keep the case simple we’ll keep the default configuration (remember previous blog post, we discovered TCP/UDP port for RDP). Talking of condition we are. So what condition could we applied on the source-side? A good criteria would be DirectAccess clients connected on Internet. But how can we express it in IPv6? Because my DirectAccess infrastructure is not directly connected to Internet, IPHTTPS is the only IPV6 transition protocol (otherwise Teredo and 6to4 must be added). Let’s have a look at the ClientIpv6Prefix on the DirectAccess gateway with a simple Jedi trick: (Get-DaServer).ClientIpv6Prefix

clip_image016

With this we cover all DirectAccess clients connected on Internet. We just have to configure this IPv6 prefix as remote endpoint (from the helpdesk computer point of view) in the connection security rule. Question master. Why a /56 prefix and not /64. Good question Jedi Knight but even a master must keep some of his Jedi master tricks for another lesson. Just remember your UAG times, …

clip_image018

Now it’s time to move to the DirectAccess client-side of the IPSEC transport and setup a connection security rule that match the criteria.

To the DirectAccess client

clip_image020

If we have a transport IPSEC on one-side we must have a corresponding one on DirectAccess client-side. Its configuration is not identical point to point, but enough to allow transport authentication negotiation.

 

 

On the DirectAccess client-side, we should also have chosen the isolation mode (IPSEC transport).

clip_image021

This time authentication is no longer a wish but an order for incoming network flow and just a request for outgoing network flow. We don’t need extra security to access internal resources (the inception concept: IPSEC transport encapsulated in IPSEC tunnels included in IPHTTPS tunnel. A special one for paranoid-mode It security guy).

clip_image022

Here again me must configure authentication option. If they match on both sides, IPSEC transport will establish a secure communication. So it’s again an advanced configuration.

clip_image023

Because we have a certificate on the DirectAccess client why would not use it to prove we are a DirectAccess client (Kerberos Proxy mode is for padawan).

clip_image024

Because the connection security rule should only applied when connected on Internet, there is no need to keep the domain location (the opposite configuration of the helpdesk computer).

clip_image025

At last we need a name too. To make it simple, I keep the same.

clip_image026

IPSEC transport is almost operational, we just need to adapt the rule with a criteria that identify helpdesk computers connected on LAN. ISATAP prefix was designed for that. No need to apply this extra security to access internal resources.

clip_image028

But wait master, why do not apply the “fdca:abab:4a12:1::/64” prefix as provided by the ISATAP router? That’s a Jedi master trick. If you do so, you will have a connection security rule that enforce an IPSEC tunnel for that destination and an exception for the same IPV6 prefix. It’s an authentication exception rule configured with DirectAccess that say “no extra security needed to access resources depending on internal ISATAP prefix”.

clip_image030

This rule will override our rule. So my master Jedi trick is to add extra bit to the prefix. “Fdca:abab:4a12:1:0:5EFE:0:0:0:0/72” will be precise enough to have our isolation rule applied.

 

Master Yoda am’I deserved the rank of master?

There is a final test for that Jedi. Prove me your solution is now secure. Show me the IPSEC transport securing your DirectAccess Remote Management scenario. Easy it is master. Just have a look at the main mode security association, we can see an additional one coming from an ISATAP address when we launch the RDP connection. With a simple Jedi PowerShell trick, we can see the IPSEC transport main mode negotiated with our ISATAP client.

clip_image032

And this old Jedi master MS-DOS trick prove that RDP connection is established with IPv6, so RDP pass through the IPSEC transport rule.

clip_image034

We deserve you the rank of master but you won’t seat at the Jedi council.

clip_image036

Hurry you are Jedi. So hurry that you ignore one Jedi master trick you can use. IPSEC transport force is inside all protocols in your Windows Firewall with Advanced Security console.

Is that unfair? Securing IPv6 network flow is excellent but what would happen if we try to reach your DirectAccess client with IPv4. Isolation rule will not match but the RDP layer will respond to the request. You just missed a simple checkbox to enforce secured connection to be used for that protocol.

clip_image038

Now your remote management DirectAccess scenario is secure. Even a master still have to learn. If you trust in DirectAccess force, never forget to secure your remote management and never fall to the dark-side of DirectAccess.

BenoîtS – Simple and Secure by Design but Business compliant

Even an excellent DirectAccess feature can fail

No, DirectAccess is not a failure at all. But back to the UAG times, customers were expecting real-time monitoring of users access and resources previously accessed. Since Windows Server 2012 we have this feature (reporting) with enough detail to fill up databases :

RAMCONSOLE

So much details that the Remote Access Management service keep in memory. That used to lead to a memory leak until service was restarted. Microsoft issued a patch for Windows Server 2012 : KB2895930 - Remote Access Management leaks memory when a VPN or Direct Access connection is used in Windows Server 2012 to address this issue.

 

BenoîtS – Simple and Secure by Design but Business compliant

DirectAccess for everyone

By default, DirectAccess is only eligible to Enterprise edition of Windows. This licensing limitation did not help us during pre-sales of DirectAccess projects. It seems that Microsoft heard customers feedback and introduce some changes in it’s licensing agreements. 

Since the first of march 2014, customers will be able to buy Windows 8 Enterprise edition without Software Assurance (as licensing details of each contracts are complex, please review your software licenses conditions for the small lines). Now there is on reason to do not deploy DirectAccess.

 

BenoîtS – Simple and Secure by Design but business compliant

DirectAccess remote management, from Padawan to Jedi Knight

It's been a long time I did not publish something in the DirectAccess Challenge series. Let's do a deep dive in DirectAccess remote Management scenario. Be a Jedi Knight and use The DirectAccess force.

jedi32

But wait. As master Yoda used to say “Long is the path to become a Jedi master of the DirectAccess". Let's start your learning.

 

Become my Padawan

Remote Management is one of the top feature of DirectAccess. By default a DirectAccess client is able to reach internal resources such as SCCM server but the contrary is much more difficult as it requires an IPv6 connectivity from end to end. Since UAG 2010, NAT64/DNS64 feature was acting as a gateway between the IPv6 world and the IPv4 internal network, but this work only in that direction, its not bi-directional. When we think of remote management with DirectAccess, we always think of the DirectAccess for remote management only.

clip_image002

Interesting scenario but it's quite limited as we loose some cool features. In this blog post we'll see how to configure remote management with the default DirectAccess deployment scenario including security features. Time to improve you skills my Young apprentice.

 

Become a DirectAccess Apprentice

When a user using a DirectAccess client connected on Internet is requesting remote assistance (Windows remote Assistance or SCCM remote) to the helpdesk, it require an IPv6 network connectivity from the helpdesk computer to the DirectAccess client.

Even today, IPv6 is not so common (Force is not strong enough). The DirectAccess gateway act as a router for multiple IPv6 transition technologies, ISATAP is one of those. Microsoft does not recommend ISATAP global deployment. We only need it on a limited set of computers (helpdesk computers). I recommend the excellent Limiting ISATAP Services to DirectAccess Manage Out Clients from Jason Jones (a valuable former Forefront MVP) and DirectAccess Jedi master. In that strategy, we consider that only computers located on internal network (having an ISATAP address) can initiate remote management to DirectAccess clients connected on Internet. We trust them because of their location.

By default, our DirectAccess gateway act as an ISATAP router. A simple "Get-NetIsatapConfiguration" PowerShell command reveal the hostname of the ISATAP router. As it's not registered in our DNS, IPv6 capable systems cannot locate it and cannot generate their ISATAP address (DNS Global Query Block List).

clip_image003

If an ISATAP configuration is operational on our DirectAccess gateway we should be able to retrieve it's IPv6 address using a simple PowerShell command line.

clip_image004

In a single command we have all required information :

  • ISATAP link-local address
  • ISATAP unicast address
  • ISATAP prefix

For our scenario we'll need the last two. From an ISATAP client point of view, ISATAP router is an IPv4 reachable host that provide an ISATAP prefix to be used to generate an ISATAP address. ISATAP is enabled by default on all Microsoft operating systems since Windows Vista. By default operating systems try to resolve the ISATAP.<Your domain> hostname. With a simple PowerShell command we can reconfigure both state and router parameters and confirm we have an operational ISATAP interface.

clip_image005

Of course, it can be configured using group policy parameters. It's much more simple as we do not have a single helpdesk computer. You start learning well my apprentice.

clip_image006

And we can confirm, IPv6 network connectivity with a DirectAccess client connected on Internet work.

clip_image007

Let’s see that from the DirectAccess client side with a Message Analyzer trace. Don’t fear network traces my young apprentice. Use the force of Message Analyzer.

clip_image008

 

But a small reminder my young apprentice. If we see the ICMP message, it's because it's excluded of IPSEC tunnel because of default configuration provided to the DirectAccess client at firewall level:

clip_image009

Remember that ICMP messages are used by Teredo for signaling purpose my young apprentice. Easy, you think? Show me how you use the force and enable Remote Desktop.

clip_image010

And don't forget to enable the corresponding incoming firewall rule.

clip_image011

Feel the force my young apprentice. Wait a minute, we have now a TCP and UDP rule for RDP since Windows 8 & Windows Server 2012? It's a new capability included in RDP 8 to reduce networking overhead. RDP can display bandwidth-intensive content, such as video over high-latency networks (RDP Protocol).

In fact, it's much more complicated, if we extend the profile column, we discover that Domain & private firewall provides share the same firewall incoming rule. So they must be enabled too.

clip_image012

At this stage, RDP remote management from a IPv6 capable host to a DirectAccess client is operational. Do you think you can pass the tests and become a DirectAccess Jedi knight.

 

Are you ready to become a DirectAccess Jedi knight?

Becoming a DirectAccess Jedi knight is much more than mastering the Jedi light saber or IPv6. In standard DirectAccess deployment, we have two tunnels Infrastructure and user. If user is not connected RDP won't work. That's because our ISATAP client is not allowed to go through the infrastructure tunnel. Let's go back to the DirectAccess configuration side at the Infrastructure server setup.

clip_image013

We would add the hostname of our ISATAP enabled client in this interface. Watch-out young Jedi knight, your host must have a static IPv4 address or a DHCP reservation, otherwise it may not work for a long time.

clip_image014

At this stage, RDP would work once DirectAccess client can initiate a connection to the DirectAccess infrastructure, whatever a user is connected or not.

clip_image015

We are now sure that RDP network traffic always pass through IPSEC infrastructure tunnel. Time to fight the Sith Jedi knight

 

Fight the sith Jedi Knight

Never underestimate the power of the dark-side of the force Jedi knight. Are you sure it’s secure? Let's have a look at the Windows Firewall profile of my DirectAccess client with the "Get-NetConnectionProfile" PowerShell command :

clip_image016

In my case, it respond "Private". Do you understand? No? Remember the incoming firewall rules :

clip_image017

It's the same rule for Domain and Private network profile. So if a user select "private" when he connect his computer first time he connect his laptop at home, RDP is available. But the rule apply both to IPv4 and IPv6! So a user connected on the same network can initiate RDP to the DirectAccess client. We have multiple solution to address this issue your Jedi knight :

  • Rewrite default incoming firewall rule
  • Force tunneling
  • Enforce public network profile
  • IPv6 Filtering
  • Try a Jedi mind trick

 

Resist to temptation of rewriting default incoming firewall rule. It’s the dark side of the force. Force tunneling is an option, but not realistic at all. It’s a non-choice from my point of view. Blocking the "private network profile" is a better option and it enhance DirectAccess user experience. The following group policy option allow to enforce public network location for any unidentified networks.

clip_image018

IPv6 filtering will be the easiest option. It rely on Windows Firewall, more precisely on the incoming firewall rule filtering capability. We have the ISATAP prefix we discussed earlier, we can use it for filtering purpose and configure the incoming rules composing the "Remote Desktop" group as illustrated bellow.

clip_image019

Just remember to configure each protocol to enforce IPv6 filtering using the ISATAP prefix. That's a better option because we enforce IPv6 usage for RDP usage. Could we do better and deserve the rank of Jedi Master of the DirectAccess?

 

We cant deserve you the rank of master!

There are some Jedi mind tricks that could be used to provide a better approach that IPv6 filtering. But it will be for another blog post. Trust in network traces, IPv6, IPSEC and the DirectAccess force will be with you. Master Yoda will be coming soon to lean you that special Jedi mind trick.

arme_sabre_yoda_02

 

BenoîtS – Simple and Secure by Design but Business compliant

DirectAccess Client troubleshooter

Some people at Microsoft deserves their stock of Kudos. It’s not always easy to troubleshoot DirectAccess problems. Most of the time they come from a problem of misconfiguration. We wan search for a long time if we do not have access to the computer. As we cannot diagnose problems like Doctor House do, we need to rely on a strong methodology.

 

Problem, DirectAccess is composed of multiple building Lego blocks (Ipv6 is only a part of). If a strong methodology is a good starting point, a good diagnostic tool is also appreciated. until now we were only able to rely on built-in NCA/DAC capabilities. For sure it help a lot, but it’s long to parse raw data. To help us we have now the DirectAccess client troubleshooter. It’s :

  • Small to download
  • Only rely on Dot.Net Framework 4
  • Work from Windows 7 to Windows 8.1

And may help you to save a lot of time : SNAGHTML5011fb6

 

In my case, I now that I have multiple problems (even if my DirectAccess client operate like a charm). I hope we will have updated version to diagnose more cases.

 

BenoîtS – Simple and Secure by design but Business compliant

Mise en œuvre de SQL Server avec les produits de la gamme System Center c’est si simple

Lorsqu’on installe un des produits de la gamme System Center avant même son installation se pose un grand nombre de questions autour de SQL Server. Un MVP a eu l’idée intelligente de consolider toutes les informations nécessaires à la mise en œuvre de SQL Server pour chaque scénario de déploiement supporté à ce jour dans un seul document. Il y a même du Powershell pour industrialiser, alors autant ne pas s’en priver. Le guide contient quelles informations essentielles comme celle-ci pour SCOM que j’ignorais totalement :

image

 

Bref, c’est un must à savoir pour éviter de devoir réinstaller un Cluster SQL.

 

BenoîtS – Simple and Secure by Design but Business compliant

ADCS CA private key location change (again)

That’s a tricky point that can lead to serious problems. How can you restore ADCS database if you do not have the private key of your Certificate Authority? Simple, it’s included in the System Sate Backup. That may be right in some situation. Let’s see that.

 

Yes but no

Since Windows 2008, backup location of your favorite ADCS is now stored in the "%systemdrive%\ProgramData\Microsoft\Crypto\Keys" folder witch one is accessible via "%systemdrive%\users\all users\microsoft\crypto\keys". By default, the buildin Windows backup solution does not include this folder in the System state backup. That’s the reason on this initial ADCS team blog post.

For this reason, it’s always recommanded to perform a manual backup of the ADCS key using the “CERTUTIL –BackupKey <Destination Folder>” and keep this information in a safe. This was the default behavior for Windows 2008 and Windows 2008 R2.

That was before Windows Server 2012

With Windows Server 2012 and Windows Server 2012 R2, Microsoft fixed that point. While reading the what’s new section of the Windows Server 2012 ADCS role, I discovered that Windows Server 2012 Windows backup tool is now able to backup the ADCS private key as a part of a System State backup. I also discovered that this behavior also apply to Windows Server 2008 / 2008 R2 with KB2603469. When Installed we can have the same behavior from Windows 2008 to Windows Server 2012 R2.

 

To be clear, a simple table :

Operating system

KB2603469 
applicable

KB2603469 
installed

Included in System State backup

Windows 2008

Yes

No

No

Windows 2008

Yes

Yes

Yes

Windows 2008 R2

Yes

No

No

Windows 2008 R2

Yes

Yes

Yes

Windows 2012

No

N/A

Yes

Windows 2012 R2

No

N/A

Yes

 

Some powershell stuff

of course, since Windows Server 2012, you can replace the old legacy CERTUTIL.EXE –BACKUPKEY command with the “Backup-CARoleService” powershell command.

BenoîtS – Simple and Secure by Design but Business compliant

DFSR Dirty Shutdown Recovery

Un sujet un peu “capilo-tracté” pour changer et un petit retour aux sources (Active Directory). Qu’est ce qui se passe au niveau DFSR lors d’un arrêt non planifié d’un contrôleur de domaine ou d’un serveur hébergeant le rôle DFS-R et participant à un groupe de réplication.

Pour rappel DFSR repose sur une base de données Jet qui va tracer tous les changements opérés sur les fichiers dépendant d’un replicated folder donné localisé sur un volume disque particulier. On comprend tout de suite que le bon fonctionnement de cette base de données est essentiel. Sans elle, DFSR n’est plus capable de répliquer les changements opérés localement ou de déterminer s’il doit prendre en comptes les mises à jour opérées sur les autre membres du groupe de réplication.

 

Avant c’était simple

DFSR a été introduit avec Windows 2003 mais réellement généralisé à partir de Windows Server 2008 où il était possible de basculer le SYSVOL vers DFSR avec l’utilitaire DFSRMIG.EXE. Depuis cette époque, lors d’un arrêt non planifié, on avait le message suivant dans le journal dédié à DFSR :

image

 

C’est clair, rien à faire, le système d’exploitation s’occupe de tout. Si le processus de recovery se passait bien, on avait un event 2214 :

image

 

ou 2216 dans le cas contraire :

image

Dans les deux cas, on n’avait rien à faire, DFSR s’occupait de tout. Mais ça c’était avant.

 

Mais c’était avant (2008 R2/2012)

Avec Windows Server 2012, Microsoft a considéré qu’il y avait un risque de perdre des données et que par défaut DFSR ne devait plus auto-réparer sa base de données.

image

 

L’event donne deux informations :

  • Premièrement, il faut que nous nous assurions de ne pas perdre de données lors de la remise en ligne, c’est de notre responsabilité
  • Deuxièmement, que la remise en ligne s’effectue à l’aide d’une ligne de commande qui doit être exécutée localement sur le serveur incriminé.

 

Cela devient problématique car en cas de crash d’un contrôleur de domaine, Active Directory est bien capable de revenir en ligne, le répertoire SYSVOL est bien partagé et visible par les utilisateur mais le contenu des GPO peut avoir été altéré et ne plus être cohérent avec les autres contrôleurs de domaine.

 

Comme Microsoft est cohérent, il a mis à disposition un correctif KB2663685 pour Windows 2008 R2 pour reproduire le mode de fonctionnement de Windows Server 2012. Tant que le correctif n’est pas généralisé sur tous les serveurs membre du groupe de réplication DFSR, le comportement du processus de recovery va donc varier. ce correctif permet aussi de configurer le comportement du processus de recovery avec la commande suivante :

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE/TRUE

 

Maintenant c’est subtil (2012 R2)

Comme c’était pas encore assez compliqué, on change encore. Il faut lire un billet décrivant les changements opérés sur DFSR dans Windows 2012 R2 pour le comprendre :

clip_image002

 

Il faut comprendre que Microsoft a mis à disposition une clé de registre pour configurer le comportement de DFSR dans le scénario du “Dirty shutdown” mais n’a pas réussi à démontrer qu’il y a réellement risque de perte de données. La racine DFS de domaine gui prend en charge la réplication de SYSVOL échappe au processus de “Dirty shutdown”. Seulement pour lui, le recovery redevient automatique. C’est une bonne nouvelle pour les administrateurs Active Directory qui n’ont plus à se soucier du “Dirty shutdown” sur les contrôleurs de domaine Windows Server 2012 R2 (uniquement).

 

Conclusion

J’avais bien annoncé que le sujet était “capilo-tracté”. Donc pour faire simple un petit tableau pour résumer la situation :

  Windows 2008 Windows 2008 R2 (sans KB2663685) Windows 2008 R2 (avec KB2663685) Windows 2012 Windows 2012 R2
Automatic Dirty shutdown recovery pour SYSVOL Oui Oui Non Étoile Non Étoile Oui

Étoile Non sauf reconfiguration avec WMIC

 

BenoîtS – Simple and secure by Design but business compliant

Changement dans la gamme Forefront

Nous attendions avec impatience les nouvelles Roadmap des solutions qui composent la gamme Forefront. Il est important de comprendre que Forefront, n’est pas un nom de produit mais un terme marketing lancé par Microsoft il y a maintenant 10 ans. Forefront n’est donc pas un produit, ni une équipe. Ainsi, les équipes de Forefront UAG ne sont pas les mêmes que Forefront FIM par exemple, même si parfois elles peuvent bien entendu collaborer ensemble.

L’année dernière, il a été annoncé l’arrêt de l’évolution majeure de la solution TMG. A cette même occasion, on y apprend que les solutions antimalwares prenaient une nouvelle orientation. Pour rappel voici l’annonce officielle : http://blogs.technet.com/b/server-cloud/archive/2012/09/12/important-changes-to-forefront-product-roadmaps.aspx

Sur cette fin d’année 2013, Microsoft nous annonce un nouveau changement majeur dans la gamme de produit Forefront : http://blogs.technet.com/b/server-cloud/archive/2013/12/17/important-changes-to-the-forefront-product-line.aspx. Le terme marketing Forefront est donc amené à disparaitre.

Concernant Microsoft Forefront Identity Manager 2010

Microsoft maintient son investissement dans le produit Identity Manager (FIM) avec l’annonce d’une prochaine version majeure, courant 2015. Les premières informations disponible à son sujet font état de :

  • La prise en charge des scénarios de type Hybride avec l’intégration avec Windows Azure Active Directory.
  • La gestion des accès et des utilisateurs
  • L’audit et la conformité
  • D’autres nouvelles fonctionnalités, notamment avec Azure, sont à venir

Il est à noter que le composant « DirSync » de FIM, est incontournable dans tous les projets Office 365 et autres scénarios Azure. Il permet de mettre en œuvre une synchronisation d’annuaire On-Premise vers Azure Active Directory (AAD) nécessaire pour Office 365. FIM est donc juste incontournable pour tous les projets nécessitant des synchronisations d’annuaire et de gestion des identités. Dans un contexte de sécurité, les principales attaques/vol d’identités viennent de la non-gestion (utilisateurs, groupes, permissions) des identités dans AD.

Ainsi la prochaine version de la solution de gestion des identités changera très certainement de nom, et perdra tout naturellement la dénomination « Forefront » dans son appellation marketing. Nous le découvrirons sous peu, et vous le partagerons dès que possible.

 

Concernant Microsoft Forefront UAG 2010

Microsoft a pris la décision d’arrêter ses investissements dans le produit Forefront Unified Access Gateway 2010. Le produit restera supporté par Microsoft jusqu’au 14 Avril 2015 pour la phase de support standard et s’arrêtera le 14 Avril 2020 pour la phase de support étendue. Les clients disposant d’un contrat de type « Software Assurance » à la date du 1er décembre 2013 seront en mesure de déployer de nouveaux serveurs et prendre en charge de nouveaux utilisateurs sans cout de licence additionnel.

Néanmoins, le produit peut continuer de publier des ressources de manière sécurisée et s’assurer que seuls les utilisateurs autorisés puissent y accéder. Microsoft a récemment mis à disposition le Service Pack 4. Ce dernier Service Pack, prend en charge la publication de services tel que SharePoint 2013 ou Exchange 2013. Il prend en compte les dernières versions des clients (Windows 8.x & Internet Explorer 11). En plus de quelques autres améliorations mineures, le SP4 permet aussi la prise en charge de RemoteApp et les autres services RDS de Windows 2012/2012R2.

Pour les clients disposant déjà d’une solution UAG dans votre SI, il n’est pas obligatoire de migrer rapidement vers une autre solution comme WAP. La flexibilité d’UAG, la mise à jour récente du SP4 et un support jusqu’en 2020 doit permettre de répondre encore longtemps à vos besoins actuels.

Il y a toujours une forte communauté autour de la solution UAG, animée par la présence de nombreux MVP et experts communautaires. Cela permet d’apporter un support continu à la solution UAG, même au-delà de 2020. Le forum à consulter est sur le site de Technet : http://social.technet.microsoft.com/Forums/forefront/en-US/home?forum=forefrontedgeiag

 

Rappel au sujet des accès VPN et DirectAccess dans UAG :

Cela a déjà été évoqué il y a un peu moins de deux ans, depuis la sortie de Windows 2012, Microsoft recommande de privilégier le rôle Unified Remote Access de Windows Server 2012/2012 R2 en lieu et place d’UAG pour implémenter DirectAccess. Microsoft n’apportera plus d’évolution à l’implémentation DirectAccess au sein de Foreront UAG 2010.

Les implémentations de DirectAccess réalisées sur UAG devront donc être migrées vers Windows 2012 R2. Avec la solution Unified Remote Access, il est également possible de faire du VPN PPTP, L2TP et SSTP tout en ayant DirectAccess.

 

Scénario de publication :

Windows 2012 R2 apporte un nouveau rôle nommé WAP (Web Application Proxy). Ce celui-ci permet de prendre en charge certains scénarios jusqu’alors assurés par Forefront UAG 2010. Le tableau-ci-dessous synthétise les fonctionnalités offertes par les deux solutions:

Scénario

Solution possible

Publication simple d’Exchange

WAP ou Forefront UAG

Publication simple de SharePoint

WAP ou Forefront UAG

Publication de Lync WebServices

WAP ou Forefront UAG

Publication Web simple

WAP ou Forefront UAG

Publication d’Exchange avec customisation

Forefront UAG

Publication de SharePoint avec customisation

Forefront UAG

Publication Web avancée

Forefront UAG

Prise en charge de la conformité des postes

Forefront UAG

Mise en œuvre d’un portail

Forefront UAG

Single-sign-on entre les applications publiées

Forefront UAG

Personnalisation avancée

Forefront UAG

BYOD

WAP

Fédération

WAP

Si la solution Forefront UAG est déjà existante dans un réseau il n’est pas nécessaire de migrer vers la solution WAP pour le moment, en effet cette dernière est une solution encore jeune avec certaines limite :

  • Ne propose à ce jour que des scénarios de mise en œuvre « Basiques »
  • Principalement basé sur une pré-authentification AD FS ou pass-through
  • La haute disponibilité se base que sur des répartiteurs de charge matérielle
  • La configuration se trouve stockée dans l’infrastructure AD FS
  • La translation d’URL possède des limitations

 

Voici quelques articles qui présentent comment réaliser la publication des services les plus courants :

En conclusion, la majorité des scénarios de publication courants que nous avions à disposition avec Forefront UAG sont aussi disponibles avec la fonctionnalité Web Application Proxy de Windows Server 2012 R2. A ce jour, la migration de Forefront UAG 2010 vers WAP ne peut être envisagée que pour les scénarios pour lesquels WAP propose le même niveau de fonctionnalité d’UAG.

Auteurs (un peu en retard cette fois) :

Posted: 01-25-2014 11:41 by Benoît SAUTIERE | with no comments
Filed under: , , ,
Les bonnes fondations pour un cloud public avec Azure

Ca commence à faire quelques temps que je “joue” avec certaines briques d’Azure, plus particulièrement les briques infrastructures (Non je ne vais pas rebasculer vers le coté obscur du développement).

 

Pour cela encore faut-il avoir de bonnes fondations. La première brique, c’est l’identité. C’est le premier sujet sur lequel j’ai passé pas mal de temps avant même les aspects réseau. Pour faciliter la pose de notre première brique, Microsoft a eu la bonne idée de livrer des tests labs guide. Les deux premiers sont disponibles :

Le premier a pour objectif de provisionner un annuaire Windows Azure AD avec les comptes (et mots de passe) avec le contenu de notre annuaire “On premise”. Le second permet lui la mise en œuvre de la brique “ADFS” et des scénarios de SSO. Comme quoi ADFS, ce n’est pas si compliqué.

 

A vos tenants, prêt, cloud

 

Benoits – Simple and Secure by Design but business compliant

Posted: 01-20-2014 21:26 by Benoît SAUTIERE | with no comments
Filed under: ,
Ne jetez pas les clés d’Orchestrator par la fenêtre

Comme déjà abordé dans ce précédent billet, la migration vers Orchestrator 2012 R2 peut réserver quelques surprises. Il en va de même pour la migration de la base de données qui y est associée. L’équipe produit vient de publier un billet concernant un problème de migration. La KB qui y est associée KB2920037 recommande de supprimer une clé de registre pour corriger le problème de licence rencontré.

Avant de se lancer dans cette migration (et se tirer une balle dans le pied), encore faut-il avoir pensé à exporté la SQL Server service master key avec la ligne de commande suivante :

Sqlcmd –Q”BACKUP SERVICE MASTER KEY TO FILE ='C:\BACKUP\MASTER_KEY.BAK' ENCRYPTION BY PASSWORD = 'password'” 

Il est vivement recommandé de sauvegarder cette clé avant de se lancer dans le processus de migration de la base de données. Sans elle, les données chiffrées qu’elle contient sont elles aussi perdues. Je pense par exemple aux mots de passe que l’on stocke dans les variables Orchestrator.

Si la sauvegarde de cette clé n’est pas encore faite, c’est le moment.

 

BenoîtS – Simple and Secure by Design but business compliant.

DirectAccess and Windows Remote Assistance

For those of us who deployed legacy DirectAccess clients (yes Windows 7 is a legacy operating system) with Windows Server 2012 based DirectAccess we encountered the problem of Windows Remote Assistance witch was not working. That sound strange because it was working when the DirectAccess clients was connected a legacy DirectAccess Infrastructure (Yes, Forefront UAG 2010 is a legacy DirectAccess platform).

 

The Following KB2912883, provide a hotfix for Windows 7. Technically, the root cause is located in the Windows Remote Assistance module witch did not recognize the new IPv6 prefix (FD00::/8) introduced with Windows Server 2012 based DirectAccess infrastructure.

 

So don’t forget this KB during your next DirectAccess migration project from UAG.

 

BenoîtS – Simple and Secure by Design

DirectAccess advanced troubleshooting tip

Let’s start this new year with a small post on DirectAccess (DirectAccess remain in my good resolutions to-to list for another year Sourire). So happy new year and wish you successful DirectAccess deployments.

 

When a DirectAccess client is not operational we have an option to collect logs. This feature is very useful because it generate an HTML file containing all required information for troubleshooting.

SNAGHTML44e8b8ec

In normal situations all required information are in this HTML file. But sometimes we need to investigate more (deep dive in DirectAccess troubleshooting). Have you ever seen that a CAB file is included in the automatically generated Email?

image

The process collect both static and interactive data. The second one is interesting because it’s based on ETL (Event Trace Log) available since Windows 7. This feature allow to generate trace for specific scenarios and one of them is very interesting among others :

SNAGHTML44f591ec

KB2859074 – DirectAccess Diagnostic document all information collected. And some of them were very useful for me during some DirectAccess deployments. Sometimes, relevant information included in theses logs may save you hours of painful troubleshooting.

 

BenoîtS – Simple and Secure by Design but Business compliant

More Posts Next page »