Назад | Перейти на главную страницу

Как предоставить пользователю доступ к хранилищу сертификатов в Windows Server 2012?

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

У меня есть сценарий PowerShell, который использует XapSignTool.exe для подписи пакета .xap. Предоставляются закрытый ключ и пароль. Когда я запускаю сценарий, войдя в систему как пользователь в группе администраторов, он работает нормально.

Я также запускаю службу удаленного управления Windows на том же компьютере. С другой машины, Linux, я использую протокол winrm для вызова сценария PowerShell с необходимыми параметрами. Затем инструмент XapSignTool.exe или, в частности, signtool.exe, который используется ниже, выдает ошибку:

Error information: "Error: Store::ImportCertObject() failed." (-2146893808/0x80090010)

Я поискал код и выяснил, что это значит, т.е.

NTE_PERM
0x80090010
В доступе отказано.

Название метода ImportCertObject () наводит меня на мысль, что инструмент пытается импортировать предоставленный закрытый ключ в хранилище сертификатов.

Интересно то, что если я сначала запускаю скрипт при входе в систему, и он работает, последующие вызовы через winrm работают. Это наводит меня на мысль, что сертификат правильно импортируется пользователем, который является администратором.

Служба WRM работала под учетной записью сетевой службы, поэтому я предположил, что у нее нет разрешений на вставку в хранилище сертификатов. Я поместил учетную запись NS в группу «Администраторы» в надежде, что она заработает, но этого не произошло. Для тестов я поместил \ Everyone в группу «Администраторы», и вызов winrm для сценария PowerShell по-прежнему завершился ошибкой «Доступ запрещен».

Почему это? Как я могу предоставить пользователю доступ к хранилищу сертификатов?

Я также хочу иметь возможность сделать это для многих таких сертификатов, поэтому это нужно автоматизировать.

После нескольких дней исследований я не нашел причину на самом низком значимом уровне, но немного выше, чем tat.

Сценарий работал, когда пользователь входил в систему, поскольку уже был зарегистрирован в интерактивном режиме на машине. Если я выйду из машины, скрипт перестанет работать.

Это было проблемой с WinRM, и одним из обходных путей было использование CredSSP. Другой способ решить эту проблему - изменить все решение на службу HTTP или потребителя очереди сообщений.

Возникла аналогичная проблема с signtool.exe, возвращающим «Ошибка: сбой Store :: ImportCertObject ()». (-2146893808 / 0x80090010). В моем случае я подключался из Linux через ssh, а sshd размещался в оболочке среды Cygwin.

Следующий пост на https://cygwin.com/ml/cygwin/2008-10/msg00588.html. казалось очень актуальным. (смотрите также - https://cygwin.com/ml/cygwin/2007-01/msg00651.html)

Либо используйте аутентификацию по паролю вместо аутентификации с открытым ключом при входе в систему через ssh. Аутентификация по паролю создает действительный сеанс входа в систему, поэтому вы правильно идентифицированы и проблема должна исчезнуть.

В нижней строке либо логин на основе пароля пользователя, либо настройка учетной записи службы с соответствующими привилегиями. Где-то при использовании аутентификации на основе сертификатов олицетворение пользователей работает не так, как ожидалось.

Хоть и старый пост, но надеюсь, что другие сочтут его полезным.

У меня была ошибка, похожая на эту, и когда я ее искал, ничего важного, кроме этого, не возникло, поэтому я просто хотел опубликовать свое решение на случай, если кто-то еще придет сюда с моей проблемой.

Разница заключается в коде ошибки "(-2146893792 / 0x80090020)" вместо того, который был в исходном сообщении.

Проблема оказалась, когда я преобразовал JKS в PFX для хранилища сертификатов. Я использовал старую версию Java Keytool для выполнения преобразования, которое не предупреждало меня о том, что изменение пароля хранилища ключей отличается от изменения пароля закрытого ключа для сертификата. В итоге у меня были разные пароли, и большинство инструментов (включая SignTool) предполагают, что пароли одинаковы. Выполнение нового преобразования, убедившись, что для закрытого ключа и пароля хранилища установлено одно и то же, решило проблему.