420 likes | 542 Views
COMP3123 Internet Security. Richard Henson University of Worcester October 2011. Week 4 Access Controls: Network Directories & the PKI. Objectives: Explain the components of a network directory service
E N D
COMP3123 Internet Security Richard Henson University of Worcester October2011
Week 4 Access Controls: Network Directories & the PKI • Objectives: • Explain the components of a network directory service • Explain how the use of security policies can help prevent network internal security breaches • Analyse Windows active directory and compare it with an x500 standard service • Prepare a Windows active directory tree with two contiguously named domain controllers
“Network Directories” • Directories not to be confused with “folders”… • generally a data store that changes only infrequently… • e.g. a telephone directory • to avoid confusion, computer-based directories also called “repositories” • Lots of different “network databases” have evolved on the web • not a good idea! • often contain approx. the same info... • Problem: one updated, all should be • but unlikely in practice unless a managed solution
Meta-Directory • Simple idea of putting all information about any one entity or object in one place… • information about those entities and objects can then be presented in a consistent way • simplifies collection and distribution of info on an Intranet covering the whole organisation • Examples of Directory-enabled applications • enforce network policies! • across the network • between networks • digital signature verification • remote dial-in access authorization • signing in to a network
Network Directories & the PKI • Needs to avoid multiple-directories problem… • Solution: • use the meta directory approach • provide digital certificate information on the web as a “directory service” • use LDAP applications to directly access that info
Distributed Directory • Another way of keeping entity information consistent if it does need to appear in multiple locations • entry may appear in multiple directories • e.g. one for each email system (if more than one) • e.g. one for gaining access to the network by logging on • Paper-based equivalent – series of telephone directories each covering a clearly define area • collectively cover a wide geographical region • serve a variety of purposes • all part of the same system for communication • Regular directory synchronisation essential for maintaining consistency of information
Development of Internet Directories and IESG • IESG (Internet Engineering Steering Group) provides technical management of IETF activities • As approp, translate RFC proposals into RFC standards • Procedure: • draft RFC submitted • if accepted: IESG elevates it to RFC “draft” status • RFC then given consideration as a standard… • draft RFC eventually may become a true Internet standard • Example of successful evolution: x500 -> LDAP
X500 Architecture • Internet database based on the OSI model • RFC 1006 • allows OSI applications to run over an IP network • Full X500 Architecture: • DMD (directory management domain) • DSA (directory system agent) • DUA (directory user agents) • DIB (directory information base – object oriented!) • e.g.: a directory service database • DIT (directory information tree) • e.g.: Windows 2000 Active Directory
X500 Protocols • DAP (Directory Access protocol) • DSP (Directory System protocol) • DISP (Directory Information Shadowing Protocol) • DOP (Directory operational binding management protocol) • Collectively, these protocols give X500 a wide range of functionality, but the structure is cumbersome…
Simplifying X500 - LDAP • Known as Lightweight Directory Access Protocol • Thanks to University of Michigan Researchers, early 1990s • gave up on the complexities of X.500 • came up with a scheme that: • retained the X.500 directory structure • gave it a streamlined access protocol based on standard TCP/IP instead of ISO • Other improvements: • pared-down referral mechanism • more flexible security model • no fixed replication protocol
Microsoft and x500 • In 1996, Microsoft launched version 4 of its mailserver software, Exchange • Designed also to provide the infrastructure to enable DAP clients to access Microsoft Exchange directory service information… • client served as an X.500 DAP client to DAP-compliant directories • e.g. U.S. Government Defense Messaging System (DMS) • Also designed to manage table entries efficiently using a new obj oriented database engine called ESE (Extensible Storage engine)
Microsoft and LDAP • Microsoft wanted to use X500 in its directory service planned for next version of NT • Like Michigan Uni, found X500 cumbersome, and adapted LDAP • Supporting the Open Directory Services Interface (ODSI), Microsoft helped build a PKI service provider (Verisign) that supports the LDAP protocol • allowed developers to build applications that register with, access, and manage multiple directory services with a single set of well-defined interfaces • Microsoft Exchange Server 4 supported LDAP • Internet Explorer supported LDAP from v4 onwards
LDAP, ESE, and Active directory • Windows 2000 “active directory” service was a successful commercial roll out of an X500 compliant directory service • used LDAP… • also used (uses) ESE to manage data tables • and DNS to integrate with www locations • Next version of Microsoft Exchange also used the ESE/LDAP/DNS combination…
Directory Services and “Active Directory” • Active Directory has just one data store, known as the directory • Stored as NTFS.DIT • where does “.dit” originate from? • distributed across ALL domain controllers (dcs) • links to objects on/controlled by each dc • changes automatically replicated to all dcs • Contains details of: • stored objects • shared resources • network user and computer accounts
Directory Services and Domain Trees • Active Directory logically links domains together • very useful for networks with more than one domain • each domain is identified in the directory by a DNS domain name • Multiple domains with contiguous DNS domain names, make up adomain tree • if domain names are non-contiguous, structures form separate domain trees
“Trust Relationships” between (legacy) NT Domains • Account authentication between domains was first established in the Windows NT architecture • Allowed users and computers can be authenticated between any domains • Problem: Windows NT trust relationships were isolated and individual
Active Directory Trust Relationships • Automatically created between adjacent domains (parent and child domains) in the tree • users and computers can be authenticated between ANY domains in the domain tree • So how does this all work securely in practice, across an entire enterprise????
Access to Network Resources and Security Controls • The set of security mechanisms used to define what a user can access after logging on to a secured environment • enforce “authorisation” • “identification” and “authentication” may also be associated with logging on • Effect includes: • access to systems & resources • interactions users can perform
Mechanism of Access ControlIn Windows • User management level: • pre-defined Groups for Users to belong to • control of file and service access permissions • trusted relationships across domains • Translated down to system level by… • System Policies and Group Policies • Control of user and system desktop settings
Control of End User and System Settings • In Windows, ultimately, controls user access through the local Windows registry • first made available to simplify configuration in Windows 95 • effectively replaced CONFIG.SYS, AUTOEXEC.BAT, SYSTEM.INI and WIN.INI by a single structure • all settings saved into a hierarchical data file called SYSTEM.DAT • Principles later extended to networks…
The local registry and Windows networks • Like Windows 95, Windows NT v4 allowed system and user settings to be configured locally by registry overwrite files • However, it also made it possible for files within a network to overwrite the local registry as well… • facility available on any Windows client machine that used a Windows registry
What is The Registry? • Five basic subtrees: • HKEY_LOCAL_MACHINE : local computer info. Does not change no matter which user is logged on • HKEY_USERS : default user settings • HKEY_CURRENT_USER : current user settings • HKEY_CLASSES_ROOT : software config data • HKEY_CURRENT_CONFIG : “active” hardware profile • Each subtree contains one or more subkeys
Editing Registry Settings • Generally…. DON’T!!! Contents of the registry should not be changed in any way unless you really know what you are doing!!! • Special tools available e.g. REGEDT32 for those with experience: • used to edit local registry settings on Windows NT systems • Bearing in mind, however, that registry settings can also be overwritten in memory by data downloaded across the network…
System Policy File • Consists of a collection of registry settings • Can apply different system settings to a computer, depending on the user or group logging on • Can overwrite: • local machine registry settings • current user registry settings • Should therefore only be used by those who know what they are doing!!!
System Policy File • NTCONFIG.POL • provides a list of desktop settings, and therefore can be used to control aspects of appearance of the desktop • held on Domain Controllers • read during logon procedure • Different NTCONFIG.POL files can be applied to: • groups • users • computers
What is a Security Policy? • A set of rules and procedures that state the access rights and privileges of a particular user/group of users • Should also: • confirm the identity of the people that are attempting to access the network • prevent imposters from accessing, stealing, or damaging system resources
Implementation of Security Policy • Intention: • create a computing environment that provides users with all of the information and resources they need to be successful • protect the information and resources on the network from damage and unauthorized access
Group Policy in Windows 2000 (and subsequent) Networks • Group Policy settings • define access to local and network resources from the user's desktop environment: • e.g. Startmenu options • provide access to programs/resources that user needs to use • Group Policy Objects • used with authenticated users to enhance flexibility and scalability of security beyond “domains”, and “NT trusted domains” • trust achieved through: • Active directory – establishment of “trees” • Kerberos authentication
Implementation of Group Policy Objects • Group Policy objects are EXTREMELY POWERFUL… • contain all specified settings to give a group of users their desktop with agreed security levels applied • template editing tool available as a “snap-in” with Windows 2000 • creates a specific desktop configuration for a particular group of users • The GPO is in turn associated with selected Active Directory objects: • Sites • Domains • organizational units
Combined Power of Group Policies and Active Directory • Enables written user/group policies to be easily implemented in software • Enables policies to be applied across whole domains: • beyond in trusted contiguous domains in the domain tree • or even across any non-contiguous domains in the same forest • Because Active directory is x500 compliant, all the principles of directory services apply
Authentication Factors • Classified as type 1, type 2, or type 3: • Type 1: Knowledge based (what user knows) • information provided based on unique knowledge of the individual being authenticated • Type 2: Token based (what user has/does) • information comes from a token generated by a particular system • token is tied in some way to the user logging on • generally not considered a good idea on its own because someone else could have stolen/copied it • Type 3: Characteristic based (what user is) • biometric data from the person logging in
One time Passwords (OTP) • Can only be used once… • If user gets it wrong, becomes invalid… • locked out • has to contact administrator to reset • Implemented as a type 2 factor • password characters randomly generated • If used properly… • very secure indeed • problem: degree of randomness…
Single Sign On (SSO) • Logon once… • authenticated for all servers in that environment • More a convenience matter than a security issue • only one set of authentication factors needed • single username/authentication factor database covering all servers • SOME very secure environments have dropped SSO in favour of separate logon for each server • arguable whether this is necessary but avoids the “all eggs in one basket” argument
Password Administration • Three aspects: • Selection • should be a company IS policy that includes choice of password • generally no. of characters is a good match with strength – the higher the better • Management • selection & expiration period must comply with policy • Control • policy should be enforced by the network itself • usually achieved through use of “group policies”
Access Control Techniques • Discretionary (DAC) • access to files/resources controlled by administrator • Achieved through ACLs (Access Control Lists) • consist of ACEs (Access Control Entries) • the granting of access can be audited • Mandatory (MAC) • access dependent on rules/classifications • classification dependent on security clearance levels • hierarchical or compartmentalised, or hybrids
Remote Logon and Kerberos Authentication • KDC can maintain a secure database of authorised users,passwords & domain names maintained throughout an active directory domain tree using Kerberos V5 security protocol • uses strong encryption • freely available from its inventor, MIT • Active Directory + Kerberos = Very Powerful combination • can even be used to authenticate across mobile & wireless networks
Components of “Enterprise wide” Login with kerberos authentication • Active Directory tree logical connects and “trusts” servers throughout the enterprise • Servers in their turn control access to users within domains • Group(s) selected during the user authentication process • Group Policy Objects invoked which rewrite registry settings and control client desktops
How much security should be applied to domain users? • General rule: don’t give a user more rights than they actually need • Think carefully… • identify security privileges appropriate to different types of user • create a group based on each type of user • Allocate each new user to an appropriate group • automatically will have appropriate access rights…
Users, Groups, Security, and NTFS partitions • Any file or folder on an NTFS partition will have file permissions imposed • Typical permissions: • No Access • Read only • Read and Execute • Write • Modify • Ownership/Full Control • Much wider range of permissions available
Point for debate: is “read only” access dangerous? • If information held on server, and accessed by dumb terminals… • secure enough! • this was the case in the days of centralised networks with no distributed processing • With client-server networking, read only means “the user can take a copy” • is this dangerous, from an organisational security point of view?
What if the network goes wrong? Accountability • The broad security concept of being able to hold a human to account for their actions using … • a strong authentication environment so one user cannot masquerade as another • strict imposition of “least privilege” • regular monitoring of the network environment • rigorous inspection of audit logs
What if the network goes wrong? Auditing • Essential component of security monitoring • A network can generate lots of data on a wide variety of network functions and results they return • this is readily customisable to focus on, for example, the behaviour of particular users or resources • data normally saved as timestamped .log files • audit files help to ensure accountability for user behaviour