Легенды и мифы ИТ #2: PKI edition.

Внимание: мой новый RSS-Feed: http://feed.feedcat.net/815939

Измените свою подписку, пожалуйста.

 

Кстати, а знаете ли Вы, что на самом деле делает опция “Allow private key to be exported” или “Prompt the user during enrollment and require user input when the private key is used” в шаблоне сертификата? Делают ли они использвоание сертификата более безопасным или нет?

Я знаю как минимум пару людей, которые точно знают ответ на этот вопрос. К сожалению, я не так давно вышел из пелены невежественности, но лучше ж поздно, чем слишком поздно В общем, короткий ответ: нет. CA не имеет ни малейшей возможности заставить клиента вести себя таким образом, как предполагает название этой настройки. В шаблоне содержатся лишь рекомендации клиентской части не экспортировать закрытый ключ.

Потому в Windows 2003 экспортировать такой сертификат через GUI было нельзя, а вот некоторые сторонние утилиты это сделать могли. Впрочем и с помощью стандартных утилит некоторые типы сертификатов были легко экспортируемы, если верить документации. А вот начиная с Windows 2008 (ну или Windows 7) сделали “улучшение” и теперь можно экспортровать неэкспортируемое.

Так что смысла в этой опции мало: только как защита от дурака.

Будьте осторожны и старайтесь задумываться над тем, что порой кажется очевидным. =)

Легенды и мифы ИТ #1: Number of previous logons to cache

Знаете, как IT Pro я частенько сталкиваюсь с тем, что иначе как мифами и не назовешь. Видимо, IT уже настолько старая отрасль, что свои мифы в ней просто не обходимы. Иногда, столкновение с ними становится настолько частым, что объяснение что и где не так, как в этой легенде становится смертельно скучным. Что еще более удивительно, чем сам факт существования мифов, так это то, что описание того, как правильно, есть на куче ресурсов в Интернете, но... Ну, в любом случае, наверняка есть люди, которые знают людей, которые читают мой блог и не читают эти ресурсы, так что я все равно их тут изложу постепенно.

Давайте начнем с самого базового, но очень часто всплывающего мифа о работе одной настройки в групповых политиках. Да, ту самую, о которой сказано в заголовке. Я однажды встречал человека, которого из-за нее чуть не уволили. Правда. Как всегда: “входит шеф и говорит, что нужно запретить продажникам входить в их ноутбуки больше, чем 15 раз без подсоединения к корпоративной сети, а то задолбали вообще в офисе не появляться”. “Нет проблем”, отвечает ему администратор, меняет настройку политики на 15 и отчитывается о выполнении задачи. А спустя некоторое время выясняется, что задача вовсе и не выполнена и начальство спускает всех собак. Что же случилось и как это поправить?

Перво-наперво, однозначно было ошибкой не проверить, а работает ли Ваше изменение (Я тоже наступал в свое время на эти грабли… Плохие воспоминания… ).

Во-вторых, эта настройка регулирует вовсе не то, что кажется на первый взгляд. Если мы прочитаем ее описание в первоисточнике (а это хорошая идея для реализации перед изменениями), то мы увидим следующее: “Determines the number of users who can have cached credentials on the computer”. Или в моём вольном переводе: “Определяет количество пользователей, которые могут иметь закешированные учетные данные на этом компьютере”. Вот оно! Количество самих учетных данных, которые можно кешировать, а не раз, которые можно использовать каждый из них. Так что если у Вас есть разъездной ноутбук, на котором работает 15 пользователей (ого…), то это может Вам помочь. Но не сможет ограничить количество раз, которое можно входить в систему без контакта с  контроллером домена. 

И в-третьих, плохие новости: я не знаю, как сделать то, что требовал тот самый начальник. По-крайней мере, не знаю, как сделать это встроенными средствами Windows. Если Вы знаете – поделитесь. Впрочем, незнание, это все равно не повод говорить шефу, что Вы решили эту задачу.