Hi guys,

This article deals with windows user account authentication failure.

I'll try to explain somes tricks and tips I experienced while using the multiple ways available in VBScript, C#, C++ or even JAVA to authenticate a user account on a local machine or against Active Directory domain using LDAP.

I'll focus on failure issues when you get the following error or exception :

ERROR_LOGON_FAILURE
Logon failure: unknown user name or bad password.

Basically you get this error message when a logon attempt failed if the given password was bad, if the user account does not exist or if the password is expired, or if the password must be changed.

As a developer or IT Administrator you may need to know exactly why the attempt failed. 

There are actually multiple APIs to do so, let's take .NET case and  PrincipalContext class : https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.aspx

From Namespace : System.DirectoryServices.AccountManagement

This class behind the scene instatiates a COM object that makes a LDAP query to the Active Directory domain to try to authenticate the user.

You'll understand later that this is basically the reason why you can get the same error message for multiple distinguished cause.
Indeed, Active Directory Services Interface (ADSI) supports the following categories of error codes:
- ADSI error codes
- COM general error codes
- Win32 error codes for the Lightweight Directory Access Protocol (LDAP) provider.

All ADSI error codes are returned as COM HRESULT values and can be grouped into these three categories.

Because a Windows API can mix heterogeneous components, the system-supplied LDAP provider maps the standard LDAP error codes into the following Win32 error codes.

Standard Win32 error codes are also used to return ADSI error messages. In particular, the ADSI LDAP provider maps all the LDAP-defined error codes to Win32 error codes.

The following KB articles deals with this topic :
https://support.microsoft.com/kb/232282/ 

The error we got "ERROR_LOGON_FAILURE" is actually the Win32 error code for "LDAP_INVALID_CREDENTIALS".
The issue is that at an LDAP layer, there is no disction made with the cases we would like to differenciate.

The "LDAP_INVALID_CREDENTIALS" will be returned in any cases, if the password is wrong, expired or needs to be changed.

There are actually multiple workarounds you can use to achieve your goal.

Once you get the error : “Logon failure: unknown user name or bad password.” If you want to determine if the login attempt failed because the password is bad or because it is expired, what you can do is to query for that user on Active Directory using LDAP.
Then look for value of PasswordExpired or ms-DS-User-Password-Expired attributes.

According to the documentation : https://msdn.microsoft.com/en-us/library/ms677838(VS.85).aspx
It Indicates whether the password for the account that this attribute references has expired. True if the password has expired; otherwise, False.

To finish, there is Win32 API you can use to authenticate a user that is not based on that COM component and will return you the correct error code depending if the password is expired or if the password entered by the user is wrong.

You can use LogonUser https://msdn.microsoft.com/en-us/library/aa378184(VS.85).aspx that will return one of the following error :

ERROR_PASSWORD_EXPIRED 1330
ERROR_LOGON_FAILURE 1326
ERROR_PASSWORD_MUST_CHANGE 1907

Here we go, I hope that post helped you.

Cheers,

--Michel

Salut à tous,

Cet article traite des problèmes d'authentification des comptes utilisateur Windows.

Je vais tenter partager avec vous quelques expériences rencontrées lors de développements VBScript, C#, C++ ou même JAVA pour authentifier un compte utilisateur Windows sur une machine locale ou dans un domaine Active Directory en utilisant LDAP.

Je vous propose de nous interesser à l'erreur ou l'exception :

ERROR_LOGON_FAILURE
Logon failure: unknown user name or bad password.

Typiquement vous obtenez ce message d'erreur losque qu'une tentative d'authentification échoue, si le mot de passe renseigné est incorrecte, si le compte utilisateur n'existe pas, si le mot de passe du compte est expiré ou alors doit être changé.

En tant que développeur ou Administrateur d'un parc informatique nous pouvons avoir besoin de connaitre la source exacte de l'erreur.

Il existe divers méthodes pour authentifier un compte, prenons par exemple l'exemple .Net avec la classe PrincipalContext : https://msdn.microsoft.com/en-us/library/system.directoryservices.accountmanagement.principalcontext.aspx

De l'espace de nom : System.DirectoryServices.AccountManagement

Le méchanisme interne de cette classe instancie un objet COM qui effectue des requêtes LDAP vers le domaine  Active Directory afin de tenter une authentification.

Vous comprendrez pourquoi cette implémentation est en fait problématique dans notre effort de différentiation des types d'erreurs liés à l'authentification.

En effet,  Active Directory Services Interface (ADSI) supporte les catégories suivantes de code d'erreurs :
- Les codes d'erreurs ADSI
- Les codes d'erreurs standards de COM
- Les codes d'erreurs WIN32 spécifique au fournisseur Lightweight Directory Access Protocol (LDAP)

Toutes les erreurs ADSI sont retournées comme des valeurs HRESULT COM qui peuvent être regroupées dans ces trois catégories.

Parce qu'une API Windows peut reposer sur des composants hétérogènes, le système propose un fournisseur LDAP dont les codes d'erreurs ont une correspondance avec les codes d'erreurs Win32.

Les codes d'erreurs standards Win32 sont aussi utilisés pour retourner des message d'erreur ADSI. Plus précisément les fournisseurs ADSI LDAP font la correspondance entre toutes les erreurs définies par LDAP  et leurs équivalents Win32.

L'article KB suivant traite de ce sujet :
https://support.microsoft.com/kb/232282/ 

L'erreur  "ERROR_LOGON_FAILURE" que nous traitons dans cet article est en fait l'équivalent Win32 de l'erreur LDAP "LDAP_INVALID_CREDENTIALS".

Le problème qui se pose c'est qu'au niveu LDAP, il n'y a pas de disctinction faite entre les différents cas de figures qui nous interressent.

L'erreur "LDAP_INVALID_CREDENTIALS" sera retournée par l'API appelante dans tous les cas, que le mot de passe du compte soit mauvais, expiré ou doive être changé.
C'est donc assez problématique et cela masque la vraie nature du problème.

Il existe cependant des moyens de contournement afin de remonter à la source du problème.

Une fois que vous avez l'erreur : “Logon failure: unknown user name or bad password.” si vous souhaiter déterminer si l'authentification a échoué parce que le mot de passe du compte fournit était incorrect ou s'il a expiré vous pouvez faire une requête LDAP afin d'obtenir les valeurs des attributs du compte suivants  PasswordExpired ou ms-DS-User-Password-Expired.

D'après la documentation : https://msdn.microsoft.com/en-us/library/ms677838(VS.85).aspx
Cet attribue indique si le mot de passe est expiré. La valeur True  sera renseignée si le mot de passe est expiré; sinon, False.

Pour terminer, il existe aussi des API Win32 pour authentifier un compte qui ne sont pas basés sur ce composant COM et qui retourneront un code d'erreur approprié.

Vous pouvez utiliser par exemple LogonUser https://msdn.microsoft.com/en-us/library/aa378184(VS.85).aspx qui vous retournera l'une des erreurs suivantes :

ERROR_PASSWORD_EXPIRED 1330
ERROR_LOGON_FAILURE 1326
ERROR_PASSWORD_MUST_CHANGE 1907

Voilà j'espère que cet article vous a été utile.

Bon code.

--Michel

Hi there,

I know some of you have been waiting for a while before I made my first technical post. I’ve been busy helping you guys solving development issues, isn’t that a good justification? J

Today, I’m going to give you an example of a typical scenario application’s developer faces with when a new version of Windows is released and we discover that our application that was working perfectly fine on previous version now has a completely different behavior.

When that happens, we usually think that because our code was working fine before it means that something is going wrong with this new version of Windows. That can be true but experience shows that most of the time, we’ve to reconsider our assumption. To insure application backward compatibility, this is very unlikely that an API with the exact same name and parameter has his behavior changed from a version of Windows to another.

I had a customer who was facing the following issue:

PROBLEM:

He has written a native C++ application to print out his documents. The program has its own feature to connect a printer on network and printing out the documents. The application is working fine on Windows XP for years, but it seems that it is not compatible with Windows Vista. He’s getting an "invalid handle" error.

EXPECTATIONS / AGREED RESOLUTION:

What is happening? How to get rid of this issue?

ENVIRONMENT:

Windows Vista

Shared printed accessible from any machines from local area network

SUMMARY OF TROUBLESHOOTING:

In such circumstances the first thing we need to find out is what API’s call generates the error.

This can be done either by tracing the application with a debugger or by taking a process memory dump when the issue occurs. I’ll explain in a later post both of these different approaches.

The error was returned by calling the CreateFile API (https://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx ).

C++

HANDLE WINAPI CreateFile(

  __in      LPCTSTR lpFileName,

  __in      DWORD dwDesiredAccess,

  __in      DWORD dwShareMode,

  __in_opt  LPSECURITY_ATTRIBUTES lpSecurityAttributes,

  __in      DWORD dwCreationDisposition,

  __in      DWORD dwFlagsAndAttributes,

  __in_opt  HANDLE hTemplateFile

);

 

This function creates or opens a file or I/O device and returns a handle that can be used to access the file or device for various types of I/O depending on the file or device and the flags and attributes specified.

The game is now to understand why the call fails on Windows Vista returning VALID_HANDLE_VALUE.

Reading the documentation we should have a look at the “return value” section.

It says the following:

Return Value :

If the function succeeds, the return value is an open handle to the specified file, device, named pipe, or mail slot.

If the function fails, the return value is INVALID_HANDLE_VALUE. To get extended error information, call GetLastError().

We could see that the ERROR_FILE_NOT_FOUND was returned by GetLastError(). This makes us think that for any reason, the API is not able to access the target file. At this step we can try to find in the documentation any hints that may lead us to any root cause, for instance any implementation changes or restriction coming with Windows Vista. Any reference like this one: https://support.microsoft.com/kb/942448/en-us (Changes to the file system and to the storage stack to restrict direct disk access and direct volume access in Windows Vista and in Windows Server 2008).

The ultimate path to follow is to read all the information provided by the documentation regarding ERROR_FILE_NOT_FOUND. We are lucky more details regarding this error can be found in the documentation in the “Opening LPT Ports” section. It’s said that specifying OPEN_EXISTING as dwCreationDisposition parameter will cause the function to fail when called on Windows Vista or Windows 2008 server to open an LPT port that is mapped to a network share. GetLastError() returns ERROR_FILE_NOT_FOUND.

The customer’s application was calling the API with the following parameters:

C++

CreateFile(“\\MyServer\MyPrinter” , FILE_FLAG_OVERLAPPED, FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);

 

At this step we can notice that this is actually a known issue. To avoid this you should use the OPEN_ALWAYS flag instead that will force the driver to start the device so that the WriteFile interface is available. The code was modified that way:

C++

CreateFile(“\\MyServer\MyPrinter” , FILE_FLAG_OVERLAPPED, FILE_SHARE_WRITE, 0, OPEN_ALWAYS, 0, 0);

 

 With this solution the application was able to run successfully on both version of the operating system.

To put it in a nutshell, when developing an application the first thing you should do is to read carefully the documentation and use the appropriate parameters. Most of the time this will prevent you for facing to this kind of issues. If any system change is susceptible to have an impact on an API, the documentation may mention it. If this is not the case, please don’t hesitate to raise the issue on the article in the appropriate section.

I hope that you found this post useful.

Cheers,

Bonjour à tous,

Oui c’est vrai, j’ai un peu tardé à écrire mon premier post technique, mais j’ai une bonne excuse, j’étais occupé à aider certains d’entre vous à résoudre leurs problèmes de développement J

Aujourd’hui je vais vous décrire un scenario typique que les développeurs d’application rencontrent lors d’une migration d’application pour la dernière mouture du système d’exploitation. Comment une application qui fonctionne parfaitement sur une version de Windows donnée se comporte-t-elle de manière différente sur son successeur ?

De manière générale quand ce type de situations se présente, le premier réflexe est de penser que quelque chose ne va pas avec cette nouvelle mouture de l’OS. C’est une assertion possible, mais dans la plupart des cas il faut savoir remettre en question cette hypothèse. Afin d’assurer la rétrocompatibilité des applications, il est vraiment peu probable qu’une API appelée avec les mêmes paramètres ait un comportement différent d’une version de l’OS à l’autre. Ce n’est cependant pas une hypothèse à exclure.

Un développeur a été confronté à la situation suivante :

PROBLEME :

Il développe une application native en C++ qui imprime des documents. L’application gère d’elle-même la connexion à l’imprimante réseau et y envoie les documents à imprimer. L’application fonctionne correctement depuis plusieurs années sous Windows XP, mais il semblerait qu’elle ne soit pas compatible avec Windows Vista. Il obtient le message d’erreur suivant quand il tente d’imprimer un document : "invalid handle".

ATTENTES DU DEVELOPPEUR :

Savoir ce qui pose problème et comment faire en sorte que son application marche aussi bien sous Windows XP que Windows Vista.

ENVIRONMENT:

Windows Vista

Imprimante partagée et accessible par toutes les machines du réseau local

RESUME :

Dans de telles circonstances la première chose à faire est d’identifier l’appel à la fonction qui soulève le problème.

Cela se fait généralement en traçant l’exécution du code avec débogueur ou alors par l’analyse d’une capture mémoire complète de la du processus. Je donnerai des exemples de ces deux approches dans un prochain article.

Dans ce cas précis, comme le problème a pu être facilement reproduit dans une application d’exemple minimaliste, il a été possible d’identifier que l’appel à la fonction suivante posait problème :   

API CreateFile (https://msdn.microsoft.com/en-us/library/aa363858(VS.85).aspx ).

 C++

HANDLE WINAPI CreateFile(

  __in      LPCTSTR lpFileName,

  __in      DWORD dwDesiredAccess,

  __in      DWORD dwShareMode,

  __in_opt  LPSECURITY_ATTRIBUTES lpSecurityAttributes,

 

Cette fonction crée puis ouvre un fichier ou Entrée/Sortie de périphérique et en retourne un handle qui peut être utilisé pour accéder au fichier ou périphérique en question selon différents types d’E/S en fonction des attributs spécifiés.

Le but du jeu est maintenant de comprendre pourquoi l’appel à cette fonction échoue et renvoie la valeur : INVALID_HANDLE_VALUE.

En lisant la documentation de l’API dans la section “valeur de retour” nous pouvons lire les informations suivantes :

Valeur de retour :

Si la fonction réussit, la valeur de retour est un handle ouvert au fichier, périphérique, named pipe (canal nommé) ou mailslot spécifié.

Si la fonction échoue, la valeur de retour est  INVALID_HANDLE_VALUE. Afin d’obtenir plus d’information sur l’erreur faire un appel à GetLastError().

L’erreur ERROR_FILE_NOT_FOUND  a été retournée par  GetLastError(). Cela laisse à penser que pour une raison encore inconnue, l’API n’a pas pu accéder à ressource cible. A ce stade nous pouvons chercher des indications dans la documentation qui pourrait expliquer ce comportement. Des indices comme des changements d’implémentation ou de politique de sécurité et restriction sont à surveiller de près.

La référence suivante : Modifications dans le système de fichiers et dans la pile de stockage pour limiter les accès disque direct et des accès directs volume dans Windows Vista et dans Windows Server 2008 ( https://support.microsoft.com/kb/942448/en-us ) est typiquement le genre d’éléments qui peut avoir une impacte sur le comportement d’une API.

La dernière piste à suivre est de lire en détails les informations fournies dans la documentation MSDN de l’API au sujet de l’erreur ERROR_FILE_NOT_FOUND. Dans ce cas précis nous avons dans la section “Opening LPT Ports” une référence intéressante. Il est expliqué que l’utilisation de l’API qui nous intéresse en spécifiant le paramètre dwCreationDisposition avec pour valeur OPEN_EXISTING aura pour effet de faire échouer l’appel sous Windows Vista et Windows Server 2008 lors des tentatives d’ouverture de port de type LPT mappé sur un partage réseau. GetLastError() retourne dans ce cas ERROR_FILE_NOT_FOUND.

Le code source qui reproduit le problème appel l’API de la manière suivante :

C++

CreateFile(“\\MyServer\MyPrinter” , FILE_FLAG_OVERLAPPED, FILE_SHARE_WRITE, 0, OPEN_EXISTING, 0, 0);

 

Nous sommes exactement dans le cas de figure décrit par la documentation. Afin d’éviter que cela se produise, il faudrait spécifier la valeur OPEN_ALWAYS  pour le paramètre dwCreationDisposition ce qui aura pour effet de forcer le pilote d’impression à démarrer le périphérique afin que l’interface WriteFile utilisée par l’API CreateFile soit disponible. Le code doit être modifié de la manière suivante :

C++

CreateFile(“\\MyServer\MyPrinter” , FILE_FLAG_OVERLAPPED, FILE_SHARE_WRITE, 0, OPEN_ALWAYS, 0, 0);

Avec cette solution, l’application est maintenant capable de s’exécuter correctement sous sur les différentes versions du système d’exploitation Windows.

Pour résumer, il est vraiment fondamental dans le cadre d’un développement ou d’un débogage d’application de se fier à la documentation et d’utiliser les paramètres appropriés en fonction du contexte d’appel aux différentes APIs. De manière générale, toute impact potentiel d’un changement au niveau du système est signalé dans la documentation de l’API. Si tel n’est pas le cas il ne faut pas hésiter à le signaler au niveau de l’article MSDN dans la section appropriée.

Voilà, j’espère que cet exemple vous a été utile et vous permettra d’anticiper ou résoudre les problèmes de ce type rencontrés lors d’une migration.

--Michel

Hi there,

 

I’m Michel Molongo, development support engineer on Windows Platform for nearly one year at Microsoft EMEA (Customer Service and Support Division). I’ve just created that blog in order to share with you different experience and topics I deal with on my day to day work around Windows. That’s also a great opportunity for me to tell about the not so well known of support engineer among Microsoft.

 

To put it in a nutshell, my mission is to help developers to solve and understand issues they may face with when they develop application targeting Windows Platform.

 

Following different kinds of issues you may encounter:

1)      I developed an application to manage my electric train toy in C++ that is using the PC’s serial port. I would like to migrate the application in .NET, I would like to know which class of the .NET Framework can be used? Is it possible to get any code samples and recommendation to do this?

 

2)      My application uses System.IO.Ports classes from .NET Framework. It crashes when I any attempt to send data on serial COM2 port is made, an unhandled exception is thrown even if I tried to handle exception with Try/Catch block. What causes the problem and how to get rid of it?

 

3)      My Win32 application that is supposed to run as service works perfectly well with Windows XP and Windows Server 2003 but doesn’t seem to work correctly with Windows Vista. Any call to CreateWindow() API returns  ERROR_ACCESS_DENIED. I need help to understand what is happening here and how I can have my application to work on Windows Vista.

 

4)      My application is based on Framework .NET 3.5, it seems to work properly on my test environment but once in production I noticed that the process’s memory usage was getting higher and higher with utilization. It looks like there is a memory leak somehow, but I am not able to find anything going wrong in my code. After two days the application hangs. How can I determine the root cause of this issue?

 

You now have an overview of how Support Engineer may help you. I’m actually the first interface between developers outside Microsoft and Windows Product group, from bug discovery to the hotfix delivery.

 

My team is specialized on a set of Windows Technologies : Active Directory, ADAM/AZMAN/SNMP/RPC, Crypto / Certificates / Security, GINA / Credential providers, MSI, NT Services, PowerShell, Printing, Sockets / TCP / IP Helper, Terminal Services / RDP, User Dumps, Vista / UAC / Upgrade, Win 32 API, WMI, WSUS (Windows Update Service).

 

I’ll mainly tell you about multiple aspects of developing for Windows whether it is native (C/C++) or managed (C#/VB.NET) code but also issues that I, my colleagues or any other developers frequently face with. You will find here how any of them have been solved and how they could have been avoided.

 

As a conclusion, you will also find in this blog recommendations and hints about tools you can use as troubleshooting purpose, code samples, information relative to Windows technologies, my job, my team and more generally Microsoft.

 

I’ll publish the posts in French, English, and maybe soon in Spanish. J

 

Please feel free to contact me if there are any topics you want to read about in that blog.

 

I wish you a pleasant reading.

 

Cheers,

 

--Michel

Bonjour à tous,

 

Je suis Michel Molongo, ingénieur au support développement sur plateforme Windows depuis un peu plus d'un an chez Microsoft EMEA (Division Customer Service and Support). Je viens de créer ce blog afin de partager avec vous différentes expériences et sujets abordés lors de mon travail quotidien autour de Windows. C'est aussi une opportunité de présenter le métier méconnu d'ingénieur support au sein Microsoft.

 

En quelques mots, mon métier consiste à aider les développeurs à résoudre les problèmes qu'ils rencontrent lors de leur développement d'application à destination de la plateforme Windows.

 

Les problèmes peuvent être de plusieurs natures, par exemple :

 

1) J'ai développé une application pour contrôler un train électrique en C++ qui utilise le Port Série du PC. Je voudrais porter l'application en .NET, je voudrais savoir quelles classes du  Framework .NET utiliser ? S’il est possible d’avoir des exemples d’utilisation de la classe ?

 

2) Mon application utilise les classes System.IO.Ports du Framework .NET, mon application crashe quand j'essaye d'envoyer des données sur le port série COM2, une exception non gérée est levée alors que j'ai encapsulé mon code dans le bloc Try/Catch qui convient pour gérer l’exception. Comment puis-je éviter ce problème? 

 

3) Mon application Win32 exécutée en tant que service fonctionne correctement sous Windows XP et Windows Server 2003 mais ne semble pas fonctionner sous Windows Vista. L’appel à l’API CreateWindow() retourne la valeur ERROR_ACCESS_DENIED. Qu’est-ce qui peut poser ce problème ? Comment puis-je faire fonctionner l’application sous Windows Vista ?

 

4) Mon application utilise le Framework .NET 3.5, elle fonctionne parfaitement dans mon environnement de test, mais une fois en production j’ai remarqué que la mémoire utilisée par le processus augmentait avec le temps sans jamais être libérée. Je constate une fuite mémoire importante qui bloque l’application au bout de deux jours d’utilisation. Je voudrais de l’aide pour déterminer les causes de ce problème.

 

Vous avez maintenant un petit aperçu des problématiques rencontrées.

 

Je suis aussi la première interface avec les développeurs pour adresser des problèmes au groupe produit Windows, de la découverte d'un bug à la publication d'un correctif.

 

Mon équipe est spécialiste sur un ensemble de technologies Windows  Active Directory, ADAM/AZMAN/SNMP/RPC, Crypto / Certificates / Security, GINA / Credential providers, MSI, NT Services, PowerShell, Printing, Sockets / TCP / IP Helper, Terminal Services / RDP, User Dumps, Vista / UAC / Upgrade, Win 32 API, WMI, WSUS (Windows Update Service).

 

Je parlerai donc principalement de différents aspects du développement sous Windows que ce soit en code natif (C/C++) ou managé (C#/VB.NET) mais aussi des problèmes qui sont régulièrement rencontrés par moi-même mais aussi par d'autres (collègues, partenaires) auxquels j'ai pu m'intéresser. Vous saurez comment certains des problèmes ont pu être résolus et de manière général comment éviter de le retrouver.

 

Pour finir, vous trouverez aussi sur ce blog des recommandations sur les outils à utiliser afin d'essayer de trouver la source de vos problèmes, des exemples de code source, des informations utiles relatives à Windows, aux technologies qui s’y associent, mon métier, mon équipe et Microsoft en général.

 

Je tâcherai de publier l'ensemble des articles en français, en anglais et dans un futur plus ou moins proche en espagnol :-)

 

N'hésitez pas à me contacter s'il y a des articles qui n'ont pas été clairs ou s'il y a des sujets que vous souhaiteriez voir abordés sur ce blog.

 

Je vous souhaite une excellente lecture.

 

--Michel