Archives mensuelles : janvier 2013

Cloud Services Process Pack sur SCSM 2012 SP1

Si comme moi vous vous êtes lancés dans la mise en œuvre d’une infrastructure Cloud Privé “sauce” Microsoft, vous avez commencé par le Private Cloud fast-track program. Après la lecture de ces documents, vous avez aussi renouvelé votre matériel voyant les 128 Go exigés en s’assurant de placer les instances SQL sur des disques hautes performances (a moins de vouloir consommer beaucoup de café froid ).

Passé ces premières étapes (douloureuses pour le portefeuille), vous vous êtres dis et si on travaillait avec le SP1 plutôt que la RTM. Pas de problème, on prend reprendre le même guide d’installation de Microsoft à quelques exceptions près :

  • SCVMM 2012 s’installe sur Windows Server 2012 (Cf Technet).
  • Le déploiement de SCVMM 2012 implique PowerShell 3.0, même pour la console
  • Le WAIK de Windows 7 doit être remplacé par le WAIK de Windows 8.
  • Microsoft SQL Server Analysis Management Objects sera celui de SQL Server 2012
  • Lors de l’importation des Management Pack de SCOM, les versions sont désormais plus récentes, cela facilite un peu les choses

C’est maintenant que le sport commence. Lorsqu’on commence l’installation du Cloud Services Process Pack sur le serveur SCSM, on obtient le résultat suivant :

INSTALLFAILURE

 

C’est étrange car si on suit le guide pas à pas, tout devrait fonctionner comme en RTM. C’est un problème qui peut se contourner si on retrouve le package Windows installer qui est derrière :

MSI

 

On pourrait dire que tout est fini, sauf que manque de bol, à un moment, il faudra que l’administrateur en charge de l’approbation des demandes de création de machines virtuelles approuve l’assignation de ressources.

ASSIGN0

 

Problème, impossible d’assigner un quelconque Cloud dans SCVMM. C’est comme si il était invisible.

ASSIGN1

 

Bizarre, cela fonctionnait très bien en RTM. Après quelques recherches, j’ai constaté que objets référencés dans SCVMM étaient bien importés à l’exception du Cloud. J’ai fini par comprendre en reprenant la création du connecteur SCVMM.

INFOVMM

 

Ca ressemblerait donc à un problème de Management pack. Pourtant, si j’ai bien suivi le guide d’installation, le management pack indiqué a bien été installé non?

image

 

Le problème, c’est la version du Management pack. Allons faire un tour du coté du connecteur SCOM CI.

SCOMCI

 

Si on clique sur le bouton Refresh, on va découvrir que certains Management Packs de SCOM ne sont pas importés dans SCSM et pour cause, c’est pas les mêmes versions.

MISSINGMP

 

Sur ma maquette, les versions concordent mais pourquoi?

REALVERSION

 

la raison est toute simple, au lieu d’utiliser la version proposée dans le Cloud Services Process Pack, j’ai utilisé celle disponible dans le répertoire d’installation de SCVMM 2012 SP1.

LOCATION

 

Une fois le Management Pack importé, on peut attendre une heure ou alors relancer le job de synchronisation MPSYNCJob et s’assurer que tous les Management packs nouvellement importés sont bien associés (il y a quelques dépendances, le pas à pas est vivement recommandé tout comme un bon café ).

RESUME

 

C’est presque fini. A ce stade, les management packs bloqués sont désormais accessibles dans le connecteur de synchronisation de SCOM. Encore faut-il bien sélectionner ceux-ci et sauvegarder la configuration avant de relancer une synchronisation.

RESELECT

 

Maintenant que le Management Pack de SCVMM 2012 de découverte est disponible dans SCSM, il devient possible de réaliser l’affectation des ressources.

ASSIGNCLOUDOK

 

Conclusion, avant de se lancer dans l’installation de SCOM/SCSM, il est impératif de disposer des bonnes versions de Management Pack. Sans cela, le problème illustré dans ce billet se reproduira pour d’autres produits.

 

Que le Cloud Privé soit avec vous.

 

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

Teredo Enterprise client side-effect

In normal condition, when a DirectAccess client is connected to corporate network, DirectAccess is not required and disable itself. In illustration bellow we can notice a Teredo Interface witch seems to be operational.

0

Technically speaking, yes Teredo is operational and we can notice that EnterpriseClient mode was enabled.

1

And technically DirectAccess is really disabled as illustrated bellow.

NRPTLAN

Default behavior of Teredo protocol it to disable itself when it detect corporate connectivity. So we should not have a Teredo interface on your client connected to corporate network.

Why?

Teredo is “configured in Enterprise Client mode”. According to the Forefront UAG team, configuring Teredo in Enterprise client mode can be considered as a good solution if your users are connecting from partners networks. In such scenarios, Teredo may detect partner corporate network and disable itself.

In normal condition, Teredo interface cannot initialize because it should not be able to reach the Internet-facing interface of your DirectAccess server. But in this scenario, this is not the case because Internet connectivity available on corporate Network does not block UDP 3544 network flow.

 

BenoîtS – Simple and Secure by Design

Windows Server 2012 DirectAccess with F5 BIG-IP white paper

When designing a highly available DirectAccess infrastructure, many customers choose to use their existing F5 BIG-IP appliances to provide network scalability and failover. With Forefront UAG 2010, F5 and Microsoft provided a deployment guide available here, including detailed information’s about BIG-IP configuration.

 

A new guide is available for Windows Server 2012 at this location. This guide cover all deployment scenarios available for DirectAccess with Windows Server 2012. But, do not expect to find detailed information covering your BIG-IP configuration. You will find most of theses information in the previous version .

 

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

DNS64 behavior change in Windows Server 2012

With Windows Server 2012, Microsoft no longer consider ISATAP as a requirement for DirectAccess deployment. With DirectAccess infrastructure based on Unified Access Gateway 2010, DNS64 return AAAA record if exists. With Windows Server 2012, this is no longer the default behavior. This change have no effect on default DirectAccess scenarios. It only impact Modified End-to-Edge scenario for Witch IPv6 connectivity is required. In my case, I was sure that my server have an IPv6 Address registered in DNS

0

 

I’ve also checked ISATAP interface configuration on my server. I was sure it was enabled.

1

 

After some research (Always perform an Update-Help command on your freshly installed Windows Server 2012, this help a lot ), I found why with a Get-NetDNSTransitionConfiguration command.

2

 

The “OnlySendAQuery” parameter manage how DNS64 respond to client. By default, It always return DNS64 generated addresses, never ISATAP /Natives addresses. To Change this behavior, just run change the value of this parameter to False with the following command :  Set-NetDNSTransitionConfiguration –OnlySendAQuery $True”

3

 

Why is it so important to have AAAA DNs records response? if you have a look at the “DirectAccessPolicy-ClientToAppServer” Connection Security rule (only present in Modified End-to-Edge scenario), you will find that each server included in the filtering group is identifier with it’s ISATAP addresses.

4

 

No need to restart your DirectAccess server. Behavior change is available to DirectAccess clients immediately unless DNS64 already present in cache. I can start working on Modified End-to-Edge scenario.

 

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

Microsoft Security Advisory 2798897

In early days of 2013, Microsoft published the Security advisory 2798897 concerning compromised certification authority. These certification authorities delivered fraudulent digital certificate that was recently used in a attack.

 

Microsoft updated his Certification Trust List to block this certification authority. For recent Operating systems (since Windows Vista), it’s an automatic process as described in KB2677070. If it’s an automatic process for recent operating systems, this it not the case for legacy operating systems such as Windows 2003.

 

Microsoft recommendation is to deploy this new certificate trust list on all systems to avoid phishing attacks, man-in-the-middle attacks.

 

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

Windows 2012 DirectAccess legacy client considerations

Let’s start this new year with a resolution : Correct previously published blog post including not accurate information (Thank you Alex ).

It might appear strange but with Unified Remote Access included with Windows Server 2012, Windows 7 DirectAccess Clients are considered as legacy clients. Legacy clients can connect to a Windows Server 2012 based DirectAccess infrastructure if we enable some compatibility features that I will describe in this blog post.

By default, A Windows Server 2012 based infrastructure is configured to operate in Kerberos proxy mode. In this default configuration, only Windows 8 clients can connect. In Kerberos Proxy mode, there is a single IPSEC Tunnel and certificates are not required. That’s a new DirectAccess deployment option available with Windows Server 2012. If you want to support Windows 7 clients, don’t forget to enable this checkbox :

ENABLEW7

When you activate the “Enable Windows 7 Clients computers to connect Via DirectAccess” checkbox, computer certificates become mandatory. That’s the minimum requirement to support Windows 7 Clients in a Windows Server 2012 based DirectAccess infrastructure.

Single-Site/Multiple site impact

Multi-site feature is introduced with Windows Server 2012. From user point of view a DirectAccess clients can have multiple entry point for a DirectAccess infrastructure. User can even select witch entry point to use. Unfortunately, this feature is only compatible with Windows 8. For this reasons, Windows 7 clients connecting to a multi-site DirectAccess infrastructure need a dedicated group policy that provide a single entry point for the DirectAccess infrastructure. As a conclusion, we cannot have Windows 7 and Windows 8 clients members of the same group in Multisite deployment (This possibe when Multi-site option is not enabled).

Windows 7 clients are considered as legacy clients. This means that :

  • They still rely on Teredo for DirectAccess
  • They need an IPSEC certificate to establish IPSEC tunnels
  • They will have their own dedicated DirectAccess configuration
  • They need a dedicated security group

From a DirectAccess point of view, there are two kind of clients,so there are two client-side GPO. This also means that there are two security group. You can find it with the Add-DAclient PowerShell command illustrated bellow :

ADDDACLIENTHELP

Great, but if we try to configure the “DownlevelSecurityGroupNameList” parameter with a single-site DirectAccess deployment, you will have the following error message :

ADDCLIENTERROR

In multisite deployments scenarios, we need separate security groups, one for Windows 8 clients and another one for legacy clients. Your Multi-site deployment can be composed of at least a single site. Legacy clients will only be able to connect to one entry point. Let’s switch our DirectAccess infrastructure to Multi-site :

ENABLE-DAMULTISITE

One important thing to notice with multi-site mode : you must separate Windows 7 and Windows 8 clients computers into different security groups because each operating system will have it’s own dedicated client-side GPO. Once we have at least one DirectAccess entry point we can configure it to support legacy clients with the Add-DAClient as illustrated bellow :

ADDCLIENTOK

By now, we have a Windows Server 2012 DirectAccess infrastructure witch is almost ready to accept legacy DirectAccess clients. Let’s have a look at the result of a Get-DAServer command :

GETDASERVER0

Server configuration seems to be fine. I have a certificate for IPHTTPS and an root certificate authority selected. With Windows 7, you still need certificates for DirectAccess. I would say that you always need certificates for DirectAccess because you always deploy it with Network Access Protection. But there is something bad with my configuration : The Teredo state parameter witch is disabled. When disabled (because no consecutive IPv4 public addresses or parameter disabled), client-side and Server-side GPO does not include Teredo configuration. With Windows Server 2012, this is no longer a problem.

If you configure your Internet-facing with a single IPv4 address, Teredo cannot be used (from the server point of view). Two public IPv4 addresses are always required on server side. Because Windows Server 2012 now allow to deploy DirectAccess behind a NAT device, Teredo is no longer a requirement.

Technically speaking you can enable it with the following PowerShell command, but its not mandatory :

ENABLETEREDO

And now, you remember why you need to create inbound rule for ICMP traffic . Now my configuration is fully operational from a technical point of view. But from user perspective there is something missing : The DirectAccess Connectivity Assistant 2.0. It’s included with Windows 8 and configured by the Client-side GPO but not for Windows 7, and more important, version 2.0 is required. This version is only supported when DirectAccess client is connected to a Windows Server 2012 based DirectAccess infrastructure. So don’t forget to create an additional client-Side GPO to configure the DirectAccess Connectivity Assistant for Legacy clients.

Edit : After some research and advices from Jason Jones, Teredo is a mandatory requirement for the Windows Server 2008 R2/UAG DirectAccess generation, not for Windows Server 2012. If Teredo is not operational for the DirectAccess client, IPHTTPS will be fine and even better with Windows Server 2012 based DirectAccess infrastructure. For many clients, having Microsoft box connected on LAN and Internet was not acceptable from a Security point of view. With Windows Server 2012, this is no longer a problem.

Thank you Jason.

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