понедельник, 30 мая 2011 г.

Странный DirectoryServices. Совет первый: выражайтесь яснее, где искать

В прошлый раз я вскользь упомянул про подводные камни, встречающиеся на пути программиста, решившего использоваться классы пространства имён System.DirectoryServices или DCOM объекты ADSI, что, по сути, то же самое. Данная тема заслуживает отдельного рассмотрения. Поэтому эту и несколько следующих заметок я посвящу ей.
Сегодня я хочу рассмотреть весьма распространённую ошибку, связанную с особенностью выбора контроллера домена, на котором будет осуществляться поиск. В большинстве случаев программист полагается на настройки по умолчанию и может получить существенное падение производительности при определённых конфигурациях. Самое неприятное то, что отследить такую ошибку на этапе тестирования очень сложно.

понедельник, 23 мая 2011 г.

DirectoryServices.Protocols – малоизвестная альтернатива

Все знают о существовании пространства имён System.DirectoryServices. Оно содержит набор классов, являющихся тонкой обёрткой над ADSIDCOM-ориентированном API для работы с Active Directory. Но ADSI не единственный интерфейс, который можно использовать для общения с контроллерами домена. Помимо него в состав WinSDK входит библиотека LDAP API, реализующая 3-ю версию LDAP API в соответствии с RFC 2251. С её помощью приложение на C++ может получить доступ к любому LDAP серверу под управлением любой операционной системы. Но что делать, если платформа приложения – .NET, а язык разработки – C#? Ответ на этот вопрос находится в пространстве имён System.DirectoryServices.Protocols.

воскресенье, 15 мая 2011 г.

Google Protobuf - замена вашему велосипеду

Как часто приходится сталкивать с проблемой сериализации / десериализации данных? И если в .NET подобная проблема решена более-менее стандартно, то, как быть, если вы пишите код на C++? Или ещё хуже: вам необходимо обмениваться сообщениями между сервером, написанным на C++ и клиентом, написанным на C#. Некоторое время назад я открыл для себя такую вещь, как Google Protocol Buffers. В этой заметке я постараюсь рассказать, что это такое и зачем оно может быть полезно.

понедельник, 9 мая 2011 г.

Чудеса аутентификации. Чудо второе: доступ запрещён

Допустим, вы пишете клиент-серверное приложение, причём серверная часть состоит из нескольких компонентов. После получения запроса, сервис, реализующий внешний интерфейс, выполняет олицетворение (impersonation) клиента и отправляет запросы к остальным частям сервера по мере необходимости. Рассмотрим типичную ситуацию: всё прекрасно работало, пока серверные компоненты были развёрнуты на одной машине в вашем тестовом окружении, но как только сервер попал в отдел контроля качества, и его части оказались на разных машинах (он стал действительно распределённым), клиент начал получать ошибку "Access denied". Даже программисты с хорошим опытом зачастую попадают в подобную ловушку и не могут сразу ответить, что же идёт не так.

воскресенье, 1 мая 2011 г.

Чудеса аутентификации. Чудо первое: доступ разрешён

Как-то раз я поспорил с одним коллегой о том, каким образом ОС Windows хэширует пароли, а именно: солит она их или нет. Коллега, будучи весьма опытным человеком, с абсолютной уверенностью утверждал, что хэш пароля просто обязан быть солёным. Его уверенность базировалась на теории о том, что без применения соли данные по хэшу легко вскрываются атакой со словарём. Вот только эта теория никак не могла объяснить такую странность: 
  • есть 2 хоста, не включённых в домен, – AliceHost и BobHost;
  • на обоих хостах есть одноимённые пользователи с одинаковыми паролями: AliceHost\user и BobHost\user;
  • на хосте AliceHost есть сетевая папка \\AliceHost\Folder, доступ к которой предоставлен только пользователю AliceHost\user;
  • если на хосте BobHost осуществить вход пользователем BobHost\user, то вы легко получите доступ к папке \\AliceHost\Folder.