Lesson 7: Managing Access Services and Accounts Flashcards
authorization
- process by which subjects (typically authenticated or computer accounts) are granted rights to access and modify resources
- important functions in authorization:
- The process of ensuring that only authorized rights are exercised (policy enforcement)
- The process of determining rights (policy definition)
implicit deny
- Access controls are usually founded on the principle of implicit deny; that is, unless there is a rule specifying that access should be granted, any request for access is denied
- can be seen clearly in firewall policies:
- firewall filters access requests using a set of rules
- rules are processed in order from top-to-bottom
- if a request does not fit any of the rules, it is handled by the last (default) rule, which is to refuse the request
least privilege
means a user should be granted rights necessary to perform their job and no more
Single Sign-On (SSO)
- a user only has to authenticate to a system once to gain access to all the resources to which the user’s account has been granted rights
- example
- Kerberos authentication and authorization model
directory services
- principal means of providing privilege management and authorization on an enterprise network
- owner or systems administrator can share resources (folders, printers, and other resources) to make them available for network users
authentication credentials
provided by each user at logon to gain access to a system-defined account
server’s security database
- contains authentication credentials (username and password, or other authentication data), and if both match (input to database), the user is authenticated
- the server security service generates an access key for the user (contains the username and group memberships of the authenticated user)
Access Control List (ACL)
- all resources on server-based systems that is used to control access to the resource
- access list contains entries for all usernames and groups that have permission to use the resource )records also the level of access)
directory
- like a database, where an object is like a record, and things that you know about the object (attributes) are like fields
- in order for products from different vendors to be interoperable, most directories are based on the same standard
- principal directory standard is the X. 500 series of standards, developed by the International Telecommunications Union (ITU) in the 1980s
Lightweight Directory Access Protocol (LDAP)
- not a directory standard but a protocol used to query and update an X.500 directory or any type of directory that can present itself as an X.500 directory
- runs over TCP and UDP port 389 by default
- basic protocol provides no security and all transmissions are in plaintext, making it vulnerable to sniffing and Man-in-the-Middle (spoofing an LDAP server) attacks
- a server that does not require clients to authenticate is vulnerable to overloading by DoS attacks
- where LDAP can be queried from some sort of web application, the application design needs to prevent the possibility of LDAP injection attacks (a malicious user may enter a search string that includes extra search filters)
distinguished name
- unique identifier for any given resource within an X.500-like directory
- distinguished name is made up of attribute=value pairs, separated by commas
- most specific attribute is listed first, and successive attributes become progressively broader
- most specific attribute is also referred to as the relative distinguished name, as it uniquely identifies the object within the context of successive (parent) attribute values
schema
- types of attributes, what information they contain, and the way object types are defined through attributes (some of which may be required, and some optional) is described by the directory schema
- some of the attributes commonly used include Common Name (CN), Organizational Unit (OU), Organization (O), Country (C), and Domain Component (DC)
- example:
CN=WIDGETWEB, OU=Marketing, O=Widget, C=UK, DC=widget, DC=com
X.500 Directory Information Tree
- X.500 directories are arranged in a hierarchy
- each directory starts at the root and passes through several levels of container objects, such as country (optional), organization, and organizational units (also optional)
- actual network resources, such as users, computers, printers, folders, or files, are referred to as leaf objects
authentication (binding to server)
- implementation:
- no authentication—anonymous access is granted to the directory
- simple authentication—the client must supply its DN and password, but these are passed as plaintext. This method could be secured if using IPSec for transport across the network
- Simple Authentication and Security Layer (SASL)—the client and server negotiate the use of a supported security mechanism. Typically, this will mean the use of either Kerberos or TLS to provide strong certificate-based authentication
Remote Authentication Dial-in User Service (RADIUS)
- standard is published as an Internet standard
- RADIUS authentication process works as follows:
1. the remote user connects to a RADIUS client, such as an access point, switch, or remote access server
- the RADIUS client prompts the user for their authentication details, such as a username and password or digital certificate. Certificate-based authentication is available if the RADIUS product supports EAP
- the remote user enters the required information. The RADIUS client uses this information to create an Access-Request packet. The packet contains the following data:
- Username and password
- Connection type (port)
- RADIUS client ID (IP address)
- Message authenticator - the Access-Request packet is encapsulated and sent to the AAA server using UDP on port 1812 (by default)
- the AAA server decrypts the password (if the password cannot be decrypted, the server does not respond)
- the client checks an authenticator in the response packet; if it is valid and an Access-Accept packet is returned, the client authenticates the user. The client then generates an Accounting-Request (Start) packet and transmits it to the server (on port 1813). It then opens a session with the user
- the server processes the Accounting-Request and replies with an Accounting-Response
- when the session is closed (or interrupted), the client and server exchange Accounting-Request (Stop) and Response packets
Terminal Access Controller Access-Control System Plus (TACACS+)
- similar protocol to RADIUS but designed to be more flexible and reliable
- designed by Cisco
- uses TCP communications (over port 49), and this reliable, connection-oriented delivery makes it easier to detect when a server is down
- all the data in TACACS+ packets is encrypted (except for the header identifying the packet as TACACS+ data), rather than just the authentication data
- more often used for device administration than for authenticating end user devices
- allows centralized control of accounts set up to manage routers, switches, and firewall appliances, as well as detailed management of the privileges assigned to those accounts
federation
- the notion that a network needs to be accessible to more than just a well-defined group, such as employees
- in business, a company might need to make parts of its network open to partners, suppliers, and customers, and likewise have parts of its network open to its staff
- means that the company trusts accounts created and managed by a different network
- in the consumer world, a user might want to use both Google Apps™ and Twitter; if Google and Twitter establish a federated network for the purpose of authentication and authorization, then the user can log on to Twitter using his or her Google credentials or vice versa
federated identity management
networks establish trust relationships so that the identity of a user (the principal) from network A (the identity provider) can be trusted as authentic by network B (the service provider)
one-way trust
- child trusts parent but parent does not trust child
- example
- Domain B might be configured to trust Domain A. Users from Domain A can be authorized to access resources on Domain B. Users from Domain B, however, are not trusted by Domain A
two-way trust
domains are peers, and both trust one another equally
non-transitive trust
trust relationship remains only between those domains
transitive trust
trust extends to other trusted domains. For example, if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A also trusts Domain C
Security Association Markup Language (SAML)
- developed by the Organization for the Advancement of Structured Information Standards (OASIS)
- SAML authorizations (or SAML tokens) are written in eXtensible Markup Language (XML)
- Communications are established using HTTP/HTTPS and the Simple Object Access Protocol (SOAP)
- secure tokens are signed using the XML signature specification
- the use of a digital signature allows the SP to trust the IdP
- example of a SAML implementation
- Amazon Web Services (AWS) can function as a SAML service provider (allows companies using AWS to develop cloud applications to manage their customers’ user identities and provide them with permissions on AWS without having to create accounts for them on AWS directly)
- The principal’s User Agent (typically a browser) requests a resource from the Service Provider (SP), making an assertion of identity
- If the user agent does not already have a valid session, the SP redirects the user agent to the Identity Provider (IdP)
- The user agent authenticates with the IdP. The IdP validates the supplied credentials and if correct, provides an authorization token
- The user agent presents the SP with the authorization token
- The SP verifies the token and if accepted, establishes a session and provides access to the resource.
Shibboleth
- open source implementation of SAML
- main components
- Identity Provider—supports the authentication of users. The software can be integrated with LDAP, Kerberos, X.509, and other directory and authentication systems
- Embedded Discovery Service—allows the user to select a preferred identity provider
- Service Provider—processes calls for user authentication by contacting the user’s preferred identity provider and processing the authentication request and authorization response. The service provider can be used with the IIS and Apache web servers
OpenID
- standard underpinning early “sign on with” features of websites
- an example of a “user-centric” version of federated identity management
- allows a consumer website, referred to as the relying party (RP), to accept new users without having to go through an account creation step first, improving availability
- take this hypothetical situation and fictional website: fantastic-holidays.com
- fantastic-holidays.com wants to quickly accept authenticated users to participate in live chat with sales staff | does not want to force potential users to complete a sign-up form, which might act as a deterrent and reduce sales opportunities | Consequently, it becomes a relying party accepting Google.com or Live.com as identity providers | Later, if fantastic-holidays.com wins a sale and needs more information about the user, it can associate that identity with additional profile information, such as billing details
OAuth
- protocol designed to facilitate this sort of transfer of information or resources between sites
- user grants an OAuth (“auth” stands for “authorization,” NOT “authentication”) consumer site the right to access resources stored on an OAuth provider website
- uses REST (Representational State Transfer) web services, rather than SOAP, and JSON (JavaScript Object Notation) message format and JSON Web Tokens (JWT), rather than XML