This section describes iFolder user account considerations.
Because iFolder is a cross platform, distributed solution there is a possibility of virus infection on Windows machines when migrating data across the iFolder server to other platforms, and vice versa. You should enforce server-based virus scanning to prevent viruses from entering the corporate network.
You should also enforce client-based virus scanning. For information, see Configuring Local Virus Scanner Settings for iFolder Traffic
in the Novell iFolder 3.8 Cross-Platform User Guide.
You can specify any existing containers and groups in the field of the iFolder LDAP settings. Based on the Search DNs, users are automatically provisioned with accounts for iFolder services.
The list of iFolder users is updated periodically when the LDAP synchronization occurs. New users are added to the list of iFolder users. Deleted users are removed from the list of iFolder users. (This might create orphaned iFolders if the deleted user owned any iFolders). If by mistake user is deleted from the LDAP, you can create that user again with the same FDN within the so that you can recover the user’s iFolders. For more information on this, see Step 7 in the Accessing and Viewing the Server Details Page.
IMPORTANT:Whenever you move a user between contexts and you want to provide continuous service for the user, make sure to add the target context to the list of LDAP Search DNs before you move the User object in eDirectory.
The LDAP synchronization tracks a user object’s eDirectory™ GUID to identify the user in multiple contexts. It tracks as you add, move, or relocate user objects, or as you add and remove contexts as Search DNs.
The following guidelines apply:
If the user is added to an LDAP container, group, or user that is in the Search DN, the user is added automatically to the iFolder user list.
If a user is moved to a different container, and the new container is also in the Search DN, the user remains in the iFolder user list.
If you intend to keep the user as an iFolder user without interruption of service and loss of memberships and data, the new container must be added as a Search DN before the user is moved.
If the user is moved to a different container that is not specified as a Search DN before the user is moved, the user is removed from the iFolder user list. The user’s iFolders are orphaned and the user is removed as a member of iFolders owned by others. If the new container is later added as a Search DN, the user is treated as a new user, with no association with previous iFolders and memberships.
If the user appears in multiple defined Search DNs, and if one or more DNs are removed from the LDAP settings, the user remains in the iFolder user list if at least one DN containing the user remains.
If the user is deleted from LDAP or moved from all defined Search DNs, the user is removed as an iFolder user. The user’s iFolders are orphaned and the user is removed as a member of iFolders owned by others.
The iFolder Admin user and iFolder Proxy user are tracked by their GUIDs, whether their user objects are in a context in the Search DN or not.
You can specify any existing containers and groups in the Search DNs field of the iFolder LDAP settings. Based on the Search DNs, LDAPGroups are automatically provisioned with accounts for iFolder services.
The list of LDAPGroup is updated periodically when the LDAP synchronization occurs. New LDAPGroups are added to the list of iFolder users. Deleted LDAPGroups are removed from the list of iFolder users. (This might create orphaned iFolders if the deleted LDAPGroup owned any iFolders). If by mistake LDAPGroup is deleted from the LDAP, you can create that LDAPGroup again with the same FDN within the so that you can recover the user’s iFolders. For more information on this, see Step 7 in the Accessing and Viewing the Server Details Page.
IMPORTANT:Whenever you move a LDAPGroup between contexts and you want to provide continuous service for the LDAPGroup, make sure to add the target context to the list of LDAP Search DNs before you move the LDAPGroup object in eDirectory.
The LDAP synchronization tracks a LDAPGroup object’s eDirectory™ GUID to identify the LDAPGroup in multiple contexts. It tracks as you add, move, or relocate LDAPGroup objects, or as you add and remove contexts as Search DNs.
The following guidelines apply:
If the LDAPGroup is added to an LDAP container, group, or LDAPGroup that is in the Search DN, the LDAPGroup is added automatically to the iFolder LDAPGroup list.
Any changes to the LDAPGroup member list are automatically synchronized during next synchronization cycle.
If an LDAPGroup is moved to a different container, and the new container is also in the Search DN, the LDAPGroup remains in the iFolder LDAPGroup list.
If you intend to keep the LDAPGroup as an iFolder LDAPGroup without interruption of service and loss of memberships and data, the new container must be added as a Search DN before the LDAPGroup is moved.
If the LDAPGroup is moved to a different container that is not specified as a Search DN before the LDAPGroup is moved, the LDAPGroup is removed from the iFolder LDAPGroup list. The LDAPGroup’s iFolders are orphaned and the LDAPGroup is removed as a member of iFolders owned by others. If the new container is later added as a Search DN, the LDAPGroup is treated as a new LDAPGroup, with no association with previous iFolders and memberships.
If the LDAPGroup appears in multiple defined Search DNs, if one or more DNs are removed from the LDAP settings, the LDAPGroup remains in the iFolder LDAPGroup list if at least one DN containing the LDAPGroup remains.
If the LDAPGroup is deleted from LDAP or moved from all defined Search DNs, the LDAPGroup is removed as an iFolder LDAPGroup. The LDAPGroup’s iFolders are orphaned and the LDAPGroup is removed as a member of iFolders owned by others.
The iFolder Admin LDAPGroup and iFolder Proxy LDAPGroup are tracked by their GUIDs, whether their LDAPGroup objects are in a context in the Search DN or not.
NOTE:LDAP groups are not supported for Openldap.
You can restrict the amount of space each user account is allowed to store on the server by setting an account quota. The account quota applies to the total space consumed by the iFolders the user owns. If the user participates in other iFolders, the space consumed on the server is billed to the owner of that iFolder. You can set quotas at the system or user level. Within a give account quota, you can also set a quota for any iFolder.