Cela fait quelques années que je conçoit et dépanne des infrastructures d’annuaire Active Directory (pour donner une idée, j’ai commencé avec NT 4.0). On pourrait croire que c’est une routine et bien non, on a toujours quelque chose à apprendre de chaque projet de mise en œuvre ou de migration.
Le changement de mot de passe dans AD
Lorsqu’un utilisateur change son mot de passe dans l’AD depuis son poste de travail, cette information est immédiatement transmise au contrôleur de domaine hébergeant le rôle de PDCE. Le but est de pouvoir traiter l’authentification de l’utilisateur avec son nouveau mot de passe alors que ce dernier n’est pas nécessairement répliqué sur tous les contrôleurs dans le domaine. Donc normalement, lorsqu’un utilisateur change son mot de passe, il peut immédiatement l’utiliser pour s’authentifier.
Question, peut-il encore utiliser l’ancien?
Voila une bonne question. Du point de vue de l’authentification d’un utilisateur au niveau de la mire d’authentification Windows, la réponse est non. Par contre pour les accès réseaux, c’est une autre histoire. Dans le cas de mon dernier projet, mon client constatait qu’après avoir changé son mot de passe sur un contrôleur de domaine, il était toujours possible d’établir une connexion LDAP authentifiée avec l’ancien mot de passe. Le comportement était reproductible pendant une période de temps d’environ une heure. Voila déjà pas mal d’informations pour qualifier la problématique rencontrée.
Ce comportement est du à une fonctionnalité qui a été introduite avec le Service Pack 1 de Windows 2003. Celle-ci est documenté par la KB906305. L’utilisateur est effectivement capable d’utiliser son ancien mot de passe mais uniquement pour les accès réseaux. Ce comportement permet aux utilisateurs connectés de ne pas être bloqué, c’est surtout intéressant pour les comptes de services utilisés par des processus distribués. Sans cette fonctionnalité, changer un mot de passe de compte de service peut s’avérer complexe car tous les services devront être arrêtés et reconfigurés.
Selon la KB906305, cela ne concerne que les accès réseau effectués en NTLM. On peut même ajouter les accès LDAP/LDAPS, ce qui était le cas de mon client, dont les contrôleurs de domaine installés avec la dernière génération de systèmes d’exploitation Microsoft. La période pendant laquelle il est possible d’utiliser les deux mots de passe est d’une heure. C’est une clé de registre qui doit impérativement être configurée sur tous les contrôleurs de domaine.
Est-ce une faille de sécurité?
Du point de vue de la KB906305, non. Seul l’utilisateur qui a changé son mot de passe connait à la fois son mot de passe actuel et son ancien mot de passe. Dans certains environnements, où la sécurité doit être renforcée, il peut être tentant de réduire la durée de vie pendant laquelle l’ancien mot de passe est utilisable. Si une telle exigence existe, c’est peut être qu’il y a un besoin d’authentification forte des utilisateurs, que ceux-ci se connecte depuis les réseaux de l’entreprise ou depuis l’extérieur.
On a effectivement toujours quelque chose à apprendre. C’est une fonctionnalité que je pensais bien connaitre mais je ne pensais pas qu’elle puisse aussi s’appliquer au contexte de mon client.
Benoits – Simple and Secure by Design but Business compliant
I expected to write this article a little bit later (with more details) but my former colleague Olivier DETILLEUX force me to write it now. Thank-you Olivier for challenging me!
DirectAccess in Windows 8 from 10000 feet altitude
This article will be based on the DirectAccess feature included in Windows 8 as presented during the BUILD conference. Don’t expect detailed information's in this article because :
It’s based on hand-experience of the Windows 8 BUILD
It’s only a developer Preview
There a huge amount of work for Microsoft (limited documentation)
Microsoft can remove some features if they does not comply with customers expectations or Microsoft quality requirements.
For theses reason, it is only a 10000 feet altitude view and not a deep dive article. I expect to spend more time in Windows 8 DirectAccess to write detailed article.
A long path since Windows 2008 R2
Long the path was since I began to write about DirectAccess. It was at TechEd Europe in 2008 at Barcelona. DirectAccess was strange to me but interesting. Stanislas Quastana and I wrote multiple article on our respective blogs, and gave sessions to Microsoft Techdays in France on the subject. We can say that DirectAccess is an old friend of mine with numerous projects on this technology. So interesting that I’m in the process of writing a book on it. Sorry this will be un my native language for my first book.
DirectAccess was introduced in Windows 2008 R2. We can consider this was a 1.0 release. UAG 2010 can be considered as a 1.5 release, including features that were not covered in the initial release. This was an opportunity for the UAG team (much more smaller that the Windows team), to prove that this product can be used in multiple scenarios. Tomorrow, with Windows 8, considered that all features introduced in UAG 2010 are now present in Windows 8 and enhanced.
DirectAccess Management console is dead
I expected to install my DirectAccess Management console, but this feature is no longer present. DirectAccess console have been merged in a new console. DAMC is dead, long life to Remote Access Management Console.
All start from the Server Manager console. At this point you can add multiple server to manage them from one central console. This feature will be useful for high-availability and multi-site features of DirectAccess. In our simple case, DirectAccess is a role based feature.
Note to the Networking team : A scenario based installation would be a cool feature. Imagine we can deploy Windows 8 at multiple site and configure DirectAccess remotely including IPHTTPS certificate provisioning, IPsec certificate provisioning, accounting, …
In my example, my Server Manager console will be used to configure DirectAccess on my local Server.
The Remote Access Management Console is a part of the Remote Access role. The Web Server role will be automatically added for multiple purpose. First for the IPHTTPS protocol, secondly for the Network Location Server. So no change since Windows Server 2008 R2 for this point.
Here is our first new feature. DirectAccess is offered a a part of the Remote Access Management console witch allow to use VPN. We will be able to offer DirectAccess and VPN service on the same Windows 8 box. This is a cool feature. In a recent customer case, DirectAccess clients were deployed around the world with an incomplete configuration (missing IPsec certificate). It was a challenge to fix this problem. With this feature, it would be easy to provide an alternate solution to connect to the company network to fix the problem.
The only sub-role we need is the DirectAccess and VPN(RAS). Note That this sub-role is also available in Windows 8 core mode. That’s cool for security!
installation process will be staring forward.
Once installed we are invited to launch the Express configuration Wizard. That a new approach of Windows 8 server manager. That’s incredible but even DirectAccess can be configured in few seconds. We’ll se how and why later.
The Remote Access Management Console offer three scenarios. In my case, I will only focus on DirectAccess only. That’s my primary focus for this post.
That’s my favorite screen. Now we have three deployment scenarios. As you can read in the interface, the Edge topology is similar to Windows Server 2008 R2/ UAG 2010 approach.
The second scenario catch my attention. The Back topology allow you to deploy DirectAccess behind a edge firewall. In this scenario, Direct Internet connectivity is not mandatory for DirectAccess. The primary consequence is that only IPHTTPS transition protocol will be used.
At the time of writing this article, I’m skeptical about this mode. If our Windows 8 Server have a single interface, how can you configure the Firewall policy rules and IPsec tunnels. At this time, I do not have enough information to have a clear opinion about this mode.
In my deployment scenario, I started with an Edge Topology. For this reason, I need two consecutive IPv4 addresses.
Express configuration is terminated. If we consider what we know about DirectAccess in Windows 7, there is a lot a prerequisites that Windows 8 did not ask for (PKI, certificate, …). We’ll see that later.
Another cool thing. DirectAccess now have a real PowerShell provider.
And many PowerShell command. If you remember Windows Server 2008 R2 and UAG 2010 times, the PowerShell script is only calling NETSH.EXE commands and importing registry keys in GPO!
Here is the status of my first Windows 8 DirectAccess enabled platform. It seems I have a problem with ISATAP. In Windows 2008 R2, the DNS record for ISATAP was automatically created. It seems this is not the case in Windows 8. We can notice that the dashboard view give us detailed information's on each component involved in DirectAccess and connected clients. But let start to fix the problem.
Hey, wait a minute, there a bunch of new in this screen : DNS64/NAT64. This feature is now a part of the Windows 8 DirectAccess implementation, not only UAG 2010 implementation. Great!
I need PowerShell to fix my problem before continuing. ISATAP host resolution is blocked by the GlobalQueryBlockList feature. I could use DNSCMD.EXE to solve the problem but we have a PowerShell provider for DNS now.
Let start by adding a host record for ISATAP with the with the Add-DNSServerResourceRecordA commandlet.
We have a host record but we need to allow ISATAP name resolution by removing ISATAP from the GlobalQueryBlockList.
The new GlobalQueryBlockList content will be operational only if we restart the DNS Server.
Note : I was a little bit lazy. I ran my command from my DNS servers. With Remote Management enabled by default it would have been smarter to run them remotely. In production, environments with multiple DNS Servers, reconfiguring the GlobalQueryBlockList remotely will be greatly appreciated.
And now let’s see DirectAccess from a 5000 feet altitude
Remote Access Management Console look like Windows 2008 R2 DAMC console or UAG 2010 console with just a few thing different.
First thing we can notice is that the console allow to manage DirectAccess and VPN feature remotely. This was impossible in Windows 2008 R2 and UAG 2010. Let start with the first step of a complete DirectAccess configuration : Clients :
In Windows 8 DirectAccess implementation, we now have the Manage Out scenario that was only available in UAG 2010. In UAG this scenario was called “Remote Management”. In this scenario, we only have infrastructure IPsec tunnels. This means that only computer have access to the corporate network, not the users.
Next step, identify clients. We can notice that the Windows 8 DirectAccess implementation does not offer the organizational unit filtering approach that was available in UAG 2010 SP1. But the console allow us to filter GPO according to a WMI filtering query. Only laptops, notebooks and tablets will be eligible for DirectAccess.
We can also notice that now the Windows 8 DirectAccess implementation natively support the Force tunneling mode without reconfiguring parameters in GPOs. Thanks ever so much!
Another great thing is that the DirectAccess Connectivity Assistant is now integrated in the Network management in Windows 8. In an other post we’ll see that it play an important role in the multi-site scenario (Geo cluster with DirectAccess!). At this point we can notice that Microsoft did not choose to use UNC path a probes for the DAC. Only Ping and HTTP are available. This is a good decision because UNC protocol is much more consuming than a ping and users need to have access to theses shares.
By default, Windows 8 DirectAccess implementation create it’s own DNS record and use it as a probe for the DAC. And now my favorite step. During express configuration I chose to deploy DirectAccess in a Edge topology scenario. I changed my mind and moved to Back topology. Primary consequence, only IPHTTPS will be available.
I new to interface bellow since Windows 2008 R2. Nothing should change but I noticed a few things. First we can use self-signed certificates for IPHTTPS. Whoa! We no longer need a public certificate for IPHTTPS protocol?
Not really, we can deploy DirectAccess with an self-signed IPHTTPS certificate but only if our DirectAccess infrastructure is composed of a single server. With multiple servers and multi-site scenario a public IPHTTPS certificate is still required.
The interface bellow allow us to select the internal ADCS role that will deliver certificate to DirectAccess clients and Servers. But there is something strange. Why the wizard present this configuration as an option? Yes. In some scenarios IPsec certificates would no longer be required for DirectAccess deployment. I do not have precise explanation on how it work, this is great for customers witch are no longer forced to deploy an ADCS infrastructure for DirectAccess (except for OTP scenarios, …).
In Windows 2008 R2 DirectAccess implementation, it is possible to host the Network Location Server locally. This is still the case in Windows 8. One noticeable change, is that we can use an self-signed certificate. It seems that DirectAccess will become less and less dependable from the ADCS role and certificates. Cool for customers but is it still secure. That a question I have no answer today.
There is no change at the configuration of the content of the NRPT. We can notice that’s my DNS server IPv6 address that will be used for internal DNS name resolving. In UAG implementation, it would be DNS64. Maybe a bug of because ISATAP was not operational while running the wizard, …
The DirectAccess/Networking team made a single error in their design. UAG interface was much more readable and usable. Please, change this. UAG interface was able to locate HRA and SCCM servers in Active Directory automatically. That was great, …
The final stage. And another surprise. Where is my star-war scenario (end to end)? I hope to see it one day. Otherwise, no noticeable change at this point.
My DirectAccess is now fully operational. As we can see some PowerShell commandlet executed. Hope to have some time for a deep dive in a fully configured DirectAccess Server in PowerShell.
But let start with a single command : Get-DAServer.
There is an interesting line : Teredo state Disabled. Interesting. This means that DirectAccess can work without Teredo and linked prerequisites (Two public IPv4 consecutives addresses)? Yes. That would be easier to deploy DirectAccess now! This also means that only IPHTTPS will be available. Consider that it is an Universal Bypass Protocol for NAT enabled DMZ.
Let see what other new feature we have in the configuration console, maybe on the task section on the right, …
Whoa! High availability is now a feature of Windows 8 DirectAccess Design, in NLB and HLB. Great. Hope that the configuration steps are much more easier than with UAG.
It teams always search tools for tracing activities. DirectAccess have native tracing tools on the client side. With Windows 8 DirectAccess implementation we have it in the console.
This feature is just an interface for the “NETSH.EXE TRACE START CAPTURE=YES TRACEFILE=c:\CAPTURE.ETL” command line, … Lazy admins will appreciate.
Last important feature of Windows 8 DirectAccess implementation is a great enhancement in accounting. In UAG 2010 SP1, we were able to trace computer and user activity. We had reporting capabilities but we had to generate our own reports.
That the end of this sneak preview of DirectAccess in Windows 8. There are multiple enhancements in this new release of DirectAccess and we only see the most visible. There are much more to say. The most important information is that DirectAccess in Windows 8 introduce all feature of UAG 2010 and even add some more (Multi-site). DirectAccess will be easier to deploy, many perquisites that were considered as show stoppers by customers will disappear. VPN/SSL Appliance vendors will have real competitor with this new DirectAccess. Next time we’ll se how it works on client side and what changed in the GPOs.
Personal note : Congratulation to the Windows Networking team and DirectAccess Team. You made a great job.
BenoitS – Simple and Secure By Design but Business Compliant