internal
Stanford Windows Infrastructure - Authorization
Authorization is the process of granting or denying access to resources. This page provides a brief description about Authorization services provided by the Stanford Windows Infrastructure.
Windows Credential System
Most Windows authorization is centered around the concept of the Security Identifier or SID. Every User, Group, Machine, and Domain has a SID value associated with it. When a user logs on (see Authentication), a credential is created containing the user's SID, SID values for the security groups that the user is a member of in the domain that the Domain Controller is authoritative for, and SID values for any Universal groups that the user is a member of. There are also some SID values that are calculated based on context, such as the SID for an interactive user "INTERACTIVE". If a user contacts a resource in another domain that has a trust relationship with the log on domain, the domain controller for that domain will supply SID values for security groups that the user is a member of in it's domain.
When an access needs to be authorized this collection of SIDs is compared with the Access Control List or 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 my require multiple ACLs to be evaluated - if any ACL does not allow the requested access, then the access fails.
Typical ACE ordering is:
- 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 what are known as "User Rights". These are assigned privileges to perform system-wide operations. Some are implied by membership in a certain machine local group, such as "Administrators". Others are configurable by system group policy settings. Typical rights are "Log on Locally" or "Shutdown the system"
Group Types
(See Exchange for details about Distribution Groups)
Global Security Groups
| Contains | Scope |
|---|---|
| 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 |
This group type is used in the Windows infrastructure primarily for Workgroup Manager controlled groups in WIN. Some temporary global groups are created for the purpose of Windows NT 4.0 migrations into the infrastructure in the case of a very complex move scenario.
Domain Local Security groups
| Contains | Scope |
|---|---|
| Contains users or groups from any domain trusted by the domain | Can be a member of any Domain Local group or used for permissions on any resource in the local domain |
This group type is used primarily in Windows infrastructure child domains to assign permissions to resources. This group type offers the most flexibility and convenience in applying permissions.
Universal Security Groups
| Contains | Scope |
|---|---|
| Contains users or Global groups from any domain in a forest | Can be a member of any Domain Local group or used for permissions on any resource in a forest. |
This group type is not recommended for use in the Stanford Windows Infrastructure. It is meant for configurations where user's primary logons may be in multiple domains. These groups incur a higher resource cost for the infrastructure and may not be supported in all connection scenarios.
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 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, external or internal security attacks, accidental or intentional modifications to system setup and configurations, and accidental or intentional access to confidential programs or documents.
Microsoft White Paper: Using a Least-Privileged User Account
Workgroup Manager Integration
As a part of the WinHarvester process (see Directory), data about the Workgroup Manager groups that a user is a member of is stored in the Active Directory. A process running in the Infrastructure uses that data to construct global groups in the root domain (WIN).
The resulting groups are named the based on the Workgroup Manager names, given naming limitations of Active Directory Groups
- Group names (legacy) cannot contain colon charactors ":", so these are replaced with hyphens "-"
- Group names must be 64 characters or less. If a group name is longer, it is truncated
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
Each of these global groups contains only global groups as members. The member groups are used to hide the actual membership of the Workgroup Manager group while still allowing the Active Directory group to function for allocating permissions.
Role-Based Access Control
Role-based Access Control or "RBAC" is a fairly new concept for Windows. Instead of granting or denying access based on an account or groups that that account is a member of, the access is based on a role. The Authorization Manager API, which delivers role-based access control, is only available for Windows 2000 and above. At this time, it is primarily used for ASP.NET applications.
A Role can be determined by:
- Membership in Active Directory or machine local groups
- LDAP query groups, where Active Directory attributes determine role membership
- Scripts for more complex roles or applying business logic
Microsoft Article: Role-Based Security
