Archives mensuelles : janvier 2014

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 Non Oui

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 :

Sur cette fin d’année 2013, Microsoft nous annonce un nouveau changement majeur dans la gamme de produit Forefront : . 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) :

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 :

  • Creating a Windows Azure AD and Windows Server AD Environment using DirSync with Password Sync
  • Creating a Windows Azure AD and Windows Server AD Environment with Federation (SSO)

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

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 ). 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