Learn more about these different git repos.
Other Git URLs
Current iteration of the Winbind backend allows defining "idmap backend" and configures "idmap uid" and "idmap gid" based on the administrator provided id ranges.
However, the syntax is slightly different what is being suggested in the manual pages and if more than one domains are using Winbind then there might be issues with the current approach. idmap_rid(8) has an example how to configure rid properly for several domains:
workgroup = MAIN idmap backend = tdb idmap uid = 1000000-1999999 idmap gid = 1000000-1999999 idmap config MAIN : backend = rid idmap config MAIN : range = 10000 - 49999 idmap config TRUSTED : backend = rid idmap config TRUSTED : range = 50000 - 99999
Also if using idmap_ad then you might also want to set the winbind nss info option.
There was some discussion related this in the mailing list, particularly related idmap_tdb and idmap_rid. From https://fedorahosted.org/pipermail/sssd-devel/2011-November/007645.html:
It seems that if one doesn't explicitly set non-default idmap backend then the tdb backend will get used meaning that users in a domain will get different uids on different systems using the SSSD/Winbind backend. And the current configuration file being generated by SSSD for the winbind daemon does not include any domain specific configuration for the id mappings. So if an organization has two AD domains like PROD and TEST (a rather common case when preparing for a DC update, e.g., PROD is AD 2003 and TEST is for AD 2008 testing), how can one configure the backend to be used with both of these domains if IdM for UNIX is not in use?
If needed please feel free to split this ticket into separate ones for each of the items mentioned in the comments here.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.8.0
milestone: SSSD 1.8.0 => NEEDS_TRIAGE
milestone: NEEDS_TRIAGE => SSSD 1.8 AD Integration NEEDS TRIAGE
milestone: SSSD 1.8 AD Integration NEEDS TRIAGE => SSSD Deferred
rhbz: => 0
Since we dropped the winbind provider this ticket is not applicable any more.
blockedby: => blocking: => feature_milestone: => proposed_priority: => Undefined resolution: => wontfix status: new => closed
Metadata Update from @myllynen: - Issue set to the milestone: SSSD Patches welcome
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/2137
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.