Thursday, October 23rd, 2008...11:48 pm

Bądź unikalny … bez znaków diakrytycznych

Jump to Comments

Polskie znaki diakrytyczne sprawiają różne problemy już od dawna, można zresztą powiedzieć że ogólnie znaki diakrytyczne, nie tylko te polskie. W szczgólności mogą one też sprawiać pewne trudności w przypadku katalogu AD i logowania w systemie Windows. Temat wyszedł ostatnio kilka razy na forum i w rozmowach więc ku pamięci i wiedzy innych pokrótce napiszę o co chodzi.

(cc) ·júbilo·haku·

Ci którzy już trafili na ten problem wiedzą zapewne o czym będę pisał. Dla innych polecam szybkie ćwiczenie i założenie w katalogu użytkownika z nazwą logowania “żółw” a następnie próbę zalogowania się używając konta “żółw” ja i “zolw”. Wow … działa.

Ewentualnym innym ćwiczeniem jest próba utworzenia dwóch kont, z nazwami logowania odpowiednio “żółw” i “zolw”. W tym drugim przypadku, zakładając że założyliśmy pierwsze konto powinniśmy uzyskać informację, że taki użytkownik już istnieje.

Zachowanie takie nie dotyczy tylko i wyłącznie atrybutu samAccountName. W przypadku atrybutów dla których wymagana jest unikalność zachowanie takie może sprawić nam problem dla:

  • nazwy logowania użytkownika
  • atrybuty RDN dla obiektu (czyli na przykład atrybutu CN użytkownika).

Powód takiego zachowania to sposób, w jaki wartości znakowe są porównywane w ramach katalogu. Trochę światła na to jak to działa rzuca wpis na blogu Michaela Kaplana.

The reason is that Active Directory passes the following flags:

NORM_IGNORECASE | NORM_IGNORENONSPACE | NORM_IGNOREWIDTH | NORM_IGNOREKANA

which means that there are many distinctions like this that are folded together.

 

W wyniku tego, przy porównaniu łańcuchów znakowych większość znaki diakrytyczne (nie tylko polskie) zostają “spłaszczone” do ich odpowiedników. Dzięki temu, w przypadku wskazanego powyżej użytkownika logowanie możliwe jest zalogowanie się używając zarówno ciągu znaków z polskimi znakami jak i bez nich.

Żeby całą rzecz uczynić ciekawszą, to zmienna USERNAME zostanie ustawiona zawsze na taką wartość, jaka zostanie wpisana w dialogu logowania, co opisuje KB 839515. Praktyczny efekt tego zachowania jest taki, że dla użytkownika może zostać utworzony na przykład folder profilu zawierający znaki diakrytyczne.

To co jest mniej oczywiste to obecność polskich znaków w ramach atrybutu będącego RDN dla obiektu, na przykład CN dla obiektu użytkownika. W tym wypadku, wartość takiego atrybutu może zawierać, tak jak i w przypadku nazwy logowania, polskie znaki diakrytyczne.  Unikalność RDN jest jednak wymagana tylko w ramach tego samego kontenera, czyli inaczej niż w przypadku samaccountname, jest możliwe założenie w katalogu użytkownika o CN:

  • CN=jan zolw
  • CN=jan żółw

bez żadnego ostrzeżenia ze strony usługi katalogowej. Problemy pojawią sie dopiero wtedy, gdy spróbujemy umieścić oba takie obiekty w jednym OU. W takim przypadku uzyskamy jedynie komunikat błędu  podobny do tego , opisanego w KB 234051. Artykuł ten wspomina co prawda o wymogu unikalności atrybutu RDN, niestety nie wspomina nic o konieczności zapewnienia również unikalności z dokładnościa do wartości, pozbawionych tych znaków.

Ma to też swój efekt w przypadku zapytań LDAP. Jeżeli utworzymy dwa obiekty użytkowników o CN jak powyżej, to zapytanie o dowolną kombinację znaków tych wartości zawsze zwróci nam dwa obiekty, tak jak w przykładzie poniżej:

adfind -b dc=w2k,dc=pl -s subtree -f "(&(objectClass=user)(cn=jan żółw))" -dn

AdFind V01.37.00cpp Joe Richards (joe@joeware.net) June 2007

Using server: W08LHFDC01.w2k.pl:389

Directory: Windows Longhorn

dn:CN=Jan zółw,OU=TEst USers,DC=w2k,DC=pl
dn:CN=jan zolw,OU=Diacritic,DC=w2k,DC=pl

2 Objects returned

Jakie są z tego wnioski praktyczne?  Warto zaplanować schemat nazewniczy w taki sposób, żeby takich konfliktów unikać. Nie zawsze się da, ale myśląc nad jego określeniem warto o tym pamiętać. W szczególności budując rozwiązania automatyzujące zarządzanie kontami warto zadbać o to, aby sposób generowania unikalnych nazw użytkowników uwzględniał te zależności.

I uprzedająć pytanie .. nie, nie ma możliwości zmiany tego zachowania.

4 Comments

  • Dość ciekawy problem zachodzi, gdy masz zrobiony Trust z MIT Kerberos i logowanie na stacje jest wykonywane za pomocą cross-realmu. Jeśli ktoś w Mitowskim kerberosie ustawił sobie hasło z polskimi znakami, to raz się zaloguje a raz nie:) Czasem były osoby, które przez miesiąc logowały się bez problemu, a po tym miesiącu to było chybił trafił:) Jedynym rozwiązaniem (jak dla mnie mądrym) było wykluczenie znaków diakrytycznych z haseł:)

  • To nie do końca to samo tak myślę … i raczej nie wiązałbym tego z samym katalogiem AD jako takim, raczej ewentualnie sposobem w jaki hasła są przechowywane po stronie tego zdalnego realm lub coś podobnego.
    Same hasła ze znakami diakrytycznymi działają poprawnie w katalogu i możliwe jest logowanie z ich pomocą. Takie problemy o jakich piszesz występowały chociażby w Outlooku 2000. Hasła z PL literką nie pozwalały na zalogowanie się. Nie wiem czy nie zostało to poprawione gdzieś po drodze, ale w czasach gdy się zajmowałem wsparciem pewnej instalacji był to typowy problem zgłaszany przez użytkowników.

  • Wiesz trudno mi powiedzieć, gdzie leży problem. Podejrzewam, że coś jest nie tak z przekazywaniem haseł. Dlatego, że tak jak powiedziałeś w samym AD jest możliwość wykorzystania polskich znaków w haśle, w MIT Kerberosie też taka opcja działa.Wcześniejszy wpis wrzuciłem jako ciekawostkę 🙂 Może ktoś kiedyś będzie w podobnej sytuacji jak ja i się mu to przyda.

  • hehe
    doświadczalnie już to testowałem: http://www.w-files.pl/polskie-znaki-w-ad-i-dns-i-nie-tylko-2/
    – dobrze dostać do tego trochę wyjaśniających informacji (:

Leave a Reply