2. Lesson 1 Overview
• Overview of Active Directory, Identity, and Access
• Active Directory Components and Concepts
• Install Active Directory Domain Services
3. Lesson 1: Overview of Active Directory, Identity, and Access
• Information Protection in a Nutshell
• Identity and Access
• Authentication and Authorization
• Authentication
• Access Tokens
• Security Descriptors, ACLs, and ACEs
• Authorization
• Stand-Alone (Workgroup) Authentication
• Active Directory Domains: Trusted Identity Store
• Active Directory, Identity, and Access
• Active Directory and IDA services
4. Information Protection
• It’s all about connecting users to the information they require
securely
• IDA: Identity and Access
• AAA: Authentication, Authorization, Accounting
• CIA: Confidentiality, Integrity, Availability, and Authenticity
5. Identity and Access
• Identity: User account • Resource: Shared Folder
• Saved in an identity store • Secured with a security
(directory database) descriptor
• Security principal • DACL or “ACL”
• Represented uniquely by • ACEs or “permissions”
the SID
6. Authentication and Authorization
A user presents credentials that The system creates a security
are authenticated by using the token that represents the user
information stored with the user’s with the user’s SID and all related
identity group SIDs
A resources is secured with an The user’s security token is
ACL: permissions that pair a SID compared with the ACL of the
with a level of access resource to authorize a requested
level of access
7. Authentication
Authentication is the process that verifies a user’s identity
Credentials: At least two components required
• User name • Secret, for example, password
Two types of authentication
• Local (interactive) Logon– • Remote (network) logon–
authentication for logon to the local authentication for access to
computer resources on another computer
8. Access Tokens
User’s Access Token
User SID
Member Group
SIDs
Privileges
(“user rights”)
Other access
information
10. Authorization
Authorization is the process that determines whether to grant or deny a user a
requested level of access to a resource
Three components required for authorization
• Resource • Access Request • Security Token
System finds first ACE in the
User’s Access Token ACL that allows or denies the Security Descriptor
requested access level for any
User SID SID in the user’s token SACL
DACL or “ACL”
Group SID
ACE
List of user Trustee (SID)
rights Access Mask
Other access ACE
Trustee (SID)
information Access Mask
11. Stand-Alone (Workgroup) Authentication
• The identity store is the SAM database on the Windows
system
• No shared identity store
• Multiple user accounts
• Management of passwords is challenging
12. Active Directory Domains: Trusted Identity Store
• Centralized identity store
trusted by all domain
members
• Centralized authentication
service
• Hosted by a server
performing the role of an AD
DS domain controller
13. Active Directory, Identity, and Access
An IDA infrastructure should:
Store information about users, groups, computers and
other identities
Authenticate an identity
• Kerberos authentication used in Active Directory
provides single sign-on. Users are authenticated only
once.
Control access
Provide an audit trail
14. Active Directory and IDA Services
Active Directory IDA services :
Active Directory Lightweight Directory Services (AD LDS)
Active Directory Certificate Services (AD CS)
Active Directory Rights Management Services (AD RMS)
Active Directory Federation Services (AD FS)
Editor's Notes
Cram Class #2Date: 2/4/2012
Active Directory and its related services form the foundation for enterprise networks running Windows as they store information on user identity, computers, and services, authenticate a user or a computer, and provide a mechanism for the user or the computer to access resources from the enterprise.
Active Directory Domain Services (AD DS) provides the functionality of an identity and access (IDA) solution for enterprise networks.After completing this lesson, you will be able to:Explain authentication and authorization concepts, terminologies processes, and technologies.Position the strategic role of a directory service in an enterprise in relation to identity and access.
Because users require different levels of access to different classes of information, you need to associate the correct users with the correct levels of access – information protection.The industry defines several approaches to achieving information protection. Each of these “alphabet soup” frameworks is simply a different perspective on the same problem:Identity and Access (IDA) – Users and other security principals, which may include computers, services, and groups, are named as identities (accounts) that are given access (permissions) to information, resources, or systems.Authentication, Authorization, and Accounting (AAA) – Users provide user name and password that are authenticated when their credentials are validated. Users are given permissions to resources (access control) that are used to authorize access requests. Access is monitored, providing accounting and auditing. In some documentation, auditing is split out as a separate “A” from accounting, leading to the acronym, “AAAA”.Confidentiality, Integrity, and Availability (CIA) – Information is protected to ensure that it is not disclosed to unauthorized individuals (confidentiality), is not modified incorrectly (integrity) intentionally or accidentally, and is available when needed (availability).ReferencesMicrosoft Identity and Access Solutions: http://www.microsoft.com/en-us/server-cloud/identity-access-management/default.aspx
At the core of information protection are two critical concepts: identityandaccess.In a secured system, each user is represented by an identity. In Windows systems, the identity is the user account. The accounts for one or more users are maintained in an identity store, which is also known as a directory database. An identity is called a security principal in Windows systems. Security principals are uniquely identified by an attribute called the security identifier (SID).On the other end of the system is the resource to which the user requires access. The resource is secured with permissions, and each permission specifies a pairing of a specific level of access with an identity. Many Windows resources, including significant files and folders on NTFS volumes, are secured by a security descriptor that contains a discretionary access control list (DACL) in which each permission takes the form of an access control entry (ACE).
There are a few concepts and process that you must understand about users and resource access. When a user tries to access a resource on a local or a remote system, several procedures are initiated. It’s all about mapping a user SID to the appropriate ACE on a resource.References:Logon and Authentication Technologies: http://technet.microsoft.com/en-us/library/cc780455(WS.10).aspxAuthorization and Access Control Technologies: http://technet.microsoft.com/en-us/library/cc782880(WS.10).aspx
Authentication is the process of verifying a user’s identity. The user provides credentials that contain at least two components: a logon name and a secret known only to the user and the system, such as a password. The system validates the accuracy of the credentials against those stored as part of the identity.There are two types of authentication: local and remote. Local, or interactive, logon occurs when a user logs on to a computer directly, such as when you log on to your laptop. Remote, or network, logon occurs when you connect to another computer such as a file server, mail server, to get files or other types of resources.
After user authentication, the Local Security Authority (LSA) generates a security access token (also called a security token or an access token) that represents the user to the system by collecting the user’s SID and the SIDs of all groups to which the user belongs. The access token also represents privileges (also called user rights) held by the user on the system, such as the right to shut down the system or to log on to the system interactively (locally).It is important to remember that the access token is generated and held locally on the computer that authenticated the user. When a user logs on to the desktop (local or interactive logon), the desktop creates a security token and, if the user has the right to log on to the system interactively, proceeds to invoke the Windows Explorer process, which creates the desktop.When the user connects to a server to access a shared file (remote or network logon), the server authenticates the user and generates an access token on the server that represents the user with the user’s SID and the SIDs of all groups to which that user belongs. The access token on the server is distinct from the access token on the user’s desktop. An access token is never transmitted over the network, and the LSA of a Windows system would never accept the access token generated by another LSA.This should be the case because a user belongs to different local groups on the server than on the user’s desktop, and almost certainly holds different privileges (user rights) on the server than on the desktop.
The security descriptor of a secured resource, such as a file or folder on an NTFS volume, fully describes the security characteristics of the resource. The security descriptor contains the DACL, which contains ACEs or “permissions”. Each permission is made up of a flag that indicates whether the ACE is an Allow or Deny ACE; a Trustee (the SID of a user or a group); and an access mask specifying a level of access. Therefore, the ACE defines who (the trustee represented by the DIS) can or can’t do what (represented by the access mask).The security descriptor also contains the system access control list (SACL), which contains auditing settings and attributes such as the object’s owner. Because the DACL is the focus of most day-to-day security management activities for a resource, the name and acronym is often shortened. Therefore, the shortened access control list (ACL), while technically inaccurate, is used by many administrators and much documentation (including these lessons) to refer to the DACL.
Authorization is the process that determines whether to grant or deny a user a requested level of access to a resource. An access request that indicates the resource, the level of access, and the security token representing the user is made. Then, the security subsystem examines the ACL of the resource, comparing the SIDs in the ACEs with the SIDs in the security token. The first ACE that matches both a SID in the token and the desired type of access determines whether the user is allowed (if the ACE is an Allow ACE) or denied (if the ACE is a Deny ACE) access to the resource. If no match is found, access is denied.
In a stand-alone configuration of Windows systems, also called a workgroup, each computer maintains one and only one trusted identity store: a local list of users and groups stored in the registry call the Security Accounts Manager (SAM) database. Unlike authentication in a domain, which is centralized, in workgroup, there is a distributed authentication system because each computer has its own SAM.Because Windows systems are secure, a user cannot even log on to a computer without a user account. The user must present credentials that are validated against the identities in the SAM. After a user has been authenticated and authorized for local logon, the Windows Explorer process is launched, which generates the familiar Windows desktop.If the user wishes to access a shared folder on a server, there is an immediate problem: the server does not trust an identity presented to it, because the identity has been authenticated by an unknown and untrusted system. The server trusts only its own identity store, its own SAM. Therefore, for the user to remotely log on to the server, the server must have an identity (user account) for the user in its SAM. If the logon name and password for the identity are identical to the credentials of the identity on the workstation, the authentication process that occurs is transparent to the user. This type of authentication is called pass-through authentication. If, however, the logon names or passwords do not match, the user will be prompted to enter credentials that valid for the server when the user attempts to connect to a shared resource.The ACL on a secured resource on the server cannot contain permission that refer to untrusted identities. Therefore, all users who require access to the resource must have accounts on the server.This presents obvious management challenges. If the user changes their password on the desktop, the two accounts are longer in sync, and the user will be prompted for credentials when connecting to the server. The problem only gets worse as you add more users, resources, and Windows systems to the environment. The management challenges of maintaining multiple identities for each user becomes quickly untenable.
The management and security challenges of a workgroup are solved by centralizing the identity store so that there is only one identity (user account) required for any one user – an identity store that is trusted by all computers. This unit of trusted identity is created by the introduction of an Active Directory domain and forest infrastructure.An Active Directory domain provides a centralized identity store trusted by all domain members – all computers that have accounts in the domain. A domain also provides a centralized authentication service, along with a number of other components and services, are hosted on a server performing the role of a domain controller.
Active Directory provides the IDA solution for enterprise networks running Windows. IDA is necessary to maintain the security of enterprise resources such as files, email, applications, and databases.An IDA infrastructure should do the following:Store information about users, groups, computers, and other identities. An identity is a representation of an entity that will perform actions on the enterprise network. For example, a user will open documents from a shared folder on a server. You know that the documents will be secured with permissions on an ACL. Access to the documents is managed by the security subsystem of the server, which compares the identity of the user with the identities in the ACL to determine whether the user’s request for access will be granted or denied. Computers, groups, services, and other objects also perform action on the network; they must be represented by identities. Among the information stored about an identity are properties that uniquely identify the object, such as a user name or an SID, and the password for the identity. The identity store is therefore one component of an IDA infrastructure. The Active Directory data store, also known as the directory, is an identity store. The directory itself is hosted on and managed by a domain controller – a server performing the AD DS role.Authenticate an identity. The server will not grant access to the user unless the server verifies that the identity presented in the access request is valid. To validate the identity, the user provides secrets known only to the user and the IDA infrastructure. Those secrets are compared with the information in the identity store in a process called authentication.In an Active Directory domain, a protocol called Kerberos is used to authenticate identities. When a user or a computer logs on to the domain, Kerberos authenticates the credentials and issues an information package called a ticket granting ticket (TGT). Before the user connects to the server to request the document, a Kerberos request is sent to a domain controller along with the TGT that serves to identify the authenticated user. The domain controller issues the user another information package called a service ticket that identifies the authenticated user to the server. The user presents the service ticket to the server, which accepts the service ticket as proof that the user has been authenticated.These Kerberos transactions result in a single network logon or single sign-on. After the user or computer has initially logged on and has been granted a TGT, the user is authenticated within the entire domain and can be granted service tickets that identify the user to any service. All of this ticket activity is managed by the Kerberos clients and services built into Windows, and is transparent to the user.Control access. The IDA infrastructure is responsible for protecting confidential information such as the information stored in the document. Access to confidential information must be managed according to the enterprise’s policies. The ACL on the document reflects a security policy that contains permissions that specify access levels for particular identities. The security subsystem of the server in this example is performing the access control functionality in the IDA infrastructure.Provide an audit trail. An enterprise may want to monitor changes to and activities within the IDA infrastructure, so it must provide a mechanism to manage auditing.
AD DS is the most prominent component of an IDA infrastructure, but it is not the only component of IDA that is supported by Windows Server 2008 R2. With the release of Windows Server 2008, Microsoft has consolidated a number of previously separate components into an integrated IDA platform. These services are:Active Directory Lightweight Directory Services (AD LDS)Active Directory Certificate Services (AD CS)Active Directory Rights Management Services (AS RMS)Active Directory Federation Services (AD FS)Each of these services plays a role in extending IDA to support more complex configurations and scenarios.AD LDSAD LDS is essentially a stand-alone version of Active Directory that applications access by using Lightweight Directory Access Protocol (LDAP).AD LDS is the replacement for Active Directory Application Mode (ADAM). The name of the previous version of the tool indicates its purpose: AD LDS is designed to provide support for directory-enabled applications. It can be used for applications that require a directory store, but do not require the type of infrastructure provided by an Active Directory domain.Each instance of AD LDS can have its own schema, configuration, and application partitions. This allows you to create a highly customized directory store without affecting your production IDA infrastructure, based on AD DS. Although AD LDS is not dependent on AD DS, in a domain environment, AD LDS can use AD DS authentication of Windows security principals, such as users, computer, and groups.AD LDS can be configured in a domain or non-domain environment, and it is even possible to run multiple instances on a single system, each with its own unique LDAP and Secure Sockets Layer (SSL) ports to ensure secure connection with each instance.AD CSAD CS extends the concept of trust so that a user, computer, organization, or service can prove its identity outside or inside the border of your Active Directory forest.Certificates are issued from a certificate authority (CA). When a user, computer, or service uses a certificate to prove its identity, the client in the transaction must trust the issuing CA. A list of trusted root CAs, which includes VeriSign, is maintained by Windows and updated as part of Windows Update.The certificates can be used for numerous purposes in an enterprise network, including the creation of secure channels such as the SSL example in the AD LDS section. Additionally, the certificates can be used for virtual private networks (VPNs), wireless security, and authentication, such as smart card logon.AD CS provides technologies and tools that help create and manage a public key infrastructure (PKI). Although AD CS can be run on a stand-alone server, it is much more common and much more powerful to run AD CS integrated with AD DS, which can act as a certificate store and provide a framework to manage the lifetime of certificates, how they are obtained, renewed, and revoked.AD RMSAD RMS creates a framework with which you can ensure the integrity ofinformation, both within and outside your organization.In a traditional model of information protection, ACLs are used to define how information can be accessed. For example, a user may be given the Read permission to a document. However, there is nothing to prevent that user from performing any number of actions after that document is opened. The user can make changes to the document and save it in any location, print the document, or forward the document by email to a user who otherwise does not have Read permission to the document.AD RMS addresses these and other such scenarios by enforcing information use policies. AD RMS accomplishes this by using licenses and encryption to protect information and by having rights management–enabled applications that can consume the licenses, create usage policies, open protected content, and enforce usage policies.AD FSAD FS allows an organization to extend the authority of the directory service for authenticating users across multiple organizations, platforms, and network environments.The traditional Windows domains-trust relationship creates a trust in which the trusting domain allows the trusted domain to authenticate users, but the result is that all users in the trusted domain are trusted. Moreover, to maintain a trust, several firewall exceptions must be made that are not agreeable to many organizations and certainly not suitable for supporting Web-facing applications. To overcome this problem, AD FS can be configured to maintain trusts by using common ports such as 80 and 443.AD FS is extremely useful for extending a directory's authority in business-to-business and partnership scenarios, as well as for supporting single sign-on web applications.