SetNamedSecurityInfo() & error code 1307

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) com http://www.rtfmcsi.com

RTFM Consulting Services Inc.
103 Autumn Hill Road
Greer, SC 29651

Do not send me unsolicited commercial email.
.

Relevant Pages

  • Re: SetNamedSecurityInfo() & error code 1307
    ... privs have not been granted on the member server. ... While the service is running under this service account on the DC, ... have to be granted on the *remote* system in addition being granted on the ... local system where the service account is logged on, ...
    (microsoft.public.platformsdk.security)
  • Re: sql server does not exist
    ... You can change the service account to Local System via Windows service ... Repeat for SQL Server agent. ...
    (microsoft.public.sqlserver.server)
  • kerberos SQL service accounts
    ... The SQL DBA's are being asked to change all SQL service accounts from local system to a domain user account. ... Once the SQL service account is changed from local system to a domain user account does SQL start using kerberos authentication? ... I would think i would need to regsiter a SPN for the service account that is running on the SQL virtual server or instance and not the physical node? ...
    (microsoft.public.windows.server.active_directory)
  • Re: Meta Data not found when using a Windows Service
    ... I am an administrator on this workstation. ... I just tested it as local system and it is still giving the same errors. ... Nathan ... >> I don't know what you mean by identity of the service account. ...
    (microsoft.public.dotnet.languages.csharp)