Lorsque vous souhaitez ouvrir une nouvelle session sur l’interface Integrated Dell Remote Access Controller (IDRAC), il se peut que l’erreur suivante empêche la connexion :
RAC0218 : Vous avez atteint le nombre maximal de sessions utilisateur

Ce problème est dû à une mauvaise gestion de la fermeture de certaines sessions de l’interface, qui persistent et empêchent toute nouvelle session.

Solution

Pour régler le problème, effectuez les étapes suivantes :

Téléchargez un client SSH comme PuTTY
Connectez vous à l’adresse IP de l’IDRAC sur le port 22

Connectez-vous en tant que root (mot de passe par défaut : calvin)
Tapez les commandes suivantes :

racadm
getssninfo

Identifiez les SSNID de toutes les sessions, et fermez-les une par une avec la commande suivante :

closessn -i X

où X est le SSNID de la session à fermer

Personnaliser les pages ADFS 3.0 sous Windows Server 2012 R2

Microsoft

Maxime Rastello | 01/08/2014

Depuis Windows Server 2012 R2, la plateforme Active Directory Federation Services 3.0 (ADFS) ne repose plus sur Internet Information Services (IIS). Il n’est donc plus possible de modifier manuellement le code source des différentes pages ASP.NET pour personnaliser les différentes pages de connexion.

Désormais, toutes les modifications sont à effectuer via des commandes PowerShell. Il est ainsi possible de modifier :

L’image d’illustration, le logo et la description de la page de logon
Les liens du footer (support, politique de confidentialité…)
Le CSS de toutes les pages
Les messages d’erreur et le design des pages d’erreur
Le message Copyright de Microsoft
etc.

Sachez également qu’il n’est pas nécessaire de répéter chaque commande PowerShell sur tous les serveurs ADFS d’une ferme ou sur les proxies. Les modifications sont en effet stockées dans la configuration du service ADFS, qui est partagée entre tous les serveurs de la ferme.

AVANT

APRES

Voici les principales commandes PowerShell pour modifier les éléments de base. N’oubliez pas de taper la commande suivante pour charger le module ADFS dans PowerShell si besoin :

Import-Module ADFS

Eléments génériques

Nom de l’organisation :

Set-AdfsGlobalWebContent –CompanyName "Fédération Maison"

Logo de l’entreprise :

Set-AdfsWebTheme -TargetName default -Logo @{path="C:\Ressources\votre-logo.jpg"}

Note : La résolution optimale du logo est de 260×35, 96 dpi et ne doit pas excéder 10 KB. PNG et JPG sont supportés

Illustration :

Set-AdfsWebTheme -TargetName default -Illustration @{path="C:\Ressources\illustration.png"}

Note : La résolution optimale de l’illustration est de 1420×1080, 96 dpi et ne doit pas excéder 200 KB. PNG et JPG sont supportés

Description :

Set-AdfsGlobalWebContent -SignInPageDescriptionText "<p>Ceci est un exemple de description. Vous pouvez incorporer des balises HTML comme par exemple des <a href='http://www.maximerastello.com/'>liens</a></p>"

Lien HelpDesk :

Set-AdfsGlobalWebContent -HelpDeskLink "http://www.maximerastello.com/help/" -HelpDeskLinkText "Accès au HelpDesk"

Lien Confidentialité :

Set-AdfsGlobalWebContent -PrivacyLink "http://www.maximerastello.com/privacy/" -PrivacyLinkText "Confidentialité"

Messages d’erreur

Description de la page d’erreur :

Set-AdfsGlobalWebContent -ErrorPageDescriptionText "Ceci est une description affichée sur la page d'erreur"

Message d’erreur générique :

Set-AdfsGlobalWebContent -ErrorPageGenericErrorMessage "Ceci est un message d'erreur générique. Contactez l'administrateur pour toute assistance."

Message d’erreur de la page d’autorisation :

Set-AdfsGlobalWebContent -ErrorPageAuthorizationErrorMessage "Ceci est un message d'erreur d'autorisation. Contactez l'administrateur pour toute assistance."

Message d’erreur de la page d’erreur d’authentification d’un device :

Set-AdfsGlobalWebContent -ErrorPageDeviceAuthenticationErrorMessage "Votre machine n'est pas autorisée à se connecter. Contactez l'administrateur pour toute assistance."

Pour plus d’informations, je vous recommande de lire l’article TechNet dédié à la personnalisation d’ADFS. Il contient notamment des commandes PowerShell avancées afin de personnaliser encore plus vos thèmes.

Erreur 0x800f0922 à l’installation de la KB2871690 sur Windows Server 2012

Microsoft

Maxime Rastello | 15/05/2014

Microsoft propose plusieurs solutions dans la KB2962824 pour corriger les problèmes d’installation de la KB2871690 :

Symptômes

Deux configurations sont possible :

Configuration 1
Un serveur sous Windows Server 2012 utilisant un firmware UEFI et avec l’option Secure Boot activée.
Configuration 2
Un hôte Hyper-V sous Windows Server 2012 R2, une machine virtuelle de Génération 2 sous Windows Server 2012 ou Windows 8 utilisant un firmware UEFI et avec l’option Secure Boot activée.

Dans ces configurations, la mise à jour 2871690 peut ne pas s’installer, et un message d’erreur 0x800f0922 apparait.

Cause

Cette erreur apparaît car la mise à jour 2871690 a besoin (à tort) du rôle BitLocker Drive Encryption pour s’installer.

Contournement

Pour corriger, ce problème, voici une solution de contournement selon votre scénario :

Contournement configuration 1
Installer BitLocker sur le serveur utilisant un firmware UEFI et avec l’option Secure Boot activée.
Contournement configuration 2
Installer BitLocker sur la machine virtuelle de Génération 2.

Erreur d’installation KB2920189 Windows Server 2012 R2 dans une VM de Génération 2

Microsoft

Maxime Rastello | 15/05/2014

La mise à jour KB2920189 a été publiée par Microsoft le 13/05/2014 via Windows Update. Un problème connu empêche cependant son installation sur des machines virtuelles Hyper-V de Génération 2.

Un contournement est cependant possible afin d’installer cette mise à jour correctement :

Arrêtez la machine virtuelle dans Hyper-V
Ouvrez les Propriétés de la machine virtuelle.
Dans la partie Firmware, désactivez l’option Enable Secure Boot
Démarrez la machine virtuelle et réinstallez la mise à jour KB2920189
Arrêtez ensuite la machine virtuelle
Dans la partie Firmware, activez l’option Enable Secure Boot
Démarrez la machine virtuelle

UAG 2010 et ADFS 3.0 : réparer l’affichage de la page d’authentification (logon page)

Microsoft

Maxime Rastello | 06/03/2014

Malgré la sortie du SP4, Microsoft Forefront Unified Access Gateway 2010 (UAG) ne supporte pas de manière officielle ADFS 3.0, introduit par Windows Server 2012 R2.

Après un essai plutôt concluant, UAG 2010 SP4 fonctionne en tant que Proxy ADFS 3.0. Cependant si vous utilisez l’authentification par formulaire (Form-based authentication), il se peut que le design de la page de connexion soit cassé.

La faute à UAG qui n’autorise pas par défaut l’accès au chemin /adfs/portal contenant le CSS et les images à afficher sur la page d’authentification. Pour restaurer l’affichage de la page, il suffit d’autoriser le dossier portal dans l’application ADFS et dans les propriétés du trunk UAG.

1- Ouvrez la console UAG, choisissez l’application ADFS de votre trunk HTTPS et cliquez sur Edit.

2- Dans l’onglet Web Servers, rajoutez le chemin /adfs/portal dans les Paths autorisés et validez par OK.

3- Ouvrez les propriétés de votre trunk UAG puis allez dans l’onglet URL Set. Rajoutez une nouvelle entrée avec les informations suivantes :

Name : STS_RuleX (où X est un chiffre de votre choix)
Action : Accept
URL : /adfs/portal(/.*|$)
Parameters : Ignore
Methods : POST, GET

4- En utilisant les flèches de droite, remontez cette règle pour rétablir l’ordre alphabétique (juste avant les règles pour /adfs/services/). Validez par OK.

5- Sauvegardez et appliquez la nouvelle configuration. Votre page d’authentification ADFS devrait désormais s’afficher correctement.

ADFS 3.0 sur Windows Server 2012 R2 avec Office 365

Microsoft

Maxime Rastello | 03/01/2014

Windows Server 2012 R2 intègre une nouvelle version d’Active Directory Federation Services (ADFS), estampillée 3.0.

Si plusieurs changements notables ont été apportés, la nouveauté la plus marquante est sûrement la suppression du rôle ADFS Proxy, remplacé désormais par Web Application Proxy (WAP), un composant du rôle Remote Access. Notez au passage qu’ADFS 3.0 n’utilise plus la plateforme IIS.

Web Application Proxy permet de publier sur Internet des applications présentes en interne. Deux modes sont disponibles : une authentification via ADFS avant d’accéder aux ressources, et une publication en “pass-through”, sans authentification. Avec WAP, il est donc possible de publier des applications comme Outlook Web Access, un site SharePoint ou même un simple site Web IIS. Les scénarios de BYOD (Bring Your Own Device) et d’authentification multi-facteurs sont également facilités, notamment grâce au Device Registration Service et Workplace Join.

Cet article détaille l’installation d’une infrastructure ADFS 3.0 simple (mono-serveur) et la configuration d’une fédération avec un compte Office 365 pour assurer une authentification unique (SSO).

Prérequis
Installation et configuration du rôle ADFS 3.0
Installation et configuration du rôle Web Application Proxy
Configuration de la synchronisation Active Directory / Office 365
Configuration de la fédération avec Office 365
Tests de connexion
Ajout d’une nouvelle adresse SMTP

Prérequis

Active Directory Federation Services 3.0

Windows Server 2012 R2 (Standard ou Datacenter)
Serveur joint au domaine

Web Application Proxy

Windows Server 2012 R2 (Standard ou Datacenter)
Serveur joint au domaine ou en WORKGROUP (plus sécurisé)
Au moins une adresse IP publique configurée sur la machine
Un nom de domaine externe ==> dans notre cas, adfs.home.maximerastello.com

Windows Azure Active Directory Sync

Windows Server 2003 SP2 ou supérieur (x64 uniquement)
Serveur joint au domaine (obligatoire)
PowerShell 1.0 ou supérieur
.NET Framework 3.5
Accès à Internet

~~Note : l’installation du DirSync n’est pas possible sur un contrôleur de domaine~~

Edit : La version 1.0.6567.18 de l’outil autorise désormais l’installation du DirSync sur un contrôleur de domaine. Ce n’est conseillé qu’à des fins de tests.

PKI

Autorité de certification interne
Certificat externe pour la publication du serveur ADFS ==> solution recommandée en production.
OU
Certificat interne et publication de la CRL + déploiement du certificat racine sur toutes les machines (clients et serveurs) ==> solution choisie dans notre cas pour plus de facilité, non recommandée en production.

Office 365

Un compte actif avec au moins une licence utilisateur parmi les offres suivantes :

Office 365 Moyenne Entreprise
Office 365 Grande Entreprise (E1, E3 et Exchange Online)

Note : Office 365 Petite Entreprise ne permet pas la synchronisation AD

Commentaires

Je ne détaillerai pas dans cet article l’installation des prérequis pour la mise en place d’une infrastructure ADFS. Prévoyez bien évidemment un domaine Active Directory et trois machines sous Windows Server 2012 R2, la première pour le rôle ADFS, la seconde pour WAP et la troisième pour le DirSync.

Le serveur hébergeant ADFS doit être joint au domaine dans votre réseau interne, alors que les bonnes pratiques veulent que le serveur hébergeant WAP soit laissé en WORKGROUP et placé en DMZ.

Enfin, vous aurez également besoin d’une PKI interne ainsi qu’un compte Office 365 permettant la synchronisation AD.

Infrastructure

Voici un schéma classique d’infrastructure ADFS/WAP. Pour des raisons techniques, WAP sera installé sur un serveur joint au domaine. Attention cependant, le serveur doit être joignable depuis Internet, vous devez donc posséder au moins une adresse IP publique.

Installation et configuration du rôle ADFS 3.0

L’installation du rôle ADFS se fait via le Server Manager. Dans cet exemple, ADFS est installé sur le serveur nommé HOME-ADFS.

Lorsque l’installation du rôle est terminée, il faut configurer ADFS.

Dans notre cas, nous installons le tout premier serveur ADFS interne. Il est également possible de rajouter des serveurs ADFS à une ferme existante avec ce même assistant de configuration.

Vous devez ensuite spécifier les identifiants d’un compte administrateur du domaine pour la configuration du rôle.

Il faut ensuite entrer le nom du service ADFS, choisir un certificat et un nom d’affichage “user-friendly”. Dans notre cas, nous avons choisi adfs.home.maximerastello.com, home.maximerastello.com étant le domaine AD.

N’oubliez pas de créer un enregistrement DNS de type A pour que le nom d’hôte (ici adfs) pointe vers l’adresse IP de votre serveur ADFS. Un certificat doit également être généré par votre autorité de certification interne. Dans notre exemple, j’ai opté pour un certificat de type wildcard (*) couvrant *.maximerastello.com, et contenant un Subject Alternative Name (SAN) couvrant *.home.maximerastello.com.

Vous avez ensuite le choix entre utiliser un Group Managed Service Account (gMSA) ou un simple compte de domaine. L’avantage d’utiliser un gMSA est de ne pas avoir à se soucier du mot de passe du compte puisqu’il sera généré automatiquement. Pour plus d’informations, n’hésitez pas à consulter cette page.

Attention, si vous utilisez un gMSA, vous devrez créer une clé racine Key Distribution Services (KDS Root Key) avec la commande suivante. Cela permet de fixer une date d’utilisation antérieure (-10h) pour une utilisation immédiate :

Add-KdsRootKey –EffectiveTime ((get-date).addhours(-10))

Lorsque vous aurez renseigné un compte de service ou un compte du domaine, l’assistant se charge de créer l’enregistrement SPN automatiquement. Dans notre exemple, j’opte pour un GMSA en utilisant le compte adfs_sa.

L’assistant crée un enregistrement SPN de type HOST, qui peut également être créé manuellement avec la commande suivante :

setspn -s host/adfs.home.maximerastello.com home\adfs_sa

ADFS stocke toutes ses informations dans une base données. Vous pouvez soit utiliser Windows Internal Database (WID), soit spécifier un serveur SQL Server dédié. WID ne nécessite aucune installation supplémentaire, et est souvent suffisant pour la plupart des utilisations : elle supporte jusqu’à 8 serveurs ADFS dans une même ferme.

Je vous recommande de lire cet article afin de déterminer si votre infrastructure nécessite plutôt WID ou SQL Server.

Vérifiez ensuite que les informations sont correctes dans la première fenêtre. Lorsque vous passez à l’étape suivante, les prérequis sont automatiquement vérifiés et la moindre erreur est rapportée dans cette fenêtre.

Notez au passage que si vous possédez plusieurs contrôleurs de domaine dans votre infrastructure, vous devrez patienter un peu le temps que la clé racine KDS soit répliquée.

Pour vérifier que l’installation du serveur ADFS s’est déroulée correctement, vous pouvez tenter d’ouvrir l’URL suivante depuis une machine interne au domaine : https://fqdnduserviceadfs/adfs/ls/IdpInitiatedSignon.aspx. l’affichage d’une page de connexion prouve que la plateforme est fonctionnelle.

Installation et configuration du rôle Web Application Proxy

Pour publier le serveur ADFS sur Internet, il faut utiliser un proxy ADFS. Le rôle Proxy ADFS n’existe plus à proprement parlé dans Windows Server 2012 R2. Il a été intégré à une nouvelle fonctionnalité : Web Application Proxy.

L’installation de WAP se fait via le Server Manager, en choisissant le rôle Remote Access.

Il faut ensuite sélectionner le service de rôle Web Application Proxy.

Lorsque le rôle est installé, cliquez sur le lien afin de lancer l’assistant de configuration.

Web Application Proxy a besoin du nom du service ADFS pour interagir avec. Renseignez simplement le nom choisi durant l’installation (ici adfs.home.maximerastello.com) et saisissez les accès d’un compte ayant des permissions suffisantes pour s’y connecter.

En production, il est fortement recommandé de créer un compte de domaine dédié, et de le rajouter dans le groupe des administrateurs locaux de chaque serveur ADFS.

Sélectionnez ensuite le certificat externe qui sera utilisé par les clients en provenance d’Internet. Il est fortement recommandé d’utiliser un certificat signé par une autorité de certification en ligne comme Verisign. Si vous ne souhaitez pas en acheter un, vous pouvez toujours utiliser un certificat de votre PKI interne, en prenant soin de déployer le certificat racine sur chaque machine et de publier sur Internet la CRL de votre autorité.

Terminez la configuration du rôle en validant les informations. Votre serveur ADFS est désormais accessible à l’adresse spécifiée. Depuis l’extérieur, tentez d’accéder à la même URL : https://fqdnduserviceadfs/adfs/ls/IdpInitiatedSignon.aspx.

Configuration de la synchronisation Active Directory / Office 365

Tout d’abord, Vous devez vérifier que le domaine pour lequel vous souhaitez établir une synchronisation soit bien dans la liste des domaines acceptés sur la page https://portal.microsoftonline.com/Domains/DomainManager.aspx. Pour plus d’informations concernant la synchronisation d’annuaires, consultez cette page.

Avant d’établir une synchronisation d’annuaire entre votre infrastructure et Office 365, vous devez activer le service dans les paramètres de votre compte Office 365 puis télécharger l’outil Windows Azure Active Directory Sync, à l’adresse https://portal.microsoftonline.com/DirSync/DirectorySynchronization.aspx.

L’installation de l’outil DirSync doit se faire sur un serveur joint au domaine et doté du .NET Framework 3.5. Vous pouvez l’installer manuellement en insérant le CD d’installation de Windows Server 2012 R2 et en tapant la commande suivante :

Install-WindowsFeature NET-Framework-Core –Source D:\Sources\SxS

Lancez ensuite l’installation de l’outil de synchronisation. La première fenêtre demande de renseigner des accès administrateur à la plateforme Office 365.

Note : Ces informations sont enregistrées de manière sécurisée sur le serveur DirSync.

Entrez ensuite les identifiants d’un compte administrateur du domaine. Pour des raisons de sécurité, ces accès ne sont pas sauvegardés sur le serveur.

Vous pouvez décider d’activer le mode Hybride. Sans ce mode, les objets Active Directory sont synchronisés uniquement dans le sens ‘Infrastructure interne’ > ‘Office 365’. Si le mode hybride est activé, certains attributs des objets AD peuvent être modifiés depuis l’interface de gestion Office 365, notamment la liste des adresses SMTP d’un utilisateur (proxyAddresses).

Vous avez également la possibilité d’activer la synchronisation des mots de passe. Grâce à cette option, vos utilisateurs internes peuvent accéder à leur compte Office 365 avec le même mot de passe que leur compte Active Directory. Pour plus d’informations, consultez cette page.

Terminez l’assistant pour finaliser la configuration. Je vous conseille d’effectuer une première synchronisation dès que possible.

Il est également possible de lancer manuellement la synchronisation des annuaires en utilisant la console PowerShell installée avec l’outil DirSync. Elle se nomme DirSyncConfigShell et se trouve dans le dossier C:\Program Files\Windows Azure Active Directory Sync.

Tapez ensuite la commande suivante pour lancer une synchronisation manuelle :

Start-OnlineCoexistenceSync

Pour vérifier que la synchronisation s’est correctement effectuée, vous utilisez la console Synchronization Service Manager de Forefront Identity Manager 2012 R2.

La console, nommée miisclient.exe, se situe dans le dossier C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell.

Nous reviendrons plus en détail sur cette console dans un prochain article.

Configuration de la fédération avec Office 365

Pour configurer une fédération entre votre domaine Active Directory et Office 365, vous devez tout d’abord installer les outils nécessaires pour administrer la plateforme à distance. Les étapes détaillées se situent sur la page de gestion de l’authentification unique du portail : https://portal.microsoftonline.com/IdentityFederation/IdentityFederation.aspx.

Je vous recommande d’installer les outils suivants dans l’ordre indiqué, soit sur une machine dédiée à l’administration, soit directement sur le serveur DirSync :

Microsoft Online Services Sign-in Assistant
Module Windows Azure Active Directory pour Windows PowerShell : x64 / x86

Lancez ensuite la console PowerShell Windows Azure Active Directory et tapez la commande suivante :

Connect-MsolService

Renseignez vos accès Office 365 puis tapez la commande suivante pour vérifier la liste des domaines acceptés :

Get-MsolDomain

Identifiez le domaine à fédérer avec votre ADFS, ici home.maximerastello.com, et tapez la commande suivante :

Convert-MsolDomainToFederated -DomainName home.maximerastello.com

Tests de connexion

Votre fédération ADFS avec Office 365 est désormais prête. Pour tester son bon fonctionnement, connectez-vous simplement à Outlook.com en utilisant l’adresse https://outlook.com/votrenomdedomainefédéré, par exemple https://outlook.com/home.maximerastello.com.

Si vous êtes sur un réseau externe, vous serez automatiquement redirigé vers l’adresse du proxy ADFS que vous avez publié.

Si vous êtes sur un réseau interne, l’interface Exchange Online se lance directement, sans avoir besoin de rentrer des identifiants de domaine.

Ajout d’une nouvelle adresse SMTP

Lorsque vous rajoutez plusieurs domaines dans votre compte Office 365, il peut être intéressant de les rajouter à un compte utilisateur pour qu’il dispose de plusieurs alias sur sa messagerie Exchange.

Si vous n’utilisez pas le mode hybride, vous devez modifier manuellement chaque objet Active Directory puis effectuer une synchronisation manuelle.

Ouvrez la console Active Directory Users and Computers et activez l’affichage avancé afin d’accéder à l’onglet Attribute Editor.

Repérer l’attribut proxyAddresses puis rajouter l’entrée :

smtp:adresseSMTP@domaine.com pour rajouter cette adresse en tant qu’alias simple.
SMTP:adresseSMTP@domaine.com pour rajouter cette adresse en tant qu’alias et adresse de réponse.

Note : la casse du mot clé “SMTP” est donc importante

Une double synchronisation manuelle est nécessaire pour exporter les changements dans Office 365 :

Vérifiez ensuite que les changements ont été répercutés dans la console Exchange Control Panel (https://outlook.com/ECP) :

Work Folders : Error 0x80c80001 the data transferred isn’t in the proper format

Microsoft

Maxime Rastello | 28/12/2013

Lorsque vous essayez de configurer la synchronisation des Dossiers de travail (Work Folders), il se peut que l’erreur suivante apparaisse lors de la synchronisation :

The data transferred isn't in the proper format (Error 0x80c80001)

ou en français

Les données transférées ne sont pas au bon format (Erreur 0x80c80001)

Ce problème a été identifié par Microsoft puis corrigé dans la KB2887595 de Novembre 2013. Assurez-vous d’avoir bien installé cette mise à jour sur le serveur hébergeant vos Work Folders :

Publier des RemoteApp 2012 R2 sur le portail UAG 2010

Microsoft

Maxime Rastello | 27/12/2013

Fin Novembre 2013, Microsoft a publié le Service Pack 4 de Forefront UAG 2010. Cette dernière mouture apporte enfin la compatibilité avec les systèmes d’exploitation Windows 8.1 et Windows Server 2012 R2, et permet au portail UAG de fonctionner sous Internet Explorer 11.

Grâce à UAG 2010 SP4, il est désormais possible de publier des RemoteApp Windows Server 2012 R2 sur le portail grâce à l’outil Export2Tspub.exe.

Exportation des RemoteApp avec Export2Tspub

1- Connectez-vous au serveur UAG 2010 et allez dans le dossier C:\Program Files\Microsoft Forefront Unified Access Gateway\common\bin puis récupérez le fichier Export2Tspub.exe.

2- Copiez ce fichier sur le serveur RD Session Host hébergeant vos applications RemoteApp.

3- Lancez l’application Export2Tspub.exe en tant qu’administrateur. Une invite de commande s’ouvre et commence l’exportation de la configuration RemoteApp.

4- Lorsque l’exportation est terminée, un fichier .tspub portant le nom de votre collection a été créé dans le même dossier que l’outil.

5- Récupérer le fichier .tspub sur le serveur UAG 2010.

Importation des RemoteApp dans le portail UAG

1- Ouvrez la console d’administration Forefront UAG Management.

2- Ouvrez votre trunk et ajouter une nouvelle application.

3- Choisissez Terminal Services / Remote Desktop Services puis dans la liste déroulante, choisissez RemoteApp.

4- Importez le fichier .tspub que vous avez récupéré. Le nom du serveur RD Session Host devrait se compléter tout seul. Si vous possédez une ferme de serveurs, saisissez aussi leur plage d’adresses.

5- Sélectionnez les applications RemoteApp que vous souhaitez publier sur le portail et terminez la configuration.

6- Enregistrez et appliquez la configuration UAG.

7- Vérifiez que les applications ont bien été publiées sur le portail.

Autoriser un caractère spécial dans l’URL d’un Server Web IIS

Microsoft

Maxime Rastello | 27/12/2013

Par défaut, les caractères spéciaux contenus dans une URL ne sont pas reconnus par un serveur Web IIS. Cela peut être gênant lorsque vous souhaitez par exemple publier le Delta CRL d’une autorité de certification, qui contient le caractère ‘+‘.

<a href="http://www take a look at the site here.maximerastello.com/wp-content/uploads/2013/12/CRL-Error-404.png”> Erreur 404 - Caractère spécial URL IIS

Pour autoriser l’utilisation de caractères spéciaux dans l’URL d’un site Web IIS, il faut modifier ou créer le fichier web.config du site publiant la CRL et passer le paramètre allowDoubleEscaping à true :

<configuration>
  <system.webServer>
   <security>
     <requestFiltering allowDoubleEscaping="true"></requestFiltering>
   </security>
  </system.webServer>
</configuration>

Dans le cas d’une autorité de certification, le fichier web.config est à créer dans le Virtual Directory hébergeant votre CRL et votre Delta CRL :

Joindre un domaine sur Windows RT 8 et Windows RT 8.1

Microsoft

Maxime Rastello | 26/12/2013

Par défaut, il est impossible de joindre un domaine Active Directory depuis une tablette ou un PC équipé de Windows RT. Cependant, la fonctionnalité de jonction d’un domaine est bien présente mais seulement désactivée, sûrement pour des raisons commerciales.

Avec quelques manipulations, on peut toutefois réactiver la fonctionnalité Joindre un domaine et lier votre tablette Windows RT au domaine de votre entreprise. Par la suite, il sera possible de lui appliquer des stratégies de groupe !

Nous allons donc couvrir plusieurs points :

1- Activer la fonctionnalité de jonction d’un domaine Active Directory sous Windows RT (8 ou 8.1).

2- Activer l’application des stratégies de groupe

Disclaimer : les modifications proposées ci-dessous sont livrées telles quelles. La modification de la base de registre peut altérer le bon fonctionnement de votre PC. Ce scénario est proposé à des fins de test et n’est en aucun cas supporté officiellement par Microsoft.

Joindre un domaine Active Directory

Résumé

Nous devons réactiver la fonctionnalité de jonction d’un domaine en lançant une invite de commande en tant qu’administrateur au démarrage de Windows RT et en modifiant le registre afin de réactiver l’option.

Manipulations

1- Téléchargez et décompressez ce fichier ZIP. Il contient les clés de registre à modifier.

2- Lancez le script WINRT_activer_setup_mode.reg afin d’activer le Setup Mode au démarrage de la machine.

Script du registre - Setup Mode

Vous pouvez également utiliser le script WINRT_supprimer_setup_mode.reg pour restaurer les paramètres par défaut.

3- Redémarrez la machine.

4- Dans l’invite de commandes, tapez regedit et validez par Entrée.

5- Allez dans l’arborescence HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\ProductOptions et double-cliquez sur ProductPolicy.

6- Allez vers l’offset 4700. Le but étant de rechercher la partie traitant de “WorkstationService-DomainJoinEnabled” afin de modifier cette stratégie. Le numéro de la ligne peut varier selon les machines, dans mon cas la stratégie commence à l’offset 47C0.

Repérez ensuite la chaine hexadécimale 64 00 00 à la fin de la stratégie.

7- Remplacez la chaine hexadécimale 64 00 00 par 64 00 01.

Note : Si vous êtes obligé de faire ces manipulations au clavier, vous pouvez utiliser les touches Maj + Flèche droite afin de sélectionner la partie à modifier.

8- Validez les modifications par OK et fermez la base de registre.

9- Dans la console, tapez la commande suivante afin de désactiver le service Software Protection au démarrage de la machine :

ren sppsvc.exe sppsvc-back.exe

10- Tapez la commande exit ou fermez la console afin de démarrer sous Windows RT.

11- Depuis l’écran d’accueil Windows, vérifiez que la fonctionnalité Joindre un domaine est présente. Lancez-la pour rejoindre votre domaine Active Directory.

Activation des stratégies de groupe

Pour pouvoir appliquer des stratégies de groupe aux clients sous Windows RT, il faut réactiver le service Client de stratégie de groupe, qui par défaut est désactivé et arrêté.

1- Ouvrez la console Services en tant qu’administrateur.

2- Faites un clic droit sur Client de stratégie de groupe, puis choisissez Propriétés.

3- Dans la partie Type de démarrage, choisissez Automatique, et cliquez sur le bouton Démarrer.

Réactivation du service Software Protection

Après avoir joint le domaine, il est important de réactiver le service Software Protection que nous avions désactivé précédemment. Sans ce service, il n’est pas possible d’associer son compte de domaine à un compte Microsoft et la tablette sera considérée comme non-activée.

1- Relancez le script WINRT_activer_setup_mode.reg et redémarrez votre ordinateur.

2- Dans la console, tapez la commande suivante :

ren sppsvc-backup.exe sppsvc.exe

3- Fermez l’invite de commandes en tapant exit.

4- Vérifiez que Windows RT est de nouveau activé.

Maxime Rastello

Dell IDRAC : Vous avez atteint le nombre maximal de sessions utilisateur