Проблема с использованием WIF с IIS6 - PullRequest
0 голосов
/ 28 сентября 2010

У нас возникла проблема с использованием модуля SessionAuthenticationModule на IIS 6, при попытке доступа к приложению возникает следующее исключение:

Операция защиты данных не удалась.Это может быть вызвано тем, что профиль пользователя не загружен для пользовательского контекста текущего потока, что может быть в случае олицетворения потока.

Что я смог выяснить, так это то, чтоМожно включить профили в IIS 7, но наша хостинговая компания использует IIS 6. Есть идеи, что делать? Что-то попробовать или просто общие идеи?

Stacktrace:

[CryptographicException: The data protection operation was unsuccessful. This may have been caused by not having the user profile loaded for the current thread's user context, which may be the case when the thread is impersonating.]
    System.Security.Cryptography.ProtectedData.Protect(Byte[] userData, Byte[] optionalEntropy, DataProtectionScope scope) +456
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +54

[InvalidOperationException: ID1074: A CryptographicException occurred when attempting to encrypt the cookie using the ProtectedData API (see inner exception for details). If you are using IIS 7.5, this could be due to the loadUserProfile setting on the Application Pool being set to false. ]
    Microsoft.IdentityModel.Web.ProtectedDataCookieTransform.Encode(Byte[] value) +146
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.ApplyTransforms(Byte[] cookie, Boolean outbound) +47
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(XmlWriter writer, SecurityToken token) +470
    Microsoft.IdentityModel.Tokens.SessionSecurityTokenHandler.WriteToken(SessionSecurityToken sessionToken) +89
    Microsoft.IdentityModel.Web.SessionAuthenticationModule.WriteSessionTokenToCookie(SessionSecurityToken sessionToken) +123

Ответы [ 4 ]

2 голосов
/ 23 марта 2011

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

1 голос
/ 26 октября 2010

У меня была такая же проблема с локальным сервером IIS7, и я решил ее, установив для loadUserProfile значение true в пуле приложений.Я обнаружил следующее относительно IIS6:

В IIS6 все рабочие процессы, независимо от того, какой идентификатор процесса был настроен, использовались для C: \ windows \ temp в качестве временного каталога.Более конкретно, ни один из рабочих процессов по умолчанию не загружал свой «профиль пользователя», в результате чего все они использовали c: \ windows \ temp в качестве временного каталога.Windows разрешает всем пользователям права чтения / записи / создания в этом каталоге, что позволяет «просто работать».Негативным побочным эффектом этого является то, что все AppPools по умолчанию совместно используют один и тот же временный каталог, что может привести к раскрытию информации между приложениями.В IIS7 мы выбрали более безопасный режим по умолчанию и теперь загружаем профиль пользователя по умолчанию для всех пулов приложений.

loadUserProfile и IIS7

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

0 голосов
/ 10 октября 2012

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

0 голосов
/ 07 августа 2011

Вы можете обойти необходимость в профиле пользователя, используя RSA вместо DPAPI для защиты токенов сеанса.На самом деле это лучшая практика для всех развертываний, но особенно для балансировки нагрузки (а кто не балансирует нагрузку на предприятии?)

Доминик Байер кое-что написал об этом:

...