#2078 [RFE] Support AD users from a trusted forest in sssd-ad provider
Closed: wontfix 4 years ago by pbrezina. Opened 10 years ago by dpal.

Use case:

- AD forests A, B
- Forests are in trust relationship
- Linux system is joined into forest A using sssd-ad
- Users from root and subdomains of the B should be able to log in into the system using SSSD and their identity and group membership should be resolvable.

The feature should support both cases:
- No POSIX attributes in AD - user POSIX IDs are mapped on the fly
- Leverage POSIX attributes from AD


Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.13 beta
rhbz: => todo

Fields changed

mark: => 1

Fields changed

milestone: SSSD 1.13 beta => SSSD 1.13 backlog

Mass-moving tickets not planned for the 1.13 release to 1.14

milestone: SSSD 1.13 backlog => SSSD 1.14 beta

This needs cooperation with winbind which won't happen in the next couple of months.

milestone: SSSD 1.14 beta => SSSD 1.15 beta
sensitive: => 0

Metadata Update from @dpal:
- Issue set to the milestone: SSSD Future releases (no date set yet)

7 years ago

Hello,
Are we able to seek colab with winbind, it's around a year now..
Thanks

Is there a recommended workaround to resolve this use case? Or do all machines and all users have to be members of both domains in the example, Domain A and Domain B?

Yes, that's one way. The other is to use IDM and establish trust against both domains. And of course another way is to use winbind..

Metadata Update from @jhrozek:
- Custom field design_review reset (from 0)
- Custom field mark adjusted to on (was: 1)
- Custom field patch reset (from 0)
- Custom field review reset (from 0)
- Custom field sensitive reset (from 0)
- Custom field testsupdated reset (from 0)
- Issue close_status updated to: None

6 years ago

Are there any plans to work on this issue? The current workarounds wont work for me due to security issues(both domains) and infrastructure changes(IPA).

I am also curious if and when there are plans to address this. Cross domain trusts are very common in scenarios where companies acquire other companies or in our case our Architects decided to create an entirely separate resource domain for the Cloud.

Thank You

Currently nobody is working on this and frankly I don't think anybody will in the near future. The options outside SSSD are either IPA with trusts or winbind.

Metadata Update from @jhrozek:
- Custom field design_review reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

5 years ago

I am also curious if and when there are plans to address this. Cross domain trusts are very common in scenarios where companies acquire other companies or in our case our Architects decided to create an entirely separate resource domain for the Cloud.
Thank You

FWIW, my solution/workaround was to use Centrify Express in place of SSSD. This was on Ubuntu 14.04. Centos/RedHat systems may have better SSSD implementations, not sure.

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: bugzilla

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)
- Issue tagged with: Canditate to close

4 years ago

Metadata Update from @thalman:
- Custom field design_review reset (from false)
- Custom field patch reset (from false)
- Custom field review reset (from false)
- Custom field sensitive reset (from false)
- Custom field testsupdated reset (from false)

4 years ago

Thank you for taking time to submit this request for SSSD. Unfortunately this issue was not given priority and the team lacks the capacity to work on it at this time.

Given that we are unable to fulfill this request I am closing the issue as wontfix.

If the issue still persist on recent SSSD you can request re-consideration of this decision by reopening this issue. Please provide additional technical details about its importance to you.

Thank you for understanding.

Metadata Update from @pbrezina:
- Issue close_status updated to: wontfix
- Issue status updated to: Closed (was: Open)

4 years ago

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/3120

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.

Login to comment on this ticket.

Metadata