Export (0) Print
Expand All
Collapse the table of content
Expand the table of content
Expand Minimize

Security During Synchronization

Security while synchronizing content and settings across your cluster is maintained by a combination of three factors: security features in Windows 2000, security features in IIS, and network security on your cluster management network.

Windows 2000 Security and Synchronization

Synchronization is affected by the permissions that are set for file and directory access permissions (ACLs), DCOM interface calls, and RPC operations. Application Center monitors and manages these and no security issues are normally generated by these operations.

Possible issues that you might encounter with Application Center synchronization include the following:

  • ACLs and security identifiers (SIDs). Application Center attempts to synchronize ACLs across local server, workgroup, domain, tree, and forest boundaries. ACLs that are synchronized on servers within the same domain, tree, or forest work correctly—after synchronization, their SIDs are still relevant because they are still in the same forest. ACLs that are synchronized across forest boundaries are not correct—SIDs are only relevant to the original, source forest. ACLs created on workgroup servers refer to the local servers and, except for well known SIDs (for example, administrator), are not valid on any other server. You must fix incorrect ACLs on the targets manually. Another approach is to not replicate ACLs. In this case, the ACLs are inherited from the directories on the target. Then, you can set the ACLs with whatever local user accounts are valid at the directory level and the files inherit ACLs from the parent directory.

    Bb687397.note(en-us,TechNet.10).gif Note   If an account is not valid, it is still applied; however, because the account is not valid, it is not enforced.

  • Changes to file ACLs are not synchronized automatically. If you change the ACLs on a file, the changes are not automatically synchronized by Application Center, unless the file has changed in some way (for example, the content of the file was altered or one of the file attributes has changed).

  • Application Center does not synchronize or deploy Windows 2000 user accounts. To have these accounts on your members, you must use another method. It is recommended that you create a Windows 2000 domain to share and use Microsoft Windows NT® accounts across multiple members.

  • Synchronizing to and from FAT and NTFS file systems. FAT file systems do not support ACLs. If you synchronize or deploy from a member with a FAT file system to a server with an NTFS file system, the files that are delivered to the NTFS file system inherit the ACLs from their new parent directories.

    Bb687397.caution(en-us,TechNet.10).gif Caution   Installation on FAT16 partitions is not supported (except for Administrative client installations).

    When synchronizing from NTFS to FAT, synchronization fails and the files are rolled back because the ACLs cannot be applied to the FAT file system.

    Bb687397.note(en-us,TechNet.10).gif Note   By default, ACL synchronization occurs. Use the deployment wizard to change this.

IIS Security and Synchronization

During deployment of COM+ applications and global ISAPI filters, IIS is restarted. Application Center monitors this operation. No security issues are generated by this operation.

Network Security and Synchronization

Application Center synchronization occurs on the management-traffic adapter and uses three transfer protocols:

  • DCOM, which is used for intra-cluster synchronization control information.

  • HTTP, which is used to synchronize files, including COM+ components, both intra-cluster and inter-cluster.

  • RPC, which is used for inter-cluster synchronization control information; for example, from a staging cluster to a production cluster.

Bb687397.caution(en-us,TechNet.10).gif Caution   While DCOM and RPC communication are made secure by using the same encryption mechanism (RPC packet privacy) that Windows 2000 Server employs, HTTP file transfer is not encrypted. Therefore, do not store passwords in files (for example, in ODBC connection strings in Active Server Pages [ASP]). If sensitive information is being transported and security is a concern, encrypt these files before sending them, and then decrypt these files after synchronization. Additionally, you can use IPSec Policy to provide effective encryption of HTTP traffic.

Bb687397.note(en-us,TechNet.10).gif Note    IIS passwords stored in the metabase are encrypted during synchronization.

Related Topics

  • For more information on IPSec policies, see the Windows 2000 Server Help.

Did you find this information useful? Please send your suggestions and comments about the documentation to

© 2016 Microsoft