Re: SetNamedSecurityInfo() & error code 1307
- From: DaveMo <david.mowers@xxxxxxxxx>
- Date: Thu, 3 Apr 2008 16:15:43 -0700 (PDT)
On Apr 3, 8:06 am, Chuck Chopp <ChuckCh...@xxxxxxxxxxx> wrote:
I have some code that calls SetNamedSecurityInfo() to set an arbitrary SID
value as the owner of a directory. All computers that run this code are
Win2K3 R2 with current patches. The domain consists of a single DC and a
single member server.
In the domain, I have an account that I created for this code to be executed
as while running as a service. On the DC, this service account has been
granted certain privs, including SE_TAKE_OWNERSHIP and SE_RESTORE. These
privs have not been granted on the member server.
While the service is running under this service account on the DC, it can
call SetNamedSecurityInfo() and set any arbitrary SID to the owner of any
directory on any local file system. If the directory is a UNC path to a
shared directory on the member server, even though the service account is
granted full permissions to the share & full NTFS permissions to the
directory, the call to SetNamedSecurityInfo() fails and error 1307 is
returned. Granting the service account the SE_TAKE_OWNERSHIP &
SE_RESTORE_NAME privs on the member server remedies the problem, even though
the service account never actually performs a logon on the member server.
My ??? is this:
Has this always been the case, that the SE_TAKE_OWNERSHIP & SE_RESTORE privs
have to be granted on the *remote* system in addition being granted on the
local system where the service account is logged on, before
SetNamedSecurityInfo() can successfully set an arbitrary SID value as the
owner when called on the local system but passed in a UNC path to a
directory on the remote system? Or, is this a change that has crept into
Windows due to a service pack or a hotfix sometime during the past 1 to 2 years?
IIRC, this code was written & tested upwards of 2 to 2.5 years ago, and it's
unclear to me whether or not this particular scenario was specifically
tested for, or if the [apparently] required rights were already granted on
the remote system in addition to being granted on the local system where the
service account is logged on. The docs for SetNamedSecurityInfo() indicate
the requirement for the privs, and also indicate that both local & remote
resources can be specified, but the possible requirement of granting the
rights to the service account on the remote system isn't discussed in the docs.
TIA,
Chuck
--
Chuck Chopp
ChuckChopp (at) rtfmcsi (dot) comhttp://www.rtfmcsi.com
RTFM Consulting Services Inc.
103 Autumn Hill Road
Greer, SC 29651
Do not send me unsolicited commercial email.
Hello Chuck,
Everything sounds like it is working as designed. Your uncertainty
probably has its roots in this statement:
even though
the service account never actually performs a logon on the member
server.
In actuality, your service is setting up a remote authenticated
session when it tries to change the SD on the remote system. For all
practical purposes, the behavior is the same as if you had run the
service on the remote machine. So if you need privileges when you run
it locally then you are going to need those same privileges when you
connect to something remotely.
HTH,
Dave
.
- References:
- SetNamedSecurityInfo() & error code 1307
- From: Chuck Chopp
- SetNamedSecurityInfo() & error code 1307
- Prev by Date: Get/set local security settings programmatically
- Next by Date: Re: How to retrieve "Public Key Policies" programmatically
- Previous by thread: SetNamedSecurityInfo() & error code 1307
- Next by thread: Get/set local security settings programmatically
- Index(es):
Relevant Pages
|
