Validating acl rules

After SetSiteSecurity has created the NT groups, has added the NT users to these NT groups and has set the Acl's for the NT groups, the tool will validate if all the users has sufficient access to the listed objects. SetSiteSecurity performs validation by impersonating as the user and then performing the needed operation, such as writing a file, reading it and then deleting it.

Note: Under Windows 2003 SetSiteSecurity may not be able to impersonate all users. If a user cannot be impersonated, validation is skipped and should be performed manually.

Validation may fail for a wide variaety of reasons. If validation fails, you will need to inspect the list of failed rules. Some failed validations may be ignored, others should be looked after.

These are the most common reasons why validation fails:

• Validation of a folder with temporary files may fail with an "Access to the path '...' is denied". message. It is possible that a file in the folder with temporary files is currently locked by a running application and that SetSiteSecurity used that file to check access. If you believe that the file is locked by a running application you may ignore this message.
• Validation of a folder may fail with an "Access to the path '...' is denied".  It is possible access for a user has been implicitly or explicitly denied by an Acl rule at a higher level. SetSiteSecurity only adds acl rules that grant user a right but it does not remove or modify existing Acl rules that deny access. If there is such a deny rule, you should many remove or modify it in such a way that validation succeeds.
• Http Namespace validation fails when an application like IIS or the TestSuite is running and is having a lock on a port. You may receive a message like "Failed to listen on prefix 'http://*:80/' because it conflicts with an existing registration on the machine.". Validation will succeed if you close the application before running SetSiteSecurity.