#996 RFE: Allow Constructing uid from Active Directory objectSid

Created 5 years ago by myllynen
Modified a day ago

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 [[BR]]
http://lists.arthurdejong.org/nss-pam-ldapd-users/2011/msg00213.html [[BR]]
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.

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

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:

  • 4f07a5ba197b902afd3a785baf6bd9967f50dfd2
  • d38cd6a211d3b68036ceb7bc875f832433afd035
  • 817b1bcafff27cc67630dd0cbd36df708c05fccc
  • 505e75ba28b42bb3de7a6d55de825091b70cc2b2
  • 13c88d62a09c152983abc99d989bb077fa987acb
  • d0a10e530823d6d8eff31ef164eee9ba2fb71c63
  • 8538f3d5109c548049c344fa042684d9d40f04d6
  • 2fd5864ac8eb2c4cfa0fafe7c0431a74f2ebe1fb
  • 4f3fd1fb264a7eaf3a9d062d49e071b0d17e4deb
  • 45f75fc8e98092fa48faa3d180fd42f7efd51486
  • 1a79825cfbbd26ef12ad085487247e5adf4d657d
  • 28f9836c888ce351400f8d1fd42eac905ce99f1d
  • 2aae75b167f1d9d5cf65d5529c585cfb18c6207b
  • c0dc67f92a4abee6bcce304117bf2a2362ad812c
  • 532eb49e129bedf57cdbd0a66f39ad228b8f2482
  • 58d02e0d3d6d48c97fccdb2ad7212e065671ad6d
  • 3f2fa4c9290afdb393c760419a0ff686045a1ab3
  • 8be5e4497e5008f7807178acdfcbf97365ec4e73
  • c20a339d54b39120b4051f690ca759e6d079f177
  • a23919ed39d212f9f5694d9b103c84641fdb7680
  • aef21bb77289a61796436eff7a08f64480f813ce

resolution: => fixed
status: assigned => closed

One additional fix for endianness issues:
- 9fd2775fe1ced6ff6a9a3ff7db124fcb52dade5d

a day ago

Metadata Update from @myllynen:
- Issue assigned to sgallagh
- Issue set to the milestone: SSSD 1.9.0 beta 1

Login to comment on this ticket.

enhancement

LDAP Provider

master

0

1

https://bugzilla.redhat.com/show_bug.cgi?id=768168

swalter@redhat.com

cancel