Jump to: navigation, search

V3/Use posix attributes defined in AD


Overview

The first implementation of the trusts solution takes SID of the user entry and uses a special algorithm to create unique UID for the user. The similar approach is used for GID. This works fine for the deployments that do not have POSIX attributes defined in AD.

Use Cases

In the cases when POSIX attributes are defined in AD there are usually already clients that leverage these attributes so switching to the SID -> UID/GID model is not acceptable. Instead IPA and SSSD should be able to respect the POSIX attributes defined in the AD.

Design

Exteding ID Range schema to support various types of ID Ranges

Schema

The schema has been extended to support various range types. A new attribute ipaRangeType has been added to the schema.

attributeTypes: (2.16.840.1.113730.3.8.11.41 NAME 'ipaRangeType' DESC 'Range type' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v3' )

The ipaIDrange objectclass now requires the ipaRangeType attribute:

objectClasses: (2.16.840.1.113730.3.8.12.15 NAME 'ipaIDrange' ABSTRACT MUST ( cn $ ipaBaseID $ ipaIDRangeSize $ ipaRangeType ) X-ORIGIN 'IPA v3' )

Allowed values

The ipaRangeType must obtain exactly one of the following values:

  • ipa-local for a local domain range
  • ipa-ad-winsync for Active Directory winsync range
  • ipa-ad-trust: for Active Directory domain range
  • ipa-ad-trust-posix for Active Directory trust range with POSIX attributes
  • ipa-ipa-trust for IPA trust range

This is enforced via CLI and UI validation, not in LDAP itself.

Detecting the ID range type for the AD trusted domain

To avoid the need of specifying the range parameters, such as type, range size and base, we query the AD DC.

Depending on whether the users/groups defined have specified UID and GID POSIX attributes, we create a range of appropriate type during the execution of trust-add command.

Connecting to the AD

This code will need to access AD Global Catalog service which implies authentication. Such authentication should be done using Kerberos ticket with MS-PAC attached, or trusted account like we currently do.

MS-PAC is not currently attached to HTTP/fqdn or host/fqdn tickets and we cannot use user's ticket due to fact that our KDC does not allow wide open S42Proxy relay to other domain for HTTP/fqdn. See the related ticket: https://fedorahosted.org/freeipa/ticket/3651

Obtaining information on use of POSIX attributes in AD

Information on the can be obtained conducting the following ldapsearch:

# <NIS of directly joined domain>, ypservers, ypServ30, RpcServices, System, <directly joined domain>
dn: CN=idm,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=idm,DC=com
objectClass: top
objectClass: msSFU30DomainInfo
cn: idm
distinguishedName: CN=idm,CN=ypservers,CN=ypServ30,CN=RpcServices,CN=System,DC=idm,DC=com
instanceType: 4
whenCreated: 20130625220322.0Z
whenChanged: 20130626190645.0Z
uSNCreated: 53308
uSNChanged: 61507
showInAdvancedViewOnly: TRUE
name: idm
objectGUID:: 7ntK3glNqE2KGmHY1SePWQ==
objectCategory: CN=msSFU-30-Domain-Info,CN=Schema,CN=Configuration,DC=idm,DC=com
dSCorePropagationData: 16010101000000.0Z
msSFU30MasterServerName: tbad
msSFU30OrderNumber: 10000
msSFU30Domains: idm
msSFU30MaxGidNumber: 10001
msSFU30MaxUidNumber: 10002

ID base detection

Attribute msSFU30OrderNumber holds the base from which AD starts automatically assigning UID/GID numbers. Please note that any manual intervention will not be reflected in this attribute, so changing an user's UID to 9800 manually will not change the value of this attribute.

Range size detection

Attributes msSFU30MaxUidNumber and msSFU30MaxGidNumber hold the value of next available UID/GID.

Detecting the range type

When dealing with the AD trust, we need to only decide between ipa-ad-trust type and ipa-ad-trust-posix type.

We can use presence of msSFU30MaxUidNumber and msSFU30MaxGidNumber attributes as an indicator that there exists an user with POSIX attributes defined.

Implementation

N/A

Feature Management

UI

TODO: ipaRangeType needs to be made available via UI. https://fedorahosted.org/freeipa/ticket/3759

TODO: range_type needs to be made available via UI. https://fedorahosted.org/freeipa/ticket/3049

CLI

idrange-add

An --type option has been added to the idrange-add command. Note that idrange-mod does not have this option. Since --type corrseponds to ipaRangeType attribute, the allowed value is any of the allowed values for ipaRangeType attribute.

trust-add

An --range-type option has been added to the trust-add command. All range types except ipa-local are allowed as values. Further validation is based on the trust type. For AD trust, only one of ipa-ad-trust or ipa-ad-trust-posix is allowed.

Please note that setting this attribute overrides any detection-based decision that is otherwise performed. You can set ipa-ad-trust-posix range type using this option for a trust with AD which does not have IdM for Unix support and therefore would not get any users from the AD. The reasoning behind this behaviour is that admin should have authoritative way to set the range type, since the detection might fail. Generally, you should not need to force the range type using the --range-type option.

Major configuration options and enablement

N/A

Replication

N/A

Updates and Upgrades

On package update (or whenever ipa-upgradeconfig is ran), all ID ranges that do not have the ipaRangeType attribute set, have the attribute value filled in according to their objectclass:

  • ranges with ipatrustedaddomainrange objectclass are assigned ipa-ad-trust type
  • ranges with ipadomainidrange objectclass are assigned ipa-local type

Dependencies

N/A

External Impact

N/A

Backup and Restore

N/A

Test Plan

Test scenarios that will be transformed to test cases for FreeIPA Continuous Integration during implementation or review phase.

Common assumptions

  • FreeIPA server: ipa.example.org
  • Active Directory: ad.example.org

These tests assume AD with POSIX support. More detailed info about the particular setup steps can be found in the test cases below.

Test case: Leverage POSIX attributes defined in AD

Autotest

{{{autotest}}}

Setup

  1. Setup an Active Directory server (2008 R2 or above).
  2. Install Services for Identity Management for UNIX Components:
    1. Follow the article http://technet.microsoft.com/en-us/library/cc731178.aspx
    2. Restart the Active Directory.
  3. Add a group with POSIX attributes defined to Active Directory:
    1. Start Active Directory Users and Computers tool.
    2. Select Users folder, open context menu and select New -> Group
    3. Create a new group with the name testgroup (keep default settings, that is Global scope and type security)
    4. Open the context menu for the group and select Properties.
    5. Select UNIX Attributes tab
    6. Choose NIS domain AD and fill in the GID 10047.
  4. Add a user with POSIX attributes defined to Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, uset testuser as a logon name.
    3. Create a password for the user (uncheck the "User must change password on the next logon" checkbox). By the default complexity requirements, the password must use at least three character classes, i.e. Secret123.
    4. Open the context menu for the user and select Properties.
    5. Select UNIX Attributes tab
    6. Choose NIS domain AD and fill in the UID 10042 and corresponding GID for testgroup.
  5. Add a user without POSIX attributes defined to Active Directory:
    1. Select Users folder, open context menu and select New -> User.
    2. Fill in the First and last name, use nonposixuser as a logon name.
    3. Create a password for the user (uncheck the "User must change password on the next logon" checkbox). By the default complexity requirements, the password must use at least three character classes, i.e. Secret123.
  6. Setup an IPA server with AD trust support:
    1. Run ipa-server-install
    2. Run ipa-adtrust-install
  7. Setup proper DNS records both on AD and IPA server
  8. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org

Actions

  1. Add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password
  2. Examine the created range:
    1. ipa idrange-find
  3. Test the UID assigned to the testuser
    1. getent passwd testuser@AD.EXAMPLE.ORG
  4. Test that user without POSIX attributes defined in the AD is not showing up
    1. getent passwd nonposixuser@AD.EXAMPLE.ORG

Expected results

  1. Trust should be estabilished and verified.
  2. There should be 2 ranges, IPA.EXAMPLE.ORG_id_range and AD.EXAMPLE.ORG_id_range.
    1. AD.EXAMPLE.ORG_id_range should have the following properties:
      1. Range size: at least 200 000.
      2. Range type: Active Directory trust range with POSIX attributes
  3. User should have the UID we defined in the AD. GID should belong to the testgroup.
  4. User should not show up, even though it is defined in the Active Directory.

Test case: Enforce ipa-ad-trust-posix range-type when adding the trust to the AD with POSIX support

Autotest

{{{autotest}}}

Setup

  1. Setup an AD with POSIX support as described in testcase "Leverage POSIX attributes defined in AD"
  2. Run ipa-server-install
  3. Run ipa-adtrust-install
  4. Setup proper DNS records both on AD and IPA server
  5. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org

Actions

  1. Add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-ad-trust-posix
  2. Examine the created range:
    1. ipa idrange-find
  3. Test the UID assigned to the testuser
    1. getent passwd testuser@AD.EXAMPLE.ORG
  4. Test that user without POSIX attributes defined in the AD is not showing up
    1. getent passwd nonposixuser@AD.EXAMPLE.ORG

Expected results

  1. Trust should be estabilished and verified.
  2. There should be 2 ranges, IPA.EXAMPLE.ORG_id_range and AD.EXAMPLE.ORG_id_range.
    1. AD.EXAMPLE.ORG_id_range should have the following properties:
      1. Range size: at least 200 000.
      2. Range type: Active Directory trust range with POSIX attributes
  3. User should have the UID we defined in the AD. GID should belong to the testgroup.
  4. User should not show up, even though it is defined in the Active Directory.

Test case: Enforce ipa-ad-trust range-type when adding the trust to the AD with POSIX support

Autotest

{{{autotest}}}

Setup

  1. Setup an AD with POSIX support as described in testcase "Leverage POSIX attributes defined in AD"
  2. Run ipa-server-install
  3. Run ipa-adtrust-install
  4. Setup proper DNS records both on AD and IPA server
  5. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org

Actions

  1. Add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-ad-trust
  2. Examine the created range:
    1. ipa idrange-find
  3. Test the UID assigned to the testuser
    1. getent passwd testuser@AD.EXAMPLE.ORG

Expected results

  1. Trust should be estabilished and verified.
  2. There should be 2 ranges, IPA.EXAMPLE.ORG_id_range and AD.EXAMPLE.ORG_id_range.
    1. AD.EXAMPLE.ORG_id_range should have the following properties:
      1. Range size: at least 200 000.
      2. Range type: Active Directory trust range
  3. User should not have the UID we defined in the AD, but rather one generated from SID.

Test case: Check range size grows proportionally to the number of users

Autotest

{{{autotest}}}

Setup

  1. Setup an AD with POSIX support as described in testcase "Leverage POSIX attributes defined in AD"
  2. Setup 300 000 users on the AD
    1. This will need to be done using PowerShell script
  3. Run ipa-server-install
  4. Run ipa-adtrust-install
  5. Setup proper DNS records both on AD and IPA server
  6. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org

Actions

  1. Add the trust:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-ad-trust-posix
  2. Examine the created range:
    1. ipa idrange-find
  3. Test the UID assigned to the random subset of the users in the AD
    1. getent passwd testuser47@AD.EXAMPLE.ORG

Expected results

  1. Trust should be estabilished and verified.
  2. There should be 2 ranges, IPA.EXAMPLE.ORG_id_range and AD.EXAMPLE.ORG_id_range.
    1. AD.EXAMPLE.ORG_id_range should have the following properties:
      1. Range size: at least 400 000.
      2. Range type: Active Directory trust range with POSIX attributes
  3. User should have the UID we defined in the AD. GID should belong to the testgroup.

Test case: Check proper handling of improper range types

Autotest

{{{autotest}}}

Setup

  1. Setup an AD with POSIX support as described in testcase "Leverage POSIX attributes defined in AD"
  2. Run ipa-server-install
  3. Run ipa-adtrust-install
  4. Setup proper DNS records both on AD and IPA server
  5. Make sure that the time with the AD is synchronized. Otherwise the AD KDC might not talk with FreeIPA since the clock skew might be too great.
    1. ntpdate dc.ad.example.org

Actions

  1. Try to add the trust with invalid range types:
    1. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-local
    2. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-ipa-trust
    3. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type ipa-ad-winsync
    4. ipa trust-add --type=ad ad.example.org --admin Administrator --password --range-type @!bad"type

Expected results

  1. All attempts to add the trust should fail.

RFE Author

User:Tbabej