Azure AD Connect – la version 1.2.65.0 est disponible

La version 1.2.65.0 est disponible en téléchargement. Comme d’habitude, de nouvelles fonctions sont disponibles ainsi que des corrections des problèmes connus.

Plus de détails sur [cette page]

Informations de la page officielle:

Nouvelles fonctionnalités et améliorations:

  • Changed the functionality of attribute write-back to ensure hosted voice-mail is working as expected. Under certain scenarios, Azure AD was overwriting the msExchUcVoicemailSettings attribute during write-back with a null value. Azure AD will now no longer clear the on-premises value of this attribute if the cloud value is not set.
  • Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to Azure AD. These same diagnostics can also be run directly through Powershell using the Test- AdSyncAzureServiceConnectivity Cmdlet.
  • Added diagnostics in the Azure AD Connect wizard to investigate and identify Connectivity issues to AD. These same diagnostics can also be run directly through Powershell using the Start-ConnectivityValidation function in the ADConnectivityTools Powershell module. For more information see What is the ADConnectivityTool PowerShell Module?
  • Added an AD schema version pre-check for Hybrid Azure Active Directory Join and device write-back
  • Changed the Directory Extension page attribute search to be non-case sensitive.
  • Added full support for TLS 1.2. This release supports all other protocols being disabled and only TLS 1.2 being enabled on the machine where Azure AD Connect is installed. For more information see TLS 1.2 enforcement for Azure AD Connect

Correction de problèmes connus:

  • Fixed a bug where Azure AD Connect Upgrade would fail if SQL Always On was being used.
  • Fixed a bug to correctly parse OU names that contain a forward slash.
  • Fixed an issue where Pass-Through Authentication would be disabled for a clean install in staging mode.
  • Fixed a bug that prevented the PowerShell module to be loaded when running the Troubleshooting tools
  • Fixed a bug that would block customers from using numeric values in the first character of a host name.
  • Fixed a bug where Azure AD Connect would allow invalid partitions and container selection
  • Fixed the “Invalid Password” error message when Desktop SSO is enabled.
  • Various Bug fixes for AD FS Trust Management
  • When configuring Device Writeback – fixed the schema check to look for the msDs-DeviceContainer object class (introduced on WS2012 R2)

Vous pouvez télécharger la dernière version depuis [cette page]

Quel intérêt à utiliser Ping Identity avec Azure AD Premium ?

 

Il y a quelques mois, Microsoft annonçait son partenariat avec Ping Identity pour renforcer son offre Azure AD Premium:

Mais cette annonce coïncidait avec l’annonce quelques semaines auparavant de la mise en preview d’une fonction de App Gateway au niveau d’Azure AD Connect (fonctionnel mais toujours en preview à ce jour). Ainsi, beaucoup de mes clients et contacts me demandaient au fil des semaines quel pouvait être l’intérêt pour eux d’utiliser Ping Identity alors que Microsoft fournissait maintenant une App Gateway permettant non seulement de publier des applications on-prem au niveau du portail Azure AD Premium sans l’obligation d’ouvrir des ports au niveau des firewall mais également de jouer des authentification sur l’annuaire Active Directory local sans déployer ADFS. Nous allons essayer de répondre à cette question dans cette article.

Déjà, revenons quelques instant sur l’offre Ping Identity. Ping Identity est l’entreprise leader dans le domaine des solutions de fédération d’identité pour les entreprises. Cette entreprise américaine a vraiment été un des pionniers en la matière, principalement pour les organisations avec des besoins complexes ne pouvant pas être couverts avec ADFS et Shibboleth. Mais depuis environ 18 mois, les offres Ping Identity ont été progressivement dépassées par les solutions de IDentity as a Service, qui rappelons le, propose notamment un système de fédération multi-tiers en mode SaaS. Ping Identity a essayé de réagir sur le segment IDaaS, mais leur architecture produit n’a pas convaincu, laissant le champs libre à Microsot, Centrify et Okta sur le marché IDaaS. Il fallait donc régir pour ce leader établi  de la fédération d’identité.

En septembre dernier, Microsoft annonçait donc son partenariat avec Ping Identity:

En parallèle, Microsoft proposa en private preview puis en public review la fonction App Gateway intégrée à Azure AD Connect avec notamment les possibilités suivantes:

  • Fournir un accès aux applications internes sans modification des firewall, des routeurs ou des reverse proxy
  • Sécurisation de l’accès aux applications internes via un mécanisme de “reverse VPN” basé sur la fonction bus d’Azure
  • Publication d’applications web internes utilisant IWA (Integrated Windows Authentication)
  • Publication d’applications Web utilisant “form-based access”
  • Publication d’applications publliées via la fonction Remote Desktop Gateway

Ces avancées notoires permettant nottamment à Microsoft de rattraper son retard sur la fonction Cloud Gateway proposé par Centrify via son offre IDaaS.

Que peut donc me fournir Ping Identity en plus de ces fonctions déjà très intéressantes ?

La raison principale de ce partenariat est de pouvoir traiter des applications web internes utilisant l’authentification de type headers HTTP.

Pour ce, il sera nécessaire d’installer un composant supplémentaire PingAccess au niveau du réseau local, ce composant communiquant avec Azure AD Premium et le connecteur Azure AD Connect:

Pour ce, il est possible directement au niveau de la console Azure AD Premium de publier de telles applications en indiquant quelles seront accédées en passant par le composant PingAccess:

Un des intérêts de cette combinaison est de “contourner” les options de sécurité assez faibles d’une authentification par headers Http en utilisant des APIs Azure spécifiquement développées pour faire communiquer Azure AD Premium et PingAccess: ainsi, il sera possible de définir des règles d’accès et de rôles qui seront transposées et traduites par le composant PingAccess depuis le RBAC Azure:

Quel avenir pour ce partenariat ?

Euhm… bonne question ! Pour ma part je ne suis pas convaincu par le fait que cette fonction sera suffisante a faire décoller le partenariat technologique et commercial, surtout que pour l’instant le modèle de pricing de PingAccess pour Azure AD est assez obscure, Ping Identity n’étant pas spécialement connu pour le côté bon marché de ses produits… (bon, après ce sont de très bons produits, tout se paye). De plus, au travers de mes différentes missions de consulting sur la partie IDaaS, ce type d’authentification (Headers Http) n’étaient pas la priorité des clients…

Un point stratégique important est de comprendre que les offres de IDaaS vont petit à petit éliminer le besoin de solution de fédération d’identité installées localement (ADFS, Shibboleth, Ping, ForgeRock, etc.) et vont remplacer sous forme de service SaaS l’ensemble des composants de fédération. Bien sur, pour des besoins très spécifiques, notamment en ce qui concerne des scénarios complexes dans des grandes entreprises, les passerelles de fédération d’identité installées localement ont encore de beaux jours devant elles, mais dans 5 ou 6 ans ? Pas certain !

Bon, à la fin, cela serait peut-être plus simple si Microsoft rachetait Ping Identity, non ? 😉

Les différents scénarios possibles selon la topologie d’entreprise avec Azure AD Connect

adconnect je suis tombé qq peu par hasard sur un article (US) qui me semble intéressant pour un architecte débutant dans les problématiques de synchronisation liées à Azure AD Connect. Cet article liste les différentes topologies d’entreprise existantes possibles, et les scénarios d’implémentation Azure AD Connect pour chaque situation. Quand un scénario n’est pas supporté officiellement par Microsoft, cela est notifié dans l’article, ce qui est important et parfois qq peu obscure à décrypter (supporté ou pas supporté…) pour les débutant.

Bref, l’article n’est pas révolutionnaire en soi, mais constitue un bon point de départ pour un consultant déchiffrant ce nouveau monde. L’article est disponible ici: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-topologies/

Bonne lecture 😉

Comparatif DirSync vs Azure AD Sync vs Azure AD Connect

windows_azure_smallDeuxième article remarquable sur le blog de Maxime: un article de synthèse réalisant un comparatif des trois solutions de “synchronisation” ou de “mise à jour des informations” entre les données locales et le service Azure AD (service nécessaire notamment à l’utilisation d’Office365)

Le problème de ce type d’article est le côté “périssable” de l’image instantanée des fonctions décrites, donc peu de personnes font l’effort de les écrire, encore merci à Maxime pour son travail de synthèse.

L’article est accessible [ ici ]