Ignorer les commandes du ruban
Passer au contenu principal
SharePoint

Accueil - Le blog d'Alexandre GIRAUD MVP Forefront
Alexandre GIRAUD - MVP Forefront > Le blog d'Alexandre GIRAUD MVP Forefront
Articles et annonces sur toute la gamme Microsoft Forefront et autres outils de sécurité.
juin 25
Vous obtenez le message “Unable to configure the password reset service: Error getting authtoken from https://login.windows.net/3sr.fr/oauth2/token.” lorsque vous tentez d’appliquer la commande Enable-OnlinePasswordWriteBack

Suite à mon précédent billet, j’explique qu’il y a une mise à jour de DirSync qui permet de mettre en oeuvre la fonction de Password WriteBack. http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=307

Cependant, lorsque j’ai tenté de la mettre en oeuvre la première j’ai été confronté à un problème…. J’avais le message d’erreur : “Unable to configure the password reset service: Error getting authtoken from https://login.windows.net/3sr.fr/oauth2/token.

image_thumb[1]

Cela vient du fait que vous devez utiliser une identité Azure qui a pour pré-requis :

  • Global Administrator (bien entendu)
  • Ce compte n’est pas un compte fédéré ! (je vous conseille d’utiliser le compte natif en .onmicrosoft.com)

Un grand merci à Adam Steenwyk qui m’a aidé, et m’a permis de résoudre le problème. La documentation sur MSDN n’est pas encore à jour (à l’heure où j’écris) mais il m’a été confirmé que cela sera le cas très prochainement.

juin 25
Et encore une mise à jour de DirSync (1.06765.6 ) pour le Self-Reset Password via Azure

Nous parlions dans un précédent article l’arrivée d’une nouvelle mise à jour de DirSync (version 6385.0012 http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=299 ), qui apportaient comme amélioration la prise en charge de la synchronisations des certificats S/MIME pour le chiffrement des messages avec Office 365.

Et là, à nouveau une nouvelle version 6765.6, et bien entendu qui s’accompagne avec une mise à jour spécifique pour Azure ! Avec cette mise à jour, cela est un pré-requis pour mettre en œuvre la fonction de “Password Writeback” … kezako ?

Avec Azure AD Premium, il y a de nombreux fonctionnalités supplémentaires par rapport à la version gratuite. Parmi elles, il y a une fonction qui permet de fournir aux utilisateurs un portail d’enregistrements de questions/réponses personnelles afin de pouvoir réinitialiser aux-mêmes leurs mots de passe en cas de perte. Ceci est très pratique pour des identités purement Cloud, et ainsi s’affranchir de développer cette fonction. (voir mon précédent article pour l’accès à l’évaluation : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=306)

Mais à l’aide de la dernière mise à jour de DirSync, cela peut permettre également à des comptes Active Directory On-premises de bénéficier d’un accès au Self Reset Password (comme avec FIM SSPR) mais directement dans Azure. En fait, la fonction Password Writeback permettra de recevoir la notification de changement de mot de passe, et ainsi faire la réinitialisation du mot de passe à l’aide de DirSync.

Pour cela, il faudra donc télécharger et installer (ou mettre à jour) DirSync depuis ce lien : http://go.microsoft.com/fwlink/?LinkID=278924 et d’activer la nouvelle fonctionnalité à l’aide de la commande PowerShell (Enable-OnlinePasswordWriteBack). Microsoft documente cette configuration sur leur site : http://msdn.microsoft.com/en-us/library/azure/dn688249.aspx#BKMK_2

Voilà la commande PowerShell que je recommande :

$local_AD_Cred = Get-Credential -Message 'Compte de votre AD local'
$local_MAAD_Cred = Get-Credential -Message 'Compte de votre Azure AD'
Enable-OnlinePasswordWriteBack -LocalADCredential $local_AD_Cred -AzureADCredential $local_MAAD_Cred

image

juin 25
Microsoft Azure Active Directory Premium (MAAD) disponible en version d’évaluation !

image

Microsoft Azure Active Directory Premium est la version améliorée et payante de la version Azure AD classique. Elle ajoute de nombreuses fonctionnalités intéressantes, comme la gestion d’identités avancées, le branding, le reset password, …
Inutile de tout copier/coller, car tout est expliqué déjà sur MSDN : http://msdn.microsoft.com/en-us/library/azure/dn532272.aspx

Cependant pour accéder à cette fonctionnalité jusqu’à ce jour, il fallait avec un contrat Microsoft de type EA ou VL. Il était possible de faire l’acquisition de la fonction uniquement, ou d’utilise Entreprise Mobility Suite (qui inclut MAAD Premium).
Ces types de contrats ne sont pas accessibles à tout le monde, et surtout qu’il n’est pas possible donc d’évaluer MAAD Premium. Plus d’infos sur l’accès et la configuration de MAAD Premium, toujours sur MSDN : http://msdn.microsoft.com/en-us/library/azure/dn499825.aspx

Mais les choses changent, et en bien ! Depuis cette semaine, il est possible d’accéder à une version d’évaluation d’Azure AD Premium sans contrat de licences.
On le remarque tout simplement depuis l’onglet “Licences” dans l’annuaire Azure AD.

image

Une note explicative avant, vous indiquant surtout que cette évaluation est limitée à 90 jours. Ce qui sera suffisant normalement pour évaluer les fonctions (articles à venir …)
image

Un message vous indiquera que tout s’est bien déroulé … !
image

Et vous voilà avec 100 licences MAAD Premium !
image

\: En vous souhaitant une bonne évaluation :/

mai 09
Problème de configuration du client CRM pour Outlook

Microsoft Dynamics CRM est une application de gestion relation clients, accessible aussi bien en version Online et On-Premises. L’application est essentiellement accessible à travers une interface web directement depuis le navigateur, ou l’interface y est très riche. Mais il est également possible d’utiliser un client lourd, ce dernier s’intègre directement dans le client Microsoft Outlook. La version du client Outlook, permet notamment d’avoir une version cache “hors-ligne”. Ainsi en situation de déplacement sans connexion Internet, il est toujours possible d’utiliser Dynamics CRM. Une synchronisation s’effectuera lorsque la connexion Internet sera à nouveau disponible.

Pour permettre l’utilisation du client CRM pour Outlook, il faut quelques pré-requis. Par exemple, il faut que les services WIndows Identity Foundation soient installés. Ceci peut être fait à l’aide d’une simple commande PowerShell : Enable-WindowsOptionalFeature -Online -FeatureName "Windows-Identity-Foundation". Si vous utilisez Windows 8.1, il faut appliquer le Rollup 2 : http://support.microsoft.com/kb/2919956 (Build 06.00.0002.0046). Il est nécessaire également d’avoir le client Microsoft Online Sign-In Assistant. Et c’est bien ce dernier qui pose souvent problème, nous allons le voir à travers ce billet. Sinon, pour plus d’informations sur les prérequis, se rendre sur Technet http://technet.microsoft.com/en-us/library/hh699818(v=crm.6).aspx

Alors dans mon cas, je pars du principe ou je dispose de Microsoft CRM Dynamics CRM Online configuré avec des identités fédérés. Je suis avec un client Windows 8.1 x64 et Outlook 2013 x64. Après l’installation du client CRM, depuis le portail CRM Online, l’assistant me propose de configurer l’accès à CRM. Si on conserver l’option “CRM Online'” puis on clique sur le bouton “Tester la connexion”, l’assistant a bien trouvé mon identité SSO et les informations sur mon organisation.

image

Mais si je clique sur le bouton OK afin de valider, un message d’erreur survient …

image

On va donc examiner le fichier journal de l’assistant de configuration CRM pour Outlook :

16:17:12|   Info| === Début de la journalisation de l’Assistant de configuration Microsoft Dynamics CRM pour Outlook le 09/05/2014 à 16:17:12 ===
16:17:12|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ClientConfig.Initialize
16:17:12|   Info| Client Configuration Wizard Version      : 6.0.0002.0046
16:17:12|   Info| Client Configuration Wizard LanguageID   : 1036
16:17:12|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.Validator.IsOutlookInitialized
16:17:12|   Info| Query all rows in profile table
16:17:12|   Info| Outlook is  initialized
16:17:12|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.Validator.IsOutlookInitialized
16:17:12|   Info| Client Configuration Wizard Running Mode : Normal
16:17:13|   Info| Configuration file Type : OnPremise.
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.ConfigInfo
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetAllCRMOrgsInOutlookProfile
16:17:13|   Info| Logon mapi store
16:17:13|   Info| Logon admin service
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetServiceIds
16:17:13|   Info| Query all rows in msg service table
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.OutlookCRMDatastoreInstaller.GetServiceIds
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.CleanUpDatastoreIfNeeded
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.CleanUpDatastoreIfNeeded
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ConfigInfo.ConfigInfo
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.ServerForm
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.ServerForm
16:17:13|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.SetUIData
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadAvailableUrls
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadAvailableUrls
16:17:13|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.SetUIData
16:17:18|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click
16:17:18|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection
16:17:18|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm.TestConnection
16:17:18|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm._testConnectionButton_Click
16:17:35|  Error| Error connecting to URL:
https://disco.crm.dynamics.com/XRMServices/2011/Discovery.svc Exception: System.ServiceModel.Security.SecurityAccessDeniedException: Access is denied.

Server stack trace:
   à System.ServiceModel.Channels.ServiceChannel.ThrowIfFaultUnderstood(Message reply, MessageFault fault, String action, MessageVersion version, FaultConverter faultConverter)
   à System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   à System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   à System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   à System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at [0]:
   à System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   à System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   à Microsoft.Xrm.Sdk.Discovery.IDiscoveryService.Execute(DiscoveryRequest request)
   à Microsoft.Xrm.Sdk.Client.DiscoveryServiceProxy.Execute(DiscoveryRequest request)
   à Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.DeploymentInfo.LoadOrganizations(AuthUIMode uiMode, Form parentWindow, Credential credentials)
   à Microsoft.Crm.Application.Outlook.Config.DeploymentsInfo.InternalLoadOrganizations(OrganizationDetailCollection orgs, AuthUIMode uiMode, Form parentWindow)
16:17:37|   Info| Fill organization comboBox with server information.
16:17:50|Verbose| Method entry: Microsoft.Crm.Application.Outlook.Config.ServerForm._okButton_Click
16:17:50|Verbose| Method exit: Microsoft.Crm.Application.Outlook.Config.ServerForm._okButton_Click
16:17:52|  Error| Exception : La référence d'objet n'est pas définie à une instance d'un objet.    à Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo(String redirectEndpoint, String partner, String policy, String& postData)
   à Microsoft.Crm.Outlook.ClientAuth.PassportAuthProvider`1.SignIn()
   à Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.SignIn(Uri endPoint, Credential credentials, AuthUIMode uiMode, IClientOrganizationContext context, Form parentWindow, Boolean retryOnError)
   à Microsoft.Crm.Outlook.ClientAuth.ClientAuthProvidersFactory`1.GetAuthProvider(Uri endPoint, Credential credentials, AuthUIMode uiMode, Uri webEndPoint, IClientOrganizationContext context, Form parentWindow)
   à Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserId()
   à Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary)
   à Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo()
   à Microsoft.Crm.Application.Outlook.Config.ServerForm.<InitializeBackgroundWorkers>b__2(Object sender, DoWorkEventArgs e)
   à System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

Nous avons donc ici 2 erreurs, rien que ça ! Si on se penche sur la première, le journal indique un accès refusé à l’adresse https://disco.crm.dynamics.com/XRMServices/2011/Discovery.svc. Etrange, car justement cette URL est dédiée à l’Amérique du Nord, et non l’Europe. Les programmes ont toujours du mal à traverser l’Atlantique, même avec le temps. Il est possible de connaître les URL de Discover CRM Online en fonction du type (MS Account, O365 Account) et de la localisation (EMEA, APAC, …) : http://msdn.microsoft.com/en-us/library/gg328127.aspx

Donc il aurait fallu que notre URL soit https://disco.crm4.dynamics.com/XRMServices/2011/Discovery.svc. Il est donc possible manuellement de faire la modification, en indiquant directement cette URL et se connecter.

image

Cependant, au sein d’une large organisation ceci n’est pas envisageable. Il est donc possible de déployer un fichier Default_Client_Config.xml et d’y indiquer les configurations par défaut. Le fichier de configuration pourra être ainsi déployé à l’aide d’outils comme SCCM (ou autre). Le fichier pourra contenir des informations comme ceci :

<Deployments>
    < Deployment>
           < DiscoveryUrl>https://disco.crm4.dynamics.com</DiscoveryUrl>
        < Organizations>
             <Organization IsPrimary='true'>3SR</Organization>
         </Organizations>
    </Deployment>
< /Deployments>

Plus d’infos sur les méthodes de déploiement de configuration du client CRM pour Outlook, sur MSDN http://msdn.microsoft.com/en-us/library/hh699665.aspx

A présent que l’adresse du serveur est corrigé, je n’arrive toujours pas à me connecter et la journal me présent désormais que la 2nde erreur telle indiquée dans le journal plus haut (Microsoft.Crm.Passport.IdCrl.OnlineServicesFederationLogOnManager.GetBrowserClientAuthInfo). Il semblerait donc que nous ayons un problème de gestion d’identité, étant donné la description de ce message. Nous avons vu en début de cet article, qu’en pré-requis il est nécessaire d’avoir l’assistant de connexion Microsoft Sign-In. Après vérification, je dispose déjà d’une version sur mon poste qui semble être à jour (7.250.4556.0) pourtant :

image

Je décide donc de désinstaller cette version, redémarre mon poste et tente à nouveau la configuration CRM. Cette fois-ci le message est explicit, et m’indique qu’il est nécessaire de télécharger une version de l’assistant de connexion Microsoft. il m’est d’ailleurs en plus suggéré deux liens :

Il suffit donc d’installer la version correspondante à son système; L’installation prends que quelques instants et un redémarrage est nécessaire.

image

Après installation, le niveau de version est inférieure à celle que je possédais auparavant, et me retrouve descendu en 7.250.4259.0

image

Je tente de configurer à nouveau mon client CRM, et là par magie tout fonctionne parfaitement. Le fichier de log ne montre ni erreurs, ni avertissements et tout se passe correctement !

image

Cela s’explique désormais, en trouvant cet article pour la version CRM 2011 http://support.microsoft.com/kb/2696603

Mais alors, comment en arriver là  ? Comme le poste sur lequel je me trouve est “presque frais”, j’ai donc installer l’assistant Sign-In Microsoft Online pour une raison bien précise, ou le composant était surement inclus dans une autre installation…. La réponse, comme j’administre du Microsoft Azure, du Lync, SharePoint Online, Office 365, … C’est avec les composants PowerShell d’administration, que j’ai du ajouter l’assistant de connexion Microsoft Online. Mais à présent que la version est descendue, puis-je encore faire de l’administration des services Microsoft Online ?

image

Oh, comme par hasard me voilà dans une situation où il ne m’est plus possible de me connecter aux services Microsoft Online avec PowerShell, mais je peux jouir des services de CRM Online depuis Outlook !!! Soit l’un, soit l’autre ?

Qu’il y a t’il comme version de l’assistant de connexion MS Online, connue en ligne ?

   

Si on fait la mise à jour en 7.250.43030, le client CRM continue de fonctionner mais il n’est pas possible de se connecter aux services en ligne Microsoft à l’aide de PowerShell.

Puis si on passe à la version bêta 7.250.4551, nous ne sommes plus capable de se connecter à CRM Online depuis le client Outlook, mais il est à présent possible de se connecter à Microsoft Online en PowerShell.

Et enfin, si on utilise la version 7.250.4556.0 (la plus récente à ma connaissance), il est toujours possible d’administrer Office 365 en PowerShell, mais la connexion à CRM Online ne fonctionne toujours pas !

Au final ? Nous avons donc bien un conflit important ici, car nous découvrons qu’il n’est pas possible d’avoir à la fois les prérequis pour le client Dynamics CRM Online et les prérequis pour l’administration des services Microsoft Online, un comble ! En fait pour mieux comprendre, le client CRM pour Outlook nécessite l’assistant en version 2.. Alors que pour PowerShell, il faut la version 7. Il y a une confusion pour l’utilisateur, car lorsque l’on télécharge le client 2.1, la Build est soit 7.250.4259.0 ou 7.250.43030. Comment par 7.x, c’est là que la confusion commence. C’est à partir de la version 7.250.4551 que nous avons l’assistant Microsoft Online Sign-In en version 7. Mais il n’est pas possible d’avoir à la fois la version 2.1 et 7.x sur un même poste; Alors à ce jour, et à ma connaissance, il n’est pas possible d’avoir le client CRM pour Outlook fonctionnel, tout en ayant accès aux services d’administration Microsoft Online via PowerShell. Ce sera donc soit l’un, soit l’autre; A vous de choisir !

avr. 12
FIM DirSync erreur, ne peut démarrer avec une erreur 2149781504

image

Depuis quelques temps, j’ai découvert que je ne disposais plus de synchronisation DirSync. Pourtant j’ai deux serveurs en haute-disponibilité, un en local et un autre sur Azure. Les deux se sont mis à ne plus fonctionner du jour au lendemain.

Si je regarde, les services “Windows Azure Active Directory Sync” et “Forefront Identity Manager Synchronization Service” sont arrêtés. Dans les journaux d’évènement, j’ai les erreurs ID 7001 et 7024 indiquant les problèmes de dépendances et que le service FIM Sync ne peut démarrer avec l’erreur 2149781504.

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:09:42
Event ID: 7024
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Forefront Identity Manager Synchronization Service service terminated with the following service-specific error:
%%2149781504

Log Name: System
Source: Service Control Manager
Date: 12/04/2014 13:05:01
Event ID: 7001
Task Category: None
Level: Error
Keywords: Classic
User: N/A
Computer: DIRSYNC.3sr.local
Description:
The Windows Azure Active Directory Sync Service service depends on the Forefront Identity Manager Synchronization Service service which failed to start because of the following error:
The service has returned a service-specific error code.

Après suppression et réinstallation, mise à jour en dernière version, redémarrage, reconfiguration, réparation MSI, … Bref, aucune solution standard permet de relancer la synchronisation.

Si je regarde en détail, ce problème est apparu après un redémarrage du serveur. Ce redémarrage fait suite à une série de mises à jour Microsoft. Et parmi elles, une attire mon attention

image

La mise à jour GDR 3128 de SQL Server 2012 (KB 2793634) a été installé sur les deux serveurs qui présentent le problème. Alors, il suffit donc de désinstaller cette mise à jour puis on désinstalle DirSync également ensuite.

image

Après la désinstallation de la mise à jour SQL GDR 3128, puis des composants FIM DirSync faites un redémarrage du serveur. Après le redémarrage, tentez à nouveau l’installation de DirSync. Profitez ici de mettre à niveau DirSync si besoin, pour cela voir mon article précédent : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=299

Après l’installation de DirSync, n’oubliez pas de remettre à nouveau vos paramètres de filtrage (Filtrage, Containers, …) avant d’autoriser une première synchronisation. Puis vous vous apercevrez que tout est rentré dans l’ordre à nouveau !.

Cette mise à jour SQL pose donc bien un problème direct avec l’outil de synchronisation Azure Active Directory (DirSync), car le simple fait de la désinstaller permet à nouveau une synchronisation.

avr. 06
Recevoir une notification d’expiration de mot de passe grâce à PowerShell

image

Vous avez été peu être confronté un jour, à vous rendre compte que le mot de passe de votre compte (ou ceux de vos utilisateurs) est expiré. Ceci n'est pas un problème lorsque vous êtes au bureau avec une station membre du domaine, une notification vous sera proposée pour changer votre mot de passe directement depuis le Secure Logon Screen.

Mais imaginons que vous avez une infrastructure de VM sur Azure dédiée, avec une Active Directory uniquement en mode Cloud sans VPN site à site … ? Dans ce cas, il ne sera pas possible d'effectuer le changement de mot de passe depuis l'écran de login, d'autant que par défaut sur les serveurs la pré-authentification RDP (NLA) est activée. Alors, soit il faut désactiver le NLA. Mais dans ce cas, cela baisse le niveau de sécurité. Sinon, l'autre option consiste à avertir les utilisateurs que leurs mots de passe vont expirer. C'est cette option que je décris ici.

Pour cela, j'utilise PowerShell avec le script ci-dessous. Il suffit de configurer une tâche planifiée qui s'exécute quotidiennement. Il suffit de modifier les variables surlignés en jaune, et de le paramétrer sur l'un des serveurs disposants du module PowerShell Active Directory.

Contenu du script :

# Variables
$smtpServer = "smtp.domain.local" 
$from = alert-password@domain.local
$smtp_username = "DOMAIN\SmtpUser" 
$smtp_password = ConvertTo-SecureString "Mot2Pass" -AsPlainText -Force 
$smtp_credentials = New-Object System.Management.Automation.PSCredential ($smtp_username, $smtp_password)
$expireindays = 20 
$maxPasswordAge = 90 
$OUpath = "OU=HelpDeskUsers,OU=IT,DC=domain,DC=local" 
$today = (get-date)

 

# Recherche des utilisateurs activés qui ont un mot de passe qui expire
$users = Get-ADUser -SearchBase $OUpath -Properties GivenName,mail,PasswordLastSet -Filter {(PasswordNeverExpires -eq "False") -and (Enabled -eq "True")}
foreach ($user in $users)

{
    # Informations du compte utilisateur  
    $Name = $user.GivenName
    $emailaddress = $user.mail

    # Recherche en jours de la dernière modification du mot de passe
    $passwordSetDate = $user.PasswordLastSet
    $lastset_days = (New-TimeSpan -Start $today -End $passwordSetDate).Days

    # Expire dans x jours en comparaison avec la date de modification, et la durée max autorisée
    $expireson = $lastset_days + $maxPasswordAge 

    # Préparation du message email  
    $subject="IT Services : Attention, expiration du mot de passe dans $expireson jours"      
    $body ="
    Bonjour $name,
    <p> Votre mot de passe IT va &ecirctre expir&eacute dans $expireson jours.<br>
    Merci de vous connecter d'ici ce d&eacutelai et d'effectuer la modification du mot de passe.<br>

    Au del&agrave de ce d&eacutelai, vous ne pourrez plus vous connecter et vous devrez contacter votre administrateur.
    <p>Merci de votre compr&eacutehension<br> 
    </P>"  

    # Envoi du mail si l'expiration est < 20 jours  
    if ($expireson -lt $expireindays)
    {
        echo "Attention : Le compte de $Name expire bientôt ($expireson jours). Envoi d'un mail vers $emailaddress en cours"       
Send-Mailmessage -smtpServer $smtpServer -from $from -to $emailaddress -subject $subject -body $body -bodyasHTML -priority High -credential $smtp_credentials  
    }
else 
{
        echo "Information : Le compte de $Name expire dans $expireson jours. Aucun émail vers $emailaddress ne sera envoyé"
}
}

 

 

mars 23
Le 8 Avril 2014, la fin de Windows XP seulement ? et du support de Forefront UAG SP2 aussi !

image

En lisant Internet, on dirait que le 8 Avril ça va être la fin du monde presque, mais la fin de quoi en fait ? De Windows XP seulement ?

Fin de Windows XP, bien entendu !

Donc en effet, oui c’est surtout la fin de Windows XP en ce mardi 8 Avril 2014 que tout le monde retient, que certains se rappellent surement encore de Whistler ! C’était il y a 12 ans maintenant ! Il nous a bien rendu service, même si je me rappelle de la peur de tout le monde (entreprise et particuliers) avec le Service Pack 2, et que le système était un peu désaimé à cette période. Et aujourd’hui, certains ne souhaitent plus le quitter au point de devenir insociable en famille :

Le fait d’utiliser Windows XP en soi n’est pas interdit, mais l’arrêt des mises à jours de sécurité, de l’intérêt des développeurs, etc… fait que le système vous forcera tôt ou tard à devoir changer de système. Sinon, Microsoft fournit un outil de migration simplifiée et complet : http://windows.microsoft.com/fr-fr/windows7/products/features/windows-easy-transfer

Mais office 2003 également !

Et bien entendu, la version Office XP qui est arrivé presque en même temps que Windows XP? mais très vite remplacé par Office 2003 arrive lui aussi à terme. Il est donc conseillé là encore de prévoir de mettre à jour vos versions d’Office vers les versions 2010 voire 2013 directement.

Et concernant Forefront UAG 2010 ?

Le produit, bien qu’arrêté d’un point de vue développement, est toujours supporté à ce jour. Cependant, souvent les directions informatiques ne font pas attention au niveau de Service Pack minimum. Donc ce sera justement à partir du 8 Avril que le Service Pack 2 ne sera plus supporté ! Il faut donc prévoir, pour les retardataires, une mise à jour vers le Service Pack 3 Rollup 1, voire directement le Service Pack 4.

Products Released

Lifecycle Start Date

Mainstream Support End Date

Extended Support End Date

Service Pack Support End Date

Forefront Unified Access Gateway 2010

mardi 26 janvier 2010

mardi 14 avril 2015

mardi 14 avril 2020

mardi 12 avril 2011

Forefront Unified Access Gateway 2010 Service Pack 1

vendredi 10 décembre 2010

Not Applicable

Not Applicable

mardi 8 octobre 2013

Forefront Unified Access Gateway 2010 Service Pack 2

lundi 6 août 2012

Not Applicable

Not Applicable

mardi 8 avril 2014

Forefront Unified Access Gateway 2010 Service Pack 3

lundi 18 février 2013

Not Applicable

Not Applicable

mardi 13 janvier 2015

Forefront Unified Access Gateway 2010 Service Pack 4

mercredi 20 novembre 2013

Review Note*

Review Note*

 

* Support ends 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. For more information, please see the service pack policy at http://support.microsoft.com/lifecycle/#ServicePackSupport

Et si il y avait des bonnes nouvelles aussi prévue pour le 8 Avril 2014 ?

Mais bien sûr qu’il y a toujours des bonnes nouvelles, par exemple il est prévu que la mise à jour Windows 8.1 Update 1 soit publiquement disponible justement le 8 Avril 2014, coïncidence ?

image Encore une autre bonne nouvelle ? Oui mais celle-ci est plus personnelle, car c’est en ce prochain mardi 8 Avril 2014 que je fêterai mes 33 ans, où ce nombre d’années coïncidence avec le numéro de mon département qui plus est !

mars 23
Perte des paramètres réseaux pour les machines virtuelles, après une maintenance Azure ?

image

En tant qu’abonné Microsoft Azure, vous deviez recevoir de nombreuses informations par mail de la part de Microsoft Azure. Souvent pour annoncer des nouveautés et la disponibilité générale de nouvelles fonctionnalités. Mais aussi, plus rarement, des avertissements concernant une maintenance…

Cette maintenance n’aura pas vraiment d’impact, surtout si vous avez crée un groupe de haute disponibilité dans Azure. Car en effet, lors des maintenances Microsoft n’impacte jamais 2 régions en même temps. Ce que j’ai pu remarqué néanmoins, à chaque maintenance les machines virtuelles ont été redémarrées et ont perdu des paramètres réseaux spécifiques. Il devient donc impossible de se reconnecter en RDP sur les machines virtuelles à l’aide d’un compte du domaine, seulement à l’aide de comptes locaux. Et bien entendu, les services inhérents à Active Directory ne sont plus fonctionnels.

Si on regarde de plus près, c’est comme si la carte réseau avait été changée car l’ancienne est devenue en périphérique cachée. Pour être supporté, je rappelle qu’il ne faut pas mettre d’adresse IP statique sur les machines virtuelles Azure; Donc il n’est pas important de voir ce point ici. Ensuite les paramètres DNS peuvent (et doivent souvent) être distribués simplement par les paramètres des serveurs DNS du Virtual Network. Mais alors en quoi cela peut poser un problème … ? Il reste en effet les paramètres du suffixe DNS, qui a disparu, et la machine se retrouve avec cloudapp.net par défaut.

On peut aller plus loin, car il n’y a pas les paramètres de Register DNS qui sont revenus par défaut aussi pour les clients membres d’un domaine Active Directory. Et pour finir sur cette introduction, qui dit donc Active Directory dit contrôleurs de domaine. N’avions pas nous appris que les meilleurs pratiques étaient de croiser les DNS entre eux ? C’est à dire que par exemple avec 2 DC (A et B), il faut que le DCA utiliser DCB en tant que serveur DNS primaire, puis lui-même en secondaire; et vice-versa pour DCB.

Nous voyons donc que cette réinitialisation réseau suite à une maintenance Azure peut avoir des impacts sur le fonctionnement de la disponibilité des machines virtuelles, même si on utilise les fonctions de haute-disponibilité natives. Cela concerne dans ce cas-là, le scénario de machines virtuelles membre d’une forêt Active Directory.

La solution ? La solution idéale, serait bien entendu que les services réseaux d’Azure fournissent la possibilité de définir un paramètre pour les suffixes DNS. Nous serions déjà capable ici de gérer 80% du problème, puisque rien que ce paramètre permettrait de localiser à nouveau les ressources du domaine. Cette fonction n’est malheureusement pas disponible encore à ce jour, mais je vous invite très fortement à ajouter un vote au service Feedback d’Azure http://feedback.windowsazure.com/forums/217313-networking-dns-traffic-manager-vpn-vnet/suggestions/4932601-possibility-to-set-a-dns-suffix-on-azure-networks

Et sinon, devons-nous attendre que Microsoft fournisse une option ? Heureusement la réponse est non, à tout problème une solution. Il est par exemple très facile à l’aide de quelques lignes PowerShell de définir les paramètres du suffixe DNS, et par la même occasion d’activer l’enregistrement dynamique.

$dns_suffix = '3sr.ad'
$reg_path = "HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces"
$get_dnsdomain = Get-WmiObject -Class Win32_NetworkAdapterConfiguration -Filter IPEnabled=TRUE
$interface_guid = $get_dnsdomain.SettingID
reg add $reg_path\$interface_guid /v Domain /t REG_SZ /d "$dns_suffix" /f
$get_NICinfo = Get-NetConnectionProfile | Select InterfaceAlias
$interface_alias = $get_NICinfo.InterfaceAlias
netsh interface ipv4 set dnsservers name="$interface_alias" source=dhcp register=both

On peut même imaginer de faire évoluer le script pour prendre en compte des paramètres spécifiques DNS, pour gérer les paramètres statiques des contrôleurs de domaine. Il suffit de rajouter, en plus du précédent script, deux commandes netsh supplémentaires en fonction des adresses IP des serveurs DNS (uniquement pour les contrôleurs de domaine croisés, car logiquement les paramètres doivent être fournis par le DHCP d’Azure).

netsh interface ipv4 set dns name="$interface_alias" source=static address=$dns_server1 register=both
netsh interface ipv4 add dnsserver name="$interface_alias" address=$dns_server2 index=2

Alors naturellement, on peut se dire : “Je vais créer une GPO, pour rajouter ça en démarrage automatique pour mes serveurs virtuels dans Azure, facile !” … Ma réponse est non, cela ne fonctionnera pas ! Pourquoi, parce que tout simplement, la machine après le redémarrage n’aura plus de suffixe DNS, et ne pourra donc plus localiser les ressources Active Directory, donc GPO inclus ! L’époque du autoexec.bat étant révolue, il faudra donc créer une stratégie de groupe locale, à l’aide de gpedit.msc !

Ce scénario est exactement pareil lorsque votre machine est en mode Deallocated. C’est à dire quand elle est totalement coupée, puis restaurée ensuite. Vous y perdez tous vos paramètres réseaux. L’utilisation de ce type de script de manière automatique, vous évitera de perdre du temps, mais en plus cela deviendra moins gênant d’arrêter plus régulièrement les consommations de vos machines virtuelles, et donc moins cher !

A noter que si vous avez également des besoins d’utilisations d’adresses IP “statiques” pour vos machines virtuelles, sachez que désormais il est possible de créer une réservation. Ainsi, vos machines virtuelles auront l’adresse IP que vous aurez défini. Ceci n’est possible que via PowerShell Azure, en s’assurant d’avoir la dernière version possible : Set-AzureStaticVNetIP -IPAddress 192.168.0.43

Il ne devrai donc exister plus aucune problématiques réseaux désormais, afin que vos projets Azure deviennent possible dès à présent !

mars 02
Nouvelle version de DirSync, comment effectuer une mise à jour ?

Microsoft met régulièrement à jour l’outil DirSync qui permet de synchroniser les comptes d’une Active Directory On-Premises vers Windows Azure Active Directory (WAD). Ainsi, de nouvelles fonctionnalités sont présentes et bien souvent de nouveaux attributs peuvent être synchronisés.

Suite à l’arrivé de la nouvelle fonctionnalité S/Mime dans Office 365 (http://blogs.office.com/2014/02/26/smime-encryption-now-in-office-365 ), il va donc falloir mettre à jour DirSync. Car si vous souhaitez utilisez cette fonction de chiffrement pour Office 365, il est nécessaire d’avoir la version 6635.0043.

Tout d’abord, le téléchargement de la dernière version de DirSync est toujours disponible avec la même URL : http://go.microsoft.com/fwlink/?LinkID=278924. La mise à jour de DirSync peut se faire directement en In-Place Upgrade, à condition que vous aviez une version au moins en 6385.0012. Si vous êtes sur une version antérieure, il faudra désinstaller totalement le client DirSync avant de pouvoir installer la nouvelle version.

Si vous souhaitez connaître l’historique des versions de DirSync : http://social.technet.microsoft.com/wiki/contents/articles/18429.windows-azure-active-directory-sync-tool-version-release-history.aspx A l’heure ou j’écris cet article, la nouvelle version n’est pas encore indiquée, mais cela le sera d’ici peu.

Lors de la mise à jour InPlace, la configuration est détectée et l'a mise à jour se fait normalement.

clip_image003clip_image004

Il faudra tout de même effectuer l’assistant de configuration, afin d’indiquer vos options et vos identifiants (WAD et AD).

clip_image005

A l’aide de cette nouvelle version, on voit bien que l’attribut userSMIMECertificate est déjà ajouté et prêt à être synchronisé. Vous pouvez connaître les évolutions des attributs pris en charge sur le Wiki : http://social.technet.microsoft.com/wiki/contents/articles/19901.list-of-attributes-that-are-synced-by-the-windows-azure-active-directory-sync-tool.aspx 

clip_image006

A noter que si vous aviez des paramètres personnalisés (containers spécifiques, ..) dans votre précédente configuration avant la mise à jour, tout va être repris dans la nouvelle installation sauf … Oui, seul les paramètres de filtres du connecteur sont réinitialisés. Pensez-donc à les remettre ensuite Clignement d'œil

clip_image008

févr. 10
Comment mettre en place une connectivité réseau entre deux abonnements Azure différents à l’aide d’un Cisco

clip_image002

Il se peut que vous disposiez de plusieurs abonnements Windows Azure, surement grâce à certains avantages (MPN, MSDN, …). Lorsque vous créez un réseau virtuel dans Azure, vous devez indiquer à quel abonnement il doit être assigné. Cela implique donc, qu’il n’est pas possible de faire communiquer les deux souscriptions entre elles même si vous êtes bien un seul et unique propriétaire. Dans ce scénario, nous allons utiliser le réseau VPN Site à Site à l’aide d’un routeur On-Premises pour permettre le routage complet des deux réseaux virtuels.

Mais pourquoi faire ? Alors le premier scénario va concerner surtout des personnes IT (MVP, SSII, Réseaux MPN, …) qui souhaitent exploiter au mieux les différents avantages Windows Azure acquis à travers différents programmes. Ceci est en effet mon cas personnellement. Mais savez-vous que l’on ne peut pas exposer un réseau virtuel Azure sur deux affinités ? Il n’est pas possible aujourd’hui de faire communiquer un réseau en Europe de L’ouest avec un réseau en Asie ou en Amérique. Cette technique, peut donc permettre de créer des ressources sur les différentes plaques géographiques et permettre une communication réseau entre elles.

Pour revenir à mon cas, j’ai donc deux abonnements Azure. Nous allons appeler le premier A avec un subnet en 192.168.100.0/24 et le second B qui aura le réseau 192.168.80.0/24.

image

Tout d’abord, il faut s’assurer qu’il y a bien un VPN Site à Site configuré entre le réseau Azure A et le réseau On-Premises. Pour cela, regardez mon précédent article qui décrit sa mise en œuvre : http://www.alexgiraud.net/blog/Lists/Billets/Post.aspx?ID=295

Maintenant, il va falloir faire à peu près la même chose pour le second réseau, avec quelques petites exceptions. Nous allons donc créer un second réseau local, en utilisant la même adresse IP de passerelle VPN mais avec le second abonnement désormais. Et c’est là où il faut rajouter dans l’espace d’adressage local, le sous-réseau de l’autre abonnement (en plus du réseau local On-Premises). Le réseau sera donc considéré comme local pour Azure.
image

Après on lance la configuration du nouveau réseau 192.168.80.0/24 sur le nouvel abonnement, et on y assigne en connexion VPN Site à Site le nouveau réseau local. Pour terminer on créer la passerelle VPN et on récupère la clé pré-partagée (pour plus de détails voir mon précédent article). Dans l’impression écran ci-dessous, mon réseau VPN est déjà connecté ; ne pas en tenir compte.
clip_image008

A présent, il faut faire de la configuration Cisco … et oui encore J Mais si vous téléchargez le script généré, puis vous l’appliquez, votre ancienne configuration VPN Site à Site ne fonctionnera plus. Ici l’objectif est bien de faire marcher au même moment les deux VPN Site à Site. De plus, nous avons des points communs de configuration, donc inutile de dupliquer les objets de configuration Cisco.

Vous pouvez conserver les objets de configuration IkeProposal, IkePolicy et IkeKeyring de la configuration Cisco. Il reste seulement dans la configuration de Keyring à rajouter un nouveau peer. Vous y indiquer la pre-shared key associée.
image

Ensuite vous devez créer un nouveau profil Ike. Vous pouvez copier/coller le précédent profil et y changer seulement l’adresse IP publique. Vous devez conserver les paramètres de keyring.
clip_image012

A présent, il faut créer les paramètres IPSec. Hélas, il n’est pas possible de mutualiser les objets de configuration ici. Donc vous devez dupliquer les configurations Crypto Cisco. Dans mon cas j’ai mis un 2 pour différencier les paramètres. Attention, pensez bien à mettre à jour le nom du profil IKE (étape juste au-dessus) en fonction du nom que vous lui avez assigné.
clip_image014

Avant dernière étape, on va créer le tunnel. Dans le script fourni par Azure, il assigne un IP 169.254.0.1. Nous ne pouvons pas la réutiliser, donc ici j’ai mis la 169.253.0.1 pour éviter un overlap. Ensuite, il s’agit d’indiquer les adresses IP publiques et d’associer le profil IPSec que l’on vient juste de créer à l’étape précédente.
clip_image016

Et enfin pour terminer, les règles d’accès et de routage ! On donc rajouter une règle de routage et une règle d’accès comme pour le premier tunnel :

ip route 192.168.80.0 255.255.255.0 Tunnel2
access-list 101 permit ip 192.168.217.0 0.0.0.255 192.168.80.0 0.0.0.255

Normalement, à ce point-là votre réseau On-premises peut communiquer vers le nouveau réseau Azure, donc en d’autres termes seul le réseau On-Premises peut échanger des données avec les deux abonnements, mais pas les abonnements entre eux. Alors il suffit de rajouter une nouvelle access-list qui permet la communication entre le réseau 192.168.100.0/24 et 192.168.80.0/24.

access-list 101 permit ip 192.168.80.0 0.0.0.255 192.168.100.0 0.0.0.255

Et voilà ! Maintenant, vos deux réseaux Azure étant sur deux abonnements différents peuvent communiquer entre eux. Il sera possible de mettre en place des Cloud Services,… répartis sur deux affinités différentes tout en assurant une intercommunication. Cependant cela utilise votre réseau On-Premises pour assurer le routage. Alors la latence sera plus longue que prévue. Dans mon cas, voilà un exemple d’un ping depuis le réseau Azure B vers le réseau On-Premises et le réseau Azure A. On y comprend que passer un seul tunnel apporte une latence de 40 à 50ms max, alors que de repasser à nouveau par un second tunnel la latence est environ de 80/90ms.
clip_image018

1 - 10Suivante
MVP Forefront

 ‭(Masqué)‬ Liens d'administration