ID Range: new option for private groups#

Description#

SSSD provides an option to tune its behavior regarding private groups: auto_private_groups. Currently, this option is designed to work with ldap or ad providers and doesn’t behave properly when the provider is ipa and a trust is configured between IPA and AD.

The goal of this RFE is to propose the same setting at the trust level.

References:

  • BZ 1688267 (ipa) [RFE] IPA to allow setting a new range type

  • BZ 1649464 (sssd) auto_private_groups not working as expected with posix ipa/ad trust

  • SSSD #4216 [RFC] IPA: allow switching off user private groups for trusted AD users

High level overview#

Current auto private group behavior#

The auto_private_group setting can be configured in the DOMAIN section of sssd.conf.

The auto_private_groups setting can take any of these 3 values:

  • true: always create a user private group from the user’s UID number. If a GID number already exists, it is ignored.

  • false: always use the users’ primary GID number. A group with this GID number must already exist.

  • hybrid: a primary group is generated if the entry has UID = GID but there is no group with this GID. If UID and GID are different, a group with this GID number must already exist.

Transposition to AD trust environments#

Scope#

When an IPA provider is used, with an AD trust, the UIDs and GIDs belong to different ID ranges:

  • The users defined in IPA contain a uidNumber and gidNumber attribute, which must fit in the ipa-local range

  • There are 2 possibilities for the users defined in AD:

    • If they contain a uidNumber and gidNumber, the trust is established with a ipa-ad-trust-posix range and uidNumber and gidNumber values are taken from the user entry on AD

    • If they don’t define uidNumber/gidNumber, the trust is established with a ipa-ad-trust range and SSSD computes uidNumber=gidNumber from the value of the user SID.

As there can be multiple ranges defined for a single ipa provider (for instance if multiple trusts are set), the auto_private_groups setting cannot have a domain scope and needs to be set at the id range level.

=> The setting needs to be added as an option to ipa-ad-trust-posix and ipa-ad-trust ranges.

Default behavior#

When the auto_private_groups option is not explicitly set, it uses a default value:

  • For ipa-ad-trust-posix range: default value = false. This means that the uidNumber and gidNumber of the AD entry are always used, and a group with the gidNumber must already exist.

  • For ipa-ad-trust range: default value = true. This means that the uidNumber is mapped from the entry SID, the gidNumber is always set to the same value and a private group is always created.

User stories#

User story #1: AD trust with posix attributes, gidNumber corresponding to an existing group#

As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users contain posix attributes (uidNumber and gidNumber) that I want to use on IPA side, and the gidNumber corresponds to an existing AD group.

On any IPA client, the id command must return the uidNumber and gidNumber stored in AD:

# id aduser@AD-DOMAIN.COM
uid=uidNumber(aduser@ad-domain.com) gid=gidNumber(adgroup@ad-domain.com) groups=gidNumber(adgroup@ad-domain.com),...

If the gidNumber does not correspond to an existing group, the entry is not resolved.

User story #2: AD trust with posix attributes, gidNumber not corresponding to any group#

As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users contain posix attributes (uidNumber and gidNumber) but there is no group with the corresponding gidNumber. On any IPA client, the id command must return the uidNumber stored in AD:

# id aduser@AD-DOMAIN.COM
uid=uidNumber(aduser@ad-domain.com) gid=uidNumber(aduser@ad-domain.com) groups=uidNumber(aduser@ad-domain.com),...

User story #3: AD trust with SID mapping, private group created with the uidNumber#

As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users are not posix, and their SID is mapped to an uidNumber and gidNumber on IPA. The gidNumber is equal to the uidNumber and a corresponding private group is generated. On any IPA client, the id command must return the value computed from the SID stored in AD:

# id aduser@AD-DOMAIN.COM
uid=mappedValue(aduser@ad-domain.com) gid=mappedValue(aduser@ad-domain.com) groups=mappedValue(aduser@ad-domain.com),...

User story #4: AD trust with SID mapping, primary group reusing the primaryGroupID#

As an administrator, I want to establish a trust between my IPA domain and my AD domain. My AD users are not posix, and their SID is mapped to an uidNumber on IPA. I want to compute the gidNumber from the RID of the AD entry’s primaryGroupID. On any IPA client, the id command must return the value computed from the SID stored in AD:

# id aduser@AD-DOMAIN.COM
uid=mappedValue(aduser@ad-domain.com) gid=mappedValuePrimaryGroupID(adgroup@ad-domain.com) groups=mappedValuePrimaryGroupID(adgroup@ad-domain.com),...

Detailed behavior#

ipa-ad-trust-posix#

When the range has the ipa-ad-trust-posix type, the uidNumber and gidNumber are taken from the AD entry. Currently, if the gidNumber does not correspond to an existing group, the user cannot be resolved.

This situation can be fixed by setting

  • auto_private_groups=true: a private group is created with gidNumber = uidNumber.

  • auto_private_group=hybrid: if uidNumber=gidNumber but there is no group with this gidNumber, a private group is created with the gidNumber

auto_private_groups

true

false

hybrid

AD User entry with uidNumber=1000 gidNumber=missing

uid=1000 gid=1000 +private group

Not resolvable

Not resolvable

AD user entry with uidNumber=1000 gidNumber=2000 Group does not exist

uid=1000 gid=1000 +private group

Not resolvable

Not resolvable

AD User entry with uidNumber=1000 gidNumber=1000 Group does not exist

uid=1000 gid=1000 +private group

Not resolvable

uid=1000 gid=1000 +private group

AD User entry with uidNumber=1000 gidNumber=2000 Group exists

uid=1000 gid=1000 +private group

uid=1000 id=2000

uid=1000 gid=2000

ipa-ad-trust#

When the range has the ipa-ad-trust type, the uidNumber and gidNumber are computed from the entry’s SID. They currently both take the same value.

There are situations where the customer doesn’t want this behavior but would prefer to use the primaryGroupID set in the AD entry as gidNumber. This can be achieved by setting auto_private_groups=false and would solve the ticket SSSD #4216.

auto_private_groups

true

false

hybrid

AD User entry with SID mapped to 1000 primaryGroupID mapped to 2000

uid=1000 gid=1000 +private group

uid=1000 gid=2000

uid=1000 gid=2000

Design#

IPA part#

Schema#

The LDAP schema for ID ranges needs to be modified:

  • Creation of a new attribute to store the autoprivategroups option (with a DirectoryString type, single valued)

  • Modification of the ipaTrustedADDomainRange objectclass in order to allow the new attribute as OPTIONAL

    attributeTypes: (2.16.840.1.113730.3.8.23.6 NAME 'ipaAutoPrivateGroup' DESC 'Auto private groups' EQUALITY caseIgnoreIA5Match SUBSTR caseIgnoreIA5SubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 X-ORIGIN 'IPA v3' )
    objectClasses: (2.16.840.1.113730.3.8.12.17 NAME 'ipaTrustedADDomainRange' SUP ipaIDrange STRUCTURAL MUST ( ipaBaseRID $ ipaNTTrustedDomainSID ) MAY ( ipaAutoPrivateGroup ) X-ORIGIN 'IPA v3' )
    

Trust establishment#

ipa trust-add command also internally creates an idrange object but the decision is NOT to add new parameters for auto-private-range at this level. The rationale is that ipa trust-add currently provides only a subset of the idrange options (for instance it doesn’t allow to set –rid-base) and the finer configuration options are set using ipa idrange-add or ipa idrange-mod.

When the sysadmin wants to set –auto-private-range, he needs to do

  • ipa trust-add [options] AD-REALM: this command also creates the idrange AD-REALM_id_range

  • ipa idrange-mod –auto-private-groups=value AD-REALM_id_range

  • and finally reset SSSD cache: sss_cache -E

Upgrade#

There is no need to handle the new option during upgrade: SSSD must be able to assign a default value to auto_private_groups if none is set in the id range. The default value is picked according to the range type, in accordance with the content of sssd.conf man page:

  • For ipa-ad-trust-posix range: default value = false.

  • For ipa-ad-trust range: default value = true.

The schema upgrade does not require specific actions: the new attribute is optional in the existing object class and the schema is replicated to the other replicas in the topology as soon as one of them is upgraded with the new schema.