The Stanford Windows Infrastructure provides authorization services, which grants or denies access to various resources around campus based on defined permissions set by University IT (UIT).
Windows credential system
Most Windows authorization centers on the concept of the Security Identifier (SID); every user, group, machine, and domain has a SID value associated with it. When a user logs on, a credential is created containing SID values for the user, the security groups of which the user is a member (in the domain that the domain controller has authority), and any Universal groups in which the user is a member. Some SID values are calculated based on context, such as the SID for an interactive user called “INTERACTIVE.” If a user contacts a resource in another domain that has a trust relationship with the log on domain, the domain controller for the contacted domain will supply SID values for security groups in its domain of which the user is a member.
When an access needs to be authorized, the collection of SIDs related to the accessor is compared with the Access Control List (ACL) for the resource. Each Access Control Entry (ACE) is parsed until either enough rights have been gathered for the requested access or access has been denied. Some accesses may require multiple ACLs to be evaluated, but if any ACL does not allow the requested access, it is denied.
Typical ACE ordering:
- Explicit “Deny” ACEs
- Explicit “Allow” ACEs
- Inherited “Deny” ACEs
- Inherited “Allow” ACEs
Note: Inherited ACEs do not exist in all ACLs.
The credential also contains user rights, which are assigned privileges to perform system-wide operations. Some are implied by membership in a certain machine local group, such as Administrators, while system group policy settings can configure others. Typical rights include “Log on Locally” or “Shutdown the System.”
Group types
| Type | Uses | Contains | Scope |
|---|---|---|---|
| Global Security | Primarily in Windows Infrastructure for Workgroup Manager controlled groups in WIN | Users or Global groups from the local domain | Can be a member of any group or used for permissions on any resource in any domain that trusts the local domain |
| Domain Local Security | Primarily in Windows Infrastructure child domains to assign permissions to resources; offers the most flexibility and convenience in applying permissions | Users or groups from any domain trusted by the domain | Can be a member of and Domain Local group or used for permissions on any resource in the local domain |
| Universal Security | Not recommended for use in the Stanford Windows Infrastructure. Meant for configuration where users’ primary logons may be in multiple domains; incur a higher resource cost for the infrastructure and may not be supported in all connection scenarios | Users or Global groups from any domain in a forest | Can be a member of and Domain Local group or used for permissions on any resource in a forest. |
Workgroup manager integration
Part of the identity integration processes, data about the Workgroup Manager groups that a user is a member of is stored in the Active Directory. Workgroup owners can use the Workgroup Manager workgroup integration function to choose which groups are converted into Active Directory groups.
The resulting groups in Active Directory have names based on the Workgroup Manager group names, given the naming limitations of Active Directory Groups. Names must be 64 characters or less, and longer ones will be truncated. Group names (legacy) cannot contain colon characters (“:”), so hyphens (“-”) are used instead.
All of the Workgroup Manager controlled groups are found in a container called “Registry.” Under this container, there are three group containers based on some assumptions about group type based on name:
- “Organizations” contains groups generated based on Stanford identity/affiliation
- “Personal Groups” contains groups generated for a user’s personal use
- “Workgroups” contains groups generated by a functional group that has a Workgroup Manager domain
Role-based and claims-based access control
Role-Based Access Control (RBAC) means that access is based on a role, not an individual user. Roles can be predetermined in an application or computed from information about the user. Claims-Based authorization means that when the user is authenticated, the authenticating party includes claims about that user, which the application can use to determine access or roles. Claims are widely used in federated scenarios, where the client and the server may not use the same authentication system.
Most claims-based authorization now uses a set of standards called Security Assertion Markup Language (SAML). The campus already supports Shibboleth, one implementation of the standard. The Windows Infrastructure supports an interoperable implementation called Active Directory Federation Services, which generates claims from information in Active Directory. Microsoft supplies this product, along with the Windows Identity Framework and Microsoft CardSpace to create its platform for federated identity.
Microsoft also provides the Authorization Manager API (AzMan), which delivers role-based access control based on Active Directory attributes. An AzMan role can be determined by membership in Active Directory or machine local groups; LDAP query groups, where Active Directory attributes determine role membership; or scripts for more complex roles or applying business logic.
Principle of least privilege
The principle of least privilege states that users must have access to the software, data, and devices required to perform their daily duties, but must not have access to local or network resources that are not required for their job tasks. Similarly, any process accounts must have access necessary to run the process, but no more. If low-privileged accounts are compromised, they will do a lot less damage to a system than a high-privileged account is capable of doing.
Consequently, using a non-administrator account instead of an administrator account while completing daily tasks offers the user added protection against infection from a host of malware, internal or external security attacks, accidental or intention to system setup and configurations, and accidental or intentional programs or documents.
