FreeIPA
banners
Contribute to FreeIPA!

From Free IPA

Contents

[edit]

Summary

freeIPA2.0 will focus on making IPA as usable as possible by other projects. This will include enabling IPA to manage machine and service identity and creating a plug-in architecture for IPA.

The goal is to release a follow on freeIPAv2 within nine months of the release of freeIPAv1 that will:

  • Address barriers to v1 usage
  • Provide v2 Identity functionality (machine and service identity)
  • Provide initial Policy and Audit functionality
[edit]

General Overview

[edit]

Main Use Cases Solved by IPAv1

  • Manage Linux/Unix user identity, groups, passwords centrally and more easily (CLI,GUI)
  • Authenticate user to Linux/Unix using Kerberos/LDAP instead of NIS
  • Easily install Kerberos, LDAP, NTP
  • Enable basic synchronization with AD
[edit]

Main Use Cases for IPAv2

  • User Identity Management (based on functionality implemented in v1)
  • Machine identity
    • Enrollment of the new machines
      • As a result of the enrollment machine principal must be created and machine credentials provisioned to the machine
      • Machine credentials can be keytab and/or machine certificate.
    • Machine authentication
      • Machines coming on the network and requesting services within the IPA realm shall be authenticated against that realm
      • Machine authentication credentials shall be used to provide mutual authentication/trust, encryption, and SSO capabilities for the services and applications requesting resources and accessing other services within the same IPA realm
    • Machine Management
      • Allow management of individual machines, groups of machines and virtual instances
      • Allow centralized management of different kinds of machine policies
    • Policy Management
      • Identify and group applications for the purpose of applying policy to them
      • Create an integrated policy delivery mechanism
      • Centrally describe and define compliance policies for the machines
    • Access Control
      • Set and enforce policy of which users can access which applications on which machines.
      • Enable central management of pam login access controls
      • Enable a centrally managed SUDO configuration to scope administrative control.
      • Enable central management of SELinux based Role Based Access Control
      • Enable central management of SELinux policy
  • Audit
    • Centrally collect and store:
      • (i) security events
      • (ii) all logs
      • (iii) every keystroke
by a selected group of users and or machines.
    • Centrally audit compliance with the policies
    • Centrally manage what log events are collected from what groups of machines
    • Manage collected logs easily
    • Provide reporting tools
    • Provide external interfaces to analyze and relate collected data
  • External Interfaces
    • Create an interface to provide access control and authentication decisions to new applications (do early in project -- need to support text file)
[edit]

Compelling Reason to Use

  • Compliance and efficiency are forcing organizations off of NIS and push to have a better identity management and access control solution for the Linux/Unix world
  • Efficiency is forcing organizations to a better identity management solution
  • Too expensive to maintain own custom LDAP/Kerberos implementation
  • Have been using services that "assume a security mechanism" and wish to secure connections with kerberos or PKI
  • Compliance and efficiency motivate to centrally manage administrator delegation and SUDO configuration
  • Security and compliance push to centrally understand/analyze audit events
[edit]

Glossary

  • Compliant System Configuration = Describing how a system should be configured to comply with organizational or governmental policy
  • System Lockdown = Actually locking down a system for security and compliance
  • System Configuration Audit = Auditing a system to see if its configuration is in conformance with the compliant system configuration
  • System Event Audit = An event
  • Services = Running code to which you can connect (locally or across the network)
  • Applications = Code running locally
  • Access policy = Policy describing the rules by which an authenticated user can connect to a resource
[edit]

High Level Requirements

  • 1. Machine Identity and Authentication
  • 2. Services Identity
  • 3. Extensible (Plug-in) Architecture / Framework
  • 4. Kerberos
  • 5. Certificate and Registration Authority Integration
  • 6. Policy
  • 7. IPA client
  • 8. Migration and Interoperability
  • 9. Audit
  • 10. Security of the System
  • 11. FreeRADIUS plugin
  • 12. Active Directory Integratoin
  • 13. User Identity and Administration Enhancements
[edit]

Detailed Requirements

[edit]

1. Machine Identity and Authentication

  • [1.1] Integrate DNS server into the IPA server
    • [1.1.1] Store DNS information in LDAP
    • [1.1.2] Allow IPA clients to automatically discover IPA servers (using DNS configuration)
    • [1.1.3] Allow management of the DNS entries through the central IPA management console
    • [1.1.4] Continue to allow IPA to function with an external DNS server
  • [1.2] Policy on an IPA server shall determine the rules of the enrollment for the new machines. Options include:
    • [1.2.1] The machine shall automatically be registered in IPA and configured with settings that were pre-initialized
    • [1.2.2] An Administrator is required to manually authenticate to the IPA server and initialize the configuration settings
  • [1.3] When machine joins IPA realm the following operations shall be performed:
    • [1.3.1] A unique and permanent identifier (machine GUID) shall be set for each machine and virtual machine.
    • [1.3.2] Assign a kerberos principal to the machine/VM.
    • [1.3.3] Kerberos machine/VM principal name will be administrator assigned or automatically set
    • [1.3.4] Kerberos machine/VM principal will default to the hostname
    • [1.3.5] Capture attributes about the machine
      • [1.3.5.1] Hostname
      • [1.3.5.2] IP address
      • [1.3.5.3] Identify operating system on the machine
      • [1.3.5.4] Laptop or not
      • [1.3.5.5] Hardware information / inventory (from smolt, factor or dmidecode)
      • [1.3.5.6] In the case of administrator enrollment, the ID of the administrator
    • [1.3.6] Generate and provision keytab for machine/VM authentication
    • [1.3.7] Generate and provision machine certificate for the machine/VM to be used by applications and services that require PKI authentication
    • [1.3.8] Integrate machine into the existing network by downloading and applying policies related to the machine (network settings, policy, printers)
    • [1.3.9] Allow specifying a “policy profile” for a machine during enrollment. This will automatically place machine into corresponding machine groups
  • [1.4] Enable grouping of machines
    • [1.4.1] Define and apply different kinds of policies to different groups of machines
    • [1.4.2] Define policies for a collection of applications and apply these policies to groups or individual machines
    • [1.4.3] Allow creation of the high level collections of policies (for example: “Manager Laptop”, “Developer Desktop”, “Web Server” etc.) to simplify deployment of the system (Low Level – can be deferred)
  • [1.5] Name change and migration scenarios. Provide a tool to:
    • [1.5.1]Change the machine/VM principal name
    • [1.5.2]Change the machine kerberos principal name when a virtual machine is copied or migrated
  • [1.6] Renewal
    • [1.6.1] Automatically renew kerberos credential according to the centrally managed renewal policies
    • [1.6.2] Automatically renew and provision certificates before their expiration according to the centrally managed policy
  • [1.7] Allow a machine to leave the realm, removing the identity from IPA and destroying/revoking any certificates/keytabs. May include bootable CD to allow removal from realm and secure deletion of all storage.
    • [1.7.1] The task of removing a machine from a realm should not require access (physical or networked) to that client machine
    • [1.7.2] Allow machine to be removed from IPA realm through the IPA client software
    • [1.7.3] Allow machine to be re-enrolled into the IPA realm. This shall be a one step remove + enroll operation
  • [1.8] Update LDAP schema to support machine identity and related policies
  • [1.9] Maintain the identity of the machine or virtual machine after an upgrade of the OS including a major upgrade for instance from 4 to 5.
[edit]

2. Services Identity

  • [2.1] Services Identity and Credentials
    • [2.1.1] Allow different ways of defining services, the credentials they require for authentication and policies that control their operation:
      • [2.1.1.1] Specify trough IPA client. In this case the provisioning of the service should happen automatically (subject to policy validation on server)
      • [2.1.1.2] Specify in the GUI or command line on the server side. In this case client side software should detect (not necessarily immediately and automatically) and download application (service) related policies and credentials.
    • [2.1.2] Automatically create/provision/renew/revoke the credentials required for the services and applications to function according to the policies defined for the services and machines
      • [2.1.2.1] Machine kerberos principals shall not be used for services by default (except for SSHD which will leverage machine kerberos principal)
      • [2.1.2.2] In IPA v2 allow only Kerberos or PKI authentication for the services
      • [2.1.2.3] In IPA v2 use only one certificate for all applications and services running on the machine
  • [2.2] Service Management
    • [2.2.1] Allow unique identification of services and applications
    • [2.2.2] Provide means to define and associate policies or groups of polices to a collection (group) of applications/services running on a machine or a group of machines.
    • [2.2.3] Implement an option to automatically create service principal and/or certs when a new service is setup (later than machine join)
    • [2.2.4] Should be easy to give the same service principal to multiple services on different machines (cluster use case)
    • [2.2.5] Service principals and/or service certs should be easily co generate and manage
[edit]

3. Extensible (Plug-in) Architecture / Framework

  • [3.1] IPA should be built with an extensible framework that supports addition of multiple different features and capabilities as add-ons. It is implied that a feature can be represented by a collection of packages that by itself constitute plug-ins, modules and scripts of different nature.
  • [3.2] The IPA server shall allow following extensibility:
    • [3.2.1] Modification of LDAP Schema
    • [3.2.2] DS Server plug-in – plug-in into the LDAP server itself
    • [3.2.3] Plug-in into XML-RPC interface
    • [3.2.4] Plug-in into GUI
  • [3.3] Constraints for Extensible Framework
    • [3.3.1] Features should be able to provide schema that is picked up by the GUI
    • [3.3.2] Existing entries should be dynamically updated with default values where required by the new Schema
    • [3.3.3] Features shall be able to be installed into IPA easily
    • [3.3.4] No restart of the core IPA DS and authentication services shall be required when a new feature is installed
    • [3.3.5] The GUI may be restarted to reflect new plug in UI elements
    • [3.3.6] It shall be possible to deploy feature elements (plug-ins) in an asymmetric fashion on different IPA servers. For example, a schema for a feature is deployed on all IPA replica instances but the UI plug-in and XML-RPC service will only run on a single IPA sever
  • [3.4] Rework schema to support extensible architecture
[edit]

4. Kerberos

  • [4.1] Kerberos Functionality
    • [4.1.1] Kerberos shall work and be easy to use
    • [4.1.2] It shall be easy to configure Kerberos for the following:
      • [4.1.2.1] CIFS
      • [4.1.2.2] Apache
      • [4.1.2.3] CUPS
      • [4.1.2.4] Imap Cyrus-imapd, Dovecot,
      • [4.1.2.5] mta (for smtp) -- sendmail, postfix, exim -- include support for email aliases.
      • [4.1.2.6] Jboss
      • [4.1.2.7] Autofs integration (store maps in IPA)
    • [4.1.3] Support Kerberos referrals in IPA
    • [4.1.4] Allow Kerberos principals to be known by multiple aliases. For example, clients do not have to know a mail or web servers fully qualified domain name in order to authenticate an alias or short name should be sufficient
  • [4.2] Kerberos Integration
    • [4.2.1] Currently much of the Kerberos Service configuration information is stored in files on the local file system. This makes replication problematic. Kerberos configuration shall be stored in the Directory so it can be replicated throughout the IPA infrastructure
    • [4.2.2] Improve DS schema to store Kerberos related information
[edit]

5. Certificate and Registration Authority Integration

  • [5.1] Include a certificate authority and registration authority as part of default server installation and configuration
    • [5.1.1] No other Certificate system components will be included in this release
    • [5.1.2] No key escrow DRM
    • [5.1.3] No token management or token key smart card components
    • [5.1.4] No OCSP responder
  • [5.2] Certificate Authority will be used to issue the machine and service specific certs
  • [5.3] In this version, there will only be support for machine and service certificates. There will be no support for user certificates for authentication, signing, encryption
  • [5.4] It should be possible to store Certificates and key material in either flat files or an NSS database
[edit]

6. Policy

  • [6.1] Policy management and definition
    • [6.1.1] Policy language should be declarative and analyzable.
    • [6.1.2] Policy should be stated once in a high-level, platform neutral way and then translated to platform specific controls.
    • [6.1.3] Policy language should be standards-based if at all possible.
    • [6.1.4] Policy should be supported on Linux, Unix, Windows, MacOS.
    • [6.1.5] Platform specific policy should be possible.
    • [6.1.6] If possible use an already existing, prevalent method of specifying policy
    • [6.1.7] Allow one and the same centrally managed policies be presented in different formats to different applications (policies might be stored in a generic format but then translated into different formats by application specific plug-ins or converters)
    • [6.1.8] IPA policy storage and management engines shall be extensible so that new policies can be dropped in, managed centrally and delivered through existing IPA channels to the requesting application
    • [6.1.9] Policies (access control policies) shall (among others) include limiting of access to applications / tools to controlling the editing of configuration files or data.
    • [6.1.10] End policy types supported by the IPA system may include:
      • Sudoers files
      • SELinux policy files
      • XCCDF files
  • [6.2] The policy management and policy delivery mechanisms shall be optimized to reduce:
    • [6.2.1] Number of long lived network connections (if any)
    • [6.2.2] Policy download network traffic (what to cache and how frequently to refresh)
    • [6.2.3] Number of client requests and round trips to determine which policies apply to the machine and need to be downloaded or refreshed
  • [6.3] Policy enforcement
    • [6.3.1] Policy should be enforceable by applications that are not part of IPA (i.e., IPA Policy should serve as a platform)
    • [6.3.2] Policy decisions should be obtainable from a language-neutral source and if possible through standard interface
    • [6.3.3] Policy controls should initially target OS but be capable of controlling applications.
    • [6.3.4] Policy enforcement decision shall be based at least on the following factors:
      • User identity
      • User role
      • System/Machine identity
      • Application/service requesting identity check
      • Resource/service/application being accessed
      • Time of day/date
      • Network location/topology (???)
    • [6.3.5] For the machines (groups of the machines) analyze compliance of the systems to the centrally defined policies. In case the system is not compliant act based on the defined policies.
      • Log event
      • Alert
      • Perform action (remediation operation)
    • [6.3.6] The IPA infrastructure shall provide framework for the pluggable policy checks and actions
  • [6.4] Access Control
    • [6.4.1] Create mechanisms to deliver access control policies to the applications. The policies can be delivered in different ways:
      • [6.4.1.1] Directly via API. Application calls API to perform authorization checks. It is implementation specific whether it is an API that makes the application a direct client of the IPA server itself or a local API that allows application to connect to local IPA service (IPA client component) that abstracts the IPA server capabilities (provide early in the project cycle)
      • [6.4.1.2] Via application specific configuration files
    • [6.4.2] Following applications shall receive access control information (policies) from IPA system. The preferred channel (API vs. File) is application specific and shall be determined based on the application needs and capabilities. Applications are:
      • [6.4.2.1] PAM for needs of GDM, SSH, FTP, Login
      • [6.4.2.2] Apache to perform authorization checks while users access web resources
      • [6.4.2.3] JBoss to perform authorization checks while users access web resources
      • [6.4.2.4] IMAP
      • [6.4.2.5] SMTP
      • [6.4.2.6] iptables
      • [6.4.2.7] ipsec
      • [6.4.2.8] SUDO – for access control and authentication
      • [6.4.2.9] SELinux
    • [6.4.3] Enable reduced scope root accounts
  • [6.5] Delegation
    • [6.5.1] Allow delegation of a subset of administrator privileges to users / roles / applications.
    • [6.5.2] Administrative delegation shall include at least OS privilege, database privilege (MySQL), and JBOSS privilege.
    • [6.6] Need meta group. Group which groups up groups of users, machines, services, hosts
[edit]

7. IPA client

  • [7.1] IPA client is a separately installable package that allows machines to be integrated into the IPA domain
  • [7.2] IPA client shall be supported on:
    • [7.2.1] Red Hat Enterprise Linux 4.8 (32/64)
    • [7.2.1] Red Hat Enterprise Linux 5.3 (32/64)
    • [7.2.2] AIX 5.3
    • [7.2.3] HP-UX 11i v3
    • [7.2.4] Solaris 9, 10 (SPARC/x86/x64)
    • [7.2.5] Suse 10 (32/64)
  • [7.3] IPA client shall be a provider of the IPA services to all applications and services running on the machine
  • [7.4] IPA client shall provide IPA services to the applications regardless whether the machine is connected to the IPA server (server is reachable) or machine is offline (server not reachable)
  • [7.5] IPA must be capable of providing AAA functions to the following explicitly listed applications providing time allows to implement a corresponding plug-in
    • [7.5.1] PAM framework
    • [7.5.2] NSS (Name Service Switch)
    • [7.5.3] SUDO
    • [7.5.4] SELinux
    • [7.5.5] Automount
    • [7.5.6] Netgroups
    • [7.5.7] Linux Desktop (GNOME) (Lower priority)
    • [7.5.8] Apache (Lower priority)
    • [7.5.9] JBoss (Lower priority)
  • [7.6] IPA client installation and configuration shall support following operations:
    • [7.6.1] Enroll – make the machine a part of the IPA domain
    • [7.6.2] Disconnect – remove all the configuration related to the IPA realm
    • [7.6.3] Rebuild – disconnect and then enroll
    • [7.6.4] Uninstall – disconnect and remove software
  • [7.7] IPA Client Connectivity
    • [7.7.1] IPA client configuration shall store information required for the client to connect to IPA server and access all its services (Keberos, LDAP, XML-RPC, Policy download, DNS, Audit)
    • [7.7.2] IPA client software shall automatically discover IPA server configuration and topology and connect to the closest (best) server out of available
    • [7.7.3] IPA server shall automatically fail over to a different IPA server if its “usual” IPA server is not available
    • [7.7.4] IPA client shall effectively determine its online/offline status and automatically reconnect to IPA server when it becomes available
    • [7.7.5] IPA client offline state shall not affect response time of the IPA client service to applications
    • [7.7.6] IPA client shall be capable of caching all necessary information about at least once logged in users to be able to provide them services offline
      • [7.7.6.1] Define and apply IPA centrally managed policies regarding offline entities including;
        • [7.7.6.1.1] For how long the user offline credentials are cached (90 days default)
        • [7.7.6.1.2] What to do if time elapsed
      • [7.7.6.2] IPA client shall download and cache policies required for operation of the applications/services running on the box so that if it goes offline (IPA server becomes unreachable) the applications continue to function without destructions.
      • [7.7.6.3] On reconnect to the IPA server resync/refresh/renew cached credentials, keytabs, certs and other downloaded entities (policies and configuration information for applications) based on the centrally defined and managed policies.
    • [7.7.7] IPA Client shall work correctly whether it is connected to the IPA server via local network or VPN.[36] Post installation, if required by enterprise policy, change the root password on a device to a pre-configured one found during the configuration phase (or possibly randomized). The device is now "owned" by the administrative domain.
  • [7.8] IPA client shell automatically renew user TGT according to the centrally defined polices defined to avoid failures for the operations that take extensive period of time to run
[edit]

8. Migration and Interoperability

  • [8.1] Make it easy to migrate from NIS to IPA
    • [8.1.1] Include basic NIS Server functionality in IPA so that NIS clients can leverage NIS Server
    • [8.1.2] Store NIS information in LDAP back end
    • [8.1.3] Allow NIS information to be loaded into LDAP back end from the existing NIS configuration files
  • [8.2] Manage netgroups in IPA server
    • [8.2.1] Include netgroups response capabilities in IPA as part of NIS service
    • [8.2.2] Store netgroups information in LDAP back end
    • [8.2.3] Allow netgroups information to be loaded into LDAP back end from the existing netgroups configuration files
  • [8.3] Manage automount maps in IPA server
    • [8.3.1] Store automount information in the back end
    • [8.3.2] Allow automount information to be loaded into back end from the existing map files
  • [8.4] Enable existing SUDO configuration files to be loaded into IPA server
  • [8.5] Support IPv6
[edit]

9. Audit

  • [9.1] Centrally collect, store and audit different kinds of the audit information including but not limited to
    • Security events
    • All logs
    • Command logging
    • Every keystroke by a selected group of users
  • [9.2] Audit information from IPA servers (i.e Kerberos, LDAP, CA) must be captured by IPA audit system, aggregated, and stored centrally
  • [9.3] IPA client side portion of the audit system shall collect events from available feeds (Syslog, audit, internal security events, keyboard, other external events - whatever feed provider is installed). There is no requirement to explicitly filter the events coming through the feeds. It is the responsibility of the feed provider to define filtering policies, request them through the IPA client and respect them. IPA client shall just provide a unified interface for the event consolidation and transport
    • [9.3.1] Implement feed provider for audit system
    • [9.3.2] Implement feed provider for syslog
    • [9.3.3] Implement feed provider for internal events
    • [9.3.4] The audit system shall define, manage, and enforce central policies related to the internal event feed (shall include but not limited to: events related to machine, service rename as well as change of other principals)
  • [9.4] Logs shall be consolidated in the central place(s)
  • [9.5] Logs shall be signed to prevent tampering with them in transit
  • [9.6] Log data must be highly compressed
  • [9.7] Audit channels shall be secure (might be SSL; leverage credentials available on the machine – keytab, certs)
  • [9.8] Audit subsystem might take advantage of the AMQP technology
  • [9.9] The audit consolidation topology of the audit subsystem may be different from the replication topology
    • [9.9.1] The topology shall be changeable
    • [9.9.2] The configuration shall be stored in the back end and replicated in the IPA realm
    • [9.9.3] In case of disaster an IPA server can become a new consolidation point
    • [9.9.4] Allow consolidating different feeds in different back end servers
    • [9.9.5] Centrally configure the audit subsystem and its policies
  • [9.10] Enable storage of the audit data in the external pluggable data store (pick one depending on time available)
    • [9.10.1] SQL database
    • [9.10.2] Flat file(s)
  • [9.11] Enable reporting on the audit data
    • [9.11.1] Provide pluggable reporting mechanisms
    • [9.11.2] Allow existing reporting tools to bind into the data store (TBD during implementation)
  • [9.12] Handle disconnected machines. Depending upon the policy either
    • [9.12.1] Cache and forward log events on IPA client
    • [9.12.2] Stop machine function
  • [9.13] Audit information in transit shall adhere to existing audit information standards as much as possible (XDAS)
[edit]

10. Security of the System

  • [10.1] To modify data in IPA, user/process needs to be authenticated and authorized
  • [10.2] Secure the communication between central management store and machines
  • [10.3] Secure the machine - machine communication
[edit]

11. freeRADIUS plug-in

  • [11.1] Support freeRADIUS as a plug in server to IPA (plug-in described above)
  • [11.2] FreeRADIUS Auth Methods
    • [11.2.1] SSL Remote access.
    • [11.2.2] WirelessLAN and VPN
    • [11.2.3] 802.1x based WLAN.
    • [11.2.4] 802.1x LAN. (low priority)
  • [11.3] Enable users to be placed in a RADIUS group.
  • [11.4] Support policy with RADIUS
  • [11.5] Centrally audit
[edit]

12. Active Directory Integration

  • [12.1] Enhanced synch of user identity, group, attributes with Active Directory
[edit]

13. User Identity and Administration Enhancements

  • [13.1] Better Password Aging / Password Policy
  • [13.2] Tombstone
  • [13.3] Directory Server Get Effective Rights
  • [13.4] IPA v2 will have more flexible delegated admin controls the UI should support these
  • [13.5] Admin Approval step before user is able to gain higher priveleges
Retrieved from "http://www.freeipa.com/page/V2BPRD"
Views:  Article Discussion Edit History
Personal tools:  Log in / create account
Toolbox:  What links here Related changes Upload file Special pages Printable version