Abstract:
An improved system and method for network management is presented which facilitates better administration with a more intuitive reflection of the organizational structure with integrated security concerns by introducing novel strategies for grouping users of a network. In particular, a new group, the Universal Group, is introduced to facilitate nested groups with members in more than one Domain. Members of a universal group may be allowed access to resources across Domain boundaries, where Domains reflect a security boundary in the Network. In addition, the nesting of groups, e.g., within Universal Groups, is enabled, subject to some restrictions, in order to reduce the overhead associated with discovering the groups to which a user belongs. Furthermore, allowing a group to include members without security clearance, but restricting the groups listed on an access token corresponding to a user to groups to which the user has security clearence/authorizarion allows flexible management of groups having similar memberships but different security attributes.

Description:
TECHNICAL FIELD 
   This invention relates generally to network administration, and more particularly to the administration of an intra-organizational network with a large number of user nodes that may be organized in domains defined by security considerations. 
   BACKGROUND OF THE INVENTION 
   Various networking strategies are used in modern computer networks to enable intra-organizational communication while attempting to accommodate security concerns about preventing unauthorized access to information. Such communications range from unencrypted E-mails to encrypted secure documents that should be accessible to only a subset of users having the privilege to use the intra-organizational network. The extent of such a network could be global in geographical terms and may include local high-speed connections along with, possibly, slow linkages to far-flung nodes. 
   It is desirable in course of implementing networks to maximize authorized access without generating excessive network traffic due to the associated overhead. This overhead typically includes, among other things, maintaining a record of users authorized to access a particular network accessible resource and frequently updating such records. In a simple case, each resource maintains its own list of authorized users, and upon receiving a request for service checks the list to prevent security breaches due to access by unauthorized users. 
   Users of a network are often organized into groups. The use of groups reduces the number of list entries that have to be checked by a resource (and updated by the system) prior to granting access to a requestor because many users may belong to a group, and thus proof of a user&#39;s membership in an approved group could suffice. Such proof may be provided by presenting an “access token” that lists all of the security groups to which a particular user belongs. Additionally, administrators have to manage only one account for each user, and each user typically needs to use (and remember the password of) only one account to access resources in a domain. Thus, an effective grouping strategy should reflect the security structure of the network and the organizational dynamics of the group members. 
   An illustrative example of such existing networking strategies is provided by the “Windows NT 4.0” software provided by “Microsoft®,” which is described next in some detail in order to provide a suitable background for the enhancements introduced in this application. In keeping with the preceding description, the “Windows NT 4.0” software envisages a logical grouping of network servers and other computers that share common security and user account information as a “domain.” Within domains, administrators usually create one user account for each user. Users then log on to the domain rather than repeatedly logging on to various individual servers in the domain. A domain is simply an administrative unit of Windows NT Server Directory Services corresponding to a security boundary. Thus, computers in a single domain can share physical proximity on a small local area network (LAN) or can be located in different parts of the world and communicate over various types of physical connections, including dial-up lines, ISDN, fiber, Ethernet, Token Ring, frame relay, satellite, and leased lines etc. 
   Within a domain, “domain controllers” manage all aspects of user-domain interactions. Domain controllers are computers running “Windows NT®” Server that share one directory database to store security and user account information for the entire domain. The domain controllers in each domain form a single administrative unit and use the information in the directory database to authenticate users logging on to domain accounts. Each domain has one primary domain controller (PDC), which tracks changes made to domain accounts. Whenever an administrator makes a change to a domain account, the change is recorded in the directory database on the PDC, which is the only domain server that receives these changes directly. 
   In addition, multiple backup domain controllers (BDCs) can exist in a domain. A BDC maintains a copy of the directory database. This copy is synchronized periodically and automatically with the PDC. BDCs also authenticate user logons, and a BDC can be promoted to function as the PDC. 
   An individual may use domain resources such as files, directories, and printers if he or she has a user account created by an administrator, who assigns a user name to an account, specifies the user&#39;s identification data, and defines the user&#39;s rights on the system. Resources in the domain are available subject to user rights, privileges and system-wide policies. Advantageously, there are predefined (built-in) groups with sets of user rights already assigned. Administrators, then, can assign user rights by adding a user account to one of the predefined groups or by creating a new group and assigning specific user rights to that group. Users who are subsequently added to a group automatically gain all user rights assigned to the group account. Although, individual users can be given specific user rights, most administrators prefer to control actions on a group basis rather than on an individual user basis. 
   In contrast to “rights,” which are domain wide and defined in relation to the domain controller, “permissions” are rules that regulate which users can use objects (such as directories, files, and printers) and in what manner. The owner of an object sets the permissions on the object. Similar to user rights, a permission on an object applies to each member of a group if the group is granted the permission on the object. Under some circumstances a user may have a right but not the permission necessary to exercise the right. Often the right trumps the conflicting permission in such a situation. 
   Although small organizations can store accounts and resources in a single domain, large organizations typically establish multiple domains. Multiple domains with appropriate group definitions can advantageously allow an organization to manage far flung operations with reduced administrative overhead in course of doing business. A natural concern from a business and privacy perspective is security in the context of large networks. Often, security across multiple domains is provided through trust relationships. A trust relationship is a link that allows users authenticated in one domain to access resources in another domain, subject to access control. 
   Two types of trust relationships are encountered in most networks. In a one-way trust relationship, one domain trusts the users in the other domain to use its resources. More specifically, one domain trusts the domain controllers in the other domain to validate user accounts to use its resources. The resources that become available are in the trusting domain, and the accounts that can use them are in the trusted domain. However, if user accounts located in the trusting domain need to use resources located in the trusted domain, that situation requires a two-way trust relationship. 
   A two-way trust relationship is two one-way trust relationships in that each domain trusts user accounts in the other domain. Users can log on from computers in either domain to the domain that contains their account. Each domain can have both accounts and resources. Global user accounts and global groups can be used from either domain to grant rights and permissions to resources in either domain. In other words, both domains are trusted domains. 
   Two types of group accounts are supported in “Microsoft®” “Windows NT 4.0” software. A “global group” consists of several user accounts from only a single domain—the domain where the global group was created, that are grouped together under one group account name. “Global” indicates that the group can be granted rights and permissions to use resources in multiple (global) domains. A global group can contain only user accounts and can be created only on a domain controller and not on a workstation or member server. 
   In contrast, a “local group” consists of user accounts and global groups from one or more domains, grouped together under one account name. Users and global groups from outside a particular domain can be added to the local group only if they belong to a trusted domain. “Local” indicates that the group can be granted rights and permissions to use resources in only a single (local) domain. A local group can contain users and global groups, but it cannot contain other local groups. It is useful to note that global groups are an efficient way to add users to a local group. Although a global group can be granted permissions and rights in its own domain, it is best to grant rights and permissions to local groups and use global groups to add user accounts from account domains (trusted) to resource domains (trusting). Usually “Windows NT” domain controllers also support built-in local groups having rights corresponding to the built-in group names such as Administrators, Account Operators, Server Operators, Backup Operators, Print Operators, Users, Guests, and Replicators. 
   Member servers can participate in a domain, although participation is not required. Permissions can be set on the server&#39;s resources that allow users to connect to the server and use resources. It should be noted that a member server that does not participate in a domain has only its own database of users, and it processes logon requests by itself. It does not share account information with any other computer and cannot provide access to domain accounts. Only user accounts created at the server can be logged on to or given rights and permissions for using the server&#39;s resources. 
   SUMMARY OF THE INVENTION 
   The difficulties presented by the limiting group definitions and the efficiency considerations due to network traffic generated by the need to verify access privileges are over come by the invention in addition to presenting a method and system for better administering computer networks, including heterogenous networks spanning great geographical distances, that include resources that are not accessible to all users. A Universal Group, which has members belonging to different domains and which may use resources across domain boundaries is used to better organize users into groups. In addition, nesting of groups, e.g., within Universal Groups, is enabled subject to some restrictions in order to reduce the overhead associated with discovering the groups to which a user belongs. Furthermore, allowing a group to include members without security clearance, but restricting the groups listed on an access token to groups to which the user has security clearence/authorizarion allows flexible management of groups having similar properties but for the different security attributes. This translates into reduced network traffic due to less extensive replication requirements as well as facilitating better administration of the network by allowing groups that better reflect actual organizational relationships. 
   Additional features and advantages of the invention will be made apparent from the following detailed description of illustrative embodiments, which proceeds with reference to the accompanying figures. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
     While the appended claims set forth the features of the present invention with particularity, the invention, together with its objects and advantages, may be best understood from the following detailed description taken in conjunction with the accompanying drawings of which: 
       FIG. 1  is a block diagram generally illustrating the relationships between various security enabled groups in accordance with the invention; 
       FIG. 2  is a block diagram generally illustrating an exemplary network and the control of requests that involve security concerns; and 
       FIG. 3  illustrates a flow diagram detailing the computation of an Access Token in response to a request. 
   

   DETAILED DESCRIPTION OF THE INVENTION 
   The invention teaches an efficient method of structuring groups of objects for security purposes in a distributed computing system, and a method of unifying such groups with groups used for distributing email. 
   The invention addresses two problems encountered presently. First, in a distributed system it is advantageous to perform access control at the granularity of sets of users rather than user-by-user. This leads to the concept of a security group. Groups gain power and flexibility by allowing nesting, e.g. group A being a member of group B implies that all members of group A are effectively members of group B. However, in a distributed system it is impractical to allow arbitrary nesting of groups, because doing so makes answering the question “does this user belong to this group?” which is a basic question that must be answered to perform access control to files and other network resources, quite expensive. In accordance with the invention, a set of rules for restricted nesting of groups is provided that allows the system to model real organizations (in which group memberships must cut across organizational, network, and other boundaries) yet allows the question “does this user belong to this group?” to be answered efficiently. 
   Second, E-mail is a common distributed system application that also needs to define sets of users and distribution lists. When you send mail to a distribution list you send it to all members of the list. In accordance with a feature of the invention, a unification of distribution lists with security groups allows the maximum commonality both in the system that represents groups and in the administrative tools that manipulate groups. Furthermore, there is a specific innovation that provides the customer with control over the usage of unified groups. Accordingly, a group can be defined as “not for security”, which eliminates any negative performance impact of this group on the security system. Distribution lists are often defined “not for security.” Yet the option of defining a distribution list “for security” is retained, in which case the group serves a dual purpose. 
   In accordance with the invention there are provided definitions for three mutually exclusive group types, and an orthogonal “security-enabled” attribute on groups, thus generating six types of groups in all; a definitions of restrictions on membership and usage of groups of the various types; and a definition of an algorithm that computes the access token of a security principal. 
   Some of the relevant terms are defined next for the sake of clarity. A resource is a process in a distributed computing system. Examples of resources include directory services, file systems, and database management systems. An object, in this context, is a directory service entry. A security principal is an object representing an entity or set of entities that may have access rights to a resource. A user is a security principal corresponding to an individual. A group is a security principal corresponding to a set of individuals. A contact is an object corresponding to an individual who is not a security principal. Typically the individual represented by a contact can receive e-mail. But because the contact is not a security principal the individual represented by a contact cannot access resources. 
   In a similar vein, an access token is a data structure associated with a user attempting to access a resource. The access token contains the user&#39;s identity and the identity of groups containing the user. A domain is a security boundary in a distributed system. Each user and each resource is associated with a specific domain. A directory service object within that domain represents the user or resource. When a user attempts to access a resource, designated machines within the user&#39;s domain, called domain controllers, are responsible for authenticating (establishing the identity of) the user. Domain controllers within both the user&#39;s and the resource&#39;s domain cooperate to compute the user&#39;s access token at a resource. The resource itself then makes a yes/no access decision based on the contents of the access token, the type of access (e.g. read or write) requested by the user, and the state of the resource. 
   THE GROUP TYPES 
   In an embodiment of the invention each group has an integer groupType attribute. The possible values of groupType are defined by these bit flags:
         ADS_GROUP_TYPE_GLOBAL_GROUP   ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP   ADS_GROUP_TYPE_UNIVERSAL_GROUP   ADS_GROUP_TYPE_SECURITY_ENABLED
 
Exactly one of the first three flags must be present. The fourth flag is orthogonal to the first three. As illustrated in  FIG. 1 , there are six legal combinations:
   global security group: ADS_GROUP_TYPE_GLOBAL_GROUP &amp; ADS_GROUP_TYPE_SECURITY_ENABLED   domain local security group: ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP &amp; ADS_GROUP_TYPE_SECURITY_ENABLED   universal security group: ADS_GROUP_TYPE_UNIVERSAL_GROUP &amp; ADS_GROUP_TYPE_SECURITY_ENABLED   global distribution group: ADS_GROUP_TYPE_GLOBAL_GROUP   domain local distribution group: ADS_GROUP_TYPE_DOMAIN_LOCAL_GROUP   universal distribution group: ADS_GROUP_TYPE_UNIVERSAL_GROUP       

   For some purposes the ADS_GROUP_TYPE_SECURITY_ENABLED bit is irrelevant. Therefore it is convenient to use the term global group to mean global security group or global distribution group, domain local group to mean domain local security group or domain local distribution group, and universal group to mean universal security group or universal distribution group. 
   RESTRICTIONS ON GROUP MEMBERSHIP AND USAGE 
   The system imposes the following restrictions on group membership and usage:
         Objects from a domain cannot be contained in a global group from another domain.   A universal group cannot be contained in a global group.   A domain local group cannot be contained in groups, except for domain local groups in the same domain.   A domain local group cannot be used to control access to a resource in another domain.       

   Consequences of these restrictions include:
         Global groups can&#39;t contain users, contacts, or global groups from other domains. Global groups can&#39;t contain universal groups. Global groups can&#39;t contain domain local groups.   Universal groups can&#39;t contain domain local groups.   Domain local groups can&#39;t contain domain local groups from other domains.   A resource can&#39;t be access-controlled using domain local groups from other domains.       

   COMPUTING THE ACCESS TOKEN 
   The access token is computed in four stages. The first two stages are performed by a domain controller from the user&#39;s domain. The third stage might be performed on a domain controller of either domain. The fourth stage is performed by a domain controller of the resource&#39;s domain. 
   The four stages or steps are as follows:
         1. The user is added to the access token.   2. All global security groups from the user&#39;s domain that contain any object in the access token are added to the access token. This step is repeated until no more global security groups are added on some iteration.   3. All universal security groups from any domain that contain any object in the access token are added to the access token. This step is repeated until no more universal security groups are added on some iteration.   4. All domain local security groups from the resource&#39;s domain that contain any object in the access token are added to the access token. This step is repeated until no more domain local security groups are added on some iteration.       

   At this point the access token is complete. 
   The restrictions on the various group types relate directly to this algorithm. For instance, if a global security group were allowed to contain a universal security group, the system administrator would expect that global group and any global groups containing it to be added to the access token when the universal group is added. The algorithm above does not do this, because it would be hopelessly inefficient. Therefore the system restricts groups to structures that are consistent with the token construction algorithm. Requests to create and modify groups enter the Directory Services Agent (DSA.) The DSA passes these requests to the Security Accounts Manager (SAM) for validation. SAM enforces the group type restrictions. 
     FIG. 1  summarizes these relationships between group types described above. In  FIG. 1 , solid arrows represent the relationship “can be a member or can be contained within” while the broken arrows represent “cannot be a member of or be contained within.” Furthermore, while upward and horizontal solid directed edges are allowed, no downward directed solid edges are allowed and are not explicitly shown for reason of clarity. A user does not contain other objects, e.g., user  10  in “domain  1 ” may not contain any other object because users do not contain other objects. Similar considerations apply to the independent users  11  or  12  shown in FIG.  1 . Global security group  20  in Domain  1  may contain other global security groups from Domain  1  but not a domain other than domain  1 . Thus, the global security group  21  contains the global security group  20  but cannot contain the global security group  22  from Domain  2 . Universal security group  30  may be contained in other universal security groups, e.g., universal security group  31 . In addition, a universal security group may be contained in a universal security group from another domain. For instance, universal security group  31  from domain  1  contains universal security group  32  from domain  2 . A universal security group may also contain other universal security groups, global security groups and users, including those from other domains. Thus, universal security group  31  from domain  1  contains universal security group  32 , global security group  22  and user  12  from domain  2 . Similarly, user  10  and global security group  20  are contained in universal security group  30 . 
   Domain local security groups may contain users, global security groups and universal security groups, including those from other domains. Thus, domain local security group  40  in domain  1  contains universal security group  30 , global security group  20  and user  10  and is contained in domain local security group  41 , all from domain  1 . In addition domain local security group  41  of domain  1  contains the universal security group  32 , global security group  22  and user  12  of domain  2 . But a domain local security group cannot contain a domain local security group from another domain as is shown by the broken directed connecting domain local group  41  in domain  1  to the domain local group  42  in domain  2 . 
   Finally, an Access Control List (ACL) for providing a access to a resource, may contain universal security groups global security groups and users from any domain and domain local security groups from its own domain. ACL  50  contains domain local security group  40 , universal security group  30 , global security group  20  and user  10  of domain  1  while ACL  51  of domain contains universal security group  32 , global security group  22  and user  12  of domain  2  but not domain local security group  42 . 
     FIG. 2  presents an overview of the overall security control with the Group definitions as described herein. Requests to Create and Modify Groups  70  enter the Directory Services Agent (DSA)  80 . DSA  80  passes these requests to the Security Accounts Manager (SAM)  90  for validation. SAM  90  enforces the group type restrictions. Requests to Compute an Access Token  100  enter the Local Security Authority (LSA)  110 . The LSA  110  performs authentication, then calls SAM  90  to perform steps two through four of the algorithm described earlier. 
     FIG. 3  presents a flow diagram illustrating the previously described steps for calculating the Access Token. The User requesting an Access Token is added to the Access Token (step  120 ) followed by adding all the Global Security Groups containing any object in the Access Token (step  130 ) to the Access Token. This step leads to the addition of any Universal Groups from any Domain that contains any object in the Access Token to the Access Token (step  140 ) and the final step of adding the Domain Local Groups containing any object in the Access Token to complete the construction of the Access Token (step  150 ). 
   In other words, in accordance with the invention, groups are enabled as distribution groups and do not appear on an Access Token. However, if the security enabled bit is set then the group is included in a security token for the object. The advantage in this approach is that the group object undergoes a state change without breaking containment relationships. Consequently, there is no need to modify the containing groups if the security bit is set in a contained group, i.e. it is a security group, thus providing simple and integrated administration of groups. This is in contrast to copying from a containing group resulting in breaking containment relationships. In effect, if a putative security principal belongs to a group with the security bit enabled then computation of the Access Token, and in general an access-data-structure, can proceed with the inclusion of the group in the security token. 
   In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiment described herein with respect to the drawing figures is meant to be illustrative only and should not be taken as limiting the scope of invention. For example, those of skill in the art will recognize that the elements of the illustrated embodiment shown in software may be implemented in hardware and vice versa or that the illustrated embodiment can be modified in arrangement and detail without departing from the spirit of the invention. Those of skill in the art will recognize that all or part of the access token can be cached, with portions of the cache invalidated when security group memberships are added or removed. Rather than computing an entire access token before starting to make an access control determination, the access token can be lazy-evaluated. Access token evaluation amounts to the computation of a transitive closure of a directed graph; the literature contains many optimized algorithms or computing the transitive closure. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.