Discussion:
Help with CryptAcquireContext and Mandatory Profiles!
(too old to reply)
n***@nospam.nospam
2007-08-17 21:44:05 UTC
Permalink
Our software product that we develop calls the Windows Crypt method
CryptAcquireContext, but we have a customer that has to use mandatory
profiles. Calling this method throws the error code
NTE_TEMPORARY_PROFILE. I've researched this and have found that this is
by design for temporary profiles. And from my understanding, correct me
if I'm wrong, this is because this method would write out a key to the
profile but since its temporary it wouldn't save.

This how we call it:
CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )

A few questions:
1. Where and what does CryptAcquireContext save to a profile registry? I
did a registry export diff and saw that the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed gets changed
for a non-mandatory profile when I call the above method.
2. If we were to change the registry permissions for this mandatory
profile to allow that registry key to be editable for the profile, would
this work? We tried it for the above key, it didn't work, but it may not
be the right key for a mandatory profile.
3. Or does this method just do a blanket check to see if its a temporary
profile and not even try if it is?
4. If permissions isn't the answer, can we call CryptAcquireContext
differently to avoid this issue? We use this method for both MD5 hashing
and RC4 encryption.
5. Are there any other options either for the client's enviroment or in
our code?

Thanks for any help. We've been struggling with this for a while.

nmaier
Jeffrey Tan[MSFT]
2007-08-20 09:17:50 UTC
Permalink
Hi Nmaier,

Yes, CryptAcquireContext fails with NTE_TEMPORARY_PROFILE when it¡¯s called
from a mandatory profile. Mandatory profiles are read-only user profiles.
Since changes to the mandatory profile cannot be saved, PKI design doesn't
allow this operation, and CryptAcquireContext prevents this scenario by
failing.

Private keys are protected by DPAPI component of Windows. DPAPI component
regularly creates new master keys in the profile to protect confidential
information such as private keys. For security reasons, MasterKeys will
expire, which means that after a period of time, the hard-coded value being
three months, a new MasterKey is generated and protected in the same
manner. This expiration prevents an attacker from compromising a single
MasterKey and accessing all of a user's protected data.

The Master Key regeneration is explained in the DPAPI white-paper at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/ht
ml/windataprotection-dpapi.asp

So, higher level components that depend on DPAPI to protect confidential
information cannot be protected securely with mandatory profiles for the
same reasons.

The behavior one will see when using mandatory profiles is documented at:

Cryptographic Keys and Certificates Cannot Be Used with Mandatory Profiles
http://support.microsoft.com/default.aspx?scid=kb;en-us;264732

How to troubleshoot the Data Protection API (DPAPI)
"DPAPI and Mandatory Profiles"
http://support.microsoft.com/default.aspx?scid=kb;en-us;309408

Q243850 - 243850 - Cannot Gain Access to Microsoft Encrypted File Systems
http://support.microsoft.com/support/kb/articles/Q243/8/50.asp

SOLUTION:
There are three possible solutions:

1) If you need to access some user¡¯s private keys (i.e. when signing data)
and you want to prevent other users from using its keys, the only way is
configuring the profile as non-mandatory.

2) If you need a persistent RSA private key, then the only solution is to
use CryptAcquireContext with the CRYPT_MACHINE_KEYSET flag for private key
storage in this configuration. But this is not protected based on the
user's password hash, so any user will have access to the keys.

3) If you don¡¯t need persistent RSA private keys (i.e. when verifying
signatures), you could use CryptAcquireContext with the CRYPT_VERIFYCONTEXT
flag. The flag tells CryptoAPI to create the key container in memory and
not in the user¡¯s profile. You don¡¯t need to worry about deleting the key
container; you just release the handle with CryptReleaseContext.

Additional info about CryptAcquireContext & CRYPT_VERIFYCONTEXT:

238187 CryptAcquireContext() use and troubleshooting
http://support.microsoft.com/?id=238187

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
n***@nospam.nospam
2007-08-21 16:27:08 UTC
Permalink
Jeffrey,
Thanks for the reply, it was very informative!!

I'm looking at your option 3 with the CRYPT_VERIFYCONTEXT flag, and we are
actually already using that flag in our code.
CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )

But it doesn't work and we still get the NTE_TEMPORARY_PROFILE error
code. Our customer uses the mandatory profiles with a Citrix connection.
Would that have any effect? Is it possible there is a bug in the
CryptAcquireContext() method that is triggering that error when it
shouldn't be?

Thanks!
nmaier



On Mon, 20 Aug 2007 04:17:50 -0500, "Jeffrey Tan[MSFT]"
Post by Jeffrey Tan[MSFT]
Jeffrey
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
Jeffrey Tan[MSFT]
2007-08-23 02:48:09 UTC
Permalink
Hi Nmaier,

Thank you for the feedback.

I have discussed this issue with some other security experts. Since you
are using symmetric RC4 encryption, using CRYPT_VERIFYCONTEXT flag is the
right choice.

Actually, CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT ) doesn¡¯t guarantee that a Microsoft CSP will be used
as it depends on what is the default in the registry key.

Using CRYPT_VERIFYCONTEXT with Microsoft¡¯s CSP as below
CryptAcquireContext( &_cryptProvider, NULL, MS_DEF_PROV, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )
Or
CryptAcquireContext( &_cryptProvider, NULL, MS_ENHANCED_PROV,
PROV_RSA_FULL, CRYPT_VERIFYCONTEXT )

will create an in-memory container and should work fine. Microsoft CSP
doesn¡¯t use profile if CRYPT_VERIFYCONTEXT flag is used.

Assuming Microsoft CSP is used, CRYPT_VERIFYCONTEXT shouldn¡¯t fail with
that error code. In fact, using CRYPT_VERIFYCONTEXT flag shouldn¡¯t fail at
all.

Currently, it is hard to see the root cause without reproducing this
behavior. By guessing, I think either your application code is not making
that call as you see in the code or the error code is different. It is
highly likely the your application has other CryptAcquireContext calls that
doesn¡¯t use this flag.

To debugging this, you may attach a debugger(like windbg) to verify that
CryptAcquireContext is called correctly as you see in the code. I did not
verify that, but you may try to use the windbg commands below to dump out
the 5 parameter(dwFlags) value during your application running:
bp ADVAPI32!CryptAcquireContextA "dd poi(esp+0x14) l1;gc"
bp ADVAPI32!CryptAcquireContextW "dd poi(esp+0x14) l1;gc"

My original reply explains why why CryptAcquireContext would fail for other
flags where the user¡¯s profile is temporary. This behavior is by design.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Jeffrey Tan[MSFT]
2007-08-27 03:31:09 UTC
Permalink
Hi Nmaier,

Have you reviewed my last reply to you? Does it make sense to you? If you
still need any help or have any concern, please feel free to feedback,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
n***@nospam.nospam
2007-08-30 20:22:33 UTC
Permalink
Hi Jeffrey,
Sorry for the long delay in responding. The customer and their =

environment made it extremely difficult to troubleshoot this problem =

efficiently and quickly. We ended up having to change our code, send ou=
t =

the new DLLs, wait for the result, and then change the DLLs again =

accordingly. But I did find a solution, thanks in large part to the =

valuable information you provided here.

The Crypto provider was fine, it was the default Microsoft provider. Th=
e =

citrix connection doesn't seem to change that any. The solution was in o=
ur =

code; we weren't very specific in handling the crypto errors and as a =

result was looking in the wrong area for the problem. Once we handled t=
he =

NTE_TEMPORARY_PROFILE error correctly it worked perfectly.

Thanks for all your help and quick responses!

Nate

On Sun, 26 Aug 2007 22:31:09 -0500, "Jeffrey Tan[MSFT]" =
Post by Jeffrey Tan[MSFT]
Hi Nmaier,
Have you reviewed my last reply to you? Does it make sense to you? If =
you
Post by Jeffrey Tan[MSFT]
still need any help or have any concern, please feel free to feedback,=
thanks.
Best regards,
Jeffrey Tan
Microsoft Online Community Support
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Post by Jeffrey Tan[MSFT]
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx=
#notif
Post by Jeffrey Tan[MSFT]
ications.
Note: The MSDN Managed Newsgroup support offering is for non-urgent =
issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each =
follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach =
the
Post by Jeffrey Tan[MSFT]
most efficient resolution. The offering is not appropriate for situati=
ons
Post by Jeffrey Tan[MSFT]
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are b=
est
Post by Jeffrey Tan[MSFT]
handled working with a dedicated Microsoft Support Engineer by contact=
ing
Post by Jeffrey Tan[MSFT]
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
Post by Jeffrey Tan[MSFT]
This posting is provided "AS IS" with no warranties, and confers no =
rights.
Jeffrey Tan[MSFT]
2007-08-31 03:12:31 UTC
Permalink
Hi Nate,

Cool, thank you for confirming and feedback the status! It seems handing
the API error is a crucial part in programming.

If you need further help, please feel free to post, I will work with you,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.
Pankaj Kumar
2010-06-17 06:43:00 UTC
Permalink
Hi Jeffrey and Nate

I am having a similar kind of problem where we use our designed toolbar in IE for call purposes.It works properly in admin profile but fails to load fully in case of a mandatory user.When i say failing to load fully i mean not all widgets are getting loaded.

i tried to find out the problem and came to the conclusion that following line was cause of it :

if (!CryptAcquireContext(&hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, NULL ))
{
if(GetLastError() == NTE_BAD_KEYSET)
CryptAcquireContext(&hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_NEWKEYSET );
}


I changed it to :


if (!CryptAcquireContext(&hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_MACHINE_KEYSET | CRYPT_VERIFYCONTEXT ))
{
if(GetLastError() == NTE_BAD_KEYSET){
CryptAcquireContext(&hProv, NULL, MS_ENHANCED_PROV, PROV_RSA_FULL, CRYPT_NEWKEYSET | CRYPT_MACHINE_KEYSET | CRYPT_VERIFYCONTEXT);
}

}

Now what happens is that when i login to mandatory profile and open IE for the first time nothing happens but i can see IE running in the task manager. If i try to open IE again, the IE window now opens and everything seems to be working properly.
Now if i close and open IE , everything works as desired.
Its just that why IE doesn't open for the first time, i even waited for a long time but no use.

Thanks
Pankaj



jeta wrote:

Hi Nate,Cool, thank you for confirming and feedback the status!
30-Aug-07

Hi Nate,

Cool, thank you for confirming and feedback the status! It seems handing
the API error is a crucial part in programming.

If you need further help, please feel free to post, I will work with you,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

Previous Posts In This Thread:

On Friday, August 17, 2007 5:44 PM
nmaie wrote:

Help with CryptAcquireContext and Mandatory Profiles!
Our software product that we develop calls the Windows Crypt method
CryptAcquireContext, but we have a customer that has to use mandatory
profiles. Calling this method throws the error code
NTE_TEMPORARY_PROFILE. I've researched this and have found that this is
by design for temporary profiles. And from my understanding, correct me
if I'm wrong, this is because this method would write out a key to the
profile but since its temporary it wouldn't save.

This how we call it:
CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )

A few questions:
1. Where and what does CryptAcquireContext save to a profile registry? I
did a registry export diff and saw that the key
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\RNG\Seed gets changed
for a non-mandatory profile when I call the above method.
2. If we were to change the registry permissions for this mandatory
profile to allow that registry key to be editable for the profile, would
this work? We tried it for the above key, it didn't work, but it may not
be the right key for a mandatory profile.
3. Or does this method just do a blanket check to see if its a temporary
profile and not even try if it is?
4. If permissions isn't the answer, can we call CryptAcquireContext
differently to avoid this issue? We use this method for both MD5 hashing
and RC4 encryption.
5. Are there any other options either for the client's enviroment or in
our code?

Thanks for any help. We've been struggling with this for a while.

nmaier

On Monday, August 20, 2007 5:17 AM
jeta wrote:

Hi Nmaier,Yes, CryptAcquireContext fails with NTE_TEMPORARY_PROFILE when it??s
Hi Nmaier,

Yes, CryptAcquireContext fails with NTE_TEMPORARY_PROFILE when it??s called
from a mandatory profile. Mandatory profiles are read-only user profiles.
Since changes to the mandatory profile cannot be saved, PKI design doesn't
allow this operation, and CryptAcquireContext prevents this scenario by
failing.

Private keys are protected by DPAPI component of Windows. DPAPI component
regularly creates new master keys in the profile to protect confidential
information such as private keys. For security reasons, MasterKeys will
expire, which means that after a period of time, the hard-coded value being
three months, a new MasterKey is generated and protected in the same
manner. This expiration prevents an attacker from compromising a single
MasterKey and accessing all of a user's protected data.

The Master Key regeneration is explained in the DPAPI white-paper at:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/ht
ml/windataprotection-dpapi.asp

So, higher level components that depend on DPAPI to protect confidential
information cannot be protected securely with mandatory profiles for the
same reasons.

The behavior one will see when using mandatory profiles is documented at:

Cryptographic Keys and Certificates Cannot Be Used with Mandatory Profiles
http://support.microsoft.com/default.aspx?scid=kb;en-us;264732

How to troubleshoot the Data Protection API (DPAPI)
"DPAPI and Mandatory Profiles"
http://support.microsoft.com/default.aspx?scid=kb;en-us;309408

Q243850 - 243850 - Cannot Gain Access to Microsoft Encrypted File Systems
http://support.microsoft.com/support/kb/articles/Q243/8/50.asp

SOLUTION:
There are three possible solutions:

1) If you need to access some user??s private keys (i.e. when signing data)
and you want to prevent other users from using its keys, the only way is
configuring the profile as non-mandatory.

2) If you need a persistent RSA private key, then the only solution is to
use CryptAcquireContext with the CRYPT_MACHINE_KEYSET flag for private key
storage in this configuration. But this is not protected based on the
user's password hash, so any user will have access to the keys.

3) If you don??t need persistent RSA private keys (i.e. when verifying
signatures), you could use CryptAcquireContext with the CRYPT_VERIFYCONTEXT
flag. The flag tells CryptoAPI to create the key container in memory and
not in the user??s profile. You don??t need to worry about deleting the key
container; you just release the handle with CryptReleaseContext.

Additional info about CryptAcquireContext & CRYPT_VERIFYCONTEXT:

238187 CryptAcquireContext() use and troubleshooting
http://support.microsoft.com/?id=238187

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

On Tuesday, August 21, 2007 12:27 PM
nmaie wrote:

Jeffrey,Thanks for the reply, it was very informative!!
Jeffrey,
Thanks for the reply, it was very informative!!

I'm looking at your option 3 with the CRYPT_VERIFYCONTEXT flag, and we are
actually already using that flag in our code.
CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )

But it doesn't work and we still get the NTE_TEMPORARY_PROFILE error
code. Our customer uses the mandatory profiles with a Citrix connection.
Would that have any effect? Is it possible there is a bug in the
CryptAcquireContext() method that is triggering that error when it
shouldn't be?

Thanks!
nmaier



On Mon, 20 Aug 2007 04:17:50 -0500, "Jeffrey Tan[MSFT]"
<***@online.microsoft.com> wrote:
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/

On Wednesday, August 22, 2007 10:48 PM
jeta wrote:

Hi Nmaier,Thank you for the feedback.
Hi Nmaier,

Thank you for the feedback.

I have discussed this issue with some other security experts. Since you
are using symmetric RC4 encryption, using CRYPT_VERIFYCONTEXT flag is the
right choice.

Actually, CryptAcquireContext( &_cryptProvider, NULL, NULL, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT ) doesn??t guarantee that a Microsoft CSP will be used
as it depends on what is the default in the registry key.

Using CRYPT_VERIFYCONTEXT with Microsoft??s CSP as below
CryptAcquireContext( &_cryptProvider, NULL, MS_DEF_PROV, PROV_RSA_FULL,
CRYPT_VERIFYCONTEXT )
Or
CryptAcquireContext( &_cryptProvider, NULL, MS_ENHANCED_PROV,
PROV_RSA_FULL, CRYPT_VERIFYCONTEXT )

will create an in-memory container and should work fine. Microsoft CSP
doesn??t use profile if CRYPT_VERIFYCONTEXT flag is used.

Assuming Microsoft CSP is used, CRYPT_VERIFYCONTEXT shouldn??t fail with
that error code. In fact, using CRYPT_VERIFYCONTEXT flag shouldn??t fail at
all.

Currently, it is hard to see the root cause without reproducing this
behavior. By guessing, I think either your application code is not making
that call as you see in the code or the error code is different. It is
highly likely the your application has other CryptAcquireContext calls that
doesn??t use this flag.

To debugging this, you may attach a debugger(like windbg) to verify that
CryptAcquireContext is called correctly as you see in the code. I did not
verify that, but you may try to use the windbg commands below to dump out
the 5 parameter(dwFlags) value during your application running:
bp ADVAPI32!CryptAcquireContextA "dd poi(esp+0x14) l1;gc"
bp ADVAPI32!CryptAcquireContextW "dd poi(esp+0x14) l1;gc"

My original reply explains why why CryptAcquireContext would fail for other
flags where the user??s profile is temporary. This behavior is by design.

Hope this helps.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

On Sunday, August 26, 2007 11:31 PM
jeta wrote:

Hi Nmaier,Have you reviewed my last reply to you? Does it make sense to you?
Hi Nmaier,

Have you reviewed my last reply to you? Does it make sense to you? If you
still need any help or have any concern, please feel free to feedback,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.

On Thursday, August 30, 2007 4:22 PM
nmaie wrote:

Hi Jeffrey,Sorry for the long delay in responding.
Hi Jeffrey,
Sorry for the long delay in responding. The customer and their =

environment made it extremely difficult to troubleshoot this problem =

efficiently and quickly. We ended up having to change our code, send ou=
t =

the new DLLs, wait for the result, and then change the DLLs again =

accordingly. But I did find a solution, thanks in large part to the =

valuable information you provided here.

The Crypto provider was fine, it was the default Microsoft provider. Th=
e =

citrix connection doesn't seem to change that any. The solution was in o=
ur =

code; we weren't very specific in handling the crypto errors and as a =

result was looking in the wrong area for the problem. Once we handled t=
he =

NTE_TEMPORARY_PROFILE error correctly it worked perfectly.

Thanks for all your help and quick responses!

Nate

On Sun, 26 Aug 2007 22:31:09 -0500, "Jeffrey Tan[MSFT]" =

<***@online.microsoft.com> wrote:

you

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D


the
ons
est
ing
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D

On Thursday, August 30, 2007 11:12 PM
jeta wrote:

Hi Nate,Cool, thank you for confirming and feedback the status!
Hi Nate,

Cool, thank you for confirming and feedback the status! It seems handing
the API error is a crucial part in programming.

If you need further help, please feel free to post, I will work with you,
thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/subscriptions/managednewsgroups/default.aspx#notif
ications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/subscriptions/support/default.aspx.
==================================================

This posting is provided "AS IS" with no warranties, and confers no rights.


Submitted via EggHeadCafe - Software Developer Portal of Choice
Server Side Processing in ADO.NET/WCF Data Services
http://www.eggheadcafe.com/tutorials/aspnet/db179aed-47fa-4f86-a4bf-4f6f92a76585/server-side-processing-in-adonetwcf-data-services.aspx
Loading...