Fields changed

milestone: NEEDS_TRIAGE => SSSD Deferred

There was a patch proposal sent to the sssd-devel mailing which illustrates the idea and maps uids like Winbind/idmap_rid do:

https://fedorahosted.org/pipermail/sssd-devel/2011-September/007081.html

There was some initial resistance to this but it would seem that there are no fundamental issues with this approach after all, see the thread starting at:

https://fedorahosted.org/pipermail/sssd-devel/2011-November/007621.html

Of course, the patch needs improvements, these items have come up so far:

• a separate configuration option to enable this functionality[[BR]]
• mappings for gids as is now done with uids[[BR]]
• implement mappings the other way around (e.g., for ls(1) et al)[[BR]]
• possibly store the SID to sysdb[[BR]]
• perhaps consider also implementing #995[[BR]]

milestone: SSSD Deferred => NEEDS_TRIAGE
type: defect => enhancement
version: 1.6.1 => master

We will get back to this when we implement the native winbind data provider. After we will re-evaluate this patch. We need to be sure that we have a consistent solution. It is a bit premature at the moment.

milestone: NEEDS_TRIAGE => SSSD 1.8.0
priority: major => minor

Fields changed

milestone: SSSD 1.8.0 => SSSD 1.8 AD Integration NEEDS TRIAGE

Fields changed

component: SSSD => LDAP Provider
milestone: SSSD 1.8 AD Integration NEEDS TRIAGE => SSSD 1.8.0
owner: somebody => sgallagh

Fields changed

rhbz: => [https://bugzilla.redhat.com/show_bug.cgi?id=768168 768168]

Fields changed

blockedby: =>
blocking: =>
milestone: SSSD 1.8.0 => SSSD 1.9.0 NEEDS_TRIAGE

Fields changed

milestone: SSSD 1.9.0 NEEDS_TRIAGE => SSSD 1.9.0
priority: minor => critical

Fields changed

milestone: SSSD 1.9.0 => SSSD 1.9 AD Integration

Fields changed

feature_milestone: =>
milestone: SSSD AD Trust Feature => SSSD AD Extensions Feature

Our plan for this feature is as follows:

We will introduce a configuration option for AD, which will choose between:
1. SSSD will look for RFC2307bis ID attributes and will ignore any entries that are not populated (This is the current behavior and the default).
1. SSSD will ignore RFC2307bis ID attributes and instead will always construct them from the objectSID attribute, using the {{{autorid}}} id-mapping backend, taken from Samba.

We will use autorid with one enhancement (to be submitted to Samba upstream as well). In the event that the domain sid hashes to a value that is already in use, we will use the next available slot in the domain ranges.

cc: => swalter@redhat.com
status: new => assigned

Replying to [comment:11 sgallagh]:

Our plan for this feature is as follows:

We will introduce a configuration option for AD, which will choose between:
1. SSSD will look for RFC2307bis ID attributes and will ignore any entries that are not populated (This is the current behavior and the default).

On this point we may need to lookup this info from the global catalog instead of the normal LDAP tree in order to get info for the whole forest.

Fields changed

patch: 0 => 1

Fields changed

milestone: SSSD AD Extensions Feature => SSSD 1.9.0 beta 1

Fixed by:

• 4f07a5b
• d38cd6a
• 817b1bc
• 505e75b
• 13c88d6
• d0a10e5
• 8538f3d
• 2fd5864
• 4f3fd1f
• 45f75fc
• 1a79825
• 28f9836
• 2aae75b
• c0dc67f
• 532eb49
• 58d02e0
• 3f2fa4c
• 8be5e44
• c20a339
• a23919e
• aef21bb

resolution: => fixed
status: assigned => closed

One additional fix for endianness issues:
- 9fd2775

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/2038

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.