Ticket #996 (closed enhancement: fixed)

Opened 3 years ago

Last modified 2 years ago

RFE: Allow Constructing uid from Active Directory objectSid

Reported by: myllynen Owned by: sgallagh
Priority: critical Milestone: SSSD 1.9.0 beta 1
Component: LDAP Provider Version: master
Keywords: Cc: swalter@…
Blocked By: Blocking:
Tests Updated: no Coverity Bug:
Patch Submitted: yes Red Hat Bugzilla: 768168
Design link:
Feature Milestone:
Design review: Fedora test page:
Chosen: Candidate to push out:
Release Notes:

Description

In Active Directory with no Identity Management for Unix Role Service enabled there is no uid attribute available but the user id could be constructed from objectSid. This is what winbind's idmap_rid(8) and nss-pam-ldapd do:

http://www.samba.org/samba/docs/man/manpages-3/idmap_rid.8.html
http://lists.arthurdejong.org/nss-pam-ldapd-users/2011/msg00213.html
http://arthurdejong.org/viewvc/nss-pam-ldapd?view=revision&revision=1425

It would make using SSSD against AD easier if something like this would be available in SSSD, too.

Change History

comment:1 Changed 3 years ago by dpal

  • Milestone changed from NEEDS_TRIAGE to SSSD Deferred

comment:2 Changed 2 years ago by myllynen

  • Milestone changed from SSSD Deferred to NEEDS_TRIAGE
  • Version changed from 1.6.1 to master
  • Type changed from defect to enhancement

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
  • mappings for gids as is now done with uids
  • implement mappings the other way around (e.g., for ls(1) et al)
  • possibly store the SID to sysdb
  • perhaps consider also implementing #995

comment:3 Changed 2 years ago by dpal

  • Milestone changed from NEEDS_TRIAGE to SSSD 1.8.0
  • Priority changed from major to minor

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.

comment:4 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.8.0 to SSSD 1.8 AD Integration NEEDS TRIAGE

comment:5 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.8 AD Integration NEEDS TRIAGE to SSSD 1.8.0
  • Component changed from SSSD to LDAP Provider
  • Owner changed from somebody to sgallagh

comment:6 Changed 2 years ago by dpal

  • Red Hat Bugzilla set to [https://bugzilla.redhat.com/show_bug.cgi?id=768168 768168]

comment:7 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.8.0 to SSSD 1.9.0 NEEDS_TRIAGE

comment:8 Changed 2 years ago by dpal

  • Milestone changed from SSSD 1.9.0 NEEDS_TRIAGE to SSSD 1.9.0
  • Priority changed from minor to critical

comment:9 Changed 2 years ago by sgallagh

  • Milestone changed from SSSD 1.9.0 to SSSD 1.9 AD Integration

comment:10 Changed 2 years ago by dpal

  • Milestone changed from SSSD AD Trust Feature to SSSD AD Extensions Feature

comment:11 follow-up: ↓ 12 Changed 2 years ago by sgallagh

  • Cc swalter@… added
  • Status changed from new to assigned

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).
  2. 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.

comment:12 in reply to: ↑ 11 Changed 2 years ago by simo

Replying to 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.

comment:13 Changed 2 years ago by sgallagh

  • Patch Submitted set

comment:14 Changed 2 years ago by sgallagh

  • Milestone changed from SSSD AD Extensions Feature to SSSD 1.9.0 beta 1

comment:16 Changed 2 years ago by sgallagh

One additional fix for endianness issues:

Note: See TracTickets for help on using tickets.