Unless you have a really special circumstance(like a read-only archive), the share permissions are mostly just an administrative headache. It provides a second point to ensure that something didn't get missed on the NTFS side, but it also eliminates flexibility on the NTFS side.
Here is an MS page with some guidelines:
http://technet.microsoft.c
One thing to consider, when profile folders are created automatically, only the User and System have permissions and they both have full control. I've been told that the user needs to have Full Control for everything to work, but I don't have a concrete example of a failure. If it is a requirement, then you would need to grant the user full control at the share level as well.
Main Topics
Browse All Topics





by: benhansonPosted on 2009-10-29 at 00:13:37ID: 25691212
The internal host is 10.0.1.2/? Are you using a class A inside?(10.0.0.0/8, 10.0.0.0 255.0.0.0) At this point the scenario doesn't quite make sense. I would expect the static to be from the 192.168.1.x subnet to the 10.x.x.x subnet:
static (inside,outside) 10.0.1.2 192.168.1.2 netmask 255.255.255.255
The proxyarp feature works as you are thinking, I'm assuming you expected the NAT to fail after you issued 'sysopt noproxyarp outside', and you are right. It shouldn't be working. If proxyarp is enabled, the the ASA responds to arps for any IP address that has a static/global/nat defined for it. It responds with it's own external MAC address so the arp'ing client knows that it should send traffic the ASA's direction. If you do 'sysopt noproxyarp outside', the ASA will only respond to ARP request for it's actual interfaces, and thus communication from the outside to the inside host should fail.
Can you reconfirm it is working, then run 'show running-config sysopt' and post the results?