| Author | Messages | |
dc31hz
Posts:7
 | | 06/25/2009 2:42 AM |
| Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder
was created.
The EVERYONE well-known sec prin was granted full control at the share ACL.
Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts
can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
domain member computer *cannot* read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a
domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member
computers to be able to write files/append data to a share which is managed
via a cluster! I feel as if I must be missing something very simple here
:-(
Thanks,
DaveC
| | | |
| ali
Posts:2
| | 06/25/2009 9:19 AM |
| Hi David,
Someone else might be able to answer this more articulatly than me but here
goes...Local System is excactly that - it provides only local access and
when attempting to authenticate it is not able to provide
suitable credentials.
If you have a service that is running under local system and that
service requires access to the share then starting it under "Network
Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
> Rephrase of the "nutshell" comment.
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster, *by using the virtual ClusterName (or any virtual name we
> give it)*. I feel as if I must be missing something very simple here :-(
>
>
> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>
>> Hi guys,
>>
>> Microsoft Windows Server 2003 SP2. Via the cluster console a shared
>> folder was created.
>>
>> The EVERYONE well-known sec prin was granted full control at the share
>> ACL. Same at the NTFS ACL.
>>
>> Using the "virtual" ClusterName resource, all standard domain user
>> accounts can read/write the share no problem.
>>
>> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
>> domain member computer *cannot* read or write the share.
>>
>> Using the real nodename of the active node, the LOCAL SYSTEM account from
>> a domain member computer can read/write the share no problem.
>>
>> I tried "domain computers" full control on both ACLs....no change.
>>
>> Has anyone seen this before? Client system is XP SP3.
>>
>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>> computers to be able to write files/append data to a share which is managed
>> via a cluster! I feel as if I must be missing something very simple here
>> :-(
>>
>> Thanks,
>> DaveC
>>
>>
>>
>
>
| | | |
| mike.elliottuk
Posts:38
| | 06/25/2009 9:54 AM |
| I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest
considering the following;
1. For data that does not require access controls consider using null
session shares on the hosting servers. That way unauthenticated computers
(or any other account for that matter) will be able to connect and read the
shares.
2. For a more secure approach provide permissions to the share/ACL for
designated computer accounts. If there are many computers that need access
then create a group, issue the permission to the group and add the computers
to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
> Hi David,
>
> Someone else might be able to answer this more articulatly than me but here
> goes...Local System is excactly that - it provides only local access and
> when attempting to authenticate it is not able to provide
> suitable credentials.
>
> If you have a service that is running under local system and that
> service requires access to the share then starting it under "Network
> Service" should do the job.
>
> Regards,
> Alastair.
>
>
>
> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>
>> Rephrase of the "nutshell" comment.
>>
>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>> computers to be able to write files/append data to a share which is managed
>> via a cluster, *by using the virtual ClusterName (or any virtual name we
>> give it)*. I feel as if I must be missing something very simple here
>> :-(
>>
>>
>> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>>
>>> Hi guys,
>>>
>>> Microsoft Windows Server 2003 SP2. Via the cluster console a shared
>>> folder was created.
>>>
>>> The EVERYONE well-known sec prin was granted full control at the share
>>> ACL. Same at the NTFS ACL.
>>>
>>> Using the "virtual" ClusterName resource, all standard domain user
>>> accounts can read/write the share no problem.
>>>
>>> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
>>> domain member computer *cannot* read or write the share.
>>>
>>> Using the real nodename of the active node, the LOCAL SYSTEM account from
>>> a domain member computer can read/write the share no problem.
>>>
>>> I tried "domain computers" full control on both ACLs....no change.
>>>
>>> Has anyone seen this before? Client system is XP SP3.
>>>
>>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>>> computers to be able to write files/append data to a share which is managed
>>> via a cluster! I feel as if I must be missing something very simple here
>>> :-(
>>>
>>> Thanks,
>>> DaveC
>>>
>>>
>>>
>>
>>
>
| | | |
| dc31hz
Posts:7
| | 06/25/2009 11:46 AM |
| Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the
time in that instance (of course SYSVOL is not on a clustered resource).
And remember, this works fine for me, but only when specifying the true
nodename of the active server in the cluster (not desirable). I'm just
wondering what goes wrong when I specify the ClusterName. I might take a
trace later to see if anything obvious jumps out. Also later I will try to
add an explicit ACE for the computer object itself (per Mike), as I have not
tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>wrote:
> I would agree with Alastair.
>
> Depends on what kind of data/access controls you need but I would suggest
> considering the following;
>
> 1. For data that does not require access controls consider using null
> session shares on the hosting servers. That way unauthenticated computers
> (or any other account for that matter) will be able to connect and read the
> shares.
>
> 2. For a more secure approach provide permissions to the share/ACL for
> designated computer accounts. If there are many computers that need access
> then create a group, issue the permission to the group and add the computers
> to the group.
>
> Mike
>
> 2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
>
> Hi David,
>>
>> Someone else might be able to answer this more articulatly than me but
>> here goes...Local System is excactly that - it provides only local access
>> and when attempting to authenticate it is not able to provide
>> suitable credentials.
>>
>> If you have a service that is running under local system and that
>> service requires access to the share then starting it under "Network
>> Service" should do the job.
>>
>> Regards,
>> Alastair.
>>
>>
>>
>> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>>
>>> Rephrase of the "nutshell" comment.
>>>
>>> In a nutshell - I would like for LOCAL SYSTEM account from domain
>>> member computers to be able to write files/append data to a share which is
>>> managed via a cluster, *by using the virtual ClusterName (or any virtual
>>> name we give it)*. I feel as if I must be missing something very simple
>>> here :-(
>>>
>>>
>>> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx>wrote:
>>>
>>>> Hi guys,
>>>>
>>>> Microsoft Windows Server 2003 SP2. Via the cluster console a shared
>>>> folder was created.
>>>>
>>>> The EVERYONE well-known sec prin was granted full control at the share
>>>> ACL. Same at the NTFS ACL.
>>>>
>>>> Using the "virtual" ClusterName resource, all standard domain user
>>>> accounts can read/write the share no problem.
>>>>
>>>> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from
>>>> a domain member computer *cannot* read or write the share.
>>>>
>>>> Using the real nodename of the active node, the LOCAL SYSTEM account
>>>> from a domain member computer can read/write the share no problem.
>>>>
>>>> I tried "domain computers" full control on both ACLs....no change.
>>>>
>>>> Has anyone seen this before? Client system is XP SP3.
>>>>
>>>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>>>> computers to be able to write files/append data to a share which is managed
>>>> via a cluster! I feel as if I must be missing something very simple here
>>>> :-(
>>>>
>>>> Thanks,
>>>> DaveC
>>>>
>>>>
>>>>
>>>
>>>
>>
>
| | | |
| shanewilliford
Posts:39
| | 06/25/2009 1:03 PM |
| I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
| | | |
| dc31hz
Posts:7
| | 06/25/2009 2:13 PM |
| Hi Shane...only in the sense that I'm asking this under the context of a
startup script (which runs via Local System). Sorry I didn't explicitly
state that. Also I did put [OT] in the subject. I appreciate your
indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx
> wrote:
> I’m sorry…I may be missing something, but is this a group policy
> question? Not to be a “stickler” or anything, but this is a Group Policy
> list.
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 5:44 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Thanks Alastair/Mike. I'm going to respectfully disagree :-)
>
>
>
> Take computer startup as an example. Local System reads SYSVOL all the
> time in that instance (of course SYSVOL is not on a clustered resource).
> And remember, this works fine for me, but only when specifying the true
> nodename of the active server in the cluster (not desirable). I'm just
> wondering what goes wrong when I specify the ClusterName. I might take a
> trace later to see if anything obvious jumps out. Also later I will try to
> add an explicit ACE for the computer object itself (per Mike), as I have not
> tried that yet. (not in the office right now)
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
> On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>
> wrote:
>
> I would agree with Alastair.
>
>
>
> Depends on what kind of data/access controls you need but I would suggest
> considering the following;
>
>
>
> 1. For data that does not require access controls consider using null
> session shares on the hosting servers. That way unauthenticated computers
> (or any other account for that matter) will be able to connect and read the
> shares.
>
>
>
> 2. For a more secure approach provide permissions to the share/ACL for
> designated computer accounts. If there are many computers that need access
> then create a group, issue the permission to the group and add the computers
> to the group.
>
>
>
> Mike
>
> 2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
>
>
>
> Hi David,
>
>
>
> Someone else might be able to answer this more articulatly than me but here
> goes...Local System is excactly that - it provides only local access and
> when attempting to authenticate it is not able to provide
> suitable credentials.
>
>
>
> If you have a service that is running under local system and that
> service requires access to the share then starting it under "Network
> Service" should do the job.
>
>
>
> Regards,
>
> Alastair.
>
>
>
>
>
> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>
> Rephrase of the "nutshell" comment.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster, *by using the virtual ClusterName (or any virtual name we
> give it)*. I feel as if I must be missing something very simple here :-(
>
>
>
> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>
> Hi guys,
>
>
>
> Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder
> was created.
>
>
>
> The EVERYONE well-known sec prin was granted full control at the share
> ACL. Same at the NTFS ACL.
>
>
>
> Using the "virtual" ClusterName resource, all standard domain user accounts
> can read/write the share no problem.
>
>
>
> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
> domain member computer *cannot* read or write the share.
>
>
>
> Using the real nodename of the active node, the LOCAL SYSTEM account from a
> domain member computer can read/write the share no problem.
>
>
>
> I tried "domain computers" full control on both ACLs....no change.
>
>
>
> Has anyone seen this before? Client system is XP SP3.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster! I feel as if I must be missing something very simple here
> :-(
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
> Notice: The information transmitted in this e-mail may contain confidential
> and/ or legally privileged information intended only for the use of the
> individual(s) named above. Review, use, disclosure, distribution, or
> forwarding of this information by persons or entities other than the
> intended recipient(s) is prohibited by law and may subject them to criminal
> or civil liabilities. Statements and opinion expressed in this e-mail may
> not represent those of Mazuma Credit Union. All e-mail communications
> through Mazuma's corporate email system are subject to archiving and review
> by someone other than the recipient. If you have received this communication
> in error, please notify the sender immediately and delete/destroy any and
> all copies of the original message from any computer or network system.
>
| | | |
| shanewilliford
Posts:39
| | 06/25/2009 2:18 PM |
| No worries  Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
| | | |
| jlangerak
Posts:4
| | 06/25/2009 2:26 PM |
| [cid:imageb5b195.jpg@4eeff610.084c46fa]
I think he means off topic, as used in many forums...
Although personally I'd say an offtopic question would probably fit better in a mailinglist about the subject... but rather don't think it's so offtopic...
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com
T: +31 (0)20 - 620 81 99
F: +31 (0)20 - 623 06 79
M: +31 (0)6 - 41 178 057
[cid:image82b463.png@be4f5053.5ffd44f2]
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Itium ICT u op de onrechtmatigheid van het gebruiken, kopi?ren of verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of aansprakelijk worden gehouden voor en/of in verband met de gevolgen van en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the addressee or addressees and is strictly confidential or otherwise legally protected. If you are not the intended recipient, you are requested by Itium ICT to delete the message (with attachments) without opening it and you are notified by Itium ICT that any disclosure, copying or distribution of the information contained in the message (with attachments) is strictly prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability of the information contained in these message (including attachments), nor shall the information be construed as constituting any obligation on the part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
| | | |
| shanewilliford
Posts:39
| | 06/25/2009 2:44 PM |
| Ahhh yes...that's right; it's so rare I see it that I forgot. Thanks!
Yeah, I don't think this is so off topic, but I get so many emails from so many different venues, sometimes it can be overwhelming...
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Jake Langerak
Sent: Thursday, June 25, 2009 8:24 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
[cid:image001.jpg@01C9F570.F52C1920]
I think he means off topic, as used in many forums...
Although personally I'd say an offtopic question would probably fit better in a mailinglist about the subject... but rather don't think it's so offtopic...
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com
T:
+31 (0)20 - 620 81 99
F:
+31 (0)20 - 623 06 79
M:
+31 (0)6 - 41 178 057
[cid:image002.png@01C9F570.F52C1920]
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of aansprakelijk worden gehouden voor en/of in verband met de gevolgen van en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the addressee or addressees and is strictly confidential or otherwise legally protected. If you are not the intended recipient, you are requested by Itium ICT to delete the message (with attachments) without opening it and you are notified by Itium ICT that any disclosure, copying or distribution of the information contained in the message (with attachments) is strictly prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability of the information contained in these message (including attachments), nor shall the information be construed as constituting any obligation on the part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx> [mailto:xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx<mailto:xxxxxxxxxxxxxxxx>> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
| | | |
| JamieNelson
Posts:166
| | 06/25/2009 3:20 PM |
| Sounds like a Kerberos issue. Do you have a "virtual" computer object in Active Directory?
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Shane Williford
Sent: Thursday, June 25, 2009 8:43 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Ahhh yes...that's right; it's so rare I see it that I forgot. Thanks! J
Yeah, I don't think this is so off topic, but I get so many emails from so many different venues, sometimes it can be overwhelming... J
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Jake Langerak
Sent: Thursday, June 25, 2009 8:24 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
I think he means off topic, as used in many forums...
Although personally I'd say an offtopic question would probably fit better in a mailinglist about the subject... but rather don't think it's so offtopic...
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com
T:
+31 (0)20 - 620 81 99
F:
+31 (0)20 - 623 06 79
M:
+31 (0)6 - 41 178 057
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of aansprakelijk worden gehouden voor en/of in verband met de gevolgen van en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the addressee or addressees and is strictly confidential or otherwise legally protected. If you are not the intended recipient, you are requested by Itium ICT to delete the message (with attachments) without opening it and you are notified by Itium ICT that any disclosure, copying or distribution of the information contained in the message (with attachments) is strictly prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability of the information contained in these message (including attachments), nor shall the information be construed as constituting any obligation on the part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries J Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged.
If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
| | | |
| JamieNelson
Posts:166
| | 06/25/2009 5:30 PM |
| Darren, you're right. However, if Kerberos authentication wasn't configured on the cluster, there is no computer object in AD. I think that is what his problem is.
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, June 25, 2009 10:17 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sorry to join this late but LocalSystem represents the AD computer account. As such it does have access to network resources as long as the computer account has such access.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Nelson, Jamie
Sent: Thursday, June 25, 2009 7:19 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sounds like a Kerberos issue. Do you have a "virtual" computer object in Active Directory?
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Shane Williford
Sent: Thursday, June 25, 2009 8:43 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Ahhh yes...that's right; it's so rare I see it that I forgot. Thanks! J
Yeah, I don't think this is so off topic, but I get so many emails from so many different venues, sometimes it can be overwhelming... J
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Jake Langerak
Sent: Thursday, June 25, 2009 8:24 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
I think he means off topic, as used in many forums...
Although personally I'd say an offtopic question would probably fit better in a mailinglist about the subject... but rather don't think it's so offtopic...
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com
T:
+31 (0)20 - 620 81 99
F:
+31 (0)20 - 623 06 79
M:
+31 (0)6 - 41 178 057
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of aansprakelijk worden gehouden voor en/of in verband met de gevolgen van en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the addressee or addressees and is strictly confidential or otherwise legally protected. If you are not the intended recipient, you are requested by Itium ICT to delete the message (with attachments) without opening it and you are notified by Itium ICT that any disclosure, copying or distribution of the information contained in the message (with attachments) is strictly prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability of the information contained in these message (including attachments), nor shall the information be construed as constituting any obligation on the part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries J Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
________________________________
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
| | | |
| dmarelia
Posts:394
| | 06/25/2009 5:37 PM |
| Ah, got it. Thanks Jamie.
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Nelson, Jamie
Sent: Thursday, June 25, 2009 9:28 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Darren, youre right. However, if Kerberos authentication wasnt configured
on the cluster, there is no computer object in AD. I think that is what his
problem is.
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy
Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Darren Mar-Elia
Sent: Thursday, June 25, 2009 10:17 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sorry to join this late but LocalSystem represents the AD computer account.
As such it does have access to network resources as long as the computer
account has such access.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Nelson, Jamie
Sent: Thursday, June 25, 2009 7:19 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sounds like a Kerberos issue. Do you have a virtual computer object in
Active Directory?
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy
Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Shane Williford
Sent: Thursday, June 25, 2009 8:43 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Ahhh yes
thats right; its so rare I see it that I forgot. Thanks! J
Yeah, I dont think this is so off topic, but I get so many emails from so
many different venues, sometimes it can be overwhelming
J
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of Jake Langerak
Sent: Thursday, June 25, 2009 8:24 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
I think he means off topic, as used in many forums
Although personally Id say an offtopic question would probably fit better
in a mailinglist about the subject
but rather dont think its so offtopic
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com
T:
+31 (0)20 - 620 81 99
F:
+31 (0)20 - 623 06 79
M:
+31 (0)6 - 41 178 057
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de
geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd.
Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT
u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst
Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of
verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of
enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of
aansprakelijk worden gehouden voor en/of in verband met de gevolgen van
en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig
versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the
addressee or addressees and is strictly confidential or otherwise legally
protected. If you are not the intended recipient, you are requested by Itium
ICT to delete the message (with attachments) without opening it and you are
notified by Itium ICT that any disclosure, copying or distribution of the
information contained in the message (with attachments) is strictly
prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability
of the information contained in these message (including attachments), nor
shall the information be construed as constituting any obligation on the
part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries J Umm
what is OT?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a
startup script (which runs via Local System). Sorry I didn't explicitly
state that. Also I did put [OT] in the subject. I appreciate your
indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford
<xxxxxxxxxxxxxxxx> wrote:
Im sorry
I may be missing something, but is this a group policy question?
Not to be a stickler or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the
time in that instance (of course SYSVOL is not on a clustered resource).
And remember, this works fine for me, but only when specifying the true
nodename of the active server in the cluster (not desirable). I'm just
wondering what goes wrong when I specify the ClusterName. I might take a
trace later to see if anything obvious jumps out. Also later I will try to
add an explicit ACE for the computer object itself (per Mike), as I have not
tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>
wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest
considering the following;
1. For data that does not require access controls consider using null
session shares on the hosting servers. That way unauthenticated computers
(or any other account for that matter) will be able to connect and read the
shares.
2. For a more secure approach provide permissions to the share/ACL for
designated computer accounts. If there are many computers that need access
then create a group, issue the permission to the group and add the computers
to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
Hi David,
Someone else might be able to answer this more articulatly than me but here
goes...Local System is excactly that - it provides only local access and
when attempting to authenticate it is not able to provide suitable
credentials.
If you have a service that is running under local system and that service
requires access to the share then starting it under "Network Service" should
do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member
computers to be able to write files/append data to a share which is managed
via a cluster, by using the virtual ClusterName (or any virtual name we give
it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder
was created.
The EVERYONE well-known sec prin was granted full control at the share ACL.
Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts
can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a
domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member
computers to be able to write files/append data to a share which is managed
via a cluster! I feel as if I must be missing something very simple here
:-(
Thanks,
DaveC
_____
Notice: The information transmitted in this e-mail may contain confidential
and/ or legally privileged information intended only for the use of the
individual(s) named above. Review, use, disclosure, distribution, or
forwarding of this information by persons or entities other than the
intended recipient(s) is prohibited by law and may subject them to criminal
or civil liabilities. Statements and opinion expressed in this e-mail may
not represent those of Mazuma Credit Union. All e-mail communications
through Mazuma's corporate email system are subject to archiving and review
by someone other than the recipient. If you have received this communication
in error, please notify the sender immediately and delete/destroy any and
all copies of the original message from any computer or network system.
_____
Confidentiality Warning: This message and any attachments are intended only
for the use of the intended recipient(s), are confidential, and may be
privileged. If you are not the intended recipient, you are hereby notified
that any review, retransmission, conversion to hard copy, copying,
circulation or other use of all or any portion of this message and any
attachments is strictly prohibited. If you are not the intended recipient,
please notify the sender immediately by return e-mail, and delete this
message and any attachments from your system.
| | | |
| dc31hz
Posts:7
| | 06/25/2009 6:50 PM |
| Right on Jamie...there are no computer objects currently for the virtual
server names. In fact kerb auth is not even enabled on the resource, and a
trace confirms the SPN is not found so we fall back to NTLM.
In fact if I just start by trying to list the folder contents using the IP
address then it fails (fails with BOTH the virtual IP and the physical IP of
the active node). So that indicates this doesn't work well over NTLM at
all. Any thoughts why not? Note this could be a very simple answer and
just my lack of understanding about computer account using that
authentication mechanism!
I will post back later the test results of doing this over Kerberos for
anyone interested.
-DC
On Thu, Jun 25, 2009 at 12:35 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>wrote:
> Ah, got it. Thanks Jamie.
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
> *Sent:* Thursday, June 25, 2009 9:28 AM
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Darren, you’re right. However, if Kerberos authentication wasn’t configured
> on the cluster, there is no computer object in AD. I think that is what his
> problem is.
>
>
>
> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Darren Mar-Elia
> *Sent:* Thursday, June 25, 2009 10:17 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Sorry to join this late but LocalSystem represents the AD computer account.
> As such it does have access to network resources as long as the computer
> account has such access.
>
>
>
> Darren
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
> *Sent:* Thursday, June 25, 2009 7:19 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Sounds like a Kerberos issue. Do you have a “virtual” computer object in
> Active Directory?
>
>
>
> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Shane Williford
> *Sent:* Thursday, June 25, 2009 8:43 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Ahhh yes…that’s right; it’s so rare I see it that I forgot. Thanks! J
>
>
>
> Yeah, I don’t think this is so off topic, but I get so many emails from so
> many different venues, sometimes it can be overwhelming… J
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Jake Langerak
> *Sent:* Thursday, June 25, 2009 8:24 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> I think he means off topic, as used in many forums…
>
>
>
> Although personally I’d say an offtopic question would probably fit better
> in a mailinglist about the subject… but rather don’t think it’s so offtopic…
>
>
>
>
>
> *Jake* *Langerak *
>
> *Itium ICT*
>
>
>
> Keizersgracht 442
>
> 1016 GD AMSTERDAM
>
> The Netherlands
>
>
>
> xxxxxxxxxxxxxxxx
>
> www.itiumict.com
>
>
>
> T:
>
> +31 (0)20 - 620 81 99
>
> F:
>
> +31 (0)20 - 623 06 79
>
> M:
>
> +31 (0)6 - 41 178 057
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
>
>
>
> Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de
> geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd.
> Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT
> u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst
> Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of
> verspreiden van de inhoud van dit bericht.
> Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of
> enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of
> aansprakelijk worden gehouden voor en/of in verband met de gevolgen van
> en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig
> versturen en ontvangen van de inhoud van dit bericht.
>
> This e-mail message, including any attachment(s), is intended solely for
> the addressee or addressees and is strictly confidential or otherwise
> legally protected. If you are not the intended recipient, you are requested
> by Itium ICT to delete the message (with attachments) without opening it and
> you are notified by Itium ICT that any disclosure, copying or distribution
> of the information contained in the message (with attachments) is strictly
> prohibited and unlawful.
> Itium ICT cannot assume any responsibility for the accuracy or reliability
> of the information contained in these message (including attachments), nor
> shall the information be construed as constituting any obligation on the
> part of Itium ICT.
>
>
>
> *Van:* xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
> *Namens *Shane Williford
> *Verzonden:* donderdag 25 juni 2009 15:17
> *Aan:* xxxxxxxxxxxxxxxx
> *Onderwerp:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> No worries J Umm…what is “OT”?
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 8:12 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Hi Shane...only in the sense that I'm asking this under the context of a
> startup script (which runs via Local System). Sorry I didn't explicitly
> state that. Also I did put [OT] in the subject. I appreciate your
> indulgence :-)
>
>
>
> -DC
>
> On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <
> xxxxxxxxxxxxxxxx> wrote:
>
> I’m sorry…I may be missing something, but is this a group policy question?
> Not to be a “stickler” or anything, but this is a Group Policy list.
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 5:44 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Thanks Alastair/Mike. I'm going to respectfully disagree :-)
>
>
>
> Take computer startup as an example. Local System reads SYSVOL all the
> time in that instance (of course SYSVOL is not on a clustered resource).
> And remember, this works fine for me, but only when specifying the true
> nodename of the active server in the cluster (not desirable). I'm just
> wondering what goes wrong when I specify the ClusterName. I might take a
> trace later to see if anything obvious jumps out. Also later I will try to
> add an explicit ACE for the computer object itself (per Mike), as I have not
> tried that yet. (not in the office right now)
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
> On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>
> wrote:
>
> I would agree with Alastair.
>
>
>
> Depends on what kind of data/access controls you need but I would suggest
> considering the following;
>
>
>
> 1. For data that does not require access controls consider using null
> session shares on the hosting servers. That way unauthenticated computers
> (or any other account for that matter) will be able to connect and read the
> shares.
>
>
>
> 2. For a more secure approach provide permissions to the share/ACL for
> designated computer accounts. If there are many computers that need access
> then create a group, issue the permission to the group and add the computers
> to the group.
>
>
>
> Mike
>
> 2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
>
>
>
> Hi David,
>
>
>
> Someone else might be able to answer this more articulatly than me but here
> goes...Local System is excactly that - it provides only local access and
> when attempting to authenticate it is not able to provide
> suitable credentials.
>
>
>
> If you have a service that is running under local system and that
> service requires access to the share then starting it under "Network
> Service" should do the job.
>
>
>
> Regards,
>
> Alastair.
>
>
>
>
>
> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>
> Rephrase of the "nutshell" comment.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster, *by using the virtual ClusterName (or any virtual name we
> give it)*. I feel as if I must be missing something very simple here :-(
>
>
>
> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>
> Hi guys,
>
>
>
> Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder
> was created.
>
>
>
> The EVERYONE well-known sec prin was granted full control at the share
> ACL. Same at the NTFS ACL.
>
>
>
> Using the "virtual" ClusterName resource, all standard domain user accounts
> can read/write the share no problem.
>
>
>
> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
> domain member computer *cannot* read or write the share.
>
>
>
> Using the real nodename of the active node, the LOCAL SYSTEM account from a
> domain member computer can read/write the share no problem.
>
>
>
> I tried "domain computers" full control on both ACLs....no change.
>
>
>
> Has anyone seen this before? Client system is XP SP3.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster! I feel as if I must be missing something very simple here
> :-(
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Notice: The information transmitted in this e-mail may contain confidential
> and/ or legally privileged information intended only for the use of the
> individual(s) named above. Review, use, disclosure, distribution, or
> forwarding of this information by persons or entities other than the
> intended recipient(s) is prohibited by law and may subject them to criminal
> or civil liabilities. Statements and opinion expressed in this e-mail may
> not represent those of Mazuma Credit Union. All e-mail communications
> through Mazuma's corporate email system are subject to archiving and review
> by someone other than the recipient. If you have received this communication
> in error, please notify the sender immediately and delete/destroy any and
> all copies of the original message from any computer or network system.
>
>
>
>
> *
> ------------------------------
> *
>
> *Confidentiality Warning:* This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential, and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, retransmission, conversion to hard copy, copying,
> circulation or other use of all or any portion of this message and any
> attachments is strictly prohibited. If you are not the intended recipient,
> please notify the sender immediately by return e-mail, and delete this
> message and any attachments from your system.
>
| | | |
| JamieNelson
Posts:166
| | 06/25/2009 6:55 PM |
| Yes, please let us know. Even though it is a bit off topic I think it is good knowledge for folks on the list because these questions about authentication with the SYSTEM account come up pretty frequently around Software Distribution.
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 12:49 PM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Right on Jamie...there are no computer objects currently for the virtual server names. In fact kerb auth is not even enabled on the resource, and a trace confirms the SPN is not found so we fall back to NTLM.
In fact if I just start by trying to list the folder contents using the IP address then it fails (fails with BOTH the virtual IP and the physical IP of the active node). So that indicates this doesn't work well over NTLM at all. Any thoughts why not? Note this could be a very simple answer and just my lack of understanding about computer account using that authentication mechanism!
I will post back later the test results of doing this over Kerberos for anyone interested.
-DC
On Thu, Jun 25, 2009 at 12:35 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx> wrote:
Ah, got it. Thanks Jamie.
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Nelson, Jamie
Sent: Thursday, June 25, 2009 9:28 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Darren, you're right. However, if Kerberos authentication wasn't configured on the cluster, there is no computer object in AD. I think that is what his problem is.
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Darren Mar-Elia
Sent: Thursday, June 25, 2009 10:17 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sorry to join this late but LocalSystem represents the AD computer account. As such it does have access to network resources as long as the computer account has such access.
Darren
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Nelson, Jamie
Sent: Thursday, June 25, 2009 7:19 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Sounds like a Kerberos issue. Do you have a "virtual" computer object in Active Directory?
Jamie Nelson | Lead Analyst | BI&T Desktop Management | Devon Energy Corporation | Work: 405.552.8054 | http://www.dvn.com <http://www.dvn.com/>
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Shane Williford
Sent: Thursday, June 25, 2009 8:43 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Ahhh yes...that's right; it's so rare I see it that I forgot. Thanks! J
Yeah, I don't think this is so off topic, but I get so many emails from so many different venues, sometimes it can be overwhelming... J
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of Jake Langerak
Sent: Thursday, June 25, 2009 8:24 AM
To: xxxxxxxxxxxxxxxx
Subject: RE: [gptalk] [OT] File/Folder sharing question
Error! Filename not specified.
I think he means off topic, as used in many forums...
Although personally I'd say an offtopic question would probably fit better in a mailinglist about the subject... but rather don't think it's so offtopic...
Jake Langerak
Itium ICT
Keizersgracht 442
1016 GD AMSTERDAM
The Netherlands
xxxxxxxxxxxxxxxx
www.itiumict.com <http://www.itiumict.com/>
T:
+31 (0)20 - 620 81 99
F:
+31 (0)20 - 623 06 79
M:
+31 (0)6 - 41 178 057
Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd. Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of verspreiden van de inhoud van dit bericht.
Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of aansprakelijk worden gehouden voor en/of in verband met de gevolgen van en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig versturen en ontvangen van de inhoud van dit bericht.
This e-mail message, including any attachment(s), is intended solely for the addressee or addressees and is strictly confidential or otherwise legally protected. If you are not the intended recipient, you are requested by Itium ICT to delete the message (with attachments) without opening it and you are notified by Itium ICT that any disclosure, copying or distribution of the information contained in the message (with attachments) is strictly prohibited and unlawful.
Itium ICT cannot assume any responsibility for the accuracy or reliability of the information contained in these message (including attachments), nor shall the information be construed as constituting any obligation on the part of Itium ICT.
Van: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] Namens Shane Williford
Verzonden: donderdag 25 juni 2009 15:17
Aan: xxxxxxxxxxxxxxxx
Onderwerp: RE: [gptalk] [OT] File/Folder sharing question
No worries J Umm...what is "OT"?
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 8:12 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Hi Shane...only in the sense that I'm asking this under the context of a startup script (which runs via Local System). Sorry I didn't explicitly state that. Also I did put [OT] in the subject. I appreciate your indulgence :-)
-DC
On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <xxxxxxxxxxxxxxxx> wrote:
I'm sorry...I may be missing something, but is this a group policy question? Not to be a "stickler" or anything, but this is a Group Policy list.
Shane M. Williford
Systems Administrator
MCSE, MCSA Sec, Sec+, Net+, A+
Mazuma Credit Union
9300 Troost
Kansas City, MO 64131
xxxxxxxxxxxxxxxx
816-361-4194 x6012
From: xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx] On Behalf Of David Cliffe
Sent: Thursday, June 25, 2009 5:44 AM
To: xxxxxxxxxxxxxxxx
Subject: Re: [gptalk] [OT] File/Folder sharing question
Thanks Alastair/Mike. I'm going to respectfully disagree :-)
Take computer startup as an example. Local System reads SYSVOL all the time in that instance (of course SYSVOL is not on a clustered resource). And remember, this works fine for me, but only when specifying the true nodename of the active server in the cluster (not desirable). I'm just wondering what goes wrong when I specify the ClusterName. I might take a trace later to see if anything obvious jumps out. Also later I will try to add an explicit ACE for the computer object itself (per Mike), as I have not tried that yet. (not in the office right now)
Thanks,
DaveC
On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx> wrote:
I would agree with Alastair.
Depends on what kind of data/access controls you need but I would suggest considering the following;
1. For data that does not require access controls consider using null session shares on the hosting servers. That way unauthenticated computers (or any other account for that matter) will be able to connect and read the shares.
2. For a more secure approach provide permissions to the share/ACL for designated computer accounts. If there are many computers that need access then create a group, issue the permission to the group and add the computers to the group.
Mike
2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
Hi David,
Someone else might be able to answer this more articulatly than me but here goes...Local System is excactly that - it provides only local access and when attempting to authenticate it is not able to provide suitable credentials.
If you have a service that is running under local system and that service requires access to the share then starting it under "Network Service" should do the job.
Regards,
Alastair.
2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
Rephrase of the "nutshell" comment.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster, by using the virtual ClusterName (or any virtual name we give it). I feel as if I must be missing something very simple here :-(
On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
Hi guys,
Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder was created.
The EVERYONE well-known sec prin was granted full control at the share ACL. Same at the NTFS ACL.
Using the "virtual" ClusterName resource, all standard domain user accounts can read/write the share no problem.
Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a domain member computer cannot read or write the share.
Using the real nodename of the active node, the LOCAL SYSTEM account from a domain member computer can read/write the share no problem.
I tried "domain computers" full control on both ACLs....no change.
Has anyone seen this before? Client system is XP SP3.
In a nutshell - I would like for LOCAL SYSTEM account from domain member computers to be able to write files/append data to a share which is managed via a cluster! I feel as if I must be missing something very simple here :-(
Thanks,
DaveC
________________________________
Notice: The information transmitted in this e-mail may contain confidential and/ or legally privileged information intended only for the use of the individual(s) named above. Review, use, disclosure, distribution, or forwarding of this information by persons or entities other than the intended recipient(s) is prohibited by law and may subject them to criminal or civil liabilities. Statements and opinion expressed in this e-mail may not represent those of Mazuma Credit Union. All e-mail communications through Mazuma's corporate email system are subject to archiving and review by someone other than the recipient. If you have received this communication in error, please notify the sender immediately and delete/destroy any and all copies of the original message from any computer or network system.
________________________________
Confidentiality Warning: This message and any attachments are intended only for the use of the intended recipient(s), are confidential, and may be privileged. If you are not the intended recipient, you are hereby notified that any review, retransmission, conversion to hard copy, copying, circulation or other use of all or any portion of this message and any attachments is strictly prohibited. If you are not the intended recipient, please notify the sender immediately by return e-mail, and delete this message and any attachments from your system.
| | | |
| ali
Posts:2
| | 06/25/2009 11:42 PM |
| What was I thinking of there this morning? I’ll not make excuses but perhaps
some flashback to the old days? It’s exactly this functionality that is
exploited by conficker and the like.
Although at the risk of further shame…I’ll stand by the comment that local
system is exactly that, but when in a domain it contains the SID of the
computer account and isn’t it true therefore we don’t present credentials in
this case but use a null session? That is how I am interpreting the section
on this in the new edition of “Windows Internals” that landed on my doorstep
this week.
So what we know in this case is that Kerberos authentication is successfully
happening for the physical nodes but not for the cluster resource. We now
know why Kerberos is failing for the cluster resource.
So why is NTLM failing for the physical servers?
I’ve just done similar in a test environment consisting of an XP client and
a share on a 2003 R2 DC and the behaviour is the same :
In a cmd window running under local system :
dir \\servername\sharename <file://servername/sharename> = works (via
kerberos authentication)
dir \\ipaddress\sharename <file://ipaddress/sharename> = access denied
(using an IP address forces NTLM and we’re using a null session)
Configuring “Restrict anonymous access to Named Pipes and Shares” to be
disabled (to allow NullSessionShares) results in “dir
\\ipaddress\sharename<file://ipaddress/sharename>”
working. But you’d almost certainly not want to do that. The earlier
suggestion from Mike regarding explicitly granting access to the computer
account (by group if required) would also solve this I believe.
It’s a learning experience!
Regards,
Alastair.
2009/6/25 Nelson, Jamie <xxxxxxxxxxxxxxxx>
> Yes, please let us know. Even though it is a bit off topic I think it is
> good knowledge for folks on the list because these questions about
> authentication with the SYSTEM account come up pretty frequently around
> Software Distribution.
>
>
>
> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 12:49 PM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Right on Jamie...there are no computer objects currently for the virtual
> server names. In fact kerb auth is not even enabled on the resource, and a
> trace confirms the SPN is not found so we fall back to NTLM.
>
>
>
> In fact if I just start by trying to list the folder contents using the IP
> address then it fails (fails with BOTH the virtual IP and the physical IP of
> the active node). So that indicates this doesn't work well over NTLM at
> all. Any thoughts why not? Note this could be a very simple answer and
> just my lack of understanding about computer account using that
> authentication mechanism!
>
>
>
> I will post back later the test results of doing this over Kerberos for
> anyone interested.
>
>
>
> -DC
>
>
>
>
> On Thu, Jun 25, 2009 at 12:35 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
> wrote:
>
> Ah, got it. Thanks Jamie.
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
> *Sent:* Thursday, June 25, 2009 9:28 AM
>
>
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Darren, you’re right. However, if Kerberos authentication wasn’t configured
> on the cluster, there is no computer object in AD. I think that is what his
> problem is.
>
>
>
> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Darren Mar-Elia
> *Sent:* Thursday, June 25, 2009 10:17 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Sorry to join this late but LocalSystem represents the AD computer account.
> As such it does have access to network resources as long as the computer
> account has such access.
>
>
>
> Darren
>
>
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
> *Sent:* Thursday, June 25, 2009 7:19 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Sounds like a Kerberos issue. Do you have a “virtual” computer object in
> Active Directory?
>
>
>
> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Shane Williford
> *Sent:* Thursday, June 25, 2009 8:43 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> Ahhh yes…that’s right; it’s so rare I see it that I forgot. Thanks! J
>
>
>
> Yeah, I don’t think this is so off topic, but I get so many emails from so
> many different venues, sometimes it can be overwhelming… J
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *Jake Langerak
> *Sent:* Thursday, June 25, 2009 8:24 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> *Error! Filename not specified.*
>
> I think he means off topic, as used in many forums…
>
>
>
> Although personally I’d say an offtopic question would probably fit better
> in a mailinglist about the subject… but rather don’t think it’s so offtopic…
>
>
>
>
>
> *Jake* *Langerak *
>
> *Itium ICT*
>
>
>
> Keizersgracht 442
>
> 1016 GD AMSTERDAM
>
> The Netherlands
>
>
>
> xxxxxxxxxxxxxxxx
>
> www.itiumict.com
>
>
>
> T:
>
> +31 (0)20 - 620 81 99
>
> F:
>
> +31 (0)20 - 623 06 79
>
> M:
>
> +31 (0)6 - 41 178 057
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
>
>
>
> Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de
> geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd.
> Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT
> u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst
> Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of
> verspreiden van de inhoud van dit bericht.
> Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of
> enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of
> aansprakelijk worden gehouden voor en/of in verband met de gevolgen van
> en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig
> versturen en ontvangen van de inhoud van dit bericht.
>
> This e-mail message, including any attachment(s), is intended solely for
> the addressee or addressees and is strictly confidential or otherwise
> legally protected. If you are not the intended recipient, you are requested
> by Itium ICT to delete the message (with attachments) without opening it and
> you are notified by Itium ICT that any disclosure, copying or distribution
> of the information contained in the message (with attachments) is strictly
> prohibited and unlawful.
> Itium ICT cannot assume any responsibility for the accuracy or reliability
> of the information contained in these message (including attachments), nor
> shall the information be construed as constituting any obligation on the
> part of Itium ICT.
>
>
>
> *Van:* xxxxxxxxxxxxxxxx [mailto:xxxxxxxxxxxxxxxx]
> *Namens *Shane Williford
> *Verzonden:* donderdag 25 juni 2009 15:17
> *Aan:* xxxxxxxxxxxxxxxx
> *Onderwerp:* RE: [gptalk] [OT] File/Folder sharing question
>
>
>
> No worries J Umm…what is “OT”?
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 8:12 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Hi Shane...only in the sense that I'm asking this under the context of a
> startup script (which runs via Local System). Sorry I didn't explicitly
> state that. Also I did put [OT] in the subject. I appreciate your
> indulgence :-)
>
>
>
> -DC
>
> On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <
> xxxxxxxxxxxxxxxx> wrote:
>
> I’m sorry…I may be missing something, but is this a group policy question?
> Not to be a “stickler” or anything, but this is a Group Policy list.
>
>
>
> Shane M. Williford
>
> Systems Administrator
>
> MCSE, MCSA Sec, Sec+, Net+, A+
>
> Mazuma Credit Union
>
> 9300 Troost
>
> Kansas City, MO 64131
>
> xxxxxxxxxxxxxxxx
>
> 816-361-4194 x6012
>
>
>
> *From:* xxxxxxxxxxxxxxxx [mailto:
> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
> *Sent:* Thursday, June 25, 2009 5:44 AM
> *To:* xxxxxxxxxxxxxxxx
> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>
>
>
> Thanks Alastair/Mike. I'm going to respectfully disagree :-)
>
>
>
> Take computer startup as an example. Local System reads SYSVOL all the
> time in that instance (of course SYSVOL is not on a clustered resource).
> And remember, this works fine for me, but only when specifying the true
> nodename of the active server in the cluster (not desirable). I'm just
> wondering what goes wrong when I specify the ClusterName. I might take a
> trace later to see if anything obvious jumps out. Also later I will try to
> add an explicit ACE for the computer object itself (per Mike), as I have not
> tried that yet. (not in the office right now)
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
> On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>
> wrote:
>
> I would agree with Alastair.
>
>
>
> Depends on what kind of data/access controls you need but I would suggest
> considering the following;
>
>
>
> 1. For data that does not require access controls consider using null
> session shares on the hosting servers. That way unauthenticated computers
> (or any other account for that matter) will be able to connect and read the
> shares.
>
>
>
> 2. For a more secure approach provide permissions to the share/ACL for
> designated computer accounts. If there are many computers that need access
> then create a group, issue the permission to the group and add the computers
> to the group.
>
>
>
> Mike
>
> 2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
>
>
>
> Hi David,
>
>
>
> Someone else might be able to answer this more articulatly than me but here
> goes...Local System is excactly that - it provides only local access and
> when attempting to authenticate it is not able to provide
> suitable credentials.
>
>
>
> If you have a service that is running under local system and that
> service requires access to the share then starting it under "Network
> Service" should do the job.
>
>
>
> Regards,
>
> Alastair.
>
>
>
>
>
> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>
> Rephrase of the "nutshell" comment.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster, *by using the virtual ClusterName (or any virtual name we
> give it)*. I feel as if I must be missing something very simple here :-(
>
>
>
> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>
> Hi guys,
>
>
>
> Microsoft Windows Server 2003 SP2. Via the cluster console a shared folder
> was created.
>
>
>
> The EVERYONE well-known sec prin was granted full control at the share
> ACL. Same at the NTFS ACL.
>
>
>
> Using the "virtual" ClusterName resource, all standard domain user accounts
> can read/write the share no problem.
>
>
>
> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
> domain member computer *cannot* read or write the share.
>
>
>
> Using the real nodename of the active node, the LOCAL SYSTEM account from a
> domain member computer can read/write the share no problem.
>
>
>
> I tried "domain computers" full control on both ACLs....no change.
>
>
>
> Has anyone seen this before? Client system is XP SP3.
>
>
>
> In a nutshell - I would like for LOCAL SYSTEM account from domain member
> computers to be able to write files/append data to a share which is managed
> via a cluster! I feel as if I must be missing something very simple here
> :-(
>
>
>
> Thanks,
>
> DaveC
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> ------------------------------
>
> Notice: The information transmitted in this e-mail may contain confidential
> and/ or legally privileged information intended only for the use of the
> individual(s) named above. Review, use, disclosure, distribution, or
> forwarding of this information by persons or entities other than the
> intended recipient(s) is prohibited by law and may subject them to criminal
> or civil liabilities. Statements and opinion expressed in this e-mail may
> not represent those of Mazuma Credit Union. All e-mail communications
> through Mazuma's corporate email system are subject to archiving and review
> by someone other than the recipient. If you have received this communication
> in error, please notify the sender immediately and delete/destroy any and
> all copies of the original message from any computer or network system.
>
>
>
>
> *
> ------------------------------
> *
>
> *Confidentiality Warning:* This message and any attachments are intended
> only for the use of the intended recipient(s), are confidential, and may be
> privileged. If you are not the intended recipient, you are hereby notified
> that any review, retransmission, conversion to hard copy, copying,
> circulation or other use of all or any portion of this message and any
> attachments is strictly prohibited. If you are not the intended recipient,
> please notify the sender immediately by return e-mail, and delete this
> message and any attachments from your system.
>
>
>
| | | |
| dc31hz
Posts:7
| | 06/26/2009 11:24 AM |
| HI all,
Thanks Alastair! Indeed I can also confirm that enabling Kerberos
authentication on any clustername resource definitely allows for Local
System to read (or write) the shared folder(s) on the cluster. Trace
confirms SPN is found and therefore a ticket is granted, etc...
As for NTLM....grr...very frustrated now as to why this doesn't work (yet).
I don't even know why I care so much EXCEPT for the fact that like Jamie
said earlier many people who establish a cluster with virtual servers and
shared folder resources might not realize that Local System credentials fail
under the default NTLM, regardless of the ACLs they configure. This could
explain for prior postings on the subject. Obviously enabling Kerberos
is the simple fix.
But again I have to think back to non-clustered folder shares which Local
System *is* able to access just fine as long as "authenticated users" or
"domain computers" (or the computer object itself) have permission. I admit
I have not tried mucking with the RestrictAnonymous settings yet, but I did
explicitly grant the computer object itself access to the clustered shared
folder and got nothing for it :-(
Alastair, when you changed the RestrictAnonymous setting and then tested -
did you :
a) Use the IP address for the Virtual Server? (or physical node)
b) Also try using the ClusterName (or VirtualServer name) ?
I'd be very curious to know if this is some sort of problem with the cluster
service itself or else something I don't fully understand about NTLM.
I posted this question in Microsoft.Public.Security but if anyone has a
suggestion of a better spot please let me know.
Thanks again!
-DaveC
On Thu, Jun 25, 2009 at 6:38 PM, alastair cain <xxxxxxxxxxxxxxxx> wrote:
> What was I thinking of there this morning? I’ll not make excuses but
> perhaps some flashback to the old days? It’s exactly this functionality that
> is exploited by conficker and the like.
>
> Although at the risk of further shame…I’ll stand by the comment that local
> system is exactly that, but when in a domain it contains the SID of the
> computer account and isn’t it true therefore we don’t present credentials in
> this case but use a null session? That is how I am interpreting the section
> on this in the new edition of “Windows Internals” that landed on my doorstep
> this week.
>
> So what we know in this case is that Kerberos authentication is
> successfully happening for the physical nodes but not for the cluster
> resource. We now know why Kerberos is failing for the cluster resource.
>
> So why is NTLM failing for the physical servers?
>
> I’ve just done similar in a test environment consisting of an XP client and
> a share on a 2003 R2 DC and the behaviour is the same :
> In a cmd window running under local system :
> dir \\servername\sharename = works (via kerberos authentication)
> dir \\ipaddress\sharename = access denied (using an IP address forces NTLM
> and we’re using a null session)
>
> Configuring “Restrict anonymous access to Named Pipes and Shares” to be
> disabled (to allow NullSessionShares) results in “dir
> \\ipaddress\sharename” working. But you’d almost certainly not want to do
> that. The earlier suggestion from Mike regarding explicitly granting access
> to the computer account (by group if required) would also solve this I
> believe.
>
> It’s a learning experience!
> Regards,
> Alastair.
>
>
> 2009/6/25 Nelson, Jamie <xxxxxxxxxxxxxxxx>
>
> Yes, please let us know. Even though it is a bit off topic I think it is
>> good knowledge for folks on the list because these questions about
>> authentication with the SYSTEM account come up pretty frequently around
>> Software Distribution.
>>
>>
>>
>> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
>> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
>> *Sent:* Thursday, June 25, 2009 12:49 PM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Right on Jamie...there are no computer objects currently for the virtual
>> server names. In fact kerb auth is not even enabled on the resource, and a
>> trace confirms the SPN is not found so we fall back to NTLM.
>>
>>
>>
>> In fact if I just start by trying to list the folder contents using the IP
>> address then it fails (fails with BOTH the virtual IP and the physical IP of
>> the active node). So that indicates this doesn't work well over NTLM at
>> all. Any thoughts why not? Note this could be a very simple answer and
>> just my lack of understanding about computer account using that
>> authentication mechanism!
>>
>>
>>
>> I will post back later the test results of doing this over Kerberos for
>> anyone interested.
>>
>>
>>
>> -DC
>>
>>
>>
>>
>> On Thu, Jun 25, 2009 at 12:35 PM, Darren Mar-Elia <xxxxxxxxxxxxxxxx>
>> wrote:
>>
>> Ah, got it. Thanks Jamie.
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
>> *Sent:* Thursday, June 25, 2009 9:28 AM
>>
>>
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Darren, you’re right. However, if Kerberos authentication wasn’t
>> configured on the cluster, there is no computer object in AD. I think that
>> is what his problem is.
>>
>>
>>
>> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
>> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *Darren Mar-Elia
>> *Sent:* Thursday, June 25, 2009 10:17 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Sorry to join this late but LocalSystem represents the AD computer
>> account. As such it does have access to network resources as long as the
>> computer account has such access.
>>
>>
>>
>> Darren
>>
>>
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *Nelson, Jamie
>> *Sent:* Thursday, June 25, 2009 7:19 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Sounds like a Kerberos issue. Do you have a “virtual” computer object in
>> Active Directory?
>>
>>
>>
>> *Jamie Nelson* | Lead Analyst | BI&T Desktop Management | *Devon Energy
>> Corporation* | Work: 405.552.8054 | http://www.dvn.com
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *Shane Williford
>> *Sent:* Thursday, June 25, 2009 8:43 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Ahhh yes…that’s right; it’s so rare I see it that I forgot. Thanks! J
>>
>>
>>
>> Yeah, I don’t think this is so off topic, but I get so many emails from so
>> many different venues, sometimes it can be overwhelming… J
>>
>>
>>
>> Shane M. Williford
>>
>> Systems Administrator
>>
>> MCSE, MCSA Sec, Sec+, Net+, A+
>>
>> Mazuma Credit Union
>>
>> 9300 Troost
>>
>> Kansas City, MO 64131
>>
>> xxxxxxxxxxxxxxxx
>>
>> 816-361-4194 x6012
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *Jake Langerak
>> *Sent:* Thursday, June 25, 2009 8:24 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> *Error! Filename not specified.*
>>
>> I think he means off topic, as used in many forums…
>>
>>
>>
>> Although personally I’d say an offtopic question would probably fit better
>> in a mailinglist about the subject… but rather don’t think it’s so offtopic…
>>
>>
>>
>>
>>
>> *Jake* *Langerak *
>>
>> *Itium ICT*
>>
>>
>>
>> Keizersgracht 442
>>
>> 1016 GD AMSTERDAM
>>
>> The Netherlands
>>
>>
>>
>> xxxxxxxxxxxxxxxx
>>
>> www.itiumict.com
>>
>>
>>
>> T:
>>
>> +31 (0)20 - 620 81 99
>>
>> F:
>>
>> +31 (0)20 - 623 06 79
>>
>> M:
>>
>> +31 (0)6 - 41 178 057
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Voor supportverzoeken stuurt u een e-mail aan xxxxxxxxxxxxxxxx.
>>
>>
>>
>> Dit e-mailbericht en enige bijlage is uitsluitend bestemd voor de
>> geadresseerde(n) en strikt vertrouwelijk of anderszins wettelijk beschermd.
>> Indien u niet de beoogde ontvanger van dit bericht bent, verzoekt Itium ICT
>> u dit bericht te verwijderen, eventuele bijlagen niet te openen en wijst
>> Itium ICT u op de onrechtmatigheid van het gebruiken, kopiëren of
>> verspreiden van de inhoud van dit bericht.
>> Itium ICT is niet aansprakelijk voor virussen in dit e-mailbericht en/of
>> enige bijlage. Itium ICT kan op geen enkele wijze verantwoordelijk of
>> aansprakelijk worden gehouden voor en/of in verband met de gevolgen van
>> en/of schade ontstaan door het onjuist, onvolledig en/of niet-tijdig
>> versturen en ontvangen van de inhoud van dit bericht.
>>
>> This e-mail message, including any attachment(s), is intended solely for
>> the addressee or addressees and is strictly confidential or otherwise
>> legally protected. If you are not the intended recipient, you are requested
>> by Itium ICT to delete the message (with attachments) without opening it and
>> you are notified by Itium ICT that any disclosure, copying or distribution
>> of the information contained in the message (with attachments) is strictly
>> prohibited and unlawful.
>> Itium ICT cannot assume any responsibility for the accuracy or reliability
>> of the information contained in these message (including attachments), nor
>> shall the information be construed as constituting any obligation on the
>> part of Itium ICT.
>>
>>
>>
>> *Van:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *Namens *Shane Williford
>> *Verzonden:* donderdag 25 juni 2009 15:17
>> *Aan:* xxxxxxxxxxxxxxxx
>> *Onderwerp:* RE: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> No worries J Umm…what is “OT”?
>>
>>
>>
>> Shane M. Williford
>>
>> Systems Administrator
>>
>> MCSE, MCSA Sec, Sec+, Net+, A+
>>
>> Mazuma Credit Union
>>
>> 9300 Troost
>>
>> Kansas City, MO 64131
>>
>> xxxxxxxxxxxxxxxx
>>
>> 816-361-4194 x6012
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
>> *Sent:* Thursday, June 25, 2009 8:12 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Hi Shane...only in the sense that I'm asking this under the context of a
>> startup script (which runs via Local System). Sorry I didn't explicitly
>> state that. Also I did put [OT] in the subject. I appreciate your
>> indulgence :-)
>>
>>
>>
>> -DC
>>
>> On Thu, Jun 25, 2009 at 8:01 AM, Shane Williford <
>> xxxxxxxxxxxxxxxx> wrote:
>>
>> I’m sorry…I may be missing something, but is this a group policy question?
>> Not to be a “stickler” or anything, but this is a Group Policy list.
>>
>>
>>
>> Shane M. Williford
>>
>> Systems Administrator
>>
>> MCSE, MCSA Sec, Sec+, Net+, A+
>>
>> Mazuma Credit Union
>>
>> 9300 Troost
>>
>> Kansas City, MO 64131
>>
>> xxxxxxxxxxxxxxxx
>>
>> 816-361-4194 x6012
>>
>>
>>
>> *From:* xxxxxxxxxxxxxxxx [mailto:
>> xxxxxxxxxxxxxxxx] *On Behalf Of *David Cliffe
>> *Sent:* Thursday, June 25, 2009 5:44 AM
>> *To:* xxxxxxxxxxxxxxxx
>> *Subject:* Re: [gptalk] [OT] File/Folder sharing question
>>
>>
>>
>> Thanks Alastair/Mike. I'm going to respectfully disagree :-)
>>
>>
>>
>> Take computer startup as an example. Local System reads SYSVOL all the
>> time in that instance (of course SYSVOL is not on a clustered resource).
>> And remember, this works fine for me, but only when specifying the true
>> nodename of the active server in the cluster (not desirable). I'm just
>> wondering what goes wrong when I specify the ClusterName. I might take a
>> trace later to see if anything obvious jumps out. Also later I will try to
>> add an explicit ACE for the computer object itself (per Mike), as I have not
>> tried that yet. (not in the office right now)
>>
>>
>>
>> Thanks,
>>
>> DaveC
>>
>>
>>
>>
>> On Thu, Jun 25, 2009 at 4:53 AM, Mike Elliott <xxxxxxxxxxxxxxxx>
>> wrote:
>>
>> I would agree with Alastair.
>>
>>
>>
>> Depends on what kind of data/access controls you need but I would suggest
>> considering the following;
>>
>>
>>
>> 1. For data that does not require access controls consider using null
>> session shares on the hosting servers. That way unauthenticated computers
>> (or any other account for that matter) will be able to connect and read the
>> shares.
>>
>>
>>
>> 2. For a more secure approach provide permissions to the share/ACL for
>> designated computer accounts. If there are many computers that need access
>> then create a group, issue the permission to the group and add the computers
>> to the group.
>>
>>
>>
>> Mike
>>
>> 2009/6/25 alastair cain <xxxxxxxxxxxxxxxx>
>>
>>
>>
>> Hi David,
>>
>>
>>
>> Someone else might be able to answer this more articulatly than me but
>> here goes...Local System is excactly that - it provides only local access
>> and when attempting to authenticate it is not able to provide
>> suitable credentials.
>>
>>
>>
>> If you have a service that is running under local system and that
>> service requires access to the share then starting it under "Network
>> Service" should do the job.
>>
>>
>>
>> Regards,
>>
>> Alastair.
>>
>>
>>
>>
>>
>> 2009/6/25 David Cliffe <xxxxxxxxxxxxxxxx>
>>
>> Rephrase of the "nutshell" comment.
>>
>>
>>
>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>> computers to be able to write files/append data to a share which is managed
>> via a cluster, *by using the virtual ClusterName (or any virtual name we
>> give it)*. I feel as if I must be missing something very simple here
>> :-(
>>
>>
>>
>> On Wed, Jun 24, 2009 at 9:42 PM, David Cliffe <xxxxxxxxxxxxxxxx> wrote:
>>
>> Hi guys,
>>
>>
>>
>> Microsoft Windows Server 2003 SP2. Via the cluster console a shared
>> folder was created.
>>
>>
>>
>> The EVERYONE well-known sec prin was granted full control at the share
>> ACL. Same at the NTFS ACL.
>>
>>
>>
>> Using the "virtual" ClusterName resource, all standard domain user
>> accounts can read/write the share no problem.
>>
>>
>>
>> Using the "virtual" ClusterName resource, the LOCAL SYSTEM account from a
>> domain member computer *cannot* read or write the share.
>>
>>
>>
>> Using the real nodename of the active node, the LOCAL SYSTEM account from
>> a domain member computer can read/write the share no problem.
>>
>>
>>
>> I tried "domain computers" full control on both ACLs....no change.
>>
>>
>>
>> Has anyone seen this before? Client system is XP SP3.
>>
>>
>>
>> In a nutshell - I would like for LOCAL SYSTEM account from domain member
>> computers to be able to write files/append data to a share which is managed
>> via a cluster! I feel as if I must be missing something very simple here
>> :-(
>>
>>
>>
>> Thanks,
>>
>> DaveC
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> ------------------------------
>>
>> Notice: The information transmitted in this e-mail may contain
>> confidential and/ or legally privileged information intended only for the
>> use of the individual(s) named above. Review, use, disclosure, distribution,
>> or forwarding of this information by persons or entities other than the
>> intended recipient(s) is prohibited by law and may subject them to criminal
>> or civil liabilities. Statements and opinion expressed in this e-mail may
>> not represent those of Mazuma Credit Union. All e-mail communications
>> through Mazuma's corporate email system are subject to archiving and review
>> by someone other than the recipient. If you have received this communication
>> in error, please notify the sender immediately and delete/destroy any and
>> all copies of the original message from any computer or network system.
>>
>>
>>
>>
>> *
>> ------------------------------
>> *
>>
>> *Confidentiality Warning:* This message and any attachments are intended
>> only for the use of the intended recipient(s), are confidential, and may be
>> privileged. If you are not the intended recipient, you are hereby notified
>> that any review, retransmission, conversion to hard copy, copying,
>> circulation or other use of all or any portion of this message and any
>> attachments is strictly prohibited. If you are not the intended recipient,
>> please notify the sender immediately by return e-mail, and delete this
>> message and any attachments from your system.
>>
>>
>>
>
>
| | | |
|
|