|
Posted by Steven L Umbach on June 10, 2005, 10:47 am
Please log in for more thread options Thanks for clarifying that for me. Most of the time the issue is with the
computer account and that is the easiest way to disable that server for EFS
on shares rather than configuring the user account to not be able to be
delegated.
I have never tried that myself as a way to prevent a user from creating EFS
files on a share and I wonder if the changes have not been replicated to all
the necessary domain controllers or the information is being cached on the
server or once the user has the certificate on the server disabling his
account to not be able to be trusted for delegation does no longer matter.
What you might try is to create a test user that has his account configured
so that it can not be trusted for delegation right off the bat and then see
if that new test user can encrypt a file via EFS on the server share. If
that works try deleting an existing user profile on the server for a user
and then have them try to encrypt a file via EFS on the share. The user
profile is where the EFS certificate/private key is located. --- Steve
> Thanks Steve,
>
> Your solution of disabling EFS on the server is the best one I think, as I
> have only one server on remote sites, so it must be used both as
> fileserver
> and DC. which implies that it should be trusted for delegation.
>
> However, I re-read MS document that gives EFS recipe for remote shares at:
>
http://www.microsoft.com/resources/documentation/Windows/XP/all/reskit/en-us/Default.asp?url=/resources/documentation/Windows/XP/all/reskit/en-us/prnb_efs_umpb.asp
> And I quote:
> "6- EFS must impersonate the user to obtain access to the necessary public
> or private key. This requires the following:
> 1. The computer must be a domain member in a domain that uses Kerberos
> authentication because impersonation relies on Kerberos authentication and
> delegation.
> 2. The computer must be trusted for delegation.
> 3. The user must be logged on with a domain account that can be
> delegated.
> Note:
> Use the Active Directory Users and Computers snap-in to configure
> delegation
> options for both users and computers. To trust a computer for delegation,
> open the computer's Properties sheet, and select Trusted for delegation.
> To
> allow a user account to be delegated, open the user's Properties sheet. On
> the Account tab, under Account Options, clear the The account is sensitive
> and cannot be delegated check box. Do not select The account is trusted
> for
> delegation. This property is not used with EFS."
>
> I conducted some tests and no matter if I check or clear the "The account
> is
> sensitive and cannot be delegated" check box in the user properties, that
> does not change anything at all. A user from a station can still
> encrypt/decrypt files on the network share.
>
> Maybe I am missing something here... Whereas I got a perfect solution for
> my
> needs, if someone has an explanation, I would be very grateful.
>
> Thanks,
> Guillaume.
> -
>
>
> "Steven L Umbach" wrote:
>
>> The computer account needs to be trusted for delegation - not the user
>> account. Domain controllers need to be trusted for delegation. You could
>> either use a different server for your share or configure the Domain
>> Controller Security Policy so that the domain controller will not use
>> EFS.
>> The link below should help. --- Steve
>>
>> http://www.petri.co.il/disable_efs_in_windows_xp_2003.htm
>>
>> > Hi,
>> >
>> > On a Windows 2003 native domain we have setup an Enterprise CA that
>> > emits
>> > EFS v2 Certificates through auto-enrollment. We want users to be able
>> > to
>> > encrypt on their computers, but NOT on network shares.
>> > Here is the test:
>> > - in Active Directory, user1 (test) account property "Account is
>> > sensitive
>> > and cannot be delegated" is checked. So I presume delegation cannot
>> > occur
>> > - we have a DC (trusted for delegation), on which there is a share
>> > (share
>> > is
>> > on a DC as remote offices only have one server)
>> > - from a station, logged on as user1, we connect to the shre, create a
>> > file
>> > and try to encrypt it.
>> > And... It works! File is encrypted using EFS.
>> >
>> > How is it possible as this account is supposed not to be delegated?
>> >
>> > Server: W2003 SP1, Station XP SP1
>> >
>> > Thanks,
>> > Guillaume.
>> >
>>
>>
>>
| 
XML Sitemap