Archives de catégorie : Troubleshooting

Séance de Cluedo avec ADFS : Authentification ADFS en boucle sur Office 365

On est quelques un à s’être cassé les dents dessus. Le fameux cas ou quoi que l’on fasse nos utilisateurs de services fédérés avec la solution ADFS ne peuvent pas s’authentifier sur Office 365. C’est un cas que l’on peut reproduire avec toutes les versions d’ADFS. En fait, nos utilisateurs peuvent s’authentifier autant qu’ils le veulent, ça les ramène toujours à la mire d’authentification.

clip_image001

Sur ce sujet, Microsoft a écrit de beaux articles :

J’ai eu beau retourner ces articles dans tous les sens, impossible de trouver le pourquoi. J’avais juste quelques premières constatations. Quelque chose me disait qu’il y avait un coupable mais impossible de savoir comment le colonel moutarde avait tué dans la bibliothèque. Voilà quelles étaient mes premières constatations :

  • Si on s’authentifie avec un compte qui n’existe pas ou un mot de passe faux, tout se déroule normalement
  • Du point de vue ADFS, cela fonctionne, j’ai bien un Event qui m’indique qu’un ticket Kerberos a été délivré
  • Ça ne concerne pas tous les comptes (sinon c’est pas drôle)

Après quelques heures de recherche, j’ai exclus Office 365 de la liste des suspects, tout comme les F5 BIG-IP et même les serveurs Web Application Proxy. En procédant par élimination, il ne restait donc que les deux serveurs ADFS de ma ferme. Vu que j’arrivais toujours à reproduire le problème en bloquant l’un ou l’autre de mes serveurs ADFS, j’en ai donc conclus que le problème était partagé par les deux serveurs de la ferme. Plus la peine de descendre plus bas, le coupable est nécessairement à cet étage. C’est en observant le fonctionnement de la ferme ADFS avec des comptes pour lesquels cela fonctionne et d’autres pour lesquels cela ne fonctionne pas que j’ai mis le doigt dessus.

Lorsqu’on reprend le processus de fonctionnement d’ADFS de bout en bout, notre serveur ADFS doit interroger l’annuaire Active Directory. Dans mon contexte, mon infrastructure ADFS utilise un compte de service GMSA. Voyant un token ADFS généré, je me disais qu’il n’y avait pas de problème. Erreur de ma part. J’ai fini par comparer les ACL sur les comptes différents comptes et finir par m’apercevoir d’un détail qui me choquait :

clip_image002

Ça a l’air de rien mais cette permission change tout lorsqu’on regarde un utilisateur, ou même un device :

clip_image003

C’est étrange mais quand elle est là (et que le compte de service de votre ferme ADFS n’est pas membre du groupe Admin du domaine), c’est tout de suite beaucoup plus facile pour ADFS de fonctionner normalement. Avec ces quatre permissions magiques, l’authentification ADFS fonctionne comme un charme. Maintenant qui m’a mis sur la voie ? Une fonctionnalité méconnue d’Active Directory : Effective Permissions, un vieux truc introduit avec Windows Server 2008 R2 !

clip_image004

En comparant les permissions effectives entre un compte pour lequel ADFS fonctionnait et un pour lequel la même infrastructure ADFS ne fonctionnait pas, j’ai fini par comprendre qu’il y avait une différence entre mes deux comptes et trouver les permissions manquantes. Accessoirement, ces permissions sont décrites dans le schéma comme on peut le voir ci-dessous :

clip_image005

Vu que le schéma n’avait pas altéré, j’en ait déduit qu’il y a eu modification des permissions au niveau de la racine du domaine (pas glop). Ne restait donc plus qu’à propager les bonnes permissions.

BenoîtS – Simple and secure by design but Business compliant (with disruptive flag enabled)

DFSR Dirty Shutdown Recovery

Un sujet un peu “capilo-tracté” pour changer et un petit retour aux sources (Active Directory). Qu’est ce qui se passe au niveau DFSR lors d’un arrêt non planifié d’un contrôleur de domaine ou d’un serveur hébergeant le rôle DFS-R et participant à un groupe de réplication.

Pour rappel DFSR repose sur une base de données Jet qui va tracer tous les changements opérés sur les fichiers dépendant d’un replicated folder donné localisé sur un volume disque particulier. On comprend tout de suite que le bon fonctionnement de cette base de données est essentiel. Sans elle, DFSR n’est plus capable de répliquer les changements opérés localement ou de déterminer s’il doit prendre en comptes les mises à jour opérées sur les autre membres du groupe de réplication.

 

Avant c’était simple

DFSR a été introduit avec Windows 2003 mais réellement généralisé à partir de Windows Server 2008 où il était possible de basculer le SYSVOL vers DFSR avec l’utilitaire DFSRMIG.EXE. Depuis cette époque, lors d’un arrêt non planifié, on avait le message suivant dans le journal dédié à DFSR :

image

 

C’est clair, rien à faire, le système d’exploitation s’occupe de tout. Si le processus de recovery se passait bien, on avait un event 2214 :

image

 

ou 2216 dans le cas contraire :

image

Dans les deux cas, on n’avait rien à faire, DFSR s’occupait de tout. Mais ça c’était avant.

 

Mais c’était avant (2008 R2/2012)

Avec Windows Server 2012, Microsoft a considéré qu’il y avait un risque de perdre des données et que par défaut DFSR ne devait plus auto-réparer sa base de données.

image

 

L’event donne deux informations :

  • Premièrement, il faut que nous nous assurions de ne pas perdre de données lors de la remise en ligne, c’est de notre responsabilité
  • Deuxièmement, que la remise en ligne s’effectue à l’aide d’une ligne de commande qui doit être exécutée localement sur le serveur incriminé.

 

Cela devient problématique car en cas de crash d’un contrôleur de domaine, Active Directory est bien capable de revenir en ligne, le répertoire SYSVOL est bien partagé et visible par les utilisateur mais le contenu des GPO peut avoir été altéré et ne plus être cohérent avec les autres contrôleurs de domaine.

 

Comme Microsoft est cohérent, il a mis à disposition un correctif KB2663685 pour Windows 2008 R2 pour reproduire le mode de fonctionnement de Windows Server 2012. Tant que le correctif n’est pas généralisé sur tous les serveurs membre du groupe de réplication DFSR, le comportement du processus de recovery va donc varier. ce correctif permet aussi de configurer le comportement du processus de recovery avec la commande suivante :

wmic /namespace:\\root\microsoftdfs path dfsrmachineconfig set StopReplicationOnAutoRecovery=FALSE/TRUE

 

Maintenant c’est subtil (2012 R2)

Comme c’était pas encore assez compliqué, on change encore. Il faut lire un billet décrivant les changements opérés sur DFSR dans Windows 2012 R2 pour le comprendre :

clip_image002

 

Il faut comprendre que Microsoft a mis à disposition une clé de registre pour configurer le comportement de DFSR dans le scénario du “Dirty shutdown” mais n’a pas réussi à démontrer qu’il y a réellement risque de perte de données. La racine DFS de domaine gui prend en charge la réplication de SYSVOL échappe au processus de “Dirty shutdown”. Seulement pour lui, le recovery redevient automatique. C’est une bonne nouvelle pour les administrateurs Active Directory qui n’ont plus à se soucier du “Dirty shutdown” sur les contrôleurs de domaine Windows Server 2012 R2 (uniquement).

 

Conclusion

J’avais bien annoncé que le sujet était “capilo-tracté”. Donc pour faire simple un petit tableau pour résumer la situation :

  Windows 2008 Windows 2008 R2 (sans KB2663685) Windows 2008 R2 (avec KB2663685) Windows 2012 Windows 2012 R2
Automatic Dirty shutdown recovery pour SYSVOL Oui Oui Non Non Oui

Non sauf reconfiguration avec WMIC

 

BenoîtS – Simple and secure by Design but business compliant

DirectAccess advanced troubleshooting tip

Let’s start this new year with a small post on DirectAccess (DirectAccess remain in my good resolutions to-to list for another year ). So happy new year and wish you successful DirectAccess deployments.

 

When a DirectAccess client is not operational we have an option to collect logs. This feature is very useful because it generate an HTML file containing all required information for troubleshooting.

SNAGHTML44e8b8ec

In normal situations all required information are in this HTML file. But sometimes we need to investigate more (deep dive in DirectAccess troubleshooting). Have you ever seen that a CAB file is included in the automatically generated Email?

image

The process collect both static and interactive data. The second one is interesting because it’s based on ETL (Event Trace Log) available since Windows 7. This feature allow to generate trace for specific scenarios and one of them is very interesting among others :

SNAGHTML44f591ec

KB2859074 – DirectAccess Diagnostic document all information collected. And some of them were very useful for me during some DirectAccess deployments. Sometimes, relevant information included in theses logs may save you hours of painful troubleshooting.

 

BenoîtS – Simple and Secure by Design but Business compliant

Deploying DirectAccess with least privileges

Since Windows Server 2012, deploying DirectAccess became so simple, too simple (It’s by design now ). We just need domain admin privileges to perform the operation. That’s far away from a least privilege level. From a security guy point of view we should be able to deploy DirectAcecss with the least privileges as possible. fasten your seatbelt and take an aspirin, you’re welcome to that journey.

 

Let’s start easy

Let’s see how to perform a DirectAccess deployment with limited set of privilèges with a DirectAccess infrastructure based on Windows Server 2012. Starting point, this TechNet section :

image

 

According to this documentation, its possible and even documented :

  • GPOs must exists before configuration activation
  • User activating DirectAccess configuration must have “Full GPO permission” on created GPOs
  • GPOs should be linked but it’s not mandatory

 

I provided all theses detailed information to the Active Directory team. I was ready to deploy DirectAccess for my customer. That’s now that problems appears. First problem located in the Remote Access Management Console. I logged onto my URA server with an account having the following privileges :

  • Local administrator level of the URA Server
  • Full control permission on GPO “GPO DA CLIENT”
  • Full control permission on GPO “GPO DA SERVER”

0APPLYDABUG

OK, it’s not a problem, just a warning. Technically speaking, my user account performing the operation have no delegation to create and manage WMI filters in group policies for my Active Directory Domain. Could it be a problem? No, unless you need to use the “Enable DirectAccess for mobile computers only” Option. In my case, I don’t need this privilege.

 

I follow my path into DirectAcecss configuration without problem until activation process :

1APPLYDABUG

 

Technically, the wizard cant create GPOs with default name using my least privilege account. We will use the change link to see that deeper.

2APPLYDABUG

Simple problem and simple solution. The wizard try to create DirectAccess GPOs with default names. Because my account have least privileges, it’s not possible. Let solve this minor problem with the browse button and select our pre-existing GPOs.

3APPLYDABUG

One problem closed, a new one arise. It could be so simple. Here again, it’s just a warning. In my case, the wizard is unable to link my GPOs at the root of the Active Directory because my account does not have required privileges for that. This is only a warning. I will have to ask the Active Directory team to link my GPOs. From a security guy point of view it’s a good thing.

Until now, deploying DirectAccess with a least privilege account seems to be an easy thing. In illustration bellow I can the that the red cross icon was replaced with a simple warning. Let’s apply this configuration and celebrate a new successful DirectAccess deployment.

4APPLYDABUG

 

Ouch. Congratulations will have to wait. We have a major problem here.

5APPLYDABUG

 

Is there a doctor in the place?

Yes I need a doctor for that (now your aspirin should be useful). How is it possible to have a denied access error to a group policy witfor witch we have a “Full control” permission on a GPO. I need a doctor, the doctor with his tool. Doctor, would you lend my your sonic screwdriver?

6APPLYDABUG

 

Let’s start with a small tip from the doctor, with the help of his sonic screwdriver. Let’s grab the Powershell command that generated this error.

7APPLYDABUG

 

And see what it look like in PowerShell mode.

8APPLYDABUG

 

It seems to be a permission problem on the GPO, there is no doubt about it. I asked the Active Directory team to verify permission on the GPO. They confirm the “Full control” permission on the GPO. That’s strange because the wizard did not warn me about that.

 

That’s here begin the twilight zone

It’s the twilight zone because here what we have in the Group Policy Management Console.

9APPLYDABUG

We can see my least privileges account having exactly the same permissions on the Group Policy “GPO DA Server”. If we have the same permission (and there is no deny permission), how could it be possible to have an access denied error. OK, let’s go deeper in the twilight zone and compare detailed permissions with the ”old school method”, before GPMC. Here is the “Domain admin group” detailed permissions :

10APPLYDABUG

 

And the “least privilege account”. OK, we have something strange.

11APPLYDABUG

 

In the GPMC console, both security objects objects have the same level of privileges but if we have a closer look at detailed permissions, it’s not the case. Let sum up :

  • Both security objects have the same permission level in GPMC but It’s not the case in the “Group Policy Editor”
  • “Domain Admin group” does not have “Full control permission” and my least privilege account have it
  • “Domain Admin group” does not have “Apply group policy permission” and my least privilege account have it
  • “Domain Admin group” have “special permissions” and my least privilege account not.

 

It’s interesting. My least privilege account seems to have more permissions than the default domain admin group. Why would I have an access denied error message in such situation? Let’s have a global view of the permissions with the “Advanced button”.

 

Doctor do you have an idea or do you escape?

That was a shock for me but the advanced view confirmed that my least privilege account have more permissions than the default domain admin group.

12APPLYDABUG

Doctor response was easy.

13APPLYDABUG

But let’s be more logic. Full control level is only a combination of permission on specific attributes. Let’s see the combination for the domain admin group.

13APPLYDABUG

So the only missing permissions are  “Full control » and “All extended rights”. Let’s remove theses permissions for my least privilege account.

14APPLYDABUG

Now, both accounts have the same permissions. Let’s check that.

15APPLYDABUG

 

Almost perfect. We just need to remove the “Apply group policy permission”. Now we have exactly the same permissions for both security objects.

16APPLYDABUG

 

We will apply the same fix to the other group policy object. In GPMC, there is no change, even if we fixed some special permissions (if the doctor have an opinion about it, …).

17APPLYDABUG

 

You’re joking?

Does my least privilege account had too much privilege? It’s not possible. Yes, but someday with a little help of bugs, … I removed permissions given to my least security account to solve the problem. And the problem is solved.

18APPLYDABUG

 

At last, we can see that because my least privilege account does not have permission on attribute “GPLINK” at the root of the domain the wizard cant link my GPOs. It’s normal, the Active Directory team did not linked my GPOs at the moment I generated my DirectAccess configuration.

 

Conclusion

This experience lead to multiple conclusions :

  • There might be something wrong with the URA activation process, code review might be necessary at this level
  • Don’t trust the first error message you see. In our case, I did not have exact required permission.
  • Stop watching Doctor who series 

 

Doctor I give you back your sonic screwdriver.

 

BenoîtS – Simple and Secure by Design but Business compliant (And Doctor Who addict)

Mais pourquoi mon HRA refuse t’il de s’installer?

Il y a des jours quand ça veux pas, ça veux pas. Voila le me message d’erreur que j’ai obtenu lors de l’installation d’un Health Registration Authority sur une plateforme Windows Server 2008 R2 française. Premier reflexe, la localisation. Mes récentes expériences avec Orchestrator m’ont démontré la subtilité qui existe entre des produits globalisés versus localisés. Dans mon cas, l’interface graphique ne nous donne pas beaucoup d’informations sur la nature de l’erreur. Par contre, il m’indique que l’installation de sous-rôles ou rôles complémentaires a elle échouée et qu’il est nécessaire de redémarrer.

clip_image001

Après avoir exclue la cause française (problématique reproduite sur plateforme full US), j’attaque une approche dichotomique (non, je ne fais pas de développement, juste de la recherche d’erreur de la manière rationnelle). Pour faire simple, installer manuellement chaque rôle, sous-rôle et fonctionnalité jusqu’à tomber sur celle qui pose problème. A première vue, c’est bien le HRA. Cette fois l’erreur est plus précise (détail recherches sur le code erreur). On avance, on a un code erreur, c’est déjà mieux.

clip_image002

Tous les autres composants ou sous-composants se sont bien installés. Il faut aller plus avant dans les logs du composant ServerManager. Allons donc faire un tour dans le fichier « C:\Windows\Logs\ServerManager.Log ». Le code erreur affiché dans la console ne nous aide pas. Une rapide consultation de votre moteur de recherche ne nous fournira pas de piste spécifique. Remontons donc la liste dans le fichier de log.

clip_image004

On retrouve bien l’information. Elle vient même du composant Component Based Servicing (CBS) qui est plus connu sous le nom de Trusted Installer. Allons donc faire un tour dans le fichier journal de ce composant : « C:\Windows\Logs\CBS\CBS.Log ». En remontant le fichier de journalisation en partant de la fin, on arrive bien à identifier que le problème vient bien du package « Microsoft-Windows-HealthCertificateServer-RunTime ».C’est bien le HRA, plus précisément un package particulier. Est-il corrompu? Nan, c’est beaucoup plus simple. Ce n’est pas non plus un problème de quota comme l’indique le fichier de journalisation.

clip_image006

La réponse est quelques lignes au-dessus. De belles commandes « APPCMD.EXE » pour assurer la création des répertoires virtuels « DomainHRA » et « NonDomainHRA ».

clip_image008

Ce sont ces commandes qui ne passent pas. A tout hasard, j’ouvre une invite de commande MS-DOS pour tenter de les exécuter manuellement pour finalement me rendre compte de ce qui manque. Et si mon site web par défaut n’existait tout simplement pas? Bingo, dans mon cas, ce n’est pas qu’il n’existe pas mais qu’il a été renommé (des normes applicatives, toujours des normes applicatives, …). Ben celle-là elle ne passe pas. Le processus d’installe ignore le fait qu’on puisse renommer le « Default Web Site ». Une fois le site renommé, le HRA s’installe tout seul.

clip_image009

Un petit tour rapide dans la console « Gestionnaire des services Internet (IIS) » pour vérifier la présence de mon répertoire virtuel. C’était bien cela.

clip_image011

Conclusion : Quand on vous dit que l’installation du serveur est « fresh out of the box », premier réflexe ne rien en croire et vérifier plutôt deux fois qu’une. C’est comme les projets qui se déroulent sans problème, c’est de la science-fiction.

 

Note : le processus d’installation du HRA n’est pas un cas isolé. Il existe d’autres produits Microsoft pour lesquels la présence du site web par défaut est nécessaire pour que le processus d’installation se déroule normalement.

 

BenoîtS – Simple and Secure by Design but Business compliant

TCPv4 based applications with DirectAccess

Client-side Applications used on DirectAccess laptops must be bale to communicate with their server-side with IPv6. In most case, theses applications does explicitly require IPv4 based connectivity. But for some of them they only use TCPv4 based connections. In my special case, my client-side application check for IPv4 based connectivity to communicate with it’s server-side part.

 

Because of this, my application does not work with DirectAccess. This does not means it is impossible. In my case, my application need to contact a Windows 2003 SMTP service and it works in IPv6 thanks to DNS64/NAT64.

1

 

This was a real problem for my customer because it was one of his major business application. I was looking for a solution when I found the PORTPROXY feature provided by my favorite network took : NETSH.EXE.

2

 

Let’s have a look at the V4toV6 interface type. It is possible to redirect an IPv4 TCP based connection to a IPv6 destination :

3

 

Problem, with DirectAccess, we have an IPv4 based connectivity but this may charge each time I need to connect to my application. This is right, but we all have an IPv4 address that never change located on our computer, the loopback interface. So let create an V4toV6 interface that will listen on my loopback interface for my port and connect it to the same port on the server-side part of my application.

9

 

Let’s check this new interface is operational. We can list it.

4

 

But most important : Does it works?

5

 

yes it works!

6

 

This solution looks great but it is only a workaround. You should contact your application editor for a fix. But watch out, there are some limitations.

 

Limitations of this approach

First limitation of this solution is that it only apply to TCP based connections. Maybe one day, UDP will be supported.

7

 

Second problem, user must have Administrator level privilege to create the interface as illustrated bellow :

8

 

And Finally, the NAT64 limitation. NAT64 address structure is composed as illustrated bellow :

03EI37

 

Problem, the EUI64 Interface ID include a random part because it is a temporary address. This means that the IPv6 address that will be configured for the PORTPROXY Interface will change. This means, you must recreate the interface each time you want to use this type of address.

 

BenoîtS – Simple and Secure by design but business compliant

DirectAccess–Troubleshooting case

I was involved in multiple DirectAccess projects. During these projects, IT teams expect from me to give all information I can on troubleshooting issues that could happen. We can learn from each DirectAccess deployment and discover new issues.

 

During a recent deployment I faced to a new kind of issue. Some time to times, DirectAccess configuration on mobile computer was disabled as illustrated bellow :

SNAGHTMLf2922

 

Interesting case. The most simple solution to fix this issue is to reconfigure the Name Resolution Policy parameter as illustrated bellow : 

SNAGHTML105456

 

And most important, we must click to the apply button and restart the DNSCLIENT Service. That how to fix the issue.

 

Why this issue?

Good question. At the date of today, I have no idea of the root cause of this problem. I suppose that users have local administrators privileges and played with NRPT Configuration.

 

How to prevent it?

Another good question. I had no time to search for a good solution but Ronny De Jong found a good one you can read on his post. Simple but good idea. Now we just need to use this registry key in an additional GPO in order to force NRPT configuration.

 

Note : Keep this page in your bookmark. This will be useful to understand how NRPT work.

 

Benoits – Simple and Secure by Design but Business compliant

DirectAccess Deployment Tip : Don’t go too fast to deploy clients!

During one recent DirectAccess deployment, we encountered a special case I called the : “Too fast to deploy DA clients”. Some DirectAccess clients were operational but some others were not. While starting troubleshooting, we noticed that all failed computers shared the same issue : No IPsec certificate. Everything was OK, except the IPsec certificate.

 

Challenge, how to restore DirectAccess connectivity without return these computers to France? We could start building a complex infrastructure to distribute IPsec certificates but we were short in time. Because all computers were located in the same location, we had an idea. Why not using another computer to request computer on behalf of others. That’s a good idea. Let start to see how to do this magic trick.

 

First of all, we need another Certificate Template for these DirectAccess Clients. If we take a look at some properties of my default DA certificate we can notice that DNS name information will be retrieved from Active Directory. Even if we include this information in an Certificate request file, this information will be ignored. For this reason, we need an extra certificate template. This new certificate template will be based on my existing DA certificate template except a few points that must be fixed. In my lab, this new certificate template will be named “Offline Da Certificate”.

 

A new certificate template

In my point of view, certificate file time for this special certificate template must be limited to one day. This is not a normal situation. When DirectAccess connectivity will be restored, we would no longer need this certificate.

CERT0

 

Second point, we need to authorize private key exportation. This is mandatory otherwise, the certificate will be useless when imported on the Computer having the problem.

CERT1

 

And most important we must reconfigure how ADCS will generate subject name that will be registered in delivered certificates. By default, information are extracted from Active Directory. We cannot use this option. Information will be supplied in the request. Note that in the capture bellow, the checkbox “Use Subject information from existing certificates for Auto enrollment renewal request” is no checked. That’s a temporary certificate, there is no need to renew it!

CERT2

 

Request an Offline certificate

Once this new certificate template is published and available on any DirectAccess clients computers, we can start. On an operational DirectAccess client computer, we must logon with required privileges. Our goal is to request a computer certificate on behalf of another. Il my case CLIENT1.DIRECTACCESSLAB.LAN is operational and CLIENT2.DIRECTACCESSLAB.LAN. Si let’s perform a computer certificate enrollment, online, thanks to DirectAccess. This will be a classic new request, no need to perform the request offline

0

 

We will choose “Offline Da Certificate”, but before enrolling, more information’s are expected. So let’s fill in the blanks.

1

 

First missing information, Subject name. We need this information twice, in Distinguished name but also in DNS format. Because theses information are no longer extracted from Active Directory, we must provide them. We could stop here and submit the request but simple way does not means dirty way.

2

 

On the General tab, we will provide the friendly name of the Certificate and a description. This last information will be useful. At the end of the process, our CLIENT2.DIRECTACCESSLAB.LAN will have DirectAccess operational and two certificate. How can we remove the good one?

3

 

Request was processed. Now we have two certificates on CLIENT1.DIRECTACCESSLAB.LAN. Hopefully we can distinguish the good certificate to export.

4

 

Most important, we must export this certificate with it’s private key. Otherwise, certificate will be unusable on CLIENT2.DIRECTACCESSLAB.LAN. Do don’t forget to check the good checkbox!

5

 

A computer with multiple identifies will generate problems at short terms. In order to avoid problems, I recommend to delete the private key once export was performed.

6

 

Because we export the private key, this sensitive information must be secured in the PFX file.

7

 

Import certificate on Failed DirectAccess client

Now let’s move to CLIENT2.DIRECTACCESSLAB.LAN and perform a certificate Import in the Computer node. Sure, we have required information, …

9

 

And magic, we have an IPsec certificate available in the computer node. This is a temporary certificate. Now it’s time to restore DirectAccess Connectivity.

10

 

Restating the computer is a solution but if you have required privileges to import a certificate in the computer store, you can also restart the IP Helper Service.

11

 

This is not magic, this is only DirectAccess. Bellow, we can see I have an IPHTTPS Tunnel. Great. Let’s see if it works.

12

 

A simple “NETSH.EXE ADVFIREWALL MONITOR SHOW MMSA” prove we have IPsec Tunnels. But we can do more. We can prove that this computer is now able to request it’s missing DA certificate.

13

 

Simply run a “CERTUTIL.EXE –PULSE” and the computer will contact enrollment servers to see what certificates can be enrolled.

14

 

yes, the good one. Our failing CLIENT2.DIRECTACCESSLAB.LAN was able to enroll it’s missing certificate. Problem we have now two valid certificates. How can we be sure to delete the good one?

15

 

Have a look at the description extension field. That’s why I always fill it.

16

 

As a conclusion, even if you are confident about your DirectAccess infrastructure, never forget to perform a checklist on DirectAccess enabled computers before they leave outside. This particular problem was easy to solve, but it would be more complicated if group policies objects did not applied. That’s another challenger for a future post.

 

BenoîtS – Simple and Secure by Design but Business compliant

IPHTTPS troubleshooting survival guide

When you have problem with IPHTTPS in DirectAccess, there might be hundreds of reasons, including IT guy errors. Enumerate all errors might be too long, there are too many cases and causes. It would be easier if we have a list of all error code that a NETSH.EXE INTERFACE HTTPSTUNNEL SHOW INTERFACE can generate. This list exists, and it’s available on MSDN at this address. Bookmark this address if you don’t want to spend your time in IPHTTPS troubleshooting.

 

There is only one error code to keep in memory : 0x80090328. It means that IPHTTPS certificate has expired. I also called it Error 40 for 40 centimeters of the IT admin station who did now renew the certificate!

 

BenoîtS – Simple and Secure by Design but Business compliant.

Pour les séances de troubleshooting IPHTTPS

Quand le protocole IPHTTPS utilisé par DirectAccess ne fonctionne pas, il peut y avoir une multitude de raisons. Au lieu de toutes les énumérer, le plus simple c’est déjà d’avoir la liste des codes erreurs qu’une interface IPHTTPS peut inventer pour refuser de fonctionner. Ca existe, c’est disponible sur le MSDN à cette adresse.

 

S’il y en a un à conserver en mémoire : 0x80090328. Il indique un certificat expiré, aussi appelé, code erreur 40 pour 40 centimètres de la station d’admin de l’exploitant.

 

BenoîtS – Simple and Secure by Design but Business compliant.