IX509PrivateKey::Create выдает отказ в доступе при вызове сетевой службы

Я использую IX509PrivateKey для создания ключа для запроса сертификата X.509 (как «NT AUTHORITY\NETWORK SERVICE»), а метод Create генерирует отказ в доступе (я P/Invoke-ing интерфейс отправки из С# , поэтому HRESULT преобразуется в исключение .NET). Монитор процессов также показывает отказ в доступе к файлу ключа (файл ключа создается).

Вот фактический код:

        IX509PrivateKey privateKey = new CX509PrivateKey() as IX509PrivateKey;
        privateKey.Length = request.KeyLength;
        privateKey.ExportPolicy = X509PrivateKeyExportFlags.XCN_NCRYPT_ALLOW_EXPORT_FLAG;
        privateKey.KeySpec = X509KeySpec.XCN_AT_SIGNATURE;
        privateKey.KeyUsage = X509PrivateKeyUsageFlags.XCN_NCRYPT_ALLOW_ALL_USAGES;
        privateKey.MachineContext = true;
        privateKey.Create();
        return privateKey;

Если вместо этого я создам набор ключей пользователя (установив для MachineContext значение false), я увижу «Файл не найден» вместо «Отказано в доступе». Но ProcMon ничего не показывает; никаких попыток доступа к каким-либо ключевым файлам.

В Process Monitor я смог определить, что «Сетевая служба» не имеет доступа к файлу ключа, поэтому я использовал свойство IX509PrivateKey::SecurityDescriptor, чтобы установить его. «Сетевая служба» действительно тогда имела доступ к ключевому файлу, но я все еще получал отказ в доступе от Create, а ProcMon по-прежнему показывал отказ в доступе к файлу.

Много TIA для любых идей.


x509 cryptography winapi cryptoapi
person JohnC    schedule 27.06.2012    source источник
comment
Какой путь вы видите запрещенным в Procmon? IIRC, NETWORK_SERVICE не имеет особых прав в папке C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys, где хранятся ключи.   -  person ixe013    schedule 28.06.2012
comment
Определяемый доступ — это файл ключа в каталоге MachineKeys по указанному выше пути. Но когда предоставляется дескриптор безопасности, сетевая служба имеет полный контроль над этим файлом, и доступ по-прежнему запрещен.   -  person JohnC    schedule 28.06.2012

Ответы (1)


arrow_upward
1
arrow_downward

Причина этой проблемы установлена.

Вызов IX509PrivateKey::Create происходил внутри веб-службы. В результате это происходило под видом IUSR. Мы отредактировали ACL, включив не того пользователя. Оказалось, что прямой доступ запрещен, только для запутанной учетной записи пользователя. Это условие можно наблюдать в ProcMon. В столбце «Подробности» ProcMon будет четко указано (возможно, вам придется включить «Расширенный вывод»), что вызов был выполнен под учетной записью олицетворенного пользователя.

Чтобы более жестко контролировать учетную запись пользователя, под которым осуществляется вызов, и осуществляется доступ к ЦС, мы перенесли запрос вне процесса. Вызовы API регистрации теперь выполняются из собственной службы Windows и предоставляются через WCF (net.tcp) веб-службе, работающей в IIS. Это было бы моей рекомендацией для других. IMO, риск наличия еще одной «движущейся части» перевешивается отсутствием контроля над выполнением вызовов в IIS.

person JohnC    schedule 05.07.2012