From Fedora Project Wiki
No edit summary
 
(16 intermediate revisions by 3 users not shown)
Line 3: Line 3:
== Summary ==
== Summary ==
The new major release of IPA will have a number of new features:
The new major release of IPA will have a number of new features:
* trusts to Active Directory domains,  
* '''Please note, this feature will not be ready in the F17 timeframe and will be move to the next release''' trusts to Active Directory domains,  
* SE Linux management,
* SE Linux management,
* SSH public keys management,
* SSH public keys management,
Line 13: Line 13:
* Name: [[User:sbose| Sumit Bose]]
* Name: [[User:sbose| Sumit Bose]]
* Email: sbose@redhat.com
* Email: sbose@redhat.com
* '''please add more, if needed'''
* Name: [[User:abbra| Alexander Bokovoy]]
* Email: abokovoy@redhat.com
* Name: [[User:jcholast| Jan Cholasta (SSH key management)]]
* Email: jcholast@redhat.com
* Name: [[User:jzeleny| Jan Zelený (SELinux management)]]
* Email: jzeleny@redhat.com


== Current status ==
== Current status ==
* Targeted release: [[Releases/17 | Fedora 17 ]]
* Targeted release: [[Releases/17 | Fedora 17 ]]
* Last updated: 2012-01-20
* Last updated: 2012-02-07
* Percentage of completion: 50%
* Percentage of completion: 100%


<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
<!-- CHANGE THE "FedoraVersion" TEMPLATES ABOVE TO PLAIN NUMBERS WHEN YOU COMPLETE YOUR PAGE. -->
Line 28: Line 33:


=== SSH public keys management ===
=== SSH public keys management ===
SSH public keys for users and hosts can be stored in FreeIPA. Upon login, keys are fetched from FreeIPA server by SSSD and cached/used for verification. HBAC rules are used to augment access on per-host per-service bases and FreeIPA tools are used to manage user's public keys and impersonation accounts.
SSH public keys for users and hosts can be stored in FreeIPA. Upon login, keys are fetched from FreeIPA server by SSSD and cached/used for verification. HBAC rules are used to augment access on per-host per-service bases and FreeIPA tools are used to manage user's public keys.


=== Trust to Active Directory Domains ===
=== ''Moved to next release'' -- Trust to Active Directory Domains ===
Currently FreeIPA uses ''winsync'' to allow users from an Active Directory domain to access resources in the IPA domain. To achieve this ''winsync'' replicates the user and group data from an Active Directory server to the local server and tries to keep them in sync.
Currently FreeIPA uses ''winsync'' to allow users from an Active Directory domain to access resources in the IPA domain. To achieve this ''winsync'' replicates the user and group data from an Active Directory server to the local server and tries to keep them in sync.


With the new trust feature the user and group data is read from the Active Directory server as it is needed. Additionally Kerberos cross realm trust is set up which allows Single-Sign-On between the Active Directory and the IPA domain. I.e. a user from the Active Directory Domain can access kerberized resources from the IPA domain without being asked for a password.
With the new trust feature the user and group data is read from the Active Directory server as it is needed. Additionally Kerberos cross realm trust is set up which allows Single-Sign-On between the Active Directory and the IPA domain. I.e. a user from the Active Directory Domain can access kerberized resources from the IPA domain without being asked for a password.
 


== Benefit to Fedora ==
== Benefit to Fedora ==
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
<!-- What is the benefit to the platform?  If this is a major capability update, what has changed?  If this is a new feature, what capabilities does it bring? Why will Fedora become a better distribution or project because of this feature?-->
* Trust to Active Directory Domains will have the following benefits
* '''Moved to next release''' Trust to Active Directory Domains will have the following benefits:
** Single-Sign-On between the Active Directory and IPA domain
** Single-Sign-On between the Active Directory and IPA domain
** Allow users from the IPA domain (Linux users) to access resources from the Active Directory domain
** Allow users from the IPA domain (Linux users) to access resources from the Active Directory domain
** No need to set POSIX attributes in the Active Directory domain
** No need to set POSIX attributes in the Active Directory domain
* SSH public keys management will have the following benefits:
** Centralized management of SSH host identity information
** Allow IPA users to authenticate using SSH public keys in the IPA domain


== Scope ==
== Scope ==
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
<!-- What work do the developers have to accomplish to complete the feature in time for release?  Is it a large change affecting many parts of the distribution or is it a very isolated change? What are those changes?-->
* Trust to Active Directory Domains requires the following changes:
* '''Moved to next release''' Trust to Active Directory Domains requires the following changes:
** FreeIPA have to be extended to store and manage the needed data to maintain the trust to the Active Directory domain and have to provide tools to set up the trust
** FreeIPA have to be extended to store and manage the needed data to maintain the trust to the Active Directory domain and have to provide tools to set up the trust
** SSSD needs to be able to query the IPA server to resolve users and groups from the Active Directory domain
** SSSD needs to be able to query the IPA server to resolve users and groups from the Active Directory domain
** Samba4 have to be updated to a recent version to allow FreeIPA to use libraries and binaries to set up and maintain the trust to an Active Directory domain
** Samba4 have to be updated to a recent version to allow FreeIPA to use libraries and binaries to set up and maintain the trust to an Active Directory domain
* SSH public keys management requires the following changes:
** FreeIPA has to allow storage of SSH public keys for users and hosts and provide tools to manage them
** SSSD has to be able to acquire the keys from the IPA server and provide an interface to use them in OpenSSH


== How To Test ==
== How To Test ==
Line 64: Line 74:
3. What are the expected results of those actions?
3. What are the expected results of those actions?
-->
-->
=== ''Moved to next release'' Trust to Active Directory Domains ===
* Detailed information about how to set up and test Trusts to Active Directory domains can be found at [http://freeipa.org/page/IPAv3_testing_AD_trust IPAv3 testing AD Trust]
* Detailed information about how to set up and test Trusts to Active Directory domains can be found at [http://freeipa.org/page/IPAv3_testing_AD_trust IPAv3 testing AD Trust]
=== SELinux ===
=== SELinux ===
* install FreeIPA server
* install FreeIPA server
Line 77: Line 89:
* try to log in
* try to log in
* a file should be created in /etc/selinux/<username> which contains the mapping as set by ipa selinuxusermap-add command
* a file should be created in /etc/selinux/<username> which contains the mapping as set by ipa selinuxusermap-add command
=== SSH public keys management ===
* install FreeIPA server
* check that the server's host keys got stored in IPA with ipa host-show command
* add a user and add his/her SSH public keys with ipa user-add command
* try to log in the server with SSH


== User Experience ==
== User Experience ==
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
<!-- If this feature is noticeable by its target audience, how will their experiences change as a result?  Describe what they will see or notice. -->
* If a trust is created between an Active Directory and an IPA domain
* '''Moved to next release''' If a trust is created between an Active Directory and an IPA domain
** Users from the Active Directory Domain can access resources of the IPA domain and the other way round
** Users from the Active Directory Domain can access resources of the IPA domain and the other way round
** For kerberized services single-sign-on is possilbe
** For kerberized services single-sign-on is possible


== Dependencies ==
== Dependencies ==
Line 99: Line 116:
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The Fedora Release Notes inform end-users about what is new in the release.  Examples of past release notes are here: http://docs.fedoraproject.org/release-notes/ -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
<!-- The release notes also help users know how to deal with platform changes such as ABIs/APIs, configuration or data file formats, or upgrade concerns.  If there are any such changes involved in this feature, indicate them here.  You can also link to upstream documentation if it satisfies this need.  This information forms the basis of the release notes edited by the documentation team and shipped with the release. -->
* With Fedora 17 it would be possible to create a trust relationship between an IPA and an Active Directory domain which would allow users from one domain to access resource of the other domain.
* '''Moved to next release''' With Fedora 17 it would be possible to create a trust relationship between an IPA and an Active Directory domain which would allow users from one domain to access resource of the other domain.


== Comments and Discussion ==
== Comments and Discussion ==
Line 105: Line 122:




[[Category:FeatureReadyForWrangler]]
[[Category:FeatureAcceptedF17]]
<!-- When your feature page is completed and ready for review -->
<!-- When your feature page is completed and ready for review -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- remove Category:FeaturePageIncomplete and change it to Category:FeatureReadyForWrangler -->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- After review, the feature wrangler will move your page to Category:FeatureReadyForFesco... if it still needs more work it will move back to Category:FeaturePageIncomplete-->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->
<!-- A pretty picture of the page category usage is at: https://fedoraproject.org/wiki/Features/Policy/Process -->

Latest revision as of 11:35, 7 February 2012

New Features of IPA v3

Summary

The new major release of IPA will have a number of new features:

  • Please note, this feature will not be ready in the F17 timeframe and will be move to the next release trusts to Active Directory domains,
  • SE Linux management,
  • SSH public keys management,

Owner

Current status

  • Targeted release: Fedora 17
  • Last updated: 2012-02-07
  • Percentage of completion: 100%


Detailed Description

SE Linux management

FreeIPA provides means to store mapping between SE Linux contexts and users on per-host per-user basis. When user logs in into the FreeIPA-enrolled host, appropriate SE Linux context is fetched from FreeIPA server and used to set up proper security context at the host.

SSH public keys management

SSH public keys for users and hosts can be stored in FreeIPA. Upon login, keys are fetched from FreeIPA server by SSSD and cached/used for verification. HBAC rules are used to augment access on per-host per-service bases and FreeIPA tools are used to manage user's public keys.

Moved to next release -- Trust to Active Directory Domains

Currently FreeIPA uses winsync to allow users from an Active Directory domain to access resources in the IPA domain. To achieve this winsync replicates the user and group data from an Active Directory server to the local server and tries to keep them in sync.

With the new trust feature the user and group data is read from the Active Directory server as it is needed. Additionally Kerberos cross realm trust is set up which allows Single-Sign-On between the Active Directory and the IPA domain. I.e. a user from the Active Directory Domain can access kerberized resources from the IPA domain without being asked for a password.

Benefit to Fedora

  • Moved to next release Trust to Active Directory Domains will have the following benefits:
    • Single-Sign-On between the Active Directory and IPA domain
    • Allow users from the IPA domain (Linux users) to access resources from the Active Directory domain
    • No need to set POSIX attributes in the Active Directory domain
  • SSH public keys management will have the following benefits:
    • Centralized management of SSH host identity information
    • Allow IPA users to authenticate using SSH public keys in the IPA domain

Scope

  • Moved to next release Trust to Active Directory Domains requires the following changes:
    • FreeIPA have to be extended to store and manage the needed data to maintain the trust to the Active Directory domain and have to provide tools to set up the trust
    • SSSD needs to be able to query the IPA server to resolve users and groups from the Active Directory domain
    • Samba4 have to be updated to a recent version to allow FreeIPA to use libraries and binaries to set up and maintain the trust to an Active Directory domain
  • SSH public keys management requires the following changes:
    • FreeIPA has to allow storage of SSH public keys for users and hosts and provide tools to manage them
    • SSSD has to be able to acquire the keys from the IPA server and provide an interface to use them in OpenSSH

How To Test

Moved to next release Trust to Active Directory Domains

  • Detailed information about how to set up and test Trusts to Active Directory domains can be found at IPAv3 testing AD Trust

SELinux

  • install FreeIPA server
  • add a user with ipa user-add command
  • setup PAM and NSS to use SSSD for authentication
  • setup sssd to connect to the ipa server and user it as id and auth provider
  • try to log in (and change your password if asked to)
    • if this works, then initial setup is complete
  • log out
  • add SELinux user map which applies to the user/host pair by ipa selinuxusermap-add command
  • setup SSSD to use the IPA server as session provider
  • try to log in
  • a file should be created in /etc/selinux/<username> which contains the mapping as set by ipa selinuxusermap-add command

SSH public keys management

  • install FreeIPA server
  • check that the server's host keys got stored in IPA with ipa host-show command
  • add a user and add his/her SSH public keys with ipa user-add command
  • try to log in the server with SSH

User Experience

  • Moved to next release If a trust is created between an Active Directory and an IPA domain
    • Users from the Active Directory Domain can access resources of the IPA domain and the other way round
    • For kerberized services single-sign-on is possible

Dependencies

  • for Trust to Active Directory domains a recent and extended version of the samba4 package is needed.

Contingency Plan

None necessary, revert to previous release behaviour.

Documentation

  • IPAv3 testing AD Trust describes the steps how to set up a trust relationship to an Active Directory domain and how to use it.

Release Notes

  • Moved to next release With Fedora 17 it would be possible to create a trust relationship between an IPA and an Active Directory domain which would allow users from one domain to access resource of the other domain.

Comments and Discussion