Patent Application
20080098120
As briefly described above, embodiments are directed to dynamic computation of identity-based attributes. With reference to
Computing device 100 may have additional features or functionality. For example, computing device 100 may also include additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in
Computing device 100 also contains communication connections 116 that allow the device to communicate with other computing devices 118, such as over a network. Networks include local area networks and wide area networks, as well as other large scale networks including, but not limited to, intranets and extranets. Communication connection 116 is one example of communication media. Communication media may typically be embodied by computer readable instructions, data structures, program modules, or other data in a modulated data signal, such as a carrier wave or other transport mechanism, and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. The term computer readable media as used herein includes both storage media and communication media.
In accordance with the discussion above, computing device 100 system memory 104 (and processor 102, and related peripherals can be used to implement host 120, server 122, and cache 124. Host 120, Server 122, and cache 124 in an embodiment can be used for authentication server auditing of clients using cache provisioning (described below with reference to
In addition, the local (read-only) domain controller is configured to only store the resources (e.g., user accounts “secrets”) that are needed for that branch location. For example, as will be understood more fully from the following specification and claims, the hub domain controller partitions for each branch which users can login to client computer systems at the given branch. The hub domain controller, however, does not automatically provide these resources to all local domain controllers at each branch, but provides only those authorized secrets to the given branch upon an appropriate login by the user. Thus, in one implementation, the local (read-only) domain controller is configured to receive and store only a select few of the company's or organization's secrets, which can limit the potential security exposure of the server.
For example,
As shown, the hub domain controller 203 includes a resources component 210, which comprises all of the configuration, non-secret, and secret information that is used or available with each branch domain controller (e.g., 255). For example, in one implementation, the resources component 210 contains user accounts in the company or organization, including the corresponding user names and passwords. The resources component 210 also contains user name and password versioning information, as well as versioning information for various configuration information used at a given branch. The hub domain controller 203 is configured to change configuration resources and/or location of resources/secrets for each different local domain controller.
For example,
Thus, as shown in
The authentication module 245 identifies whether the local domain controller's secret and the user's logon credentials provided in message 280 are authentic and current. If either the local domain controller's secret or the user's logon credentials are not current, not valid, or not authentic for some other reason, the hub domain controller 203 returns an error to the local domain controller. Assuming, nevertheless, that the local domain controller's secret is valid, the authentication module 245 also checks to see if “User A” is allowed to access the resource (e.g., logon) at “Branch A” 250. For example, if User A is allowed to logon at Branch B (not shown), but not allowed to logon at the requested branch (i.e., “Branch A”), the authentication module 245 might allow the login, but will not allow the branch domain controller to cache the user's secret (e.g., user account 225a). Alternatively, the hub domain controller can return an error, if appropriate.
As shown in
As such,
The illustrated “as needed” or “on-demand” type of approach, however, is not required in all situations. For example, an authorized branch manager (of another branch) or company president may be visiting branch 250 that day, and will need to access one or more of the client computer systems for presentation purposes. An authorized user, such as the local network administrator for the local domain controller, can request the visitor's account in advance. For example, the local network administrator can send a request through the local domain controller 255, or through another local client computer system (e.g., 270) to the hub that requests the visitor's account.
As with prior requests, the request for advanced access also includes authentication information for the requestor, as well as the secret for the local domain controller provided earlier by the hub domain controller 203. The authentication module 245 at the hub domain controller 203 then checks to see if the visitor's account is one that can be provided in advance, and, if appropriate checks the credentials of the requester. For example, the hub domain controller can check the requester's credentials if the requester has not yet been cached at the local domain controller where the requester is making the request.
In addition, the hub domain controller 203 can check to see if the secret provided by the local domain controller is accurate. If appropriate, the hub domain controller 203 then passes the visitor's user account to the local domain controller, where it can be stored in cache 265 for an appropriate amount of time. When that amount of time has expired (e.g., when periodic updates are scheduled to be sent and received next), the hub domain controller can send information that invalidates the metadata of the secret received in advance. As will be understood more fully from the following text and claims, the messaging invalidating the secret's metadata itself comprises one or more timestamps to ensure proper ordering, prioritization, and discarding of invalid secrets cached or received by the local domain controller.
In an implementation using Kerberos, the login process of a client includes finding a Key Distribution Center (KDC) by using indirection. Using indirection in the login process typically does not specifically target a unique KDC, but rather uses a generic name that will return any KDC available, and typically nearby. This allows automatic affiliation between the KDC and the client—but this affiliation is normally unknown to the client (which normally only knows that the request is sent to an arbitrary KDC).
The first information passed is an AS_REQ (authentication server request) from the client to the KDC. This is information that can identify the client to the KDC, and normally has a limited lifetime. These messages can be snooped upon by unauthorized parties, and because the messages are also sent independently to other KDCs, they are not typically good identifiers of client affinity to a specific KDC.
The KDC responds with an encrypted package for the client identified by the AS_REQ. This package is normally only decryptable by someone holding the client's password (not available from the AS_REQ alone)—which in an embodiment is the identified client itself. The contents of the package are a typically a session key and a TGT (ticket granting ticket).
Further, when the client wishes to make a connection to some resource (such as another client, computer, resource, and the like), it creates a request and encrypts it with the session key, and includes the TGT. This request, called a TGS (ticket granting server) request can be copied and sent to other KDCs, but the internal information, the session key, the TGT, the identification of the resource requested, and the type of service requested are very resistant to being modified or spoofed (at least by network sniffing). Therefore, the TGS request itself is not a good identifier of client affinity to a specific KDC, but the data in the TGS can be used as an identifier of the client affinity. Specifically, the identity of the resource requested and the type of service requested are good identifiers of client affinity to a specific KDC.
In a Windows® logon process, a client typically requests from the affiliated KDC the services of LDAP (lightweight directory access protocol) or HOST. These are normally used for querying a Group Policy or downloading a Group Policy. Therefore, if the rule is used that whichever client, in an authorized list for a specific KDC, requests an LDAP or HOST service from that KDC in a TGS_REQUEST that is allowed to be cached, the list for tracking approximate client physical locality will be automatically created as described above.
Because the user who is logging in is by definition not already cached, all requests of the caching-KDC are forwarded to a full KDC. Accordingly, a full KDC makes the decision whether to allow caching of the TGS_REQUEST information. If the list of clients that are to be allowed to have their information and passwords cached at any single KDC is too broad, for example if too many users are allowed or a large superset of the actual physically local users, a large part of the benefit knowing the client affinity can be lost. If a very small set of clients, which directly relate to the actual physically local users and computers, is used then the security of the solution is maximized.
However, independently managing such a small list for each locale for any large or dynamic organization can be time-consuming and error prone. One question is how to automatically create the list of allowed users, while ensuring the system is secure. In an embodiment, a second list of clients who are authorized to be allowed to be cached is kept, which adds a (simplifying) level of indirection to the process. This list can be relatively large, and can include all possible clients except those explicitly denied (this list is relatively easy to manage, and in fact already is in many environments). When the large list is used, a determining factor becomes, of those who are authorized by the large list, who should be allowed to be cached. A “deny list” can also be used. As discussed above, clients that have their locations approximated via the affinity with a particular KDC can thus be cached with a level of trust.
In operation 304, it is determined that the client is not cached at the caching-KDC, and because the AS_REQ cannot be locally processed, the AS_REQ request is forwarded to a full KDC.
In operation 306, the full KDC validates the AS_REQ as if it had directly originated with the first client. If the validation is successful, the full KDC creates a response, which includes a session key and a TGT, and encrypts the response with the client password. It sends this to the caching-KDC from which it received the forwarded AS_REQ request. In operation 308, the caching-KDC returns it intact to the client, and in operation 310, the client receives the response and decrypts it.
In operation 312, the first client wishes to query about the Group Policy as part of the logon process. The first client creates a TGS_REQUEST for the LDAP service on the caching-KDC. The TGS_REQUEST is sent (comprising server and service information, along with the TGT), encrypted with the session key to the caching-KDC itself.
In operation 316, the caching-KDC verifies that it cannot read the session key to be able to decrypt the request, and the request is forwarded it to the full KDC.
In operation 318, the full KDC decrypts the information and validates the request that came from the original client by using the correct session key, and a valid TGT. The full KDC notes that the request is for the LDAP service on the caching-KDC, and marks that client to be allowed to be cached by the caching-KDC. The full KDC responds to the request appropriately, and sends the info to the caching-KDC.
In operation 320, the caching-KDC forwards the response from the full KDC to the client.
In operation 322, the client initiates a connection to the LDAP service on the caching-KDC using the Kerberos information in the TGS response.
In operation 324, the caching-KDC (because the client made an LDAP service request) requests of the full KDC that it be allowed to cache the client's information and password.
In operation 326, the full KDC determines that the client has been marked to be cached by the caching-KDC, and grants the request, sending the caching-KDC the requested information and passwords. Further requests (for TGSs to other site affiliated resources and for additional AS_REQs and TGT requests) from the client to the caching-KDC can be serviced by the caching-KDC itself, with no forwarding required.
The above specification, examples and data provide a complete description of the manufacture and use of embodiments of the invention. Since many embodiments of the invention can be made without departing from the spirit and scope of the invention, the invention resides in the claims hereinafter appended.
