|
Posted by Dave Williams on March 3, 2006, 10:52 am
Please log in for more thread options Ah that's very interesting, that Domain Admins (therefore AD controller
Administrators group) has no advanced privileges on a member server other
than those granted by that member's Administrators group.
I'll ask the customer to try with a few other combinations along those
lines, and let you know how it goes.
>I believe static analysis of rights is rather more involved than is
> just looking at the effective by listing out from the token.
> So the service works is Domain Admin, running on a member,
> but not is only in that member's local Administrators group?
> That seems to imply it is an issue with access to off-box resource,
> as being in Domain Admins will not give any (in default settings
> at least) added privs on a member beyond what is given to its
> Adminsitrators.
>
>> Thanks for your feedback. I did look at sysinternals before making this
>> posting (as I've got handy apps from them before). The only thing I can
>> see that might be appropriate is TokenMon, which lists live privilege
>> allocations, rather than listing the static state which I think would be
>> adequate for my purposes.
>>
>> Your description is quite correct. The service is not running on a DC,
>> it's on a member server.
>>
>> Currently I have discovered that the service user being a member of the
>> Domain Admins group resolves the issue, and I'm suspecting (but not yet
>> confirmed) that being a member of the Administrators group for the domain
>> will also resolve the issue. The user is already a member of the
>> Administrators group for the machine, so my task will be to identify what
>> are the privilege differences between those two groups, then
>> incrementally add and remove those until I work out what's the key one.
>>
>> The problem is on a customer site, which slows down testing of the issue,
>> and the customer requires that we set minimal rights on the user running
>> the service, so just leaving it as member of the domain's Administrators
>> group is not considered to be a solution.
>>
>> Any suggestions would be appreicated :)
>> Dave
>>
>>
>>>I believe that www.sysinternal.com has tool you might use that
>>> looks at the live token and lists out the privileges. It seems to
>>> me the problem going that route is you will see very many that
>>> are not involved as admins have most all.
>>> To clarify the situation . . .
>>> You have developed a true service
>>> When you define this service with the service control manager
>>> to start in a custom account (that has right to log in as service)
>>> the service starts, but cannot write files to specificed area.
>>> If you add that custom account to administrators group of the
>>> machine where installed then the file write works.
>>> ???
>>> Notice I got rid to the Domain Admins part, and implied this
>>> is not installed on a DC (administrators group of the machine).
>>> Can you narrow it down to a non-DC install or do you really
>>> need to take the discussion onto DC territory (Adminsitrators
>>> group in domain) ?
>>>
>>>> Hi all, is there a simple utility I can use that will list all the
>>>> privileges a user has in a Windows 2000 environment?
>>>>
>>>> A service I've develeoped is getting a failure to create a file on one
>>>> user's disk drive but not on another drive in the same system. The
>>>> problem is not fixed by granting the user that runs the service full
>>>> access to the base directory, but it is fixed by adding the user that
>>>> runs the service to the Domain Admins group.
>>>>
>>>> I figure the only way to diagnose this is to work out what the
>>>> privilege difference between the user that runs the service as it is,
>>>> and that user when it's added to Domain Admins (I will test if the
>>>> problem occurs if the user is added to the Administrators group for the
>>>> domain, which I believe is the one with all the privileges).
>>>>
>>>> I'd ideally like something that would list all the privileges a user
>>>> has, pref using the descriptive name not the symbolic name for the
>>>> privilege, and which group they were got through etc.
>>>>
>>>> Or any other suggestions for tracking down this issue!
>>>>
>>>> Thanks,
>>>> Dave
>>>>
>>>
>>>
>>
>>
>
>
|