RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 923808 - Wrong description for backend providers
Summary: Wrong description for backend providers
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: doc-Identity_Management_Guide
Version: 6.4
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Deon Ballard
QA Contact: Jenny Severance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-03-20 13:51 UTC by Thorsten Scherf
Modified: 2014-05-10 03:43 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-05-10 03:43:43 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)

Description Thorsten Scherf 2013-03-20 13:51:46 UTC 
Description of problem:
The following statement on page 378 chapter 20.1.1.2 is misleading:

"A domain in SSSD defines four backend functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use an identity provider to supply the information for any one (or all)
of those four functions."

This should be changed to:

"A domain in SSSD defines four backend functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use an backend provider to supply the information for any one (or all)
of those four functions. SSSD requires at least one identity provider. If no provider is specified for authentication, access and password change, SSSD uses the identity provider as default."



Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Dmitri Pal 2013-03-20 15:57:26 UTC 
May be like this?

"A domain in SSSD defines four backend functions: authentication, identity lookups, access, and password changes. The SSSD domain is then configured to use a backend provider to supply the information for any one (or all)
of those four functions. SSSD requires at least the identity provider to be specified for a domain. If no provider is specified for authentication, access and password change, SSSD uses the identity provider value to determine how other functions should be provided. For example, if identity provider value is 'ldap' other functions will be configured assuming they are provided by the same LDAP server as the identity provider, if identity provider is 'ipa' other functions will be configured assuming they are provided by the same IdM server, etc."

I wonder whether this applies to AD provider.
I hope so. But what is the access provider for AD? It is same as with LDAP, right?
Comment 2 Jakub Hrozek 2013-03-20 17:04:02 UTC 
(In reply to comment #1)
> I hope so. But what is the access provider for AD? It is same as with LDAP,
> right?

acess_provider=ad expands to:

access_provider=ldap
ldap_access_order = expire
ldap_account_expire_policy = ad
Comment 3 Dmitri Pal 2013-03-20 19:24:44 UTC 
Then we should probably have a table of the defaults.

Something like:

If only identity provider is specified other back end provider settings are assumed based on the following table:

Identity Provider   Authentication  Access provider  Password Change
ad                     ...          <Jakub's reply>      ...
ipa                    ...               ...             ...
ldap                   ...               ...             ...

Makes sense?
... - need to be replaced with the actual defaults
Comment 4 Jakub Hrozek 2013-03-21 10:06:17 UTC 
For "bare" providers the situation is actually very simple, it's always the same value.

For "composite" providers like ipa or ad this table would make sense for the subchapters about the providers.
Comment 7 Deon Ballard 2014-05-10 03:43:43 UTC 
Mass closure of bugs modified in 2013. All of these are in the currently-published docs.
Note You need to log in before you can comment on or make changes to this bug.