Команда ktpass отключает аутентификацию по паролю

Question

У меня просто небольшой вопрос по команде ktpass. У меня есть пользователь my-test-user с паролем myPassword!. Я могу войти в систему с этой учетной записью, используя имя пользователя и пароль. Но когда я использую следующую команду для создания файла keytab, я просто могу войти в систему с файлом keytab (например, kinit).

ktpass /out test.keytab /princ HTTP/[e-mail] /pass * /mapuser [e-mail] /ptype KRB5_NT_PRINCIPAL /crypto RC4-HMAC-NT

Если я пытаюсь подключиться с помощью имени пользователя / пароля, свойство badPwdCount увеличивается.

Мой вопрос: отключает ли команда ktpass аутентификацию по паролю?

Большое спасибо.

Answer 1

Короткий ответ: нет.

В /pass *опция означает запрос пароля. В /mapuserопция означает поиск деталей в AD. Если значение передано через /pass не соответствует тому, что хранится в AD, /mapuser call установит пароль в AD для всего переданного.

На какой сборке Windows вы это используете? В сборке ktpass, поставляемой с Windows 2012, есть ошибка в /passобработка параметров, которая добавляет управляющий символ клавиши ввода в строку, отправляемую в AD, так что она сбрасывает ее неправильно. Это было исправлено в более поздних версиях ОС.

Answer 2

Нет, но здесь есть пара возможных факторов:

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

По-видимому, это сделано для того, чтобы клиенты Linux могли успешно получить билет с этой таблицей ключей (поскольку от клиента Linux, использующего kinit, если мы попытаемся получить билет Kerberos, используя имя участника-службы, зарегистрированное в учетной записи как имя участника-службы, но не совпадающее с именем участника-пользователя какой-либо учетной записи, kinit сообщит нам, что принципал не существует). Клиенты Windows могут получать билеты для имен участников-служб, которые только что зарегистрированы как имена участников-служб, не требуя, чтобы имя участника-пользователя учетной записи службы соответствовало запрашиваемому имени участника-службы.

Итак, если бы мы попытались аутентифицироваться, используя «обычный» UPN учетной записи (имя UPN было до запуска, например [e-mail]), после создания keytab без указания , проверка подлинности завершится ошибкой, так как этот UPN больше недействителен.

Другая проблема заключается в том, что, кажется, «искажает» пароль, который вводится при использовании параметра, чтобы заставить его запрашивать ввод пароля. либо установит пароль на то, что мы указываем (если он не включен), либо просто создаст keytab, используя указанный нами пароль, поверив нам на слово, что он правильный (но, конечно, полученный keytab не будет работать, если неверный пароль дано).

Основываясь на моем тестировании, если мы введем пароль в самой команде (например), keytab будет работать нормально (при условии, что пароль был правильным), и аутентификация по паролю также должна работать, хотя только если мы либо укажем имя пользователя в DOMAIN\usernameформат или если мы включили -SetUPNв нашей команде из-за проблемы с UPN, указанной выше.

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

• Либо результирующий файл keytab будет недействительным и не будет работать — это происходит, если мы включили параметр (который говорит не менять пароль учетной записи), потому что тогда генерируется keytab с искаженным паролем, хотя «настоящий» пароль на account — это значение, которое мы ввели в подсказке.
• Или результирующий пароль для учетной записи будет установлен на неизвестное значение (а не значение, которое мы ожидаем) — т. е. искаженная версия введенного нами пароля — это произойдет, если мы не включили , и в этом случае изменится пароль учетной записи на любое значение, в которое он искажает наш ввод. В этом случае keytab будет работать, но когда мы попытаемся пройти аутентификацию с этой учетной записью, используя пароль, мы получим ошибку неверного пароля (поскольку пароль в учетной записи не тот, который мы думаем, - это не то значение, которое мы ввели по подсказке).

Я проверил и подтвердил это поведение на 2008R2, 2012 и 2012R2 — мне не удалось протестировать что-либо более новое.

Подводя итог: если вам нужно знать пароль учетной записи, чтобы вы могли аутентифицироваться с помощью любого метода (пароль или keytab) после создания keytab, вам нужно ввести свой пароль в самой команде ktpass, а не запрашивать ее ( т.е. использовать /Pass P@ssw0rdскорее, чем /Pass *). Просто убедитесь, что вы делаете это в безопасной обстановке, где нет возможности, чтобы кто-то заглядывал вам через плечо или молча наблюдал за вашим экраном (к счастью, Windows по умолчанию не записывает историю cmd постоянно).

С другой стороны, если вам не нужно знать пароль учетной записи после создания keytab, то, вероятно, лучше всего просто использовать +rndPass- это заставит сгенерировать случайный пароль для учетной записи, и keytab будет работать нормально.

*РЕДАКТИРОВАТЬ/ОБНОВИТЬ: Еще одна особенность, которую я обнаружил при тестировании, заключается в том, что кажется, что новая учетная запись создается с известным паролем и запускается для создания таблицы ключей для этой учетной записи, указав пароль в команде, как указано выше, но с параметром результирующая таблица ключей не будет работать. Если мы запустим и укажем пароль без , чтобы ktpass"сбросить" пароль (на то же значение, которое уже было - значение, которое мы установили при создании учетной записи), полученный keytab работает нормально, как и аутентификация по паролю. И любые последующие вкладки, созданные с этого момента, будут работать (даже если они созданы с помощью -SetPass). У меня нет объяснения такому поведению (наблюдается на Server 2012 и 2012R2).