<p>Un collègue vient de me démontrer que les comptes dans notre AD de test pouvaient s’authentifier en remplaçant chaque caractère « a » dans leur <code>samAccountName</code> par le caractère danois å (ASCII 134 / <a href="https://www.fileformat.info/info/unicode/char/00e5/index.htm" rel="noopener nofollow ugc">å</a>).</p>
<p>Par exemple, l’utilisateur <code><domaine>\aaa</code> peut s’authentifier en tant que <code>ååå</code>.</p>
<p>J’ai essayé de reproduire cela dans un AD W2K12R2 fraîchement provisionné (serveur unique, toutes les valeurs par défaut), et cela fonctionne aussi. J’ai créé un compte <code>aaa</code> (sans jamais toucher à la lettre å dans le processus, de sorte que rien ne contient <code>å</code>) et j’ai exécuté :</p>
<pre><code class="lang-auto">PS C:\Users\Administrator> runas /user:ååå notepad
Enter the password for ååå:
Attempting to start notepad as user "DEV-DLI\ååå" ...
PS C:\Users\Administrator>
</code></pre>
<p>ce qui a provoqué le démarrage du bloc-notes, s’exécutant en tant que <code>aaa</code>.</p>
<p>La même chose semble s’appliquer pour « o » et le caractère danois ø, tandis que le dernier caractère spécial danois æ ne semble correspondre à aucun autre caractère. Avec l’utilisateur <code>aaa</code> dans AD, essayer de créer un utilisateur avec le samAccountName <code>ååå</code> échouera, vous informant que « Le nom d’ouverture de session utilisateur que vous avez choisi est déjà utilisé (…) ».</p>
<p>J’ai cherché comme un fou sur Google, mais je n’ai pas réussi à comprendre ce qui se passe. Quelqu’un a-t-il des pistes sur la raison pour laquelle cela fonctionne ?</p>
