Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
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.
DescriptionWaldirio M Pinheiro
2023-02-17 03:36:50 UTC
Description of problem:
When adding attributes in sssd.conf that we have already, the cross-forest query just stop working.
For example, when adding the entry below
---
[nss]
user_attributes=+mail, +sn, +givenname
[domain/EXAMPLE]
ldap_user_extra_attrs=mail, sn, givenname
---
The mail attribute will cause issues on idm side and as consequence, all the users with email on AD will not be available to query anymore. For example, "id user1", it will return user not available. However, when checking for an user that has no email, administrator for example, the response will be there.
Version-Release number of selected component (if applicable):
IPA, version: 4.9.10
How reproducible:
100%
Steps to Reproduce:
1. Install idm
2. Install ad
3. Create the cross-forest trust
4. do the query "id user", assuming that @acme.local it's from AD. The response should be ok
5. Change the sssd.conf and add the entry as below, after cleanup the cache and restart sssd
---
[nss]
user_attributes=+mail, +sn, +givenname
[domain/EXAMPLE]
ldap_user_extra_attrs=mail, sn, givenname
---
Actual results:
the field mail causes some issues in sssd logs and also remove the ability to query any user that has email on AD
Expected results:
only cause an alert and everything keep working as expected.
Additional info:
Comment 1Alexander Bokovoy
2023-02-17 07:30:31 UTC
Move to SSSD.
Please also attach SSSD logs that demonstrate your problem.
Hi,
this sounds a bit like to old https://bugzilla.redhat.com/show_bug.cgi?id=1362023.
As Alexander said, please provide SSSD debug logs with 'debug_level=9' in the [pam], [nss], [ifp] and [domain/...] sections from the IPA client and IPA server. The logs in the case are not consistent. But what I'VE seen so far from the latest client logs:
- it looks like 'full_name_format = %1$s' is still used on the IPA server, this is not supported.
- there seem to be a disconnect with the attribute names, on the client they are stored as givenname, sn and mail in the cache but looked up as 'user_attributes=+firstname, +lastname, +email'. Please note that the client gets all user attributes including the attribute names from the IPA server and the ldap_user_extra_attrs option is only used on the IPA server and has no effect on the IPA client.
HTH
bye,
Sumit
Quote from a private comment by Sumit:
```
the IPA server is sending the 'mail' attribute twice to the client and the client does not check for duplicates and failed to store the data in the cache.
To fix this we can either make sure that the server only sends each attribute once or let the client check for duplicates or both.
Since it might be better to spend the time once on the server instead of on each client it might be best to fix the server side first.
One way to fix it on the server is to replace add_strings_lists() in sss_nss_cmd_getorigbyname_common() by something which checks the strings are unique in the resulting list. Btw, since 'nss_ctx->extra_attributes' cannot change at runtime it might be a small optimization to merge 'defattrs' and 'nss_ctx->extra_attributes' only once when sss_nss_cmd_getorigbyname_common() is called first and store the result in the nss context.
```
Pushed PR: https://github.com/SSSD/sssd/pull/6759
* `master`
* b50415978d2f0fad3291d86e0a5340be7ab90528 - IPA: Do not duplicate the entry attributes.
* de258f011b9c6fc97e9157435cd2845be1c5d0e0 - RESPONDER: attr_in_list() is replaced by string_in_list_size()
* 2b8fed59140e32f7a8fa9bafe9e84b8db96d1ae5 - UTIL: add_strings_lists() becomes add_strings_lists_ex()
* 1b45f29f459f13173af99e75b4bb43ed945680aa - UTIL: New function string_in_list_size()
* dc508f032904f008714418509a13f79a17660659 - IPA: Do not try to add duplicate values to the LDAP attributes
* ca7c9f6066d150c1a88bda6bda2843f244e5289d - TEST: Fix pam-srv-tests to correctly treat the test name
* `sssd-2-9`
* 355b0c2e89606a0db1697b232743f50a2e60ee57 - IPA: Do not duplicate the entry attributes.
* bfc88dc3c637eb5ceaba5345f779d560ff9c81c8 - RESPONDER: attr_in_list() is replaced by string_in_list_size()
* 010e61ffa0da1d58470cea9d5c506a117755bf62 - UTIL: add_strings_lists() becomes add_strings_lists_ex()
* 42cf3c41c566cfca61397139cad079dd6d1e151c - UTIL: New function string_in_list_size()
* 228183bf4a9ea93d6f6a97801646887a0491a944 - IPA: Do not try to add duplicate values to the LDAP attributes
* 50922242888b5f4d5b41f9c3549df45dc975dad1 - TEST: Fix pam-srv-tests to correctly treat the test name
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (sssd bug fix and enhancement update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHBA-2023:7127